Começo pelo que este texto não consegue fazer, porque muda como o resto deve ser lido.
Não tenho números de conclusão para mostrar. O DevForm é novo, ninguém rodou formulários suficientes por ele para que uma porcentagem signifique algo, e a internet está cheia de afirmações do tipo «formulários de uma pergunta convertem 40% melhor» que sempre acabam num post de um fornecedor falando dos próprios clientes. Repetir uma dessas seria pegar emprestado um número que não posso conferir para vender um produto que eu mesmo construí.
Então: o mecanismo, o que o produto mede, e como descobrir por conta própria.
O que um formulário longo pede de alguém
Você abre um formulário de catorze campos e toma uma decisão antes de responder qualquer coisa: vale a pena?
Toma essa decisão com tudo à vista. Cada campo em branco está na sua frente, a barra de rolagem avisa que tem mais embaixo, e as duas perguntas que você preferia não responder estão ali, visíveis. O custo da interação inteira é apresentado de uma vez, no momento em que a pessoa tem menos interesse investido e menos ideia de por que aquilo tudo está sendo perguntado.
Uma pergunta por tela inverte isso. Agora a decisão é «respondo esta pergunta?», tomada várias vezes, cada uma por alguém um pouco mais comprometido que na anterior. O trabalho total é o mesmo. A sequência de decisões não é, e as pessoas não avaliam uma série de custos pequenos como avaliam um grande.
Há um segundo efeito de que se fala menos e que provavelmente vale mais: uma pergunta sozinha numa tela pode ser bem escrita. Numa grade de catorze campos, cada rótulo é espremido em duas palavras, porque catorze frases ficariam absurdas. Com uma tela inteira, a pergunta pode trazer uma frase explicando por que você está perguntando. E «por que estão me perguntando isso?» é a causa real do abandono na pergunta constrangedora, não o esforço de digitar.
O contra-argumento honesto
Formulários de uma pergunta são piores para algumas coisas, e quem os vende raramente diz quais.
Formulários curtos. Três campos numa tela está ótimo. Dividir em três telas acrescenta duas transições sem economizar nada de ninguém, e faz o formulário parecer mais longo do que é.
Formulários preenchidos com frequência. Se alguém envia o mesmo formulário toda semana, essa pessoa quer a grade densa. Ela sabe os campos, tabula entre eles, e o seu fluxo gentil de um em um virou atrito semanal.
Qualquer coisa que exija comparar respostas. Se a pergunta nove só faz sentido ao lado do que puseram na quatro, mostrar uma de cada vez esconde justamente o que precisam ver.
O caso mais forte para uma pergunta por tela é exatamente onde a maioria dos fundadores precisa: um formulário enviado a frio para pessoas sem relação prévia com você, preenchido uma vez, em que cada pergunta precisa de explicação. Pesquisa com clientes, em outras palavras.
O que o DevForm registra e um formulário comum não
Uma resposta parcial é gravada assim que alguém responde a primeira pergunta. Não no envio.
É a característica que eu mais defenderia, porque transforma o formulário abandonado de ausência em evidência. A caixa de respostas mostra separadamente as contagens exatas de completas e não terminadas, e as não terminadas dizem onde as pessoas param.
Um agrupamento de abandonos numa pergunta específica é a coisa mais acionável que um formulário produz. Costuma significar uma de três coisas, e dá para distinguir relendo a pergunta:
- Pede algo que a pessoa não tem à mão.
- Pede algo que ela ainda não quer dar, e você não explicou por que precisa.
- É ambígua, e parar é mais fácil que adivinhar.
Nada disso aparece numa taxa de conclusão. Só aparece se as respostas parciais forem guardadas.
As parciais são apagadas depois de trinta dias: quem começou um formulário e foi embora não concordou em você guardar metade das respostas para sempre.
A lógica condicional, onde os formulários costumam quebrar
A outra metade de «as pessoas terminam» é não perguntar o que não se aplica. As condições do DevForm
são poucas de propósito — é, não é, é uma de, foi respondida, não foi respondida — e o
interessante não são os operadores.
É que o editor avisa sobre três erros específicos:
- Uma condição que aponta para um campo que não existe mais.
- Uma condição que aponta para uma pergunta posterior no formulário.
- Uma condição que aponta para si mesma.
Os três produzem um formulário que parece correto e se comporta errado, geralmente pulando uma pergunta em silêncio. As referências para frente são as piores, porque se leem perfeitamente e não têm como funcionar: quando a condição é avaliada, aquela pergunta ainda não foi feita.
Um formulário com ramos que você não consegue verificar é pior que um linear que você consegue. Daí a lista curta: cinco condições que cabem na cabeça ganham de vinte que não cabem.
O que não existe
- Sem upload de arquivos. Em nenhum plano. O controle fica desativado no editor.
- Sem e-mails de aviso. Nada chega quando alguém responde: você olha a caixa ou exporta.
- Sem webhooks, integrações, pagamentos, assinaturas ou cálculos.
Se o seu formulário precisa anexar um documento, o DevForm é a ferramenta errada hoje, e não há plano que mude isso.
Como conseguir o número que eu não pude dar
Faça a comparação você mesmo, uma vez, com um formulário que ia mandar de qualquer jeito:
- Monte as mesmas perguntas duas vezes: uma por tela, e todas numa página só.
- Divida o tráfego. Dois links para dois formulários basta.
- Compare concluídos sobre iniciados, não sobre visitas. Uma visita que nunca respondeu a primeira pergunta é um resultado sobre a sua página, não sobre o formulário.
- Dê duas semanas e algumas centenas de inícios antes de acreditar em qualquer um dos dois números.
O que sair vai falar das suas perguntas, do seu público e do seu tráfego — mais do que qualquer referência publicada consegue dizer.