Errores de formulario: qué recomienda la investigación

La investigación sobre errores de formulario parte de una idea simple: quien encuentra un error intenta terminar una tarea, y cada paso extra cuesta atención. El archivo del NN/g probó durante años cómo informa un formulario un problema, y el resultado es más concreto de lo que sigue la media de las pantallas de registro. El índice de temas de diseño de interacción (en inglés) reúne las piezas detrás de este post.

Cuándo validar mientras se escribe y cuándo esperar

Valida dentro del campo cuando la herramienta lo permita, y deja el mensaje junto a ese campo. La pauta pide respuesta instantánea en un campo complejo, como una contraseña con reglas, porque la persona necesita conocer la regla antes de seguir.

La misma pauta ordena no disparar la validación antes de que la persona termine el campo. Marcar un campo como erróneo mientras el cursor sigue ahí interrumpe el flujo y trata un valor a medias como fallo.

Lo que decide es el tipo de campo, no una regla fija. Un campo simple espera a que la persona salga, y un campo con regla visible puede responder mientras escribe. El archivo convive con las dos lecturas y no ofrece criterio de desempate.

Mostrar que algo salió bien también importa. Cuando el campo es complejo, una confirmación discreta avisa que el valor pasó.

Etiqueta, placeholder y espacio en blanco

Un placeholder dentro del campo no es una etiqueta. Desaparece en la primera tecla, y la persona pierde la pregunta justo cuando empieza a responder. También apuesta a la memoria de corto plazo: después de escribir, no queda texto para revisar antes de enviar.

El mismo patrón molesta a quien navega con teclado y hace que el campo vacío parezca menos importante que el lleno, porque el texto dentro de la caja atrae el ojo. El placeholder también se puede confundir con autocompletado, y a veces obliga a la persona a borrarlo a mano. Una etiqueta flotante mantiene la etiqueta visible y resuelve parte del problema, pero no resuelve la atención ni la confusión con un dato automático.

La respuesta recomendada es etiqueta y pista fuera del campo, siempre visibles. La excepción declarada es un formulario con uno o dos campos muy frecuentes, como búsqueda e inicio de sesión.

El espacio en blanco tiene regla propia. La etiqueta pertenece más a su campo que al campo siguiente, por la ley de la proximidad, la misma que respeta el microcopy de producto. Agrupar campos relacionados hace que el formulario parezca más corto, porque el ojo lee bloques en vez de una columna de cajas. La etiqueta arriba del campo se escanea mejor, la etiqueta a la izquierda sirve cuando el ancho aprieta, y la etiqueta a la derecha pelea con el escaneo.

Cómo escribir el mensaje de error

El mensaje tiene que ser explícito, legible, educado y preciso, con consejo práctico. Decir que el campo está vacío no es un mensaje de error; decir qué escribir sí lo es. El acierto también merece respuesta, así que un campo complejo debe confirmar que pasó.

El color separa el error del estado normal, y el rojo carga el fallo en la mayoría de los sistemas. El amarillo sirve al aviso, y el verde o el azul sirven al éxito. El color solo no alcanza, así que un icono o una animación discreta ayuda al ojo a encontrar el problema en un formulario largo.

No escondas el mensaje en un tooltip. El icono pasa desapercibido y el texto solo aparece al pasar el cursor o al enfocar, lo que cobra un paso que el error no necesitaba. Un resumen de validación en la parte superior tampoco sostiene el trabajo solo, porque la persona tiene que emparejar cada línea con un campo.

Deja el modal para los casos raros. El diálogo interrumpe la tarea y aumenta la carga, lo que cae bien en un evento del sistema que exige decisión y no en un campo aislado que necesita arreglo.

Indicador de obligatorio y ruido de aviso

Un artículo sobre indicadores, validaciones y notificaciones (en inglés) separa tres formas de hablar de la pantalla. Un indicador es contextual, condicional y pasivo. Una validación es el mensaje de error ligado al campo, y se queda hasta que la persona actúe sobre él. Una notificación viene de un evento del sistema y no de la acción inmediata. Se divide entre la versión que exige acción, que debe interrumpir, y la pasiva, que puede pasar desapercibida.

La distinción importa porque el mismo componente recibe veredicto opuesto en cada papel. El modal es ruido en el error de campo y herramienta correcta en el evento del sistema que pide decisión.

Un aviso que aparece y se va es una notificación pasiva, y falla como error porque la persona puede desviar la mirada en el instante en que surge. Si el error desaparece antes de que alguien lo lea, es como si nunca hubiera aparecido. Por eso el estado de carga y vacío necesita un diseño que sostenga la información, y no un parpadeo.

