El canon de los formularios: cada campo es una pregunta

Un formulario es el momento en que una interfaz deja de presentar y empieza a preguntar. Cada campo es una pregunta dirigida a alguien que preferiría estar haciendo otra cosa, lo que significa que cada campo innecesario es una imposición y cada campo confuso es una pequeña traición. El oficio de los formularios se reduce a un canon que cabe en la cabeza: haz las menos preguntas posibles, en una sola columna, con etiquetas visibles; acepta las respuestas tal como las da la gente; dispara la validación cuando la persona termina una idea, no a mitad de una tecla; escribe errores que expliquen cómo resolver el problema; y nunca, bajo ninguna circunstancia, tires a la basura lo que el usuario escribió. Casi toda la fricción que se ve en los formularios reales es la violación de alguna de esas líneas. {.answer-block}

TL;DR

• Un formulario es una conversación, así que pregunta como lo haría una persona: las menos preguntas posibles, en una columna ordenada, agrupadas por tema – y cada campo debe justificarse frente al costo de preguntarlo.
• La maquetación ya está resuelta: una sola columna, etiquetas encima del campo y un ancho de campo que insinúe el largo de la respuesta. Los formularios de varias columnas y los trucos de etiqueta flotante cambian comprensión real por una elegancia imaginaria.
• Acepta las respuestas tal como las da la gente. Recorta el espacio sobrante, toma el teléfono en cualquier formato, mantén el campo entero en lugar de partirlo en tres casillas: normalizar es trabajo del software, no del usuario.
• Valida al salir del campo, no en cada tecla, y escribe errores que enseñen: qué salió mal, cómo arreglarlo, junto al campo que le corresponde.
• Lo que el usuario escribió es sagrado. Un envío fallido que borra el formulario, o un botón deshabilitado que no dice por qué, convierte a un participante dispuesto en un exparticipante.

Por qué cada campo es una pregunta

Trata el formulario como la transcripción de una entrevista y su calidad se vuelve legible. ¿Un entrevistador competente pediría tu número de fax por pura costumbre? ¿Exigiría tu fecha de nacimiento antes de explicar para qué? ¿Te interrumpiría a mitad del deletreo de tu correo para anunciar que no es válido? ¿Olvidaría todo lo que dijiste porque tu código postal llevaba un espacio? Cada uno de esos gestos tiene su equivalente en un formulario en producción, y los usuarios lo viven igual que vivirían al entrevistador: como una grosería.

El encuadre también produce la primera y más importante de las reglas, la que precede a toda maquetación y todo estilo: cada campo debe justificar su existencia frente al costo de preguntar. Cada pregunta adicional aumenta el abandono; cada respuesta recogida es un dato que ahora tienes que guardar, proteger y responder por él. El movimiento más potente en el diseño de formularios es borrar: el campo que quitas rinde más que cualquier pulido que pudieras aplicarle. El recibo canónico es el de Expedia: eliminar un único campo opcional, «Empresa», del formulario de reserva habría valido unos 12 millones de dólares al año, según se ha reportado; los clientes escribían allí el nombre de su banco y luego fallaban la verificación de la dirección. Un campo, interrogado con honestidad, le ganó a cualquier rediseño. «Opcional» no es una justificación: es una imposición más pequeña, pero imposición al fin. Pide lo que necesitas para completar la transacción, marca como opcional ese campo que de verdad lo es y deja todo lo demás para después, cuando la relación se lo haya ganado. (El bando contrario prefiere poner un asterisco en cada campo obligatorio; cuando casi todo es obligatorio, los asteriscos son papel tapiz.)

Las reglas de maquetación

La maquetación de formularios es uno de los pocos rincones del diseño donde la evidencia está prácticamente cerrada, lo que convierte cualquier desvío en una decisión en contra del usuario:

Una sola columna. Un formulario es una secuencia de preguntas, y una columna única vuelve inequívoca esa secuencia: responde, baja, termina. Las maquetaciones de varias columnas obligan a decidir el orden de lectura en cada fila – ¿a lo ancho o hacia abajo? – y la gente lo resuelve de forma inconsistente, saltándose campos que nunca vio. En la comparación de eyetracking más conocida, los mismos campos en una sola columna se completaron unos quince segundos más rápido que repartidos en dos. Las excepciones son los compuestos genuinos que se leen como una sola respuesta: ciudad / estado / código postal en una línea, una fecha en tres partes. Eso es una pregunta que viste tres campos, no tres preguntas.

