Diseño de formularios: labels, orden y longitud
Un buen formulario mantiene las etiquetas visibles, ajusta el tamaño de los campos y marca los opcionales. Qué dicen el NN/g, GOV.UK y un estudio de CHI 2014.
¿Por qué los formularios fallan tanto?
Porque cada campo es una pequeña decisión y cada decisión mal resuelta es una oportunidad de abandono. Un estudio presentado en CHI 2014 (Seckler, Heinz, Bargas-Avila, Opwis y Tuch), citado por el NN/g, comparó formularios que seguían las pautas de usabilidad con formularios que las incumplían: los primeros tuvieron un 78 % de envíos correctos al primer intento, frente a un 42 % de los segundos (NN/g: Web Form Design, Kathryn Whitenton, 2016).
Ese dato es el argumento para empezar por lo básico: etiquetas, orden, longitud y errores. Antes de pensar en animaciones o micro-interacciones, un formulario tiene que sostenerse en esas cuatro cosas.
¿Dónde van las etiquetas?
El NN/g recomienda poner la etiqueta inmediatamente encima del campo en móvil y en formularios de escritorio cortos. Solo en formularios de escritorio muy largos conviene ponerla al lado. La razón práctica es que una etiqueta encima sigue visible mientras la persona escribe, y no se pierde cuando el campo se llena.
Evita usar el texto de ejemplo dentro del campo como si fuera la etiqueta. Desaparece al escribir y la persona no puede revisar qué debía poner. El NN/g indica que el texto de marcador de posición causa muchos problemas de usabilidad y que es mejor evitarlo.
¿Cuánto debe medir cada campo?
Los campos de texto deben tener aproximadamente el tamaño de lo que se espera escribir. Un campo muy largo para un código postal sugiere que hay que escribir más de lo necesario, y uno muy corto para una dirección obliga a la persona a desplazarse o a no ver lo que escribió. Como ejemplo, el NN/g analizó los nombres de ciudad de 2 130 participantes de una conferencia de UX: el 99,9 % tenía 19 caracteres o menos, con un rango de 3 a 22. Es un dato de una muestra concreta, así que úsalo como guía, no como norma universal.
¿Cómo se marcan los campos obligatorios y opcionales?
El NN/g recomienda limitar el formulario a uno o dos campos opcionales y marcarlos con claridad como opcionales. El GOV.UK Design System añade «(optional)» a la etiqueta de los campos opcionales y pide no marcar nunca los obligatorios con asteriscos (GOV.UK Design System: Question pages).
Si una pregunta necesita una explicación, usa un texto de ayuda de una sola frase corta debajo de la etiqueta, para información que ayude a la mayoría a responder. Las explicaciones largas no van ahí.
¿Un campo por página o todos en una pantalla?
El GOV.UK Design System recomienda empezar con una pregunta por página: según su guía, así la gente entiende mejor qué se le pide. Cuando una página tiene una sola pregunta, esa pregunta puede ser el encabezado de la página. Sobre el indicador de progreso, la guía sugiere empezar sin él y, si la gente tiene dificultades, probar uno simple de paso o de pregunta. Cita el caso del equipo de Carer’s Allowance, que retiró un indicador de 12 pasos sin efecto en las tasas ni en los tiempos de finalización (GOV.UK Design System: Question pages).
Como criterio práctico, una pregunta por página encaja cuando cada respuesta depende de la anterior. Si la persona necesita comparar o revisar varios datos a la vez, agrupar campos relacionados en una pantalla con secciones puede funcionar mejor. En ambos casos, prueba con usuarios.
¿Cómo se muestran los errores?
Los errores son parte del formulario, no un accidente. El GOV.UK Design System recomienda poner el mensaje en rojo después de la pregunta y del texto de ayuda, con un borde rojo que lo conecte con el campo, y resumir todos los errores arriba de la página con el mismo mensaje que aparece junto al campo. También pide no borrar ningún campo del formulario al mostrar el error, y preferir una instrucción directa (su ejemplo es «Enter your first name») antes que una descripción del fallo («First name must have an entry»). Entre las palabras que evita está «please», porque implica una opción (GOV.UK Design System: Error message).
El NN/g añade dos reglas: señalar el error con varias pistas y no solo con el color, y conservar lo que la persona escribió para que pueda corregirlo. Para el momento en que se valida cada campo, lee timing de validación en formularios.
Ejemplo ilustrativo
Ejemplo ilustrativo: un formulario de alta de un servicio pide nombre, apellido, fecha de nacimiento, código postal y teléfono opcional. La versión original tenía etiquetas dentro de los campos, un campo de código postal del mismo tamaño que el de dirección y un «*» junto a cada obligatorio. Al enviar con un dato mal escrito, el mensaje decía «Dato inválido» y borraba el formulario completo. El rediseño pone las etiquetas arriba, ajusta el campo de código postal a cinco caracteres, marca el teléfono como «(opcional)» y conserva los datos al producirse un error. El mensaje dice «Escribe tu código postal con cinco números», una instrucción directa en lugar de una descripción del fallo. Al terminar, el equipo revisa cuántos envíos llegan sin errores al primer intento.
Si las respuestas deben validarse en el momento, combina este artículo con cómo escribir mensajes de error y con los estados de carga para el envío.
Errores comunes
- Poner la etiqueta solo como texto de marcador de posición.
- Usar campos del mismo tamaño para un código postal y una dirección.
- Marcar con asterisco los campos obligatorios en lugar de indicar cuáles son opcionales.
- Borrar el formulario cuando hay un error.
- Mostrar «Dato inválido» sin decir qué corregir.
- Pedir datos que el servicio no necesita.
Qué puedes hacer mañana
- Abre tu formulario más largo y cuenta cuántos campos son realmente necesarios para el servicio.
- Revisa cada etiqueta: si desaparece al escribir, muévela arriba.
- Envía el formulario con un error a propósito y verifica que el mensaje dice qué corregir y que los datos se conservan.