Mensajes de error que ayudan: validación, tono y recuperación en webs y apps

Hace unos meses acompañé a mi madre a renovar una suscripción online. Rellenó el formulario con calma, pulsó «Enviar» y la página se recargó con un mensaje en rojo arriba del todo: «Error en los datos». Todos los campos estaban vacíos otra vez. No sabía qué había fallado, ni dónde, y había perdido lo escrito. Lo intentó una segunda vez, con el mismo resultado, y lo dejó para «otro día». Resultó que el problema era un espacio entre los números del teléfono.

Los errores van a ocurrir siempre: datos mal escritos, tarjetas caducadas, conexiones que se cortan, servidores que tardan. Lo que diseñamos no es un mundo sin errores, sino lo que pasa cuando aparecen. Y ahí hay una oportunidad preciosa: un error bien resuelto transmite que al otro lado hay alguien que ha pensado en ti, y eso genera más confianza que un proceso que nunca tropieza.

En esta guía repasamos cómo trabajamos los errores en el estudio: cómo prevenirlos, cuándo validar, cómo escribir el mensaje, cómo hacerlo accesible y cómo ayudar a recuperarse sin perder nada por el camino.

01Prevenir antes que corregir

El mejor mensaje de error es el que no hace falta mostrar. La quinta de las heurísticas de Nielsen habla precisamente de eso: diseñar para que los errores sean difíciles de cometer. En la práctica, muchas validaciones fallidas desaparecen con unos pocos cambios.

• →Acepta formatos variados. Un teléfono con espacios, guiones o prefijo; una fecha con barras o guiones; una tarjeta con o sin espacios. El sistema limpia el dato por dentro y la persona escribe como le sale natural.
• →Usa el control adecuado. Un selector de fecha en lugar de un campo libre, un desplegable de provincia en lugar de texto, un interruptor en lugar de «escriba sí o no».
• →Rellena lo que ya sabes. Con el código postal se puede proponer la ciudad; con el correo de una cuenta, no hace falta pedirlo otra vez.
• →Limita lo imposible. Si un hotel no admite reservas de más de 30 noches, el calendario no deja seleccionar la noche 31.
• →Pide confirmación antes de lo irreversible. Borrar, pagar o enviar algo que no se puede deshacer merece un paso de revisión.

Con WCAG 2.2 llegó además un criterio que va en esta línea: el 3.3.7, de entrada redundante, pide que no se obligue a volver a escribir información que la persona ya ha dado en el mismo proceso, salvo casos justificados.

02Validar en el momento justo

Cuándo aparece un error importa tanto como lo que dice. Validar demasiado pronto resulta impertinente; validar demasiado tarde obliga a volver atrás. Esta tabla resume las opciones:

El patrón que mejor funciona combina los momentos: se valida al salir del campo, y si había un error, se revalida mientras la persona lo corrige, para que el mensaje desaparezca justo cuando el dato pasa a ser válido. Es una forma de ser exigente tarde y generoso pronto: el aviso llega cuando ya se ha terminado de escribir y se retira en cuanto se arregla.

El resumen de errores en formularios largos

Cuando un formulario tiene muchos campos y se envía con varios errores, el sistema de diseño del gobierno británico, GOV.UK, propone un patrón muy probado: un recuadro al principio de la página titulado «Hay un problema», con la lista de errores enlazados a cada campo, y el foco del teclado movido a ese recuadro. Quien usa lector de pantalla lo escucha nada más enviar, y quien ve la pantalla puede saltar a cada campo con un clic.

03La anatomía de un buen mensaje de error

Un buen mensaje de error responde, en este orden, a dos preguntas: qué ha pasado y cómo se arregla. A veces añade una tercera, por qué, si ayuda a entender la solución. Todo en lenguaje de la persona y sin señalarla como culpable.

Algunas pautas que aplicamos siempre:

• →Específico. «Introduce una fecha de nacimiento anterior a hoy» en lugar de «Fecha no válida».
• →Orientado a la solución. Empezar por lo que hay que hacer suele funcionar mejor que describir el fallo.
• →Sin culpa. «La contraseña no coincide» en lugar de «Has introducido mal la contraseña».
• →Sin jerga. Nada de «Error 422», «campo nulo» o «formato inválido» como mensaje principal.
• →Breve. Una frase, dos como mucho. Si hace falta más, probablemente se puede prevenir el error.
• →Coherente con la etiqueta. Si el campo se llama «Teléfono móvil», el error habla de «teléfono móvil», no de «número de contacto».

Esta tabla recoge reescrituras reales que hemos hecho en auditorías:

Los principios de tono, voz y patrones de texto son los mismos que desarrollamos en la guía de UX writing; aquí los aplicamos al momento más delicado.

04Errores accesibles para todas las personas

Un error que no se percibe no ayuda. WCAG dedica varios criterios a este momento: el 3.3.1 pide identificar el error y describirlo en texto, el 3.3.3 pide sugerir la corrección cuando se conoce, y el 3.3.4 pide poder revisar, corregir o confirmar antes de enviar datos legales, financieros o importantes. A eso se suma el 1.4.1: el color no puede ser el único medio para comunicar algo.