Campo de fecha y formato

El archivo lista cuatro formas de pedir una fecha: calendario, selector de desplazamiento en el celular, tres menús separados para día, mes y año, y escritura directa. El calendario sirve al rango corto y al rango entre dos fechas. El selector de desplazamiento sufre cuando la lista crece. Los tres menús cobran pasos innecesarios. La escritura directa suele ser el camino más eficiente, sobre todo para una fecha lejana, y debe estar siempre disponible.

Un campo de fecha bien hecho acepta cualquier separador y no exige formato fijo ni carácter especial. Avisa cuando la fecha es imposible en vez de suponer y quita opciones sin sentido. También conserva lo que la persona ya escribió y mantiene el rango coherente cuando cambia uno de los extremos.

Para un público internacional, el mes escrito con letras o el conjunto de campos separados evita el problema de orden entre día y mes, que cambia de país en país.

Formulario largo contra flujo por etapas

La longitud sola no decide si el formulario se volvió aplicación. La prueba es el tipo de información, el número de pasos, el área condicional y la linealidad del camino. Un formulario que pasa de dos pantallas suele apuntar a una tarea que pide aplicación, con respuesta propia, ayuda en contexto y flujo flexible.

Una página larga puede ser la respuesta correcta cuando todos los campos son de verdad necesarios. Agrupar esos campos en bloques visibles mantiene la página legible sin convertirla en un flujo por etapas. Esa corrección más discreta sirve a la mayoría de los sitios.

Cortar la pregunta antes de adornar el campo

El framework EAS avanza en tres movimientos: eliminar, automatizar y simplificar. Eliminar es cortar la pregunta que no es necesaria ni urgente, aplazar lo que se puede preguntar después y no obligar a registrarse antes de la compra.

Automatizar es reusar el dato que el sistema ya tiene e inferir en vez de pedir, como derivar la ciudad del código postal. Es también ofrecer guardar el valor para la próxima vez.

Simplificar es un valor por defecto útil, formato libre que el sistema limpia por detrás, y un recurso del celular para foto o respuesta hablada. Un formulario que cabe en un campo, como el patrón de registro de un solo campo, muestra hasta dónde llega el primer movimiento.

El framework cierra con una advertencia. Simplificar no es lo mismo que borrar campos, porque el formulario largo a veces es el necesario. Ese punto es donde encuentra la divergencia de abajo.

El error común

El problema más común no es que falte una regla. Es usar la regla en el lugar equivocado. La mayoría de los formularios importa el patrón más severo de otro contexto. Un modal responde al error de campo, y un tooltip carga la pista. Un placeholder queda donde debería haber etiqueta, y una página de resumen devuelve a la persona arriba para buscar la caja rota.

El caso de la falsa alerta de misil en Hawái (en inglés) muestra lo mismo desde el otro lado. El operador eligió la opción equivocada y confirmó, lo que el artículo llama un “lapso”, la distancia entre querer una acción y ejecutar otra parecida en piloto automático. El diseño cargó la culpa, no la persona: pista engañosa, opción mal diferenciada, presentación problemática y falta de confirmación para una acción destructiva.

Ese caso resume todo el tema. Un formulario que culpa a la persona por un fallo de diseño va a seguir cosechando el mismo error, y el rediseño es la solución donde el entrenamiento no lo es. La prevención de errores es una de las diez heurísticas detrás de este trabajo, y pesa más en un sistema donde el error cuesta caro.

Dónde discrepan las fuentes

Cuándo validar: una pauta pide respuesta dentro del campo al terminar y pide respuesta instantánea en un campo complejo como la contraseña, mientras otra regla prohíbe validar un campo que todavía se está escribiendo. El tipo de campo es la línea práctica, y el archivo no declara ninguna.
El modal: es ruido en el error de campo e interrupción correcta en el evento del sistema que exige decisión. El mismo componente gana veredictos opuestos porque el contexto cambia.
Campo de fecha dividido: el artículo de fecha desaconseja los tres menús y, en la misma página, sugiere campos separados para un público internacional. La tensión queda abierta.
Formato libre contra máscara: el artículo de fecha pide cualquier formato, y el framework de simplificación sugiere una máscara que inserta el separador mientras se escribe. Mismo objetivo, mecanismos opuestos.
El formulario largo: un artículo trata el formulario que pasa de dos pantallas como señal de que la tarea se volvió aplicación, y otro resuelve un formulario largo solo con agrupación visual. Romper en flujo o agrupar en la misma página, y la elección depende de la tarea.