Buenas Prácticas de Diseño de Formularios: 10 Reglas para Web y Mobile
Las 10 reglas para diseñar formularios que convierten. Análisis reales de los flujos de registro de Notion, Tally y Mercury, más patrones mobile-first que realmente funcionan.
Buenas Prácticas de Diseño de Formularios: 10 Reglas para Web y Mobile
El costo de un formulario mal diseñado
Un formulario malo es un impuesto estratégico sobre cada peso que gastaste para traer a alguien a la página. Las tasas de completación para formularios de registro, checkout y onboarding promedian alrededor del 12% cuando hay fricción. Elimina la fricción y ese número supera el 50%.
La diferencia casi nunca está en el copy o el branding. Está en las diez reglas, aplicadas de forma consistente.
Los formularios con 30 campos al estilo Salesforce existen porque alguien mapeó un esquema de base de datos sobre una página y lo llamó formulario. El usuario no firmó para eso. Llegó por el producto, y tu lógica de calificación te costó el lead.
Regla 1: Una columna, una tarea por pantalla
Una columna, siempre. Los layouts de múltiples columnas se ven eficientes en una grilla de Figma y destruyen las tasas de completación en una pantalla real.
El ojo lee de izquierda a derecha y espera continuidad. Cuando los campos se dividen en dos columnas, el usuario tiene que decidir qué camino seguir, y esa micro-decisión agrega fricción antes de que haya escrito un solo carácter.
El flujo de registro de Notion es una sola columna centrada con un campo a la vez en mobile. El formulario se siente rápido porque pide una sola cosa. Esa es la regla.
Regla 2: La posición del label importa más que su estilo
Los labels van encima del campo. No dentro, no al lado. Encima, siempre visibles.
El texto de placeholder usado como label desaparece en el momento en que el usuario empieza a escribir. En ese punto tiene que borrar el campo para recordar qué estaba llenando. El flujo de onboarding de Mercury usa labels persistentes sobre cada input para que el contexto nunca se pierda a mitad del formulario.
Los floating labels, que se animan desde la posición del placeholder al hacer foco, son un punto medio aceptable, pero requieren contraste preciso y timing cuidadoso para ser accesibles. Ante la duda, pon el label encima y déjalo ahí.
La investigación de UX detrás del posicionamiento de labels se cubre en profundidad en nuestra guía de métodos de investigación UX.
Regla 3: El orden de los campos sigue la realidad del usuario, no el esquema de la base de datos
La secuencia de tus campos debe coincidir con cómo una persona piensa sobre la tarea, no con cómo los ingenieros estructuraron el modelo de datos.
Un formulario de checkout que pide la dirección de envío antes de confirmar el carrito pone la carga del contexto sobre el usuario. Stripe Checkout, la referencia canónica para UX de formularios de checkout hospedado, secuencia el formulario en tres pasos:
- Email (quién eres)
- Pago (cómo vas a pagar)
- Dirección (adónde va)
Esa es la secuencia que usaría una persona razonable en persona. Cuando la base de datos maneja el orden de los campos, obtienes formularios que piden un código postal antes que el país, o un cargo antes que el nombre de la empresa.
Regla 4: Valida inline, nunca al hacer submit
Valida el campo en el momento en que el usuario lo abandona, no cuando presiona submit.
La validación al enviar significa que el usuario llena un formulario de diez campos, presiona el botón y recibe una pared de errores en rojo. Cada error es una tarea de corrección, y cada tarea de corrección arriesga perderlo por completo. La validación inline, disparada en blur, muestra el error antes de que el usuario continúe.
El inicio de sesión de Apple ID valida el formato de email en blur y confirma la disponibilidad de la cuenta antes de que el botón de submit esté activo. Esa secuencia previene dos categorías de error a la vez. Los patrones de interacción detrás de esto se cubren en nuestra guía de diseño de microinteracciones.
Regla 5: Mobile-first significa teclados para mobile
Cada tipo de campo debe invocar el teclado correcto. Eso es el 80% del diseño de formularios para mobile.
Si un campo pide un número de teléfono y aparece el teclado de texto predeterminado, el formulario está roto antes de que el usuario escriba algo. Usa inputmode="numeric" en campos numéricos, type="email" para mostrar la tecla @, e inputmode="decimal" para precios. iOS y Android soportan el rango completo de modos de entrada.
El teclado es el dispositivo de entrada principal en mobile. Especificar el incorrecto convierte un formulario visualmente bien diseñado en uno frustrante.
| Tipo de campo | Atributo HTML correcto |
|---|---|
type="email" | |
| Teléfono | type="tel" |
| Número entero | inputmode="numeric" |
| Decimal / precio | inputmode="decimal" |
| URL | type="url" |
| Búsqueda | inputmode="search" |
Para la base mobile-first más amplia donde viven estos patrones, ver fundamentos de diseño web responsivo.
Regla 6: Progreso, microcopy y el problema de los formularios largos
Si el formulario requiere más de cinco campos, muéstrale al usuario dónde está en el flujo.
El flujo de reserva en múltiples pasos de Airbnb muestra un indicador de progreso con pasos nombrados durante todo el proceso. Los usuarios que pueden ver que están al 60% tienen mediblemente más probabilidades de terminar que los usuarios que no tienen ningún punto de referencia.
Tally adopta un enfoque diferente para sus formularios embebibles: una pregunta a la vez con una barra de progreso persistente en la parte superior, que consistentemente supera a los formularios largos de una sola página en sus pruebas de usuario documentadas.
El microcopy hace el mismo trabajo. "Paso 2 de 4" es más honesto que una barra de progreso sola. "Necesitamos esto para verificar tu identidad" es más útil que un campo sensible sin etiqueta.
Regla 7: Los mensajes de error son instrucciones, no acusaciones
Escribe los mensajes de error en imperativo, no como acusación.
"Este campo es obligatorio" es una acusación. "Ingresa tu dirección de email para continuar" es una instrucción. El usuario ya sabe que algo salió mal. Lo que necesita es la solución.
El mejor copy de error nombra la condición exacta y la acción exacta: "La contraseña debe tener al menos 8 caracteres e incluir un número." Stripe Checkout hace esto con precisión. El mensaje aparece en blur, nombra el problema y desaparece en el momento en que se resuelve la condición.
No hay estado rojo persistente. Simplemente funciona.
Regla 8: El autofill es una función, no una ocurrencia tardía
El atributo autocomplete le dice al navegador exactamente qué rellenar. Úsalo en cada campo.
Un formulario de checkout con atributos de autocomplete correctos tarda unos 12 segundos en completarse en un teléfono con datos guardados. Sin ellos, el mismo formulario tarda dos minutos porque el usuario escribe todo manualmente. Esa brecha de 108 segundos es donde vive la mayor parte del abandono de checkout en mobile, y no cuesta nada cerrarla. La guía de biblioteca de componentes de UI cubre cómo integrar estos atributos en los componentes de formulario de tu design system para que nunca falten.
| Campo | Valor de autocomplete |
|---|---|
email | |
| Nombre | given-name |
| Apellido | family-name |
| Teléfono | tel |
| Dirección | street-address |
| Ciudad | address-level2 |
| Código postal | postal-code |
| Número de tarjeta | cc-number |
| Vencimiento de tarjeta | cc-exp |
Regla 9: El botón de submit lo decide todo
El botón de submit es el contrato. Su etiqueta, estado y posición señalan si el usuario puede confiar en lo que sucede a continuación.
Un botón grisado sin explicación le dice al usuario que el formulario está roto pero no por qué. Es un callejón sin salida. Un botón etiquetado "Enviar" no le dice nada al usuario sobre lo que está aceptando.
"Crear mi cuenta", "Obtener mi prueba gratis" y "Empezar a construir" son todas más honestas. Deshabilita el botón solo cuando puedas explicar el motivo en la UI. Tally usa copy específico de acción en cada paso de su constructor de formularios, y es un contribuidor directo a sus tasas de completación por encima del promedio para flujos B2B embebidos.
Regla 10: Prueba con pulgares reales, datos reales, latencia real
Probar un formulario en un navegador de escritorio sobre wifi rápido no te dice nada significativo sobre si funciona.
Prueba en un dispositivo Android de gama media con conexión 4G con datos de longitud real en cada campo:
- Un nombre con un carácter acentuado
- Una dirección con número de apartamento en la segunda línea
- Un email de 22 caracteres
- Un nombre de 1 carácter
Los casos extremos del mundo real rompen formularios que se ven perfectos en Figma. La latencia real revela si las llamadas de validación están bloqueando la entrada o corriendo de forma asíncrona. Esa distinción es invisible en un simulador de navegador y catastrófica en un teléfono con dos barras de señal.
¿Necesitas una auditoría de formularios en tu flujo de registro, checkout o onboarding? Brainy ejecuta la auditoría completa de diez reglas en pantallas reales, datos reales y números de conversión reales.
Dónde los diseñadores todavía lanzan los peores formularios
Los peores formularios en producción hoy comparten tres patrones:
- Formularios de leads de ventas enterprise: pantallas de calificación con 30 campos al estilo Salesforce con selectores obligatorios de "ingresos anuales" y sin validación inline
- Flujos de onboarding en múltiples pasos que no guardan el progreso: una llamada telefónica en el paso 7 de 9 devuelve al usuario al paso 1
- Flujos de checkout construidos antes de que mobile fuera primario, nunca reconstruidos: cada campo numérico sigue usando
type="text"porque "funciona bien en escritorio"
Las elecciones de estado de error en los tres casos también tienden a fallar los requisitos de contraste; los patrones de contraste de color accesible corrigen ese punto de falla específico.
El hilo común en los tres: el formulario fue diseñado para el sistema, no para la persona que lo llena. La solución es la misma.
Aplica las diez reglas. Empieza por mobile. Deja que la base de datos resuelva su propio esquema.
Preguntas frecuentes
¿Cuántos campos debe tener un formulario?
Los mínimos que el resultado requiera. El número correcto es aquel en el que eliminar uno más rompería el producto. Cada campo que agregas reduce la tasa de completación. Empieza desde cero y agrega solo lo que sea obligatorio.
¿Debo usar formularios en múltiples pasos o de una sola página?
Para más de cinco campos, los múltiples pasos casi siempre superan a una sola página. El requisito es el progreso visible. Sin él, los formularios en múltiples pasos rinden peor que los de una sola página porque el usuario no tiene idea de cuánto falta. Nombra los pasos y muestra dónde están en la secuencia.
¿Cuál es la mejor forma de marcar los campos obligatorios?
Marca los campos opcionales, no los obligatorios. Si la mayoría de los campos son obligatorios (que deberían serlo, dada la regla anterior), marcar cada campo con un asterisco rojo es ruido visual.
Marca las excepciones. "Opcional" junto a un campo es información significativa. Un asterisco junto a cada campo no lo es.
¿Cómo manejo los requisitos de contraseña sin castigar al usuario?
Muestra los requisitos antes de que el usuario empiece a escribir, no después de que falle. Una pequeña checklist que se activa a medida que se cumple cada condición rinde mejor que una pared de errores post-submit. Apple ID y la mayoría de los flujos de autenticación actuales usan este patrón. El feedback es en tiempo real, positivo y nunca punitivo.
¿El ancho de un campo comunica algo?
Sí, y los usuarios lo leen. El ancho del campo señala la longitud esperada del input. Un campo corto señala una respuesta corta. Un campo de ancho completo señala una más larga.
Haz coincidir el ancho del campo con la longitud esperada del input donde el layout lo permita. Un campo de código postal a ancho completo parece un error. Un textarea para una dirección parece exagerado. Haz coincidir el contenedor con el contenido esperado.
¿Qué causa más abandono de formularios en mobile?
El tipo de teclado incorrecto es el número uno. El autofill que no funciona es el número dos. Ambos son fallas silenciosas: el formulario se ve correcto, el usuario simplemente no puede completarlo eficientemente.
Corrige ambos con dos atributos por campo. La inversión es de 15 minutos. El retorno es medible en conversión de checkout dentro del mismo sprint.
Need a form audit on your sign-up, checkout, or onboarding flow? Brainy runs the full ten-rule audit on real screens, real data, and real conversion numbers.
Get Started
