Diseño de formularios para no diseñadores: por qué la gente los abandona a la mitad y cómo solucionarlo

Casi todas las apps tienen un formulario en algún lugar. Regístrate aquí. Agrega un nuevo cliente. Reserva la cita. Cuéntanos qué salió mal. Y casi todas pierden gente justo ahí: en la única pantalla donde le pides que escriba algo de vuelta. Tenían suficiente curiosidad como para llegar, y el formulario es donde cierran la pestaña en silencio.

El diseño de formularios es, simplemente, el conjunto de decisiones detrás de esa pantalla: qué campos pides, en qué orden aparecen y cómo responde el formulario cuando alguien comete un error o termina. Es uno de los cambios de mayor impacto que puedes hacerle a una app creada con IA, porque un formulario es el momento en que le pides a alguien que haga trabajo: si lo haces mal, todo el esfuerzo que pusiste en el resto de la app nunca llega a importar. Aquí está el porqué de que la gente abandone los formularios, y el puñado de cambios que logran que lleguen hasta el final.

¿Por qué la gente abandona los formularios a la mitad?

La gente abandona cuando lo que un formulario pide pesa más que lo que recibe a cambio; ese es todo el mecanismo. La mayoría de los formularios malos no son feos: simplemente piden demasiado, demasiado pronto, antes de que la persona esté convencida de que vale la pena.

Piensa en cada campo como una petición aparte. “¿Cuál es tu nombre?” es una petición mínima. “Sube tu licencia de negocio” es una petición grande. “Crea una contraseña” es media, pero también es un compromiso: dice vas a volver aquí. Cuando alguien llega a tu formulario, va sumando esas peticiones en silencio y las compara contra cuánto quiere el resultado. Así que el primer movimiento en el diseño de formularios no es visual. Es decidir qué necesitas de verdad.

¿Cuántos campos debería tener un formulario?

Los menos que puedas. La solución individual más grande para el abandono de formularios es eliminar campos, no achicarlos, no reordenarlos. Eliminarlos.

Una amiga construyó una herramienta de reservas para su negocio de limpieza. La primera versión de su formulario tenía once campos: nombre, correo, teléfono, dirección, metros cuadrados, número de recámaras, número de baños, mascotas, fecha preferida, hora preferida y “algo más”. Casi nadie lo terminaba. Lo redujimos a tres —nombre, teléfono y “¿cuándo te funciona?”— y dejamos que preguntara el resto en la llamada de confirmación que de todos modos hacía. Las reservas subieron de inmediato. Los otros ocho campos no estaban reuniendo información: estaban espantando a la gente antes de que ella siquiera consiguiera el prospecto.

Para cada campo, hazte una sola pregunta: ¿necesito esto ahora mismo, para dar el siguiente paso? Si la respuesta es “no, pero estaría bien tenerlo”, elimínalo. Siempre puedes preguntarlo después, una vez que la persona ya sea cliente en lugar de un extraño decidiendo si vale la pena molestarse. Un formulario que pide tres cosas y funciona le gana a uno completísimo que nadie completa.

¿En qué orden deberían ir los campos de un formulario?

Empieza con los campos más fáciles y de menor compromiso —los que no requieren pensar, como un nombre o un correo— y deja para después cualquier cosa que exija esfuerzo real, una vez que la persona ya tenga impulso. El orden importa más de lo que la gente espera. Una vez que alguien empieza a escribir, es mucho más probable que siga; lo difícil era arrancar. Empezar con “crea una contraseña” o “sube un documento” pide el gran compromiso antes de que exista ningún impulso, y ahí es donde la gente se va.

Si un formulario es genuinamente largo —una solicitud detallada, un registro con papeleo real— divídelo en pasos y muestra en cuál va la persona. “Paso 2 de 3” es un detalle pequeño que hace un trabajo real: le dice a alguien que el final está a la vista, así no abandona un scroll largo porque no tiene idea de cuánto falta. Una meta visible mantiene a la gente avanzando hacia ella.

