Cómo escribir mensajes de error que ayuden a corregir
Un buen mensaje de error dice qué pasó, dónde y cómo corregirlo, sin culpar a la persona. Reglas del NN/g y la heurística 9 de Nielsen, con ejemplos.
¿Por qué importan tanto las palabras?
Porque en el momento del error la persona está atorada. Quiere terminar algo y el sistema le dice que no puede. Si el mensaje es vago, la persona no sabe qué cambiar y tiende a abandonar o a probar al azar. Nielsen lo expresa en su heurística de ayudar a reconocer, diagnosticar y recuperarse de los errores, que incluye los mensajes entre sus puntos centrales (NN/g: 10 Usability Heuristics).
Esa heurística pide que los mensajes estén en lenguaje claro, sin códigos de error, que indiquen con precisión el problema y que sugieran de forma constructiva una solución. Las tres partes importan, y un mensaje que solo cumple una de ellas sigue fallando.
¿Qué dice el NN/g sobre cómo escribirlos?
El NN/g publica una guía específica para mensajes de error (NN/g: Error-Message Guidelines). Sus reglas más útiles son estas:
- Muéstralos cerca de su origen, con indicadores visibles y redundantes. Nunca uses solo el color ni solo una animación.
- No los adelantes. No tomes como error que alguien salga de un campo vacío, pero sí ofrece ayuda en tiempo real para entradas propensas a errores, como una contraseña.
- Usa lenguaje sencillo y evita mensajes genéricos como «Ocurrió un error».
- Ofrece remedios, no solo el problema. Y evita palabras que culpen, como «inválido», «ilegal» o «incorrecto».
- Conserva lo que escribió la persona, para que corrija en lugar de reiniciar. Cuando sea posible, adivina la corrección y ofrécela como opción.
- Evita el humor en los errores.
El NN/g reserva los cuadros de diálogo modales para errores graves. En la mayoría de los casos, el mensaje debe quedarse junto al campo.
¿Qué pasos sigue un buen mensaje?
Jakob Nielsen propone cinco pasos prácticos para el mensaje (UX Tigers: Heuristic 9):
- Lenguaje sencillo.
- Diagnóstico y ubicación: decir qué salió mal y dónde.
- Solución accionable.
- Visibilidad y tono: el color y la forma deben llamar la atención sin alarmar de más.
- Recuperación: una vía clara para seguir adelante, como reintentar, corregir o pedir ayuda.
Nielsen cita un ejemplo claro: «Entrada inválida. Inténtalo de nuevo» es un mal mensaje, porque no dice qué falló. «Tu tarjeta fue rechazada» con posibles causas es mejor, porque informa y sugiere qué revisar.
Ejemplos: malo y bueno
| Malo | Bueno | Por qué mejora |
|---|---|---|
| Entrada inválida | Escribe tu código postal con cinco números | Dice qué falta y cómo corregirlo |
| Ocurrió un error | No pudimos guardar tus cambios. Revisa tu conexión e inténtalo de nuevo | Explica el problema y la acción |
| Contraseña inválida | La contraseña debe tener al menos un número | Dice la regla, no culpa |
| Campo obligatorio | Escribe tu apellido | Frase concreta y accionable |
Nota que las frases buenas no usan «por favor» ni «lo sentimos». GOV.UK Design System recomienda evitarlos y escribir el mensaje con la acción directa, como «Escribe tu nombre» (GOV.UK Design System: Error message).
¿Cómo se relacionan el color y el tono?
Aquí las fuentes no coinciden del todo. El NN/g recomienda los indicadores convencionales, como texto y resaltados rojos, en negrita y de alto contraste, siempre con indicadores redundantes, como un icono. Nielsen, en su artículo de heurística 9, prefiere advertencias amarillas sobre alertas rojas en algunos casos. Ambas posturas coinciden en lo esencial: el error debe verse, y la persona debe entender qué hacer. Elige el color que tu sistema ya usa para errores y respáldalo con un icono y una frase.
¿Cuándo NO conviene un mensaje de error?
- Cuando el problema se puede evitar. Si una fecha no puede ser futura, un selector de calendario que no permite elegir una fecha inválida es mejor que un mensaje que la rechaza. El NN/g y la heurística de prevención de errores recomiendan prevenir antes de corregir.
- Cuando el error no es de la persona. Si el servicio está caído, el mensaje debe decirlo y ofrecer una alternativa, no pedir que el usuario cambie algo.
- Cuando el mensaje solo tiene sentido para quien lo programó. Los códigos de error se pueden guardar para diagnóstico, pero no mostrarse como texto principal.
Para ver cuándo validar cada campo y evitar mensajes prematuros, lee timing de validación de formularios. Y para la diferencia entre prevenir y recuperarse, mira prevención vs. recuperación de errores.
Ejemplo ilustrativo
Ejemplo ilustrativo: una app de citas médicas muestra «Error 422» cuando una persona elige una hora ya ocupada. El equipo revisa las sesiones de usuarios y ve que la mayoría vuelve a elegir la misma hora. El nuevo mensaje dice «Esa hora ya no está disponible. Estas son las tres horas más cercanas», con tres botones y el resto de la agenda visible. El campo de fecha conserva la elección de la persona. El error sigue existiendo, pero ahora la persona sabe qué hacer en el siguiente segundo.
Si el error ocurre en un formulario, revisa también el diseño de formularios. Y para que el texto sea coherente con el resto de la app, el artículo de microcopy explica cómo escribir las palabras pequeñas que guían.
Errores comunes
- Mostrar «Algo salió mal» sin decir qué, ni dónde, ni qué hacer.
- Culpar a la persona con frases como «Ingresaste mal el dato».
- Borrar el formulario completo cuando hay un error.
- Usar solo color para señalar el campo con error.
- Poner el error en un lugar lejano de la pantalla, como arriba de una página larga.
- Escribir un mensaje de error técnico que nadie puede interpretar.
Qué puedes hacer mañana
- Abre tu producto, provoca tres errores comunes y copia exactamente lo que muestra cada uno.
- Reescribe cada mensaje con la fórmula: qué pasó, dónde, qué hacer.
- Verifica que el texto conserva lo que la persona escribió y que el error se ve sin depender del color.