Cómo escribir mensajes de error de validación de formularios

Una persona introduce su correo, pasa al campo siguiente y recibe una corrección útil. Otra ve casi la misma frase mientras aún está escribiendo y se pregunta qué ha hecho mal. Las palabras pueden ser idénticas. La experiencia no.

Por eso los mensajes de validación son sorprendentemente difíciles de diseñar. Una frase más amable no rescata un aviso impaciente, y una explicación precisa no ayuda si señala la respuesta equivocada. El trabajo real consiste en decidir qué sabe el sistema, cuándo debe hablar y qué puede hacer después la persona.

Hay evidencias útiles, pero no apuntan todas a un patrón universal. La investigación de comercio electrónico, las guías de servicios públicos y los experimentos de registro ponderan de forma distinta la interrupción y los avisos tempranos. Entender esa diferencia sirve más que coleccionar mensajes supuestamente perfectos.

Qué enseñan los usuarios reales sobre validación

En el informe de enero de 2024 de Edward Scott sobre las pruebas de validación en contexto de Baymard, una participante en L.L.Bean omitió la @ del correo. El aviso apareció después de pasar al siguiente campo y lo corrigió en segundos. En Etsy, otro participante vio un error al entrar en un campo de dirección intacto y sintió que la interfaz le regañaba antes de responder. REI ofrece otro ejemplo de recuperación: el error del código de seguridad desapareció al añadir el tercer dígito que faltaba.

Estas observaciones históricas explican por qué «usa validación en contexto» es una descripción incompleta. El momento en que aparece el mensaje y aquel en que desaparece pueden importar tanto como el texto.

En nuestras revisiones lo convertiría en una pregunta: ¿el mensaje responde a una acción que la persona cree haber terminado? Pulsar Continuar expresa claramente esa intención. Salir de un campo, a veces. Poner el cursor en uno vacío, normalmente no. La interfaz necesita una razón para interrumpir, no solo un valor que todavía incumple una regla.

Un contrapunto útil es el estudio de formularios de registro de 2009 de Luke Wroblewski y Etre. Veintidós participantes probaron seis variantes. En comparación con el grupo de control, la mejor versión con validación en contexto registró, según el estudio, un aumento del 22 % en la tasa de éxito y una reducción del 42 % en el tiempo necesario para completar el formulario. Un participante explicó que prefería conocer sus errores sobre la marcha. Sin embargo, las marcas verdes junto a respuestas conocidas también generaron dudas sobre qué había verificado realmente el sistema.

La lección más útil trata de la incertidumbre: quien elige un nombre de usuario disponible necesita información que tiene el sistema; quien escribe su propio nombre quizá no necesita su aprobación. Priorizaría los avisos que resuelven una incógnita, en vez de repartir símbolos de visto bueno uniformemente por el formulario.

Por qué GOV.UK elige otro momento

El patrón de validación de GOV.UK recomienda esperar a que se intente continuar o enviar, en lugar de validar al abandonar un campo. También aconseja preservar respuestas, colocar un resumen de errores arriba, llevar allí el foco e identificar los problemas junto a sus campos. Validar antes requiere investigación de usuarios que lo respalde.

Conviene mantener visible la diferencia respecto al comercio electrónico. Un paso corto de una pregunta mantiene local la corrección tras enviar: la respuesta sigue delante. En un pago largo, el campo incorrecto puede quedar lejos cuando se envía.

Si revisara una reserva de taller, empezaría por la forma de la tarea. En una página de una sola fecha, Continuar es un momento razonable para explicar una selección no disponible. Si reúne contacto, necesidades de accesibilidad, plazas y facturación, esperar al final puede obligar a remontar todo el formulario. No justifica validar en vivo en todas partes, sino probar avisos tempranos selectivos.

También hay diferencia entre ayuda y error. Una lista de requisitos de contraseña puede explicar reglas mientras se escribe sin tratar cada condición pendiente como fallo. Una ayuda de fecha puede explicar el periodo antes de que exista un valor. La ayuda útil no tiene que esperar al envío ni parecer una advertencia roja.

