El formulario se ve limpio. Tipografía bien, botón a contraste, campos alineados. Y aun así la gente se va a mitad. No es que el diseño «no guste». Es que el email se pone rojo al primer carácter, el teléfono no admite el prefijo, el autofill pisa el DNI y el error dice «campo inválido». Eso no es estética. Es UX de formularios web.
Cada campo extra es una pregunta. Cada error mal dicho es una humillación pequeña. Cada validación a destiempo es perder el dato que el usuario ya había escrito. En un checkout o en un contacto B2B el coste no es «un poco de fricción». Es el lead o el pedido.
En Truman diseñamos formularios dentro del diseño UX/UI, no como un plugin de CF7 con diez cajas. Este artículo va a validación, mensajes, autofill y el precio de pedir de más. Lo que aplicamos en proyectos como FIHGUV —formularios institucionales, claros, sin teatro— y en producto como Weddle, donde un campo mal puesto no es una molestia: es abandono de onboarding.
input1. El usuario tiene los datos en el Safari y tu form no los recoge.UX de formularios web: el coste de cada campo
En checkout, Baymard midió en 2024 una media de 11,3 campos. La mayoría de tiendas puede vivir con unos 8. El 17 % de quienes abandonan citan un proceso largo o complicado. El número de pasos importa menos que el número de cajas que hay que entender. Un solo paso con 20 campos parece más largo que tres pasos con 7.
11,3
campos de media en un checkout en 2024. La mayoría de sitios solo necesita alrededor de 8 para completar el pedido.
Baymard Institute, Checkout Optimization: Minimize Form Fields (2024)
En un formulario de contacto el listón es más bajo y por eso se abusa. Nombre, email, mensaje. El teléfono solo si de verdad llamáis. El cargo y la empresa, si sois B2B y calificáis. «Cómo nos has conocido» no califica: entretiene a marketing y cansa al que escribe. Si el formulario no convierte, empieza por recortar, no por cambiar el color del botón. Eso lo tratamos también en por qué el formulario de contacto no convierte.
La regla que usamos: si el dato no cambia la respuesta ni el enrutado en las primeras 48 horas, no va en el primer envío. Se pide después, o no se pide. Un hospital o una fundación —el contexto de FIHGUV— no puede pedir de más por curiosidad. Un producto como Weddle no puede pedir de más en el registro si el valor aún no se ha visto.
Validación: cuándo, dónde y cómo
Hay tres momentos. Al perder el foco (blur), si el campo ya se tocó: email sin @, teléfono corto. Al escribir, solo en formatos muy cerrados (un CUPÓN de 6 caracteres). Al enviar, todo lo que no se pudo pillar antes. Validar el email en el primer carácter es hostil. No validar hasta el submit y recargar la página es hostil al revés.
El error va pegado al campo, no en un listado arriba. El campo se marca y recibe foco el primero que falla. El texto dice qué hacer, no qué filosofía de regex tienes: «Introduce un email con @, como hola@empresa.com», no «formato inválido». Si hay varios errores, se listan y se enlazan a cada campo. En móvil eso es la diferencia entre corregir y abandonar.
| Patrón | Efecto | Qué hacer |
|---|---|---|
| Error al primer carácter | Ansiedad | Espera al blur o a 2–3 caracteres de más |
| Solo error al recargar | Se pierde el contexto | Validación inline + foco al campo |
| «Campo inválido» | No enseña | Di el formato esperado con un ejemplo |
| Required sin marcar | Sorpresa al enviar | Marca obligatorios y opcionales |
| Inline + submit coherente | Corrige en el sitio | Baymard: muchos sitios aún no lo hacen |
| Autofill respetado | Menos tipeo | autocomplete y name estándar |
Baymard encontró que el 31 % de los sitios no tiene validación inline y que un 4 % la tiene mal. Solo el 14 % marca de forma explícita tanto los obligatorios como los opcionales. Si dejas «los que no llevan asterisco son opcionales» y no lo dices, el usuario trata todo como obligatorio y se cansa antes.
Mensajes de error que se pueden cumplir
Un buen mensaje tiene tres piezas: qué ha pasado, por qué (si no es obvio) y qué hacer. «La contraseña es demasiado corta» + «mínimo 8 caracteres, con un número». No «no cumple la política». La política se enseña antes de fallar, no después. El mismo criterio vale para un NIF, un código postal o un archivo de 8 MB que tu servidor rechaza sin aviso.
El color no basta. Rojo sin texto no llega a daltonismo ni a un móvil al sol. Icono + texto + aria-live o role=»alert» para que el lector de pantalla no se calle. Las leyes de UX que sí importan aquí son las de feedback y de carga cognitiva, no un recetario de sesgos con nombre de psicólogo.
Autofill, teclado y el HTML que sí importa
autocomplete=»name», email, tel, street-address, postal-code, country. Name coherente. Label asociado con for/id. Si usas un label flotante, el label sigue siendo un <label>, no un placeholder que desaparece. El placeholder no es la etiqueta: cuando el usuario escribe, el placeholder se va y ya no sabe qué campo es.
inputmode=»numeric» o type=»tel» en teléfonos. type=»email» en email. type=»file» con accept y el peso máximo escrito. En iOS, un type=»number» para un código postal puede romper el autofill y las comas. Mejor text con inputmode. Estas cosas no se ven en Figma. Se ven en un iPhone real, con contactos guardados.
¿Has rellenado tu propio formulario en el móvil, con el teclado de Safari y el llavero, sin la red del estudio? Si no, todavía no lo has diseñado: lo has dibujado.
Tip técnico: no mates el autofill por un «diseño custom»
Los selects custom que reemplazan <select>, los datepickers que no son el nativo, y los inputs dentro de divs contenteditable rompen el relleno automático y la accesibilidad. Si el beneficio visual no es enorme, usa el control nativo y estílalo. Las microinteracciones sí caben: el check verde al validar, el botón que pasa a «enviando» y no se pica dos veces, el toast de «te hemos escrito». Eso ayuda. Un dropdown reinventado para el país, no.
Después del envío: la mitad de la conversión
El usuario pulsa y no pasa nada durante dos segundos. Vuelve a pulsar. Tienes dos leads o un error 500. El botón entra en estado loading, se deshabilita, y la página de gracias dice qué ocurre ahora: «te respondemos en 24 horas laborables» o «revisa el spam». Una página de gracias vacía («mensaje enviado») no cierra la ansiedad. En un formulario de investigación o de contacto institucional, esa frase es parte del servicio.
Si el envío falla por red, el dato se conserva. Si el servidor rechaza un archivo, no limpies el resto. Si usas un captcha, el invisible o un turno justo; el captcha de semáforos en móvil es un filtro contra humanos. Y el consentimiento de privacidad es un checkbox con enlace, no un párrafo de 400 palabras metido en el mismo submit.
Un formulario bonito que grita «inválido» a la primera letra no está bien diseñado. Está a medias. La conversión está en el error, en el teclado y en no pedir lo que no vas a leer.
Antes de publicar un formulario, verifica esto
- ¿Cada campo se justifica por una decisión real en las primeras 48 horas?
- ¿Los obligatorios y los opcionales están marcados de forma explícita?
- ¿La validación espera al blur o al envío, no al primer carácter?
- ¿El error va al lado del campo, con un ejemplo de formato correcto?
- ¿autocomplete y types nativos permiten el relleno del navegador?
- ¿Lo has enviado en un iPhone, con teclado real, sin Wi‑Fi de oficina?
- ¿El botón evita el doble envío y la página de gracias dice el siguiente paso?
- ¿Un fallo de red o de archivo no borra lo que el usuario ya había escrito?
Preguntas frecuentes sobre UX de formularios web
¿Cuántos campos debe tener un formulario de contacto?
Los mínimos para responder: nombre, email, mensaje. Teléfono si llamáis de verdad. Un campo de contexto si enrutáis (sede, servicio). A partir de ahí, cada caja extra tiene que ganar más de lo que cuesta. En checkout, Baymard sitúa el objetivo cerca de 8 campos, no de 11 o 15.
¿Cuándo validar un formulario, mientras se escribe o al enviar?
Al salir del campo, si ya hay un error evidente. Al enviar, el resto. Mientras se escribe, solo en códigos cortos o contadores. Validar el email en la primera letra o esperar a una recarga completa son los dos extremos que más abandono generan.
¿Qué diferencia hay entre un error de validación y un error de servidor?
El de validación lo puede corregir el usuario en el acto. El de servidor («no hemos podido enviar») no se arregla cambiando el teléfono. Mezclarlos en el mismo «campo inválido» es mentir. El segundo necesita reintento, soporte y no perder el texto.
¿Cómo se elige entre un formulario largo y uno por pasos?
Por la cantidad de campos que el usuario debe entender a la vez, no por moda de wizard. Si son 4 cajas, un paso. Si son 12 y de temas distintos (datos, proyecto, archivos), pasos con progreso y posibilidad de volver. Un único scroll de 12 campos en móvil suele perder más que dos pantallas claras.
