Patrones de estados de error: qué mostrar cuando algo sale mal
Los estados de error son las pantallas y mensajes que aparecen cuando algo falla. Patrones para validación, fallos de sistema y recuperación, según WCAG y NN/g.
¿Qué tipos de error existen?
No todos los errores son iguales, y cada tipo pide un patrón distinto. Conviene separarlos antes de diseñar:
| Tipo | Ejemplo | Dónde aparece | Qué debe permitir |
|---|---|---|---|
| Validación | Un email sin arroba | Junto al campo | Corregir el dato y seguir |
| Acción fallida | “No se pudo guardar el borrador” | Cerca de la acción o en un aviso | Reintentar |
| Sin datos por error | La búsqueda o la carga devuelve vacío por un fallo | En la zona de contenido | Reintentar o cambiar de camino |
| Fallo del sistema | Error 500 en toda la página | Página completa | Volver, avisar o esperar |
| Permisos | No tienes acceso a este recurso | Página o sección | Pedir acceso o salir |
La regla práctica es esta: cuanto más amplio el error, más amplio el espacio que ocupa el mensaje. Un campo mal escrito no merece una página de error.
¿Cómo se diseña el mensaje de error?
NN/g define un mensaje de error como una interrupción generada por el sistema que informa al usuario de una situación incompleta, incompatible o no deseada. Su guía de 2023 (Tim Neusesser y Evan Sunwall) propone varias reglas que se pueden aplicar en cualquier pantalla:
- Cerca del origen. Muestra el mensaje junto al elemento que falla. NN/g lo dice de forma directa: el mensaje debe estar cerca de la fuente del error.
- No dependas solo del color. Usa texto, y si quieres, un icono y un borde. NN/g elogia a Amazon por combinar borde resaltado, iconografía y texto rojo.
- Sin prisa. NN/g pide evitar mostrar errores de forma prematura: dejar un campo vacío mientras se explora no es un error. La guía en tiempo real tiene sentido en campos propensos a fallos, como las contraseñas.
- Tono neutro. Evita palabras como “inválido”, “ilegal” o “incorrecto”, que según NN/g sugieren culpa del usuario.
- Ofrece una salida. Decir cuál es el problema no basta. Propón un camino: el formato esperado, un valor de la lista o una acción.
- Conserva lo que el usuario escribió. Borrar el formulario después de un error es la forma más rápida de que alguien abandone.
El criterio de WCAG 3.3.1 (Error Identification, nivel A) va en la misma dirección: el usuario debe saber que hay un error y cuál es, y ese error debe describirse en texto. Según la explicación oficial del W3C, no basta con volver a mostrar el formulario sin indicar que el envío falló.
¿Cómo escribir la sugerencia de corrección?
El criterio 3.3.3 (Error Suggestion, nivel AA) pide ofrecer sugerencias cuando se detecta un error y se conoce la forma de corregirlo. La diferencia se entiende con dos versiones, ilustrativas, del mismo mensaje:
- “Email no válido”: identifica el error, así que apunta a 3.3.1.
- “Escribe una dirección con el formato nombre@dominio.com”: además indica cómo corregirlo, que es lo que pide 3.3.3.
Si el usuario escribe “12” en un campo que pide el nombre del mes, el W3C sugiere listar los nombres aceptados o interpretar la entrada y preguntar “¿Quisiste decir diciembre?”. En un formulario de dirección, si la ciudad y el código postal no coinciden, NN/g propone no limitarse a decir que no coinciden, sino ofrecer un botón con la ciudad que corresponde al código escrito.
El criterio tiene una excepción: no se exige la sugerencia si comprometería la seguridad o el propósito del contenido. Un caso típico es un inicio de sesión, donde decir cuál de los dos datos falló puede ayudar a un atacante; ahí basta un mensaje general sobre las credenciales, con un camino para recuperarlas.
¿Cómo se diseña un fallo de sistema?
Cuando la página entera no carga, el mensaje tiene que hacer tres cosas: decir qué pasó sin tecnicismos, dar una acción concreta y no dejar al usuario en un callejón sin salida. La regla de NN/g que mejor encaja aquí es que no basta con decir cuál es el problema: hay que sugerir remedios.
Un patrón sólido tiene esta estructura:
- Qué pasó, en una frase.
- Qué puede hacer el usuario: reintentar, volver, guardar lo que tiene.
- Qué hace el sistema: “Reintentando automáticamente…” si es el caso.
- Un detalle técnico opcional, colapsado, con el código de error para soporte.
Si el error es de validación, el momento en que lo muestras cambia la experiencia: mira el timing de validación de formularios. Para escribir el texto con cuidado, lee cómo escribir mensajes de error. Para prevenir errores antes de que ocurran, lee prevención frente a recuperación de errores. Para los estados de carga que preceden a un error, mira estados de carga. Y si el fallo ocurre por una acción irreversible, como borrar, conviene revisar las salvaguardas para acciones destructivas antes de diseñar el mensaje.
Ejemplo
Ejemplo ilustrativo: un formulario de reserva con cuatro campos. Al enviar, el campo de teléfono tiene un formato incorrecto. El mensaje aparece debajo del campo con texto, un borde rojo y el formato esperado: “Escribe 10 dígitos, por ejemplo 0991234567”. Los demás datos siguen en el formulario. El botón de enviar se mantiene activo y el foco se mueve al campo con error, para que quien usa lector de pantalla lo escuche.
Un ejercicio para mañana: revisa los errores de tu producto y clasifícalos con la tabla de arriba. Si hay un mensaje de “Algo salió mal” que sirve para tres tipos distintos de fallo, ya tienes un problema para corregir.
Errores comunes
- Usar un mensaje genérico (“Error 400”) para todo tipo de fallo.
- Mostrar el error solo en color, sin texto: NN/g advierte que nunca se use solo color o animación para indicar errores.
- Poner el mensaje lejos del problema, por ejemplo solo arriba del formulario.
- Culpar al usuario con palabras como “incorrecto” o “inválido”.
- Mostrar errores antes de tiempo, mientras el usuario todavía escribe.
- Dejar un callejón sin salida: un error sin botón, sin enlace y sin explicación.
- Borrar lo que el usuario escribió al producirse el error.
- Usar modales para cualquier error. NN/g reserva los modales para errores graves que bloquean el avance; para un fallo menor, un banner o un aviso discreto suele bastar.