UX de formularios largos: 12 reglas para que se completen

La UX de formularios largos es el trabajo de diseñar formularios con decenas de campos (solicitudes de préstamo, cuestionarios de onboarding, presupuestos de seguros, altas B2B, solicitudes de subvenciones) para que quien los rellena llegue al botón de enviar y no al de volver atrás. Un formulario corto aguanta un mal diseño porque termina antes de que la fricción se acumule. Uno largo no. Cada etiqueta confusa, cada dirección que hay que volver a escribir, cada error marcado antes de tiempo se paga otra vez en la página siguiente.

Los datos son claros. El estudio de Baymard Institute sobre procesos de compra encontró que el checkout medio de 2024 pedía 11,3 campos cuando a la mayoría de las webs les bastan 8, y que el número de campos pesa más en la usabilidad que el número de pasos. Y un checkout es un formulario corto. El onboarding de un producto de crédito o una solicitud a un organismo público pueden pasar de 60 campos, y el mismo desperdicio se repite en cada página.

Cómo elegimos estas 12 reglas

Cada regla cumple tres condiciones. Tiene pruebas detrás: investigación de usabilidad publicada, un design system público o un estándar de accesibilidad. Cambia cuántas personas llegan al final. Y un equipo de producto puede aplicarla a un formulario que ya existe en un sprint, sin rehacer el backend. Las hemos ordenado como se construye un formulario: qué preguntar, cómo dividirlo, cómo se comporta cada campo y qué pasa cuando algo falla.

¿Qué debe preguntar un formulario largo?

1. Quita cada campo al que nadie sepa darle un uso

Imprime el formulario. Al lado de cada campo, escribe quién lee la respuesta y qué hace con ella. Si al lado no hay un nombre, el campo se va. Si la respuesta la lee el departamento financiero una vez al año, la pregunta pasa a un email posterior. Es una revisión aburrida y es la hora que más rinde de todo el proyecto: un campo eliminado no necesita etiqueta, validación, mensaje de error ni traducción.

2. Deja para después lo que ahora no necesitas

Muchos formularios son largos porque lo piden todo al principio. Un alta B2B pregunta tamaño de empresa, cargo, sector y teléfono antes de que la persona haya visto el producto. Ordena las preguntas según cuándo hace falta la respuesta. Se queda lo necesario para crear la cuenta. Lo que afina la conversación comercial pasa a después de la primera sesión, cuando la persona ya tiene un motivo para contestar. Es la misma lógica de los onboardings que retienen a los usuarios después de la primera semana.

¿Cómo se divide un formulario largo?

3. Empieza con una pregunta por página y luego agrupa

El GOV.UK Design System recomienda empezar con una pregunta por página. Esa «cosa» es una decisión, y una decisión puede ocupar varios campos: la fecha de nacimiento son tres campos y una sola pregunta. Con una pregunta por página se gestionan mejor las bifurcaciones, los errores y el progreso guardado, y el formulario funciona en el móvil. Es un punto de partida. En un formulario que las mismas personas rellenan cada semana, agrupa las preguntas relacionadas para ahorrar clics en «Continuar» y comprueba que cada página agrupada se sigue leyendo como una sola decisión.

4. Pon a cada sección el nombre de su contenido

Un formulario largo se rellena en varias sesiones. Quien lo rellena necesita saber dónde está y qué le falta, con palabras que reconozca: «Datos de la empresa», «Administradores», «Cuenta bancaria», «Documentos». «Paso 3 de 7» no dice si está a punto de llegar el escaneo del pasaporte. GOV.UK sugiere probar primero el formulario sin indicador de progreso, para ver si es lo bastante simple como para no necesitarlo. Cuando no lo es, una lista de secciones con nombre dice más que una barra.

5. Una sola columna

En un estudio de CXL Institute, los participantes completaron un formulario de una columna 15,4 segundos más rápido que la versión de varias columnas del mismo formulario, con 356 y 346 personas en cada grupo. Dos columnas crean dos recorridos de lectura, y quien sigue uno se salta los campos del otro. Pon dos campos juntos solo cuando se leen como una única respuesta, como el mes y el año de caducidad de una tarjeta.

¿Cómo debe comportarse cada campo?

6. La etiqueta va encima del campo, nunca dentro

El placeholder desaparece en cuanto alguien empieza a escribir. Nielsen Norman Group enumera lo que cuesta: se olvida qué pedía el campo, no se pueden revisar las respuestas antes de enviar y los lectores de pantalla no siempre lo leen. Su consejo es no usar el placeholder en lugar de la etiqueta. En un formulario largo el coste se multiplica, porque la gente vuelve a revisar páginas que rellenó hace una hora.