Anota qué disparador utiliza cada campo. «Validamos en contexto» puede ocultar tres comportamientos implementados por tres personas distintas.

Escribe la corrección que el sistema puede justificar

«Introduce un correo válido» suele cerrar la conversación cuando debería abrirla. ¿Qué significa válido? Ausente, mal formado, no disponible y no verificado son estados distintos. Confundirlos crea mensajes seguros que no explican el siguiente paso.

En el taller ficticio, el campo vacío podría decir «Introduce un correo para recibir la confirmación de reserva». Si no contiene @, «Introduce un correo que incluya @» describe un problema observable. Ninguna frase prueba que el buzón exista o pertenezca a la persona. Eso requiere otra verificación.

Es tentador escribir un mensaje muy específico para cada errata. Lo evitaría salvo que la lógica las distinga con fiabilidad. Decir que un dominio está mal escrito no ayuda si es poco habitual pero legítimo. Ante la duda, una sugerencia opcional puede ser mejor que un rechazo. El equipo debe acordar esa diferencia antes de aprobar el texto.

Este es un pequeño inventario para el taller. Cada fila empieza por una condición porque un mismo campo puede necesitar varios mensajes.

La última fila exige deliberadamente algo más al producto que una frase. Solo procede pedir una comprobación de estado si existe una forma usable de hacerla. Si no, hay que acordar otra salida con ingeniería y soporte. El texto debe revelar esa decisión pendiente, no disfrazarla con «Inténtalo de nuevo».

Haz navegable un formulario largo tras fallar

Imagina pulsar Continuar casi al final. Dos campos del principio tienen errores, pero la ventana sigue mostrando el botón. Un borde rojo fuera de pantalla no basta. La persona necesita descubrir que la acción falló y volver a las respuestas afectadas.

En el taller, un resumen puede nombrar los problemas de plazas y fecha, cada uno enlazado a su campo. El texto local permanece junto a la respuesta durante la corrección. La repetición tiene propósito: el resumen ayuda a desplazarse; el mensaje local, a editar. Cambiar la redacción entre ambos añade una interpretación innecesaria.

El resumen debe ser selectivo. Un correo que supera las comprobaciones no pertenece a la lista de errores. Tampoco hay que vaciar todo el formulario para lograr un reinicio limpio. Ver la respuesta previa ayuda a entender y cambiar solo lo necesario. Para datos sensibles, conservar exige una decisión propia de producto y seguridad; no prometas que todo se guardará siempre.

Aquí la revisión estática debe convertirse en interactiva. Sigue un enlace del resumen con teclado. Comprueba dónde cae el foco, si la etiqueta queda visible bajo una cabecera fija y si su explicación está disponible al llegar. Corrige y vuelve a enviar. Una captura muestra un recuadro rojo, no demuestra que el recorrido funcione.

En móvil, repite la secuencia con el teclado abierto. Un mensaje puede encajar perfectamente en escritorio y quedar debajo del teclado. Los errores largos deben saltar de línea, no encogerse hasta ser ilegibles. Prefiero darles otra línea a obligar a ampliar la instrucción necesaria para terminar.

El mensaje debe cambiar cuando cambian los hechos

Un error de revisión habitual es aprobar solo dos imágenes: normal y error. Lo incómodo suele ocurrir entre ambas. Se edita la respuesta, desaparece el problema original y el rojo permanece. Desde fuera, puede parecer que la corrección ha fallado.

Supón que se pidieron cuatro plazas y quedaban dos. Cambiar a dos debe activar una nueva comprobación de la regla. Cambiar de fecha es distinto: cambia el inventario del que depende. No puede quedarse sin más un aviso sobre la sesión anterior. La relación importa más que el borde rojo.

Pediría tres estados adicionales en la entrega: comprobando, aceptado para este paso y no se puede comprobar. «Comprobando disponibilidad…» no es «Dos plazas disponibles», y ninguna confirma una reserva. Mantienen honesta la interfaz si una petición tarda o la sesión se llena entre comprobaciones.