En el código, lo esencial cabe en pocas líneas. El campo se marca como no válido y se conecta con su mensaje, de forma que el lector de pantalla lea etiqueta, valor y error al llegar a él:

<label for="telefono">Teléfono móvil</label>
<input id="telefono" name="telefono" type="tel" autocomplete="tel"
       aria-invalid="true" aria-describedby="telefono-error" />
<p id="telefono-error" class="field-error">
  <span aria-hidden="true">⚠</span>
  Escribe un móvil de 9 cifras, por ejemplo 612 345 678
</p>

Además de eso:

• →El foco va al primer error (o al resumen) tras enviar, para que nadie tenga que buscarlo.
• →Los mensajes que aparecen sin recargar la página se anuncian con una región aria-live para lectores de pantalla.
• →El contraste del texto de error cumple el mínimo de 4,5:1, igual que el resto del texto.
• →Los errores no desaparecen solos con un temporizador; se van cuando el problema se resuelve.

La parte visual de los campos, con sus estados y sus etiquetas, la detallamos en diseño UI de campos de formulario.

05Recuperarse sin perder nada

Volvamos a la escena del principio. Lo que más frustró a mi madre no fue el error, sino perder lo que había escrito. Proteger el trabajo de la persona es probablemente la regla más importante de todo este tema.

1. 01Conserva todos los datos tras un error. Nunca se vacía un formulario al validarlo, ni en el navegador ni al volver del servidor. Las contraseñas y los datos de tarjeta son la única excepción razonable por seguridad.
2. 02Guarda borradores en formularios largos. Un formulario de solicitud, una reseña larga o un pedido complejo pueden guardarse localmente mientras se rellenan.
3. 03Ofrece deshacer en lugar de confirmar. Para acciones reversibles, como archivar o eliminar un elemento de una lista, un aviso con «Deshacer» durante unos segundos es más ágil que un diálogo de confirmación.
4. 04Reintenta solo cuando tenga sentido. Si se corta la conexión, la app puede reintentar el envío al recuperarla y avisar de que lo ha hecho.
5. 05Abre siempre una vía humana. En errores que la persona no puede resolver, un enlace a soporte, un teléfono o un chat, y un código de referencia breve para que el equipo lo encuentre rápido.

06Errores del sistema: cuando el fallo es nuestro

No todos los errores los provoca la persona. A veces cae un servidor, una pasarela de pago no responde o una página ya no existe. En estos casos el mensaje cambia de enfoque: asume la responsabilidad, tranquiliza sobre lo importante y ofrece una salida.

• →Página no encontrada (404): un buscador, enlaces a las secciones principales y un tono que puede permitirse algo de personalidad. Le dedicamos una guía a la página 404.
• →Error del servidor (500): «Algo ha fallado por nuestra parte» y qué puede hacer: esperar un momento, volver a la página anterior o contactar.
• →Sin conexión: un aviso discreto, el contenido ya cargado disponible y el envío pendiente guardado para cuando vuelva la red.
• →Pago rechazado: qué ha dicho el banco, en lenguaje claro, y las alternativas disponibles sin perder el carrito.
• →Sesión caducada: volver a entrar sin perder lo que se estaba haciendo, y explicar por qué ocurrió.

07Medir los errores para saber dónde mejorar

Los errores dejan rastro, y ese rastro es una mina de información. Registrar en la analítica un evento cada vez que se muestra un error de validación, con el campo y el tipo de error como parámetros, permite ver en pocas semanas qué campos dan más problemas. Casi siempre aparece un patrón: un formato de fecha que nadie acierta, un código postal que se rechaza en ciertas zonas, una contraseña con reglas que nadie recuerda.

Con esos datos, la revisión es muy concreta:

• →El campo con más errores es el primero que rediseñar, casi siempre con prevención en lugar de mejores mensajes.
• →Los errores que se repiten en la misma sesión indican que el mensaje no se entiende o no se ve.
• →Los abandonos justo después de un error señalan los momentos que más duelen.
• →Los errores del servidor se cruzan con el equipo técnico para atacar la causa de raíz.

Una revisión mensual con estas cuatro miradas convierte los errores en una lista de mejoras priorizada por su efecto real.

08Un error bien resuelto también construye marca

Cada mensaje de error es un pequeño momento de verdad. Es cuando la persona comprueba si al otro lado hay un sistema impaciente o alguien que la acompaña. Prevenir lo que se puede, validar en el momento justo, explicar con claridad y proteger lo que la persona ya hizo son gestos que no salen en ninguna foto de la web, pero que se recuerdan.

En SIMA cuidamos estos momentos en cada proyecto de diseño web y experiencia digital, desde el primer boceto de un formulario hasta el último aviso del sistema. Si sospechas que tu web pierde contactos o ventas en algún error mal resuelto, escríbenos y lo revisamos juntos.