Formularios web que convierten: cuatro tests que desmontan las buenas prácticas

Pasar de un formulario de tres campos a un asistente por pasos con barra de progreso nos costó un 21% de envíos en mobile. La implementación era correcta, el diseño estaba cuidado y la idea aparece en casi cualquier guía de optimización de formularios. Aun así, la variante perdió con una probabilidad del 0% de superar al original.

Ese test formó parte de una serie de cuatro experimentos que hicimos entre febrero y marzo de 2026 para un servicio online argentino que vende informes vehiculares. Ninguno ganó. Los cuatro, analizados juntos, nos enseñan más sobre formularios que muchos tests ganadores.

Un formulario corto con mucha intención

El punto de partida era sencillo. Una landing con un formulario de tres datos: matrícula del vehículo, CUIT/CUIL y e-mail. Tras el envío, el usuario pagaba a través Mercado Pago, fuera de la propia web.

Quien llegaba a esa página ya sabía qué quería comprar. La pregunta era dónde se perdía la gente que no terminaba.

Por qué el formulario por pasos restó un 21%

La recomendación de dividir formularios surge en formularios largos, como una solicitud de préstamo o un alta de seguro con quince campos. Ahí trocear reduce la carga percibida.

Con tres campos ocurre lo contrario. Cada paso añade un clic, una transición y una pantalla nueva. La barra de progreso anuncia "1 de 3" donde antes había una sola pantalla que se resolvía de un vistazo.

En los datos, además de caer el envío, empeoró el paso intermedio de validación del CUIT y subió la tasa de rebote.

Cuándo sí tiene sentido un formulario por pasos

Nada de lo anterior significa que los formularios por pasos no funcionen. Significa que funcionan en un contexto concreto, y que ese contexto no era el nuestro.

Hay tres situaciones en las que dividir suele tener sentido.

La primera es cuando el formulario es largo de verdad. Una solicitud de crédito, una contratación de seguro o un alta en un servicio financiero pueden pedir entre diez y veinte datos. Presentarlos todos a la vez en un móvil genera una pantalla interminable, y agruparlos en bloques lógicos (datos personales, datos del bien asegurado, datos de pago) ayuda a que el usuario sepa dónde está.

La segunda es cuando hay lógica condicional. Si las preguntas del paso dos dependen de lo que el usuario respondió en el paso uno, dividir evita mostrar campos irrelevantes. Es el caso típico de cotizadores y simuladores.

Resultados de los cuatro tests

<table> <thead> <tr> <th>Cambio</th> <th>Métrica</th> <th>Control</th> <th>Variante</th> <th>Lift</th> <th>Prob. de ganar</th> </tr> </thead> <tbody> <tr> <td>Formulario por pasos + barra de progreso + errores más claros</td> <td>Envío del formulario</td> <td>55,82%</td> <td>44,08%</td> <td>−21,03%</td> <td>0,00%</td> </tr> <tr> <td>Bloque de precio e inclusiones bajo el hero</td> <td>Envío del formulario</td> <td>54,35%</td> <td>51,37%</td> <td>−5,49%</td> <td>4,99%</td> </tr> <tr> <td>Microcopy de confianza bajo el campo email</td> <td>Envío del formulario</td> <td>59,06%</td> <td>56,74%</td> <td>−3,93%</td> <td>5,35%</td> </tr> <tr> <td>Ayuda contextual para el CUIT/CUIL</td> <td>Llegada a página de agradecimiento</td> <td>6,77%</td> <td>6,11%</td> <td>−9,8%</td> <td>14,91%</td> </tr> </tbody> </table>

La tercera es cuando los primeros pasos aportan valor por sí mismos. Un simulador que enseña una cuota orientativa antes de pedir datos personales da al usuario un motivo para seguir. Aquí el primer paso funciona como compromiso pequeño que facilita el siguiente.

Ninguna de las tres se daba en nuestro caso. Tres campos, sin condiciones y sin valor intermedio: dividir solo añadía pasos.

Tranquilizar también tiene un coste

Varios tests partían de una lógica muy extendida hoy en día: reducir la ansiedad del usuario.

En uno se mostraba el precio y lo que incluía el servicio desde el primer pantallazo. En otro se explicaba que el e-mail solo se usaría para enviar el informe. Las dos variantes perdieron.

La explicación más probable es que cada elemento añadido antes del botón compite por la atención de un usuario que ya ha decidido.

Los mensajes de confianza funcionan donde hay una duda real. La investigación de Baymard sobre abandono de carrito, con una tasa media que ronda el 70% según su recopilación de estudios, sitúa la desconfianza en el momento de introducir los datos de pago.

En este flujo, el pago ni siquiera ocurría en la página testeada. La duda que intentábamos resolver no estaba ahí.

Hay otro efecto menos evidente. Un mensaje como "no usaremos tu e-mail para spam" también puede sembrar una duda que el usuario no tenía. Si nadie se lo había planteado, el aviso le invita a planteárselo.

Medir el paso que realmente importa

Uno de los tests tuvo una primera versión que mejoraba el campo CUIT/CUIL y se evaluaba con métricas intermedias del formulario.

En la segunda versión cambiamos la métrica principal a la llegada a la página de agradecimiento, el punto más cercano a la venta que podíamos medir dentro de la web.

El resultado cambió la lectura. El envío del formulario quedó prácticamente neutro, pero la llegada final cayó de 6,77% a 6,11%.

Un test de formulario que solo mide el envío de formularios puede declarar ganadores que no venden.

Si el pago o la confirmación ocurren fuera de tu web, conviene medir el punto más profundo posible antes de decidir. Esto es trabajo de analítica digital antes que de diseño.

Cómo encontrar la fricción real antes de testear

Si cuatro hipótesis razonables sobre el formulario fallaron, la pregunta obvia es cómo elegir mejor la siguiente.

Estas son las fuentes que revisamos antes de proponer un test sobre un formulario.

La primera es el funnel campo a campo. Muchas herramientas de analítica permiten medir en qué campo se abandona, cuántas veces se corrige cada uno y cuánto tiempo se pasa en él.

Un campo con muchas correcciones indica un problema de formato o de validación. Un campo donde el usuario se detiene mucho y después abandona indica una duda sobre por qué se pide ese dato.

La segunda son las grabaciones de sesión en mobile. Ver a usuarios reales teclear en un campo numérico que abre el teclado alfabético, o pelearse con un mensaje de error que no dice qué está mal, suele aclarar más que cualquier informe.

Las recomendaciones de Baymard sobre validación online y sobre campos obligatorios y opcionales sirven como lista de comprobación mientras se revisan.

La tercera es mirar lo que pasa después del formulario. En este caso, la mayor parte del abandono ocurría entre el envío y el pago en una plataforma externa. Ningún cambio en el formulario podía resolver eso.

Qué hacer con cuatro tests perdidos

Cada uno de estos tests evitó implementar un cambio que habría restado conversión. Sin test, el formulario por pasos habría llegado a producción como una mejora obvia.

Los cuatro apuntan en la misma dirección: la fricción principal no estaba en el formulario, sino en lo que venía después (precio, pago externo, contexto). Por eso el siguiente foco del proyecto se movió ahí.

Si trabajas con formularios cortos de alta intención, hay tres criterios que aplicaríamos antes de tocar nada:

• Primero, compara el número de campos con el nivel de intención del usuario que llega.
• Segundo, define la métrica de éxito lo más cerca posible de la venta.
• Tercero, añade elementos de confianza solo donde grabaciones y datos confirmen que hay una duda.

Si tu formulario es largo, con lógica condicional o en un sector regulado como banca o seguros, el análisis cambia, y probablemente sí haya margen para dividirlo.

Si quieres saber dónde está la fricción real de tu formulario antes de rediseñarlo, empieza por una auditoría gratuita con Scan&Boost o valida hipótesis concretas en pocas semanas contactándonos.