Un formulario es donde se pierde el trabajo de todo el diseño. Has cuidado la tipografía, el color y la jerarquía, y el visitante llega al último paso, ve catorce campos en dos columnas y se va.
Aquí tienes ejemplos de formularios reales que puedes abrir hoy mismo y analizar, los principios de usabilidad que hay detrás —con el estudio que los respalda, no con opiniones— y los ocho errores que hacen que nadie complete el tuyo.
El mismo formulario, antes y después
Los dos piden lo mismo. Pincha en los campos de los dos y verás la diferencia enseguida:
Así no
Dos columnas, etiqueta dentro del campo, nombre partido en dos, email duplicado y un botón de borrar al lado del de enviar.
Así sí
Una columna, etiqueta encima, nombre completo en un campo, sin duplicados, opcional marcado y el botón dice qué hace.
Pruébalo en el móvil si puedes: en el de la derecha, al tocar el teléfono te sale el teclado numérico. En el de la izquierda, el alfabético.
De seis campos hemos pasado a tres, y solo uno es obligatorio de verdad. Ese es el trabajo: no maquetar mejor, sino quitar.
7 principios con investigación detrás
De todo lo que se dice sobre formularios, esto es lo que tiene un estudio o una norma detrás. El resto son opiniones, incluida la mía.
1. Cumplir las guías básicas casi duplica los aciertos
Empiezo por el dato que justifica todo lo demás. En un estudio publicado en CHI, los formularios que seguían las guías de usabilidad conseguían un 78 % de envíos correctos al primer intento, frente a un 42 % en los que no las seguían. Casi el doble, sin tocar el diseño visual.
Lo recoge el Nielsen Norman Group en sus diez recomendaciones para formularios, que es la fuente que consulto cuando dudo.
2. Una sola columna
Con dos columnas el usuario tiene que decidir en qué orden leer, y se salta campos. La excepción admitida son datos cortos y relacionados en la misma fila, del tipo ciudad, provincia y código postal.
Un aviso de honestidad: verás por ahí cifras del estilo «una columna convierte un X % más». No he encontrado la fuente original de ninguna. El principio está documentado; el porcentaje, no.
3. La etiqueta encima del campo, nunca dentro
Usar el placeholder como etiqueta es el error más extendido y el más fácil de arreglar. El texto desaparece justo cuando el usuario necesita comprobar qué le pedían, y en la pantalla de error ya no puede revisar nada.
Baymard documentó el comportamiento que provoca: gente borrando todo lo que había escrito solo para volver a ver la etiqueta. Y el sistema de diseño de GOV.UK lo dice sin matices: la etiqueta va alineada encima del campo, y el placeholder no sustituye a la etiqueta ni sirve para pistas.
4. Un campo de «Nombre completo», no nombre y apellidos
Este dato me sorprendió: en los test de Baymard, un 42 % de participantes escribió su nombre completo en el campo «Nombre» al menos una vez. Con un único campo de nombre completo, solo un 4 % dudó y nadie tuvo problemas. Y aun así, un 89 % de los sitios sigue partiéndolo en dos.
La causa es simple: la gente piensa en su nombre como una sola cosa. Lo mismo pasa con la dirección. En los mismos test, un 30 % se quedó parado al llegar a «Dirección, línea 2» y dudó de si había rellenado bien la primera.
5. Cada campo que quitas es una barrera menos
Los datos de Baymard sobre campos en el checkout son claros y van en la buena dirección: la media pasó de 12,7 campos en 2019 a 11,3 en 2024. Pero su conclusión es que la mayoría de los sitios solo necesitan 8.
Y el coste de pasarse está medido: un 17 % de usuarios ha abandonado una compra por lo complicado que era el proceso. No por el precio. Por el formulario.
La pregunta que le hago a cada campo antes de dejarlo: ¿qué pasa si no tengo este dato? Si la respuesta es «nada grave», fuera. Si es «lo pido por si acaso», fuera también.
6. Valida mientras escribe, no al enviar
Luke Wroblewski hizo una prueba con Etre comparando validación al enviar contra validación en línea. La mejor variante dio un 22 % más de aciertos, un 22 % menos de errores y un 42 % menos de tiempo para completarlo. Te lo doy con su matiz: es una prueba de muestra pequeña, no un estudio académico. Aun así apunta en la dirección que confirma todo lo demás.
Un detalle de implementación que importa: el mensaje de error tiene que recalcularse mientras teclea, no solo al salir del campo. Si no, el usuario corrige, ve que el error sigue ahí y piensa que sigue haciéndolo mal.
7. Marca los obligatorios en cada campo, no en una nota arriba
Poner «todos los campos son obligatorios salvo indicación» en la cabecera no funciona: nadie lee las instrucciones de arriba, y quien las lee las ha olvidado a mitad del formulario. Asterisco en cada campo obligatorio, y de propina marca los opcionales con la palabra «opcional». Lo explica el Nielsen Norman Group.
Y no pongas los asteriscos ni las etiquetas en gris pálido. Se pierden.
8 ejemplos de formularios que funcionan
Todos comprobados en julio de 2026. Ábrelos y fíjate en lo que te señalo de cada uno.
1. GOV.UK — consultar los datos de un vehículo
La referencia mundial, y no es una exageración. Una pregunta por pantalla, la etiqueta es el propio H1 de la página, y el ejemplo de formato («For example, CU57ABC») va fuera del campo, no dentro. El botón dice «Continue».
Es la mejor lección gratis de diseño de formularios que existe: ábrelo aquí.
2. NHS — buscar una farmacia
Un solo campo, y la etiqueta te dice exactamente qué acepta: «Enter a town, city or postcode in England». Nada de adivinar el formato. Ofrece además usar tu ubicación, y tiene tres mensajes de error distintos para los tres motivos por los que puede fallar la geolocalización.
3. Kagi — registro
Mi favorito de la lista por lo que no hace. Pide email y contraseña, y ya: sin repetir email ni repetir contraseña. Junto al campo de email hay un enlace que explica por qué lo necesitan. El campo opcional lleva la palabra «(optional)» escrita. Y funciona sin JavaScript.
4. Mastodon — alta en varios pasos
Hace algo que casi nadie hace: te muestra las normas antes de pedirte un solo dato. Así nadie rellena el formulario entero para descubrir después que el sitio no le interesa. Y el indicador de tres pasos está visible desde el principio, no aparece a mitad.
5. Mozilla — suscripción a la newsletter
El mejor ejemplo de gestión de errores de la lista. Cuando algo falla, muestra un resumen encima del formulario con un mensaje concreto por campo, no un «revisa los datos» genérico. Y bajo el botón hay una promesa clara: solo información de Mozilla, y puedes darte de baja cuando quieras.
Ver la suscripción de Mozilla.
6. Smashing Magazine — newsletter
Un campo. Solo el email, sin pedirte el nombre para el saludo personalizado que a nadie le importa. Lo bueno está en la microcopia: te dice qué recibes, cada cuánto, qué regalo, cuánta publicidad como máximo y que no hay envíos de terceros. Responde a todas las objeciones antes de que las pienses.
Ver la newsletter de Smashing.
7. Crowd Favorite — contacto por tipo de consulta
Este estaba en la versión antigua de este post, y desde entonces han rehecho la web entera. Su formulario de ahora hace algo inteligente: un selector del tipo de consulta (proyecto nuevo, colaboración, prensa, empleo, soporte) que cambia el formulario según lo que elijas, en vez de un cajón único para todo. Indica el límite de tamaño del archivo antes de que lo subas, y usa un campo trampa antispam en lugar de un CAPTCHA.
Ver el formulario de Crowd Favorite.
8. Lionways — contacto sencillo bien hecho
El otro superviviente de la versión antigua. Cuatro campos, de los que solo dos son obligatorios y están marcados. Campo trampa antispam en vez de CAPTCHA. Y ofrece teléfono y email directos por si no te apetece el formulario, que es un detalle de respeto poco común.
Tip: Si trabajas en WordPress y no quieres pelearte con el maquetado ni con la accesibilidad de cada campo, en los plugins de formularios de Envato Elements tienes plantillas ya montadas con etiquetas correctas y validación en línea. Aun así, repasa la lista de errores de abajo: ningún plugin te salva de pedir catorce campos.
8 errores que hunden un formulario
- Usar el placeholder como etiqueta. Desaparece justo cuando hace falta, y en la pantalla de error el usuario no puede comprobar nada.
- Dos columnas. Obliga a decidir el orden de lectura y en móvil se rompe.
- Un botón «Borrar» junto a «Enviar». El beneficio es casi nulo y el coste, perder todo lo escrito. Fuera.
- CAPTCHA. El W3C tiene un documento entero explicando que estas pruebas excluyen a personas con discapacidad y les niegan el servicio. Usa un campo trampa oculto, como Lionways y Crowd Favorite.
- Duplicar el email o la contraseña. Duplicas el trabajo y creas un error difícil de entender. Si tienes que confirmar algo, confirma el email; para la contraseña, pon un botón de «mostrar».
- Obligar a crear cuenta para enviar o comprar. Mete campos ajenos a la tarea en el peor momento. Deja la cuenta para el final, si acaso.
- Borrar lo escrito cuando falla la validación. Un 34 % de los sitios borra los datos de la tarjeta tras un error de validación, según Baymard, y eso provocó abandonos directos en sus pruebas.
- No invocar el teclado correcto en móvil. Un campo de teléfono que abre el teclado alfabético es una errata garantizada. Se arregla con
typeeinputmode.
Lo mínimo de accesibilidad
Cuatro cosas que no son opinión, son norma. Y desde 2026 en Europa hay obligaciones legales por medio, así que conviene tenerlas.
- Cada campo con su
labelasociado porforeid. No vale un texto suelto encima. Lo explica el tutorial de formularios del W3C. - Atributo
autocompletecorrecto en cada campo (name,email,tel,postal-code). No es una comodidad: es el criterio 1.3.5 de las WCAG, y ponerlo mal es un fallo tipificado. - Área pulsable mínima de 24 por 24 píxeles para nivel AA en WCAG 2.2, y 44 por 44 si quieres AAA. Los checkbox diminutos suspenden.
- Nunca señales un error solo con color. Borde, icono y texto. Quien no distingue el rojo tiene que poder saber qué campo falla.
Si quieres profundizar, te dejo la guía del European Accessibility Act para diseñadores, que es donde esto se vuelve obligatorio y no recomendable.
Preguntas frecuentes
¿Cuántos campos debe tener un formulario?
Los que necesites para hacer tu trabajo, y ni uno más. En checkout, Baymard concluye que la mayoría de los sitios se arreglaría con 8 campos y la media real es 11,3. En un formulario de contacto, con nombre, email y mensaje tienes de sobra.
¿Dónde pongo las etiquetas, arriba o al lado?
Arriba. Aguanta etiquetas largas, funciona en móvil sin reventarse y permite ver etiqueta y campo de un vistazo. Al lado solo tiene sentido en formularios muy largos con etiquetas cortas, y ni así lo recomiendo. Dentro del campo, nunca.
¿Es mala idea poner un CAPTCHA?
Sí, y no por la conversión: por accesibilidad. El W3C documenta que estas pruebas excluyen a personas con discapacidad. Verás por ahí cifras muy llamativas del tipo «el CAPTCHA reduce las conversiones un 40 %», pero no he podido encontrar el estudio original de ninguna, así que no te las doy. El argumento de accesibilidad ya es suficiente. Usa un campo trampa oculto.
¿Valido al escribir o al enviar?
Al escribir, pero con cabeza: no le digas «email inválido» a alguien que va por la tercera letra. Espera a que salga del campo para el primer aviso, y desde ahí actualiza el mensaje tecla a tecla mientras corrige.
¿Qué pongo en el botón de enviar?
La acción concreta, no «Enviar». «Enviar mi consulta», «Crear mi cuenta», «Confirmar el pedido». El sistema de diseño de GOV.UK lo recomienda así y sus botones son ejemplares: «Confirm and send», «Add another address».
¿Formulario largo de una vez o partido en pasos?
Si son más de ocho o diez campos, en pasos, y con el indicador de progreso visible desde el primero. Mastodon lo hace bien. Lo que no funciona es partir en pasos un formulario de cuatro campos: ahí solo añades clics.
Más sobre diseño y usabilidad
- European Accessibility Act para diseñadores web — donde la accesibilidad de tus formularios deja de ser opcional.
- Formularios con HTML: guía completa — el cómo se maqueta lo que aquí explico.
- Microinteracciones útiles con código — para los estados de foco y error de los campos.
- Retícula 8pt y sistema de espaciado — el espaciado entre campos también se decide.
Empieza quitando, no maquetando
Si solo vas a hacer una cosa de todo esto, haz esta: abre tu formulario y quítale un campo. El que pides «por si acaso». Después baja las etiquetas a su sitio, encima del campo, y cambia el texto del botón por lo que de verdad va a pasar al pulsarlo.
Con eso solo ya vas por delante de la mayoría. Y si te apetece, cuéntame en los comentarios cuántos campos tenía tu formulario antes y cuántos después.
