Un mensaje de error aparece cuando una persona intenta completar una tarea y algo se lo impide. Si solo anuncia que hubo un problema, deja al usuario sin saber si debe corregir un dato, esperar, volver a intentarlo o pedir ayuda. Para producto y tecnología, el objetivo no es adornar el fallo: es ayudar a decidir el siguiente paso y evitar que la persona pierda su trabajo o repita una acción con consecuencias.
Diseñar mensajes útiles requiere conocer el origen del error, la información que todavía está disponible y las opciones de recuperación. También exige coordinar el texto con el comportamiento real de la aplicación. Una instrucción como «Inténtalo de nuevo» es perjudicial si la operación ya se completó o si repetirla puede crear un duplicado.
Clasifica el error antes de redactarlo
Empieza por identificar qué impide completar la tarea y quién puede resolverlo. Esta clasificación ayuda a elegir tanto el contenido como la acción disponible:
- Error corregible por la persona: falta un campo obligatorio, el formato de un dato no es válido o una selección no cumple una condición. Explica qué hay que revisar y señala el campo concreto.
- Problema temporal del sistema: la aplicación no puede completar una operación por una incidencia o una condición transitoria. Indica si conviene esperar o reintentar y qué ocurrirá con los datos.
- Dependencia externa: un servicio conectado no responde o rechaza la solicitud. No atribuyas la causa al usuario ni prometas cuándo se resolverá. Comunica lo que la aplicación sabe y ofrece una alternativa viable.
- Situación que requiere asistencia: la persona no puede resolver el bloqueo desde la interfaz, o el caso exige una comprobación. Indica cómo contactar con soporte y qué información útil debe aportar.
No es necesario exponer la arquitectura técnica para hacer esta distinción. Sí es necesario acordar con desarrollo qué estado recibió la operación, si se guardaron cambios y si repetirla es seguro. Sin esa información, el equipo de contenido no puede ofrecer instrucciones fiables.
Incluye causa comprensible, impacto y siguiente paso
Un mensaje práctico responde, en lenguaje cotidiano, a tres preguntas: qué ocurrió, qué implica y qué puede hacer ahora. Si la información es relevante, añade si los datos se conservaron. No hace falta explicar todos los detalles internos; basta con ofrecer contexto suficiente para que la persona actúe.
Por ejemplo, «No se pudo guardar el formulario porque falta el teléfono. Añade un número en el campo Teléfono y vuelve a guardar» identifica el resultado, el motivo y la corrección. En cambio, «Error al procesar la solicitud» no indica dónde intervenir. Para un problema temporal, una formulación como «No pudimos cargar tus resultados. Tus filtros siguen disponibles; vuelve a intentarlo» ayuda solo si la interfaz realmente conserva esos filtros.
Comprueba cada texto contra el estado real del producto. Si no puedes confirmar que los datos se guardaron, no digas que están a salvo. Si no conoces la causa, no la inventes: comunica el resultado y una acción segura. Es preferible una explicación limitada y exacta a una promesa tranquilizadora que la aplicación no puede cumplir.
Elige una recuperación que no empeore el problema
La acción propuesta debe corresponder al tipo de fallo y a las consecuencias de repetir la operación. Antes de mostrar un botón o una instrucción, responde estas preguntas:
- ¿Puede la persona corregirlo? Si sí, dirige la atención al campo o la decisión que requiere cambios y conserva lo demás cuando sea posible.
- ¿Es seguro reintentar? Si la operación puede haberse completado aunque la interfaz no lo confirme, no ofrezcas un reintento a ciegas. Verifica el estado o explica cómo comprobarlo.
- ¿Se puede continuar por otra vía? Si existe una alternativa funcional, como guardar un borrador o completar el proceso más tarde, hazla visible sin ocultar la opción principal.
- ¿Hace falta soporte? Indica un canal disponible y, si resulta útil, un identificador de referencia. No conviertas el contacto en la única salida cuando la persona puede resolver el problema por sí misma.
En operaciones sensibles —por ejemplo, enviar un pedido, realizar un pago o publicar contenido— acuerda con desarrollo cómo se confirma el resultado y cómo se evita repetir acciones. El mensaje visible debe reflejar ese comportamiento; el texto por sí solo no puede garantizar que una operación sea segura.
Redacta con claridad y sin culpar
Escribe para la persona que intenta completar una tarea, no para quien depura el sistema. Evita códigos internos, nombres de componentes y expresiones como «solicitud inválida» si no explican qué corregir. Un código puede ser útil para soporte, pero debe acompañar una explicación comprensible, no sustituirla.
Usa una voz directa y neutral. «No pudimos validar la dirección» describe el resultado sin acusar. «Has introducido mal la dirección» atribuye el fallo a la persona y puede ser incorrecto: quizá el formato esperado no está claro. Evita también instrucciones vagas como «Revisa tus datos» cuando puedes señalar qué dato necesita atención.
La brevedad ayuda, pero no a costa de omitir una consecuencia importante. Si se borró una respuesta, si el proceso sigue pendiente o si la persona puede reintentarlo sin duplicar nada, dilo. Cuando no sepas cuál de esas situaciones aplica, detén la redacción y pide al equipo técnico una definición del estado.
Haz que el mensaje se perciba y pueda usarse
El texto debe aparecer cerca del elemento afectado o en un lugar coherente con el alcance del problema. Un error de campo suele ser más útil junto al campo que en un aviso distante. Si la tarea completa quedó bloqueada, un mensaje general puede explicar la situación y ofrecer una acción principal. Evita depender únicamente del color para comunicar que algo falló: acompáñalo con texto identificable.
Comprueba que el mensaje se entienda con teclado y tecnologías de asistencia, y que una persona pueda localizar el campo relacionado sin adivinar. En formularios, revisa si el error sigue visible al corregir el dato y si el foco o la navegación permiten continuar. La accesibilidad no se resuelve con una frase correcta si el aviso no llega a quien lo necesita.
También importa el momento: un aviso que desaparece antes de poder leerse, o que se muestra antes de que la persona termine de escribir, puede aumentar la confusión. Valida el comportamiento en la interfaz real y en los estados relevantes, no solo el texto en un documento.
Documenta y valida una matriz de errores
Para evitar respuestas distintas ante el mismo fallo, crea una matriz compartida entre producto, diseño, desarrollo y atención al cliente. Incluye al menos:
- Nombre del estado y origen conocido del problema.
- Tarea que estaba realizando la persona y alcance del impacto.
- Datos conservados, descartados o pendientes de confirmar.
- Texto visible, ubicación y acción disponible.
- Responsable de confirmar el comportamiento y criterio para escalar a soporte.
Prioriza los errores que bloquean tareas importantes, pueden causar pérdida de datos o generan consultas repetidas. Prueba los mensajes con tareas reales: observa si la persona entiende qué ocurrió, encuentra el siguiente paso y logra continuar sin instrucciones externas. Registra dónde abandona o vuelve a intentarlo, junto con las consultas recibidas por soporte, y contrasta esos indicios antes y después de los cambios. Una disminución de consultas por sí sola no demuestra que el problema esté resuelto: puede significar que las personas dejaron de intentar completar la tarea.
Revisa la matriz cuando cambie el flujo, las dependencias o la lógica de guardado. La calidad de un mensaje no se mide por lo amable que suena, sino por si describe con precisión el estado y permite actuar. Cuando el producto no conoce todavía el resultado, la mejor decisión puede ser evitar un reintento automático, explicar la incertidumbre y ofrecer una vía segura de comprobación o asistencia.