¿Qué campos de un formulario deberían ser obligatorios?

Los menos posibles. Marca los campos obligatorios con claridad y, más importante aún, no hagas casi nada obligatorio. Cada campo obligatorio es un lugar donde el formulario puede rechazar a alguien, y nada mata un formulario más rápido que alguien que lo llena, le da enviar y le regresan tres errores en rojo por campos que no sabía que tenía que completar.

Si un campo puede ser opcional, hazlo opcional. El número de teléfono que “te gustaría tener” no vale lo que vale la persona que no quiere darlo y se va en su lugar.

¿Cómo deberían funcionar los errores de validación en un formulario?

Una buena validación detecta un error en el momento en que ocurre y explica específicamente qué corregir, en lugar de esperar al envío y soltar una pared de rojo. Un buen formulario detecta el problema justo donde ocurrió, en el momento en que la persona termina ese campo, y dice algo específico y amable: “A este correo le falta una @”. Un formulario malo espera hasta que le dan enviar, suelta una pared de rojo y dice “Entrada inválida”, lo cual no le dice nada sobre qué corregir.

La diferencia está en si el formulario se siente del lado de la persona. “Esa fecha ya pasó, elige un día de esta semana” es una ayuda. “Error” es un regaño. Uno logra que se termine; el otro logra que se abandone. Es una parte pequeña pero real del diseño de formularios, y vale la pena revisar cada mensaje de error que tu app pueda mostrar.

¿Cómo hago que un formulario sea amigable en móvil?

Dos cosas importan más en un teléfono, y los teléfonos castigan los formularios descuidados. Primero, pide el teclado correcto: un campo de correo debería abrir el teclado con el signo @, un campo de teléfono debería abrir el teclado numérico. Tu builder puede configurar esto, y convierte escribir en algo tan simple como tocar. Segundo, usa un selector de fecha real en vez de hacer que alguien escriba “21/06/2026” con los pulgares; un calendario que se toca es más rápido y nunca produce una fecha en el formato equivocado.

Pruébalo tú mismo: abre el formulario de tu app en tu propio teléfono y llénalo como si fueras un desconocido con prisa. La fricción se nota en unos diez segundos.

¿Qué debería pasar después de que alguien envía un formulario?

Muestra una confirmación clara en el momento en que envían: un mensaje, un agradecimiento, un “lo recibimos, esto es lo que sigue”. La parte más ignorada de un formulario es el final. Alguien le da enviar y… no pasa nada visible. ¿Se envió? ¿Deberían hacerlo de nuevo? Ese silencio hace que la gente lo reenvíe, o peor, asuma que está roto y se vaya. Es una sola pantalla, y es la diferencia entre alguien que confía en tu app y alguien que se pregunta si acaba de perder el tiempo.

Cómo pedírselo a tu builder

La mayoría de esto se lo puedes pasar directo a tu builder de IA si eres específico:

• “Este formulario debería tener solo tres campos: nombre, teléfono y fecha preferida. Mueve todo lo demás a un paso posterior.”
• “Haz que todos los campos sean opcionales excepto nombre y correo.”
• “Muestra mensajes de error en línea junto a cada campo mientras el usuario escribe, con pistas en lenguaje sencillo, no una sola lista de errores al final.”
• “Usa el teclado de correo para el campo de correo y un selector de fecha para el campo de fecha en móvil.”
• “Después de que envíen, muestra una pantalla de confirmación que diga que lo recibimos y qué sigue.”

Cada una de esas es una instrucción clara que tu builder puede ejecutar, y juntas cubren la mayor parte de lo que separa a un formulario que la gente termina de uno que abandonan.

¿Cómo pruebas un formulario antes de lanzarlo?

Ábrelo en tu teléfono e intenta completarlo lo más rápido que puedas, como si nunca lo hubieras visto. Esa es toda la prueba. Nota cada punto donde dudas, entrecierras los ojos o tienes que pensar; esas dudas son exactamente donde tus usuarios reales abandonan, y ahora sabes con precisión qué corregir primero.