7. Marca los campos opcionales y deja limpios los obligatorios

Después de la regla 1, casi todos los campos son obligatorios, y un asterisco en cada uno añade ruido a cada línea. La guía de GOV.UK es añadir «(opcional)» a la etiqueta de los campos opcionales y no marcar nunca con asterisco los obligatorios. Los pocos opcionales destacan, y cada uno es una invitación a preguntarse si debe estar en el formulario.

8. Dale al campo la medida de la respuesta

Un campo de código postal tan ancho como el de la dirección hace pensar que algo está mal. Ajusta cada campo a la longitud de la respuesta que espera. Usa el tipo de input y el inputmode que abren el teclado adecuado en el móvil. Añade valores de autocomplete a los campos sobre el usuario, para que el navegador rellene nombre, email, dirección y teléfono. Esto último también es un requisito: el criterio WCAG 1.3.5 pide que el propósito de cada campo sobre el usuario se pueda identificar en el código.

9. No pidas nunca dos veces lo mismo

Dirección de facturación y luego dirección de envío. Razón social en el primer paso y otra vez en la página de la declaración. WCAG 2.2 lo convirtió en un requisito de nivel A: lo que el usuario ya introdujo en el mismo proceso debe estar rellenado de antemano o disponible para seleccionar. Las excepciones son pocas: seguridad, datos que ya no son válidos o casos en los que volver a escribir es esencial, como confirmar una contraseña nueva. La casilla «Igual que la dirección de facturación» es la solución clásica. Rellenar de antemano la página de la declaración es la que se olvida.

¿Qué debe pasar cuando algo falla?

10. Valida cuando la persona sale del campo

Luke Wroblewski probó seis versiones de un formulario de registro con la consultora de usabilidad Etre. La mejor versión con validación en línea logró un 22% más de tasa de éxito y un 42% menos de tiempo para completarlo que la validación al enviar. La muestra fue de 22 personas y el estudio es de 2009, así que los porcentajes marcan una dirección. Lo que se ha mantenido es el momento del control: un campo se valida cuando la persona sale de él. Un email marcado como no válido tras el primer carácter suena a acusación. Los errores que solo detecta el servidor van en un resumen al principio de la página, cada uno con un enlace a su campo.

11. Guarda el progreso y avisa antes de que caduque la sesión

Un formulario de 40 minutos atraviesa una pausa para comer, una reunión y una conexión que se cae. Guarda cada página cuando la persona pasa a la siguiente y dale una forma de volver: un enlace por email o la cuenta que ya tiene. Si la sesión tiene un límite de tiempo, se aplica el criterio WCAG 2.2.1: hay que avisar antes de que caduque y dar al menos 20 segundos para ampliarla con una acción sencilla, al menos diez veces. Una sesión que caduca en silencio y tira 30 respuestas pierde justo a quien ya había decidido terminar.

12. Termina con una página de revisión de respuestas

Antes del botón de enviar, muestra todas las respuestas en una página, agrupadas por sección, cada una con un enlace «Cambiar» que lleva a la pregunta y vuelve al resumen. GOV.UK lo publica como su patrón «check answers». Detecta las erratas cuando corregirlas todavía cuesta poco. Y le dice a la persona, justo antes de enviar, que el formulario ha guardado todo lo que escribió. Después del envío, explica qué pasa y cuándo, con las palabras que usarías por teléfono. Los estados de error y los estados vacíos alrededor del formulario merecen el mismo cuidado.

Por dónde empezar con un formulario que ya tienes

Antes de cambiarlo, mídelo. La analítica por campo enseña dónde pierde gente el formulario: el tiempo en cada campo, los campos que la gente vuelve a corregir, el último campo que toca alguien antes de irse. Después aplica las reglas empezando por las más baratas. Las reglas 1 y 7 son una tarde de trabajo sobre los textos. La 6, la 8 y la 9 son cambios de frontend. La 3, la 11 y la 12 tocan el flujo y el backend. Mide las finalizaciones después de cada cambio, así sabrás cuál movió el número.

La accesibilidad entra en la misma lista. La EN 301 549, el estándar europeo de referencia para la European Accessibility Act, se publicó en su versión 4.1.1 en septiembre de 2026 y adopta WCAG 2.2, con el criterio de entrada redundante incluido. Hasta que la Comisión Europea la cite en el Diario Oficial, la referencia legal sigue siendo la versión 3.2.1, basada en WCAG 2.1 AA. Las reglas de la 8 a la 11 cubren criterios de las dos. El panorama completo está en nuestro artículo sobre diseño accesible tras la European Accessibility Act.