Etiquetas encima del campo, siempre visibles. Las etiquetas al costado producen un recorrido visual irregular; las etiquetas dentro del campo (el placeholder haciendo de etiqueta) desaparecen en cuanto la persona empieza a escribir, justo cuando más las necesita: a mitad de un formulario largo, cada campo lleno se vuelve una caja misteriosa del tipo «¿esto qué era?». Las etiquetas flotantes, ese compromiso animado, sobreviven al foco pero encogen al tamaño de un pie de foto y hacen que los campos vacíos parezcan llenos: una versión más suave del mismo intercambio, pagada igualmente en comprensión. Los placeholders sirven para pistas de formato («[email protected]»), nunca para la pregunta en sí.

El ancho del campo es información. Un campo de código postal tan ancho como uno de dirección miente sobre la forma de la respuesta. Dimensionar los campos según el contenido esperado – corto para códigos postales, largo para direcciones – es el mismo oficio que el espaciado que codifica agrupación: geometría que comunica en silencio.

Agrupa por tema y deja que el espacio haga la agrupación. Contacto, envío, pago: racimos de preguntas relacionadas con costuras claras entre ellos, y esas costuras hechas de espacio en blanco en vez de recuadros o líneas. Un formulario que se lee como tres temas pequeños es psicológicamente más corto que los mismos campos en un bloque indiferenciado.

Las reglas de entrada

El tema del diseño de entradas cabe en una frase: normalizar es trabajo del software. Sea cual sea la carga de formato, la carga la lleva la máquina, porque a la máquina es a quien le importa.

• Acepta respuestas descuidadas. Recorta los espacios sobrantes: el espacio final de un correo autocompletado ha hecho fallar más inicios de sesión de los que le corresponden. Toma los teléfonos con guiones, puntos, espacios, paréntesis o nada. Acepta el número de tarjeta con o sin separaciones. Si puedes parsearlo, parséalo; rechazar 555 867 5309 porque querías 5558675309 es obligar al usuario a ejecutar a mano tu código de formateo de cadenas.
• Nunca partas lo que el usuario percibe como una sola cosa. Teléfonos en tres casillas, fechas en tres desplegables, códigos de verificación en seis celdas de un carácter con saltos de foco hechos a mano: cada uno convierte una respuesta mental única en un rompecabezas de navegación y suele romper el pegado, el método de entrada más eficiente que tiene la persona. (La excepción de los compuestos de las reglas de maquetación sigue en pie: una fecha en tres partes escritas está bien; el pecado es la ceremonia del desplegable y el foco robado, no la adyacencia. Y para los códigos, la respuesta duradera es un solo campo con autocomplete="one-time-code".)
• Invoca el teclado correcto. En dispositivos táctiles, type="email", inputmode="numeric" y compañía marcan la diferencia entre escribir una dirección en un teclado pensado para ello y cazar la @ entre capas de símbolos. Esto cuesta un atributo.
• Deja que el navegador ayude. Los tokens autocomplete correctos convierten un checkout de doce campos en dos toques para quien ya compró antes. Desactivar el autocompletado en campos de dirección y de pago – casi siempre superstición heredada de una revisión de seguridad que nunca ocurrió – descarta la mayor aceleración disponible para un formulario.
• Sal al encuentro del dedo donde aterriza. Los campos, sus botones y cualquier cosa tocable respetan el objetivo táctil mínimo de la plataforma: 44 pt en iOS, 48 dp en Android. Un campo compacto y elegante que el pulgar no acierta con fiabilidad es un formulario de escritorio disfrazado de teléfono.

Las reglas de teclado y autocompletado juntas cuestan unos pocos atributos:

<input type="tel" autocomplete="tel">              <!-- phone keypad, autofilled -->
<input inputmode="numeric" autocomplete="one-time-code">  <!-- digit pad, code autofills -->

Las reglas de validación

El momento de validar es donde los formularios se ponen hostiles con más frecuencia, y la regla es simple: responde cuando la persona termina una idea. Dispararse en cada tecla es gritar «¡correo no válido!» a alguien que lleva cuatro caracteres escritos: criticar frases antes de que terminen. La escuela opuesta valida solo al enviar, y tiene un defensor serio: el design system de GOV.UK hace exactamente eso, y acompaña el envío con un resumen de errores en la parte superior de la página, porque un resumen se puede anunciar a los lectores de pantalla y le da a quien navega con teclado un único lugar donde empezar las reparaciones. Es una postura coherente, afinada para servicios donde la accesibilidad es la restricción determinante. Para la mayoría de los formularios de producto igual me quedo con la validación al salir del campo: la persona completa el campo, sigue adelante y recibe la respuesta en la costura entre dos ideas, mientras la idea sigue tibia. (Un matiz: un campo que ya estaba inválido puede revalidarse en cada tecla, para que el estado rojo se limpie en el instante en que llega el arreglo y no un campo entero después.)

Escribir errores pasa por la misma prueba conversacional. Un error no es un veredicto: es una instrucción de reparación. «Entrada no válida» no pasa la prueba – ¿no válida por qué? – y «A esta dirección de correo le falta la @» sí. (Y la instrucción tiene que ser cierta respecto de la regla real: los números de tarjeta van legítimamente de 12 a 19 dígitos, así que «debe tener 16 dígitos» no es un mensaje de error, es un bug de validación que rechaza a todos los titulares de Amex.) Coloca el mensaje junto al campo que le corresponde, en texto – el color por sí solo excluye a las personas daltónicas, y el texto es el único canal que percibe un lector que no renderiza nada – y vincúlalo a su entrada de forma programática (aria-describedby), para que la tecnología asistiva anuncie el error junto con el campo en vez de dejarlo varado en pantalla. Mantén un tono factual: el trabajo del formulario es que la persona llegue al final, no dictaminar culpas. Toda la regla en un par:

<!-- before: a verdict, visually nearby, programmatically stranded -->
<label for="email">Email</label>
<input id="email" type="email">
<span class="error">Invalid input</span>

<!-- after: a repair instruction, announced with its field -->
<label for="email">Email</label>
<input id="email" type="email"
       aria-invalid="true" aria-describedby="email-err">
<span id="email-err">This email address is missing its @</span>

Dos reglas estructurales completan el conjunto. Nunca deshabilites el botón de envío como estrategia de validación: un botón muerto sin explicación es un acertijo, y el siguiente movimiento del usuario es irse; déjalo enviar y luego muestra con precisión qué necesita atención. (Deshabilitarlo durante un envío en curso para evitar un cobro doble es otra cosa: eso es estado, no juicio.) Y la ley más profunda del canon: un envío fallido conserva cada tecla del trabajo del usuario. Un formulario que se vacía ante un error tomó varios minutos del esfuerzo de una persona y los quemó delante de ella. Ningún refinamiento visual se recupera de eso.

El canon como checklist

La forma operativa de todo lo anterior, aplicable a cualquier formulario antes de publicarlo:

En un design system esto se endurece dentro de los propios componentes de formulario – un campo de texto que viene con su ranura de etiqueta arriba, su ranura de error abajo y su temporización de validación incorporada – de modo que el canon se sostiene por defecto y desviarse cuesta trabajo. Es el mismo argumento de sistematización que el de los tokens de movimiento: codifica la decisión una vez, o vuelve a litigarla en cada funcionalidad.

Preguntas frecuentes

¿Un formulario debe usar una columna o dos?

Una columna. Una sola columna vuelve inequívoco el orden de las respuestas y se completa de forma medible más rápido; las maquetaciones de varias columnas provocan campos saltados porque la gente resuelve el orden de lectura de manera inconsistente. La excepción es una respuesta compuesta – ciudad / estado / código postal – que es una sola pregunta expresada como entradas adyacentes.

¿Cuándo debe dispararse la validación de un formulario?

Al salir del campo, cuando la persona lo abandona, y no en cada tecla ni, para la mayoría de los formularios de producto, guardada hasta el envío. La validación por tecla critica respuestas sin terminar; la validación solo al enviar entrega todos los fallos de golpe, aunque el resumen de errores al enviar de GOV.UK es la decisión correcta donde el anuncio por lector de pantalla es la restricción determinante. Un campo ya marcado como inválido puede revisarse en cada tecla para que el error se limpie de inmediato al corregirlo.

¿Está bien usar el texto del placeholder como etiqueta del campo?

No. El placeholder haciendo de etiqueta desaparece en cuanto la persona empieza a escribir, justo cuando necesita recordar la pregunta, y convierte cada campo lleno en un dato sin rótulo a la hora de revisar. Mantén una etiqueta visible encima del campo y reserva los placeholders para ejemplos de formato.

¿El botón de envío debe estar deshabilitado hasta que el formulario sea válido?

No. Un envío deshabilitado sin explicación es un callejón sin salida que el usuario tiene que diagnosticar. Déjalo activo y, al enviar, saca a la superficie cada campo sin resolver con un error específico e instructivo a su lado, conservando todo lo que la persona ya escribió.