Algo salió mal es un mensaje frecuente y poco útil. No explica si la solicitud se recibió, si el dato está incorrecto ni si volver a intentar puede duplicar una operación. Los mensajes forman parte del funcionamiento de una herramienta, no son un detalle final de redacción. Para escribirlos bien necesitas conocer el estado real del proceso y las opciones disponibles. Un buen mensaje permite continuar o pedir ayuda con contexto. También debe poder percibirse sin depender exclusivamente de un color, una animación o una notificación que desaparece demasiado rápido.
Clasifica el problema antes de escribir el texto
Separa datos que el usuario puede corregir, permisos que requieren otra persona, interrupciones temporales y operaciones cuyo resultado aún se está verificando. Cada grupo necesita una respuesta distinta. Si falta un campo, señala cuál; si el proveedor está temporalmente inaccesible, no pidas modificar información correcta. Evita presentar una certeza cuando el estado es desconocido. El equipo de diseño y desarrollo debe acordar qué evidencia activa cada mensaje. Un texto tranquilizador no puede sustituir una confirmación que el sistema todavía no tiene ni prometer que ningún dato se perdió sin comprobarlo.
Combina explicación y siguiente paso
Escribe primero lo que ocurrió en términos del negocio y luego la acción disponible. Mantén el texto breve, pero suficiente para decidir. Para problemas que requieren soporte, ofrece una referencia técnica que no revele información sensible. Si se permite reintentar, aclara cuándo tiene sentido. No uses reintentar como salida universal para una operación que puede haberse completado. Cuando el usuario no pueda hacer nada, informa cómo se dará seguimiento o qué alternativa existe. El mensaje debe reducir incertidumbre, no trasladar al cliente la tarea de diagnosticar el sistema.
Haz perceptible el estado sin interrumpir de más
W3C explica que los mensajes de estado deben poder ser determinados por tecnologías de asistencia sin requerir necesariamente un cambio de foco. En la práctica, una confirmación visual necesita también una implementación que la haga disponible a quien utiliza otra forma de acceso. Decide cuáles mensajes deben permanecer y cuáles pueden ser discretos. Evita que una confirmación importante desaparezca antes de poder leerla. Los avisos repetidos pueden convertirse en ruido, especialmente durante operaciones frecuentes; agrupa información cuando conserve claridad y no oculte fallos que requieren intervención.
Revisa mensajes dentro del recorrido completo
Prueba éxito, error, espera y recuperación con datos ficticios. Comprueba si el formulario conserva el trabajo, si el foco queda en un lugar útil y si la acción sugerida realmente resuelve el problema. Invita a alguien que no conoce la implementación a explicar qué entiende y qué haría después. Mantén un inventario de mensajes junto a las reglas que los producen. Cuando cambie una integración o un proceso, revisa también su texto. Un mensaje correcto en una versión anterior puede volverse engañoso si el comportamiento cambia y la redacción queda olvidada.
DE LA LECTURA A LA ACCIÓN
Para aplicar hoy
- Distingue errores corregibles, fallos temporales y resultados inciertos.
- Ofrece un siguiente paso real y conserva el contexto del usuario.
- Prueba la percepción del mensaje y la recuperación, además de su redacción.
Fuentes y referencias
Documentación para profundizar. Los ejemplos de esta guía son didácticos.