Cada formulario de tu app es un lugar donde los usuarios pueden perder trabajo o rendirse. Ejecuta esta lista en cada formulario (registro, perfil, pago, feedback). Usa un dispositivo real y el teclado real.
La checklist
- Envío vacío. - Por qué: es el error más común. - Cómo comprobarlo: toca enviar con todos los campos vacíos. Cada campo obligatorio muestra un mensaje claro; nada se cae.
- Se marca qué es obligatorio y qué no. - Por qué: los usuarios no deberían descubrirlo fallando. - Cómo comprobarlo: lee el formulario antes de escribir. ¿Se ve claro qué campos son obligatorios?
- Entrada muy larga. - Por qué: el texto largo puede romper diseños, superar límites del servidor o cortarse en silencio. - Cómo comprobarlo: pega varios miles de caracteres en cada campo de texto. La app muestra un límite o lo gestiona, y el diseño se mantiene.
- Solo espacios y espacios al inicio o al final. - Por qué: " " pasa la comprobación de "no vacío", y un espacio al final rompe la comparación de emails o nombres de usuario. - Cómo comprobarlo: escribe solo espacios, y luego un valor válido con espacios alrededor. Debe rechazarse o recortarse.
- Caracteres especiales y Unicode. - Por qué: los nombres con tildes, apóstrofos, escrituras no latinas y emojis son entradas normales. - Cómo comprobarlo: prueba nombres como O'Brien, Zoë, 李雷, una cadena con direcciones mixtas y un emoji. Se aceptan, se guardan y se muestran sin cambios.
- Texto pegado. - Por qué: el texto pegado suele traer espacios ocultos, saltos de línea o un formato distinto. - Cómo comprobarlo: pega un email con un salto de línea al final, un teléfono con espacios o guiones, una contraseña de un gestor. El formulario lo acepta o indica exactamente qué está mal.
- Las reglas de formato coinciden con datos reales. - Por qué: reglas de email, teléfono o código postal demasiado estrictas rechazan a usuarios válidos. - Cómo comprobarlo: prueba una dirección con alias (name+tag@example.com), un TLD largo, un teléfono internacional y un código postal de otro país si lo soportas.
- Números y fechas. - Por qué: la coma decimal frente al punto, los valores negativos y las fechas imposibles generan datos incorrectos. - Cómo comprobarlo: escribe 1,5 y 1.5, 0, -1, un número muy grande y el 31 de febrero. Cambia la región del dispositivo y repite.
- Los errores aparecen junto al campo. - Por qué: un único error arriba obliga a buscarlo. - Cómo comprobarlo: envía datos inválidos; cada mensaje está junto a su campo, el primer error se desplaza a la vista y el teclado no lo tapa.
- Los mensajes dicen cómo corregirlo.
- Por qué: "Entrada no válida" no da nada con lo que actuar.
- Cómo comprobarlo: lee cada mensaje. Debe nombrar el problema y el formato esperado.
- Lo introducido se mantiene tras un error.
- Por qué: borrar un formulario largo al fallar hace que la gente se vaya.
- Cómo comprobarlo: haz fallar la validación o la red una vez. Todas las entradas válidas siguen ahí, salvo las sensibles como contraseñas, si las borras a propósito.
- El momento de validar es razonable.
- Por qué: los errores mientras el usuario todavía escribe molestan.
- Cómo comprobarlo: escribe un email válido despacio. No aparece ningún error hasta que sales del campo o envías.
- Se bloquea el doble envío.
- Por qué: dos toques pueden crear dos registros o dos cargos.
- Cómo comprobarlo: toca enviar varias veces seguidas, también con una conexión lenta. Solo pasa una petición.
- El teclado y el autocompletado encajan con el campo.
- Por qué: un tipo de teclado incorrecto dificulta la escritura, y el autocompletado ahorra tiempo.
- Cómo comprobarlo: el campo de email muestra teclado de email, el de número un teclado numérico, los botones siguiente y listo mueven el foco, y el gestor de contraseñas rellena.
- Se gestiona el rechazo del servidor.
- Por qué: el servidor puede rechazar lo que la app aceptó.
- Cómo comprobarlo: si puedes, haz que el backend devuelva un error de validación. La app lo muestra en el campo correcto.
- El lector de pantalla lee los errores.
- Por qué: si no, los usuarios ciegos no saben qué falló.
- Cómo comprobarlo: activa el lector de pantalla y envía datos inválidos; el error se anuncia. Mira prueba de lector de pantalla en 10 minutos.
Relacionados
Volver a todas las checklists · Checklist de estados de error · Checklist de estados vacíos
Un par de ojos nuevos encuentra el formulario que rechaza un nombre perfectamente válido. Empieza gratis: feedback privado y estructurado, 1 feedback = 1 crédito.