Conversão
Formulário de orçamento: a mensagem de erro afasta o contato?
Antes de mudar perguntas ou investir em mais tráfego, vale conferir se o formulário aceita quem tenta enviar. Um teste campo a campo ajuda a decidir o que manter, relaxar ou explicar.
Quem chega ao formulário de orçamento normalmente já fez a parte difícil: decidiu falar com a sua empresa. Por isso, uma mensagem de erro vaga ou uma regra rígida demais pode atrapalhar mais do que parece. A pergunta útil não é se o formulário valida, e sim quais validações protegem a sua operação e quais apenas impedem uma pessoa de terminar. O caminho para responder é testar cada campo com dados reais, olhar o erro que aparece e decidir se ele deve ser mantido, relaxado ou explicado.
O que o navegador já faz e onde ele para
A web.dev explica que os navegadores trazem validação embutida: com o atributo de obrigatório e com tipos como e-mail, o próprio navegador checa o formato e exibe um aviso. A mesma página lembra que o texto desse aviso varia conforme navegador e idioma, e que é possível definir mensagens próprias com a Constraint Validation API. Ela também indica que os dados precisam ser validados no servidor antes de serem armazenados.
O W3C diz algo complementar: a validação no navegador melhora a experiência, mas pode ser contornada, então não basta. Na prática, há duas camadas, cada uma com um papel. A do navegador orienta quem preenche; a do servidor protege o dado que chega ao seu CRM. Uma decisão sobre o formulário deveria considerar as duas, e a mensagem que a pessoa lê vem, em geral, da primeira.
Roteiro de teste por campo
Monte uma planilha com uma linha por entrada testada e preencha o formulário em celular e computador, em mais de um navegador. Use formas como as pessoas realmente digitam, inclusive as que você considera imperfeitas.
| Campo | Entradas para testar | O que registrar |
|---|---|---|
| Telefone | Com e sem DDD, com parênteses, espaços ou hífen, com +55, só números | Mensagem exibida, se o envio foi bloqueado, se o dado chegou legível |
| Com espaço no fim, letras maiúsculas, domínio corporativo longo, endereço com subdomínio | Mensagem exibida e se o texto está em português | |
| CNPJ | Com e sem pontuação, colado de outro documento, com espaço extra | Mensagem exibida e se o campo é realmente obrigatório para orçar |
Acrescente quatro colunas: mensagem atual, classificação do erro, mensagem reescrita e responsável pelo ajuste. Faça o teste com pessoas diferentes do time, porque quem construiu o formulário tende a digitar do jeito que ele espera. Lembre também que o resultado vale para as entradas que você testou: se nenhuma falha apareceu, isso mostra apenas que essas formas passaram, não que todas as variações possíveis passariam.
Como classificar cada erro
O W3C recomenda que a validação seja tolerante a formatos diferentes de entrada, citando telefones com separadores distintos como exemplo. Com base nisso, uma forma de avaliar cada falha é separá-la em três grupos.
- Necessário: o dado é inválido de fato e impediria o contato (e-mail sem arroba, por exemplo). Mantenha, com mensagem clara.
- Evitável: o dado é válido, mas escrito de outro jeito (pontuação no CNPJ, espaço no telefone). Relaxe: aceite e normalize por trás.
- Mal explicado: a regra faz sentido, mas a pessoa não sabe qual é. Mantenha a regra e explique o formato antes do envio, junto ao campo.
Um exemplo hipotético: se o campo de CNPJ rejeita números colados com pontos e barra, o teste vai mostrar uma falha evitável. A correção provável é aceitar qualquer pontuação e limpar o valor no servidor. Já a decisão de pedir CNPJ ou não pertence à escolha das perguntas, tema do artigo sobre perguntas no primeiro contato.
Reescrevendo a mensagem
O W3C pede mensagens concisas, fáceis de entender e com instrução simples de como corrigir. A web.dev acrescenta que cor sozinha não basta para indicar erro, então use texto ou ícone. Uma estrutura que costuma funcionar é dizer qual campo, o que ocorreu e como resolver, como em “Telefone: inclua o DDD, por exemplo (11) 99999-0000”. Compare com “Valor inválido”, que obriga a pessoa a adivinhar.
Vale ainda avisar o formato esperado antes de errar, ligar a explicação ao campo e rotular cada campo de forma clara, algo que a web.dev trata como base de qualquer formulário. O W3C observa que, quando o dado segue um formato específico, checar ao sair do campo costuma fazer mais sentido do que a cada tecla, porque a pessoa não vê erro enquanto ainda digita.
Depois dos ajustes, repita o teste e acompanhe, na ferramenta que você usa, onde as pessoas desistem e quantos envios chegam completos, sempre com o número de tentativas como denominador. Mudanças de tráfego, de período ou de perfil de visitante também alteram esses números, então uma comparação de antes e depois mostra sinais, não a causa. Nada garante que mensagens melhores gerem mais orçamentos; separar o efeito da mudança exigiria um desenho mais cuidadoso, como mostrar a versão antiga e a nova ao mesmo tempo para grupos comparáveis.
Comece pelo campo com mais entradas classificadas como evitáveis, reescreva a regra ou a mensagem dele e anote a data da mudança, para interpretar os números seguintes com cautela. Se quiser observar como pessoas reais lidam com o formulário, o texto sobre teste de usabilidade ajuda a definir como fazer.