Hay otro caso menos visible: se cambia dos veces la fecha y la primera petición termina después de la segunda. Si la antigua sobrescribe la nueva, la interfaz da una respuesta perfectamente legible a la pregunta equivocada. Las notas deben exigir resultados correspondientes a la selección actual; ingeniería decide cómo asegurarlo.

Al revisar animaciones o carga, conserva esa distinción. No se trata de dar movimiento a la transición, sino de evitar interpretar un resultado antiguo como nuevo. Si no puede comprobarse ahora, una explicación neutra es más exacta que marcar la respuesta como inválida.

Un fallo de servicio no es una pregunta mal respondida

El error de redacción más caro quizá sea pedir corregir una respuesta que nunca estuvo mal. Una petición fallida puede significar rechazo de datos, servidor no disponible o resultado desconocido. Cada posibilidad requiere otro paso.

Piensa en un tiempo de espera agotado al pulsar Reservar. La petición quizá no llegó. O quizá terminó y se perdió la respuesta. Sin saberlo, «Tu reserva ha fallado» es demasiado categórico. Repetir inmediatamente puede ser inocuo o crear un duplicado. El producto necesita una decisión explícita sobre esa incertidumbre.

En el ejemplo, revisaría la recuperación con ingeniería antes de pulir el mensaje. ¿Se puede recuperar el resultado con una referencia? ¿Repetir devuelve de forma segura el resultado original? ¿Soporte encuentra el intento? ¿Qué respuestas quedan? De ello depende si conviene consultar el estado, reintentar sin riesgo o contactar con una referencia.

No es motivo para poner detalles técnicos internos en el error. Nadie necesita una lección de fallos de red, sino lo que se sabe y un siguiente paso funcional. Una referencia ayuda si soporte puede utilizarla; un código inexplicado es otro problema que interpretar.

Las buenas prácticas incluyen la recuperación

En OpenDesign, una vista previa HTML compatible permite comparar campo normal, error y corrección. Usa valores realistas y un mensaje largo, revisa la anchura estrecha y comenta el elemento concreto. Después prueba la misma secuencia con el backend real, teclado y anuncios del lector de pantalla.

Una revisión pequeña puede enseñar más que otra ronda de adjetivos. Pide reservar cuatro plazas y deja que aparezca el conflicto. Pregunta qué creen que pasó y qué harían. No expliques el significado primero: eliminarías la ambigüedad que quieres descubrir.

Observa lo que hacen tras corregir con tanto cuidado como lo que dicen. Si releen el aviso, quizá no se borró. Si cambian un correo válido tras un tiempo de espera, la interfaz puede estar culpando al lugar equivocado. Si reinician todo, la recuperación quizá cueste más de encontrar que la tarea original.

En producción, envíos repetidos y bucles de corrección señalan dónde investigar, no explican automáticamente la causa. Muchos errores pueden indicar instrucciones confusas, reglas restrictivas, falta de plazas o un defecto de implementación. Une secuencia de eventos y comportamiento observado, sin recopilar respuestas personales en bruto solo para diagnosticar.

Antes de aprobar el ejemplo, recorrería esta secuencia:

1. Introducir una respuesta incompleta y observar cuándo aparece el aviso.
2. Enviar con dos errores y llegar a ambos campos desde el resumen.
3. Corregir una respuesta y confirmar que se conservan los otros valores.
4. Cambiar una respuesta de la que dependen otras, como la fecha, y revisar el nuevo resultado.
5. Encontrar el servicio no disponible y seguir su recuperación.

La última comprobación es el éxito. ¿La confirmación muestra fecha y cantidad corregidas? ¿Se entiende si existe una reserva? El formulario no se ha recuperado solo porque desaparezca el texto rojo.

Los buenos mensajes dejan menos por interpretar. Los casos del sector sirven porque muestran dónde se rompe esa interpretación: antes de terminar una respuesta, después de corregir o cuando la interfaz afirma saber más de lo que sabe. Toma el razonamiento, pruébalo en tu tarea y deja que la frase siga al comportamiento que realmente puedes ofrecer.