Empiezo por lo que este artículo no puede hacer, porque cambia cómo hay que leer el resto.
No tengo cifras de finalización que enseñarte. DevForm es nuevo, nadie ha pasado suficientes formularios por él como para que un porcentaje signifique algo, e internet está lleno de afirmaciones del tipo «los formularios de una pregunta convierten un 40 % mejor» que acaban remitiendo al blog de un proveedor hablando de sus propios clientes. Repetir una de esas sería tomar prestado un número que no puedo comprobar para vender un producto que construí yo.
Así que: el mecanismo, lo que el producto mide, y cómo averiguarlo tú.
Lo que un formulario largo le pide a alguien
Abres un formulario de catorce campos y tomas una decisión antes de contestar nada: ¿merece la pena esto?
La tomas con todo a la vista. Cada campo sin rellenar está delante de ti, la barra de desplazamiento avisa de que hay más abajo, y las dos preguntas que preferirías no contestar están ahí, siendo visibles. El coste de toda la interacción se presenta de golpe, en el momento en que el lector tiene menos interés invertido y menos información sobre por qué se le pregunta nada de eso.
Una pregunta por pantalla invierte eso. Ahora la decisión es «¿contesto esta pregunta?», tomada varias veces, cada una por alguien un poco más comprometido que la anterior. Es el mismo trabajo total. No es la misma secuencia de decisiones, y la gente no evalúa una serie de costes pequeños como evalúa uno grande.
Hay un segundo efecto del que se habla menos y que probablemente vale más: una pregunta sola en una pantalla se puede redactar bien. En una rejilla de catorce campos, cada etiqueta se comprime a dos palabras porque catorce frases quedarían absurdas. Con una pantalla entera, una pregunta puede llevar una frase que explique por qué la haces. Y «¿por qué me preguntan esto?» es la verdadera causa de que se abandone la pregunta incómoda, no el esfuerzo de escribir.
El contraargumento honesto
Los formularios de una pregunta son peores para algunas cosas, y quien los vende rara vez dice cuáles.
Formularios cortos. Tres campos en una pantalla está bien. Partirlos en tres pantallas añade dos transiciones para no ahorrarle nada a nadie, y hace que el formulario parezca más largo de lo que es.
Formularios que se rellenan a menudo. Si alguien envía el mismo formulario cada semana, quiere la rejilla densa. Se sabe los campos, tabula entre ellos, y tu amable flujo de una en una es ahora fricción semanal.
Cualquier cosa que exija comparar respuestas. Si la pregunta nueve solo tiene sentido junto a lo que pusieron en la cuatro, enseñarlas de una en una esconde lo que necesitan ver.
El caso más fuerte para una pregunta por pantalla es justo donde más falta le hace a un fundador: un formulario enviado en frío a gente sin relación previa contigo, que se rellena una vez, y en el que cada pregunta necesita explicación. Investigación de clientes, en otras palabras.
Lo que DevForm guarda y un formulario normal no
Una respuesta parcial se guarda en cuanto alguien contesta la primera pregunta. No al enviar.
Es la característica que más defendería, porque convierte el formulario abandonado de una ausencia en evidencia. La bandeja de respuestas muestra por separado las cifras exactas de completas y sin terminar, y las sin terminar te dicen dónde para la gente.
Un grupo de abandonos en una pregunta concreta es lo más accionable que produce un formulario. Suele significar una de tres cosas, y normalmente se distingue releyendo la pregunta:
- Pide algo que no tienen a mano.
- Pide algo que todavía no quieren dar, y no has explicado por qué lo necesitas.
- Es ambigua, y parar es más fácil que adivinar.
Nada de eso se ve en una tasa de finalización. Solo se ve si las respuestas parciales se guardan.
Las parciales se borran a los treinta días: quien empezó un formulario y se fue no aceptó que guardaras la mitad de sus respuestas indefinidamente.
La lógica condicional, donde suelen romperse
La otra mitad de «la gente termina» es no preguntar lo que no aplica. Las condiciones de DevForm son
deliberadamente pocas —es, no es, es una de, fue contestada, no fue contestada— y lo
interesante no son los operadores.
Es que el editor te avisa de tres errores concretos:
- Una condición que apunta a un campo que ya no existe.
- Una condición que apunta a una pregunta posterior en el formulario.
- Una condición que se apunta a sí misma.
Los tres producen un formulario que parece correcto y se comporta mal, normalmente saltándose una pregunta en silencio. Las referencias hacia delante son las peores, porque se leen perfectamente y no pueden funcionar: cuando se evalúa la condición, esa pregunta aún no se ha hecho.
Un formulario con ramas que no puedes verificar es peor que uno lineal que sí. Por eso la lista de operadores es corta: cinco condiciones que te caben en la cabeza ganan a veinte que no.
Lo que no hay
- Sin subida de archivos. En ningún plan. El control está desactivado en el editor.
- Sin correos de aviso. No llega nada cuando alguien responde: miras la bandeja o exportas.
- Sin webhooks, integraciones, pagos, firmas ni cálculos.
Si tu formulario necesita adjuntar un documento, DevForm es la herramienta equivocada hoy, y no hay plan que lo cambie.
Cómo conseguir el número que yo no te puedo dar
Haz la comparación tú, una vez, con un formulario que ibas a enviar igualmente:
- Monta las mismas preguntas dos veces: una por pantalla, y todas en una página.
- Reparte el tráfico. Dos enlaces a dos formularios basta.
- Compara completados sobre empezados, no sobre visitas. Una visita que nunca contestó la primera pregunta es un resultado sobre tu página, no sobre tu formulario.
- Dale dos semanas y unos cientos de inicios antes de creerte ninguno de los dos números.
Lo que salga hablará de tus preguntas, tu público y tu tráfico, que es más de lo que puede decir cualquier referencia publicada.