Formulário que as pessoas terminam: ordem, validação e erro

Se você tem um funil com formulário, ele é quase sempre a etapa onde mais gente some. E raramente por um motivo dramático — é acúmulo de atrito pequeno, cada um sozinho parecendo aceitável.

A boa notícia é que as causas são poucas e conhecidas. Dá para corrigir a maioria sem redesenhar nada.

1. Cada campo precisa se justificar

A pergunta antes de qualquer decisão visual: o que acontece se este campo não existir?

Se a resposta for "seria bom ter para segmentar depois", ele não deveria ser obrigatório — talvez nem deveria existir agora. Todo campo tem custo de conversão, e informação que você pode pedir depois, peça depois.

Três padrões que aparecem em quase todo formulário e quase sempre custam mais do que rendem:

• Telefone em cadastro que não vai ligar. É o campo que mais gera abandono, porque a pessoa entende que vai receber ligação.
• Confirmar e-mail. Não impede erro de digitação — quem digita errado, digita errado duas vezes ou cola. Melhor validar o formato e mandar confirmação.
• Nome separado em dois campos quando você só vai usar junto.

2. A ordem muda a taxa de abandono

Comece pelo fácil e pelo que a pessoa entende por que você precisa. Termine pelo que exige esforço ou desconfiança.

Isso não é truque psicológico — é reduzir a chance de a pessoa travar antes de ter investido algo. Quem já preencheu quatro campos tende a terminar o quinto; quem trava no primeiro sai sem nunca ter começado.

Agrupe por assunto e deixe o agrupamento visível. Um formulário de doze campos corridos assusta; os mesmos doze em três blocos de quatro, com título, parecem administráveis.

3. Rótulo em cima, sempre

Rótulo dentro do campo, que some quando você digita, parece limpo e cria um problema real: no meio do preenchimento, a pessoa não lembra mais o que aquele campo pedia. Em formulário longo, ela precisa apagar para conferir.

Rótulo acima do campo resolve, e tem vantagens que não são estéticas:

• Continua visível durante a digitação e na revisão final
• Não quebra quando o texto é longo ou traduzido
• Funciona com leitor de tela sem depender de atributo extra

E o rótulo precisa ser um <label> ligado ao campo. Além de acessibilidade, isso dá um ganho gratuito: clicar no texto foca o campo, o que aumenta bastante a área de toque no celular.

4. Valide na hora certa

Este é o detalhe que mais irrita e o mais fácil de errar.

Validar a cada tecla é hostil. A pessoa digita a primeira letra do e-mail e já vê "e-mail inválido" em vermelho. Ela sabe que está incompleto — você está avisando de um erro que ela está no meio de não cometer.

Validar só no envio é tarde. A pessoa preenche tudo, clica, e recebe quatro erros de uma vez, em campos que ela já esqueceu.

O meio-termo que funciona: validar quando o campo perde o foco, e a partir daí, se estava errado, validar enquanto digita — para o erro sumir assim que for corrigido. Ninguém quer continuar vendo a mensagem depois de arrumar.

Quando o valor é recusado, o movimento ajuda a comunicar antes da leitura:

Amplitude pequena e duração curta. E o movimento não substitui o texto — ele chega antes. Quem usa leitor de tela não vê balanço nenhum, então a mensagem continua obrigatória.

5. A mensagem de erro tem três obrigações

Dizer o que está errado, por quê e como corrigir. Faltando uma das três, ela vira obstáculo.

• ❌ "Campo inválido" — não diz nada
• ❌ "Senha inválida" — inválida por quê?
• ✅ "A senha precisa de pelo menos 8 caracteres. Faltam 3."

E a mensagem fica junto do campo, não numa faixa no topo. Erro no topo obriga a pessoa a procurar qual campo ele descreve — em formulário longo, ela nem vê a faixa se a página não rolar.

Três regras de acessibilidade que costumam faltar: cor não pode ser o único sinal (use ícone ou texto também), o campo com erro precisa de aria-invalid, e a mensagem precisa estar ligada ao campo por aria-describedby — senão quem usa leitor de tela sabe que há erro mas não qual.

6. Impedir o erro é melhor que avisar

Boa parte dos erros nem precisa acontecer:

• Tipo de campo certo — type="email", type="tel". No celular, isso muda o teclado que aparece, o que reduz erro e digitação.
• Preenchimento automático — o atributo autocomplete deixa o navegador preencher endereço e cartão. É a maior economia de tempo disponível e a mais ignorada.
• Aceitar formatos variados — se você aceita CPF, aceite com e sem pontuação. Limpar a string no seu código custa uma linha; obrigar a pessoa a adivinhar o formato custa desistência.
• Mostrar a regra antes — requisito de senha visível desde o começo, não como erro depois da tentativa.

7. O botão de enviar precisa se comportar

Três coisas que faltam com frequência:

Desabilitar durante o envio. Sem isso, o clique duplo cria dois cadastros. E precisa ser o atributo real, não só a aparência de desabilitado.

Mostrar que está processando. Se a requisição demora dois segundos e nada muda na tela, a pessoa clica de novo.

Não perder o que foi digitado. Se o envio falha, os dados continuam lá. Formulário que limpa tudo após erro é a forma mais rápida de perder alguém para sempre.

Um padrão que evita o salto de layout na confirmação — os dois estados ocupam a mesma célula, então o botão não muda de tamanho:

8. Teste com teclado antes de publicar

Leva um minuto e revela o que o mouse esconde. Sem tocar no mouse:

1. Tab passa por todos os campos, na ordem visual?
2. Dá para ver onde o foco está, em todos eles?
3. Enter envia o formulário?
4. Quando dá erro, o foco vai para o primeiro campo com problema?

Se algum falhar, uma parte do seu público não consegue completar — e não vai reclamar, vai só sair.

O resumo

Corte campo que não se justifica. Rótulo em cima. Valide ao sair do campo, não a cada tecla. Mensagem específica e junto do campo. Impeça o erro em vez de avisar. Botão que não deixa clicar duas vezes e não apaga nada.

Nada aqui exige redesenho. É a diferença entre um formulário que as pessoas terminam e um que elas fecham no meio — e você nunca fica sabendo por quê.