Un formulario puede parecer sencillo cuando todas las respuestas son válidas. Su calidad se aprecia mejor cuando alguien escribe mal una dirección, pierde la conexión o envía información que el servidor no acepta. Estos momentos forman parte del uso habitual y deben aparecer en el archivo de diseño junto al envío exitoso.
Piensa en un formulario de entrega. El cliente ha escrito su nombre, el número del apartamento y una nota. La consulta del código postal falla. Si la interfaz borra los campos o exige una dirección sugerida sin explicar la diferencia, el cliente tiene que proteger su trabajo del propio producto. Un diseño mejor ayuda a corregir el problema concreto y conserva el resto.
Decide qué se puede comprobar y cuándo
Enumera las reglas de validación y quién se encarga de cada una. Un campo obligatorio vacío puede identificarse localmente. Saber si una cuenta ya existe suele requerir al servidor. La disponibilidad de entrega puede depender de varios campos a la vez. Esta distinción determina cuándo un mensaje puede ser veraz.
Evita presentar un campo incompleto como un error mientras la persona todavía escribe. Cuando el feedback temprano ayude, elige un momento concreto, como salir del campo o enviar el paso. Si la comprobación es asíncrona, diferencia entre comprobando, válido e inválido. Un indicador de carga que después se convierte en un borde rojo necesita una explicación adicional.
Escribe instrucciones que permitan actuar
“Valor no válido” expresa un juicio sin explicar la corrección. “Introduce un código postal de cinco cifras” ofrece un siguiente paso concreto, siempre que esa regla corresponda al país seleccionado. Los ejemplos deben representar entradas aceptadas, y el formato no debería borrar caracteres significativos.
La guía del W3C sobre notificaciones en formularios describe formas de identificar errores y hacer accesible la información a las tecnologías de asistencia. Utilízala al revisar las asociaciones entre campos y mensajes y los resúmenes de errores. El producto aún debe aportar la explicación específica: qué falló, cómo corregirlo y si se conservó la entrada original.
Conserva el trabajo cuando falle el envío
Distingue un error de validación de un fallo al entregar la solicitud. Si una solicitud agota el tiempo de espera, el producto quizá no sepa si el servidor la recibió. Para acciones como realizar un pedido, el reintento debe coordinarse con la implementación para que otro clic no cree accidentalmente otro pedido.
En una actualización normal de perfil, conserva visibles los valores introducidos y ofrece reintentar. Si la sesión caducó, explica la necesidad de iniciar sesión y decide qué datos del borrador pueden mantenerse de forma segura. No prometas que algo se ha guardado antes de que el producto tenga pruebas de ello.
Revisa el ciclo completo de corrección
Al reunir referencias en Refcat, mira más allá del campo rojo. Sigue el envío, el resumen de errores, la entrada corregida y la confirmación final. Comprueba si la persona vuelve al lugar adecuado y si la confirmación identifica la acción completada.
Antes de entregar el formulario, recorre cuatro casos: un valor ausente, un rechazo del servidor, un fallo de red y un reintento exitoso. Incluye nombres largos realistas, distintos formatos de dirección y navegación con teclado. La entrega debe explicar cómo recuperarse de cada caso, además de mostrar variantes visuales de error.