Como usar UX writing para reduzir o abandono de formulários

O visitante leu a página do serviço, comparou a proposta com outras duas opções e decidiu pedir uma conversa. No formulário, encontra sete campos, um deles pedindo o faturamento anual, e um botão com a palavra 'Enviar'. Ninguém explica por que o faturamento importa, quem vai ler a mensagem nem quando chega a resposta. A aba fecha.

No relatório, essa visita aparece como sessão engajada sem conversão. Para quem responde por geração de demanda, ela custa duas vezes: a empresa pagou para trazer a pessoa até ali, e o contato não chegou ao comercial. Entre as explicações possíveis está o texto da interface, que é o campo de trabalho do UX writing.

Neste artigo, você vai entender como identificar se o problema está mesmo no texto, quais conteúdos do formulário merecem revisão, como fica uma boa reescrita, com exemplos de antes e depois, e como avaliar se a mudança trouxe resultado.

Por que o visitante chega ao formulário e não conclui o envio?

Em um site B2B, o formulário de contato costuma ser preenchido por alguém que ainda avalia fornecedores. Enviar os dados é um compromisso pequeno, porém real: a pessoa expõe nome, cargo e empresa a um time comercial que ainda não conhece. Antes de clicar, ela mede esse custo, e cada dúvida sem resposta aumenta o peso da decisão.

Quatro dúvidas resumem boa parte desse atrito:

• Para que serve este formulário? Um bloco intitulado 'Fale conosco' não diz se a pessoa vai pedir orçamento, agendar uma conversa ou receber um material. Sem essa informação, o visitante não sabe se está no lugar certo;

• Por que pedem esse dado? Faturamento, número de funcionários ou celular parecem invasivos quando aparecem sem contexto. A hesitação não vem do esforço de preencher, e sim da incerteza sobre o uso da informação;

• O que eu fiz de errado? Uma mensagem como 'Campo inválido' indica que há um problema, sem dizer qual nem como resolver. Se o erro se repete, o visitante passa a adivinhar o formato esperado;

• O que acontece depois do envio? Sem saber quem responde, por qual canal e em quanto tempo, a pessoa clica sem ideia do resultado. Para quem precisa levar fornecedores ao gestor até sexta-feira, o prazo pesa tanto quanto a proposta.

Nenhuma dessas dúvidas prova, sozinha, que o problema está na escrita. Um formulário com rótulos impecáveis também perde contatos quando a página atrai o público errado, quando o botão não responde no celular ou quando a oferta não convence. O texto entra no diagnóstico como uma hipótese entre várias.

O que é UX writing e qual é seu papel na conversão?

UX writing é a prática de escrever os textos que fazem parte da interface: rótulos de campos, botões, instruções, mensagens de erro, confirmações e avisos. Esses textos orientam a pessoa enquanto ela usa o site, dizem o que é esperado em cada etapa e ajudam a prevenir ou corrigir erros.

O termo microcopy costuma aparecer como sinônimo. A diferença é de escala: microcopy é a peça, como a frase abaixo de um campo, e UX writing é a disciplina que decide o que cada peça diz, onde aparece e como se relaciona com as outras.

Como o UX writing se integra ao design e ao desenvolvimento?

Em muitas empresas, os textos do formulário ficam entre áreas. O marketing escreve a página, o design desenha os campos e o desenvolvimento implementa a validação, mas ninguém responde pela frase que aparece quando o e-mail está errado. O resultado é o texto padrão da biblioteca de componentes, quase sempre genérico ou traduzido ao pé da letra.

Um trabalho de UX writing fecha essa lacuna ao tratar texto, interface e código como partes do mesmo projeto, desde o wireframe. Para entender como pesquisa, dados e design de interface entram no mesmo processo, veja o que faz uma consultoria em UX.

“No protótipo, o formulário quase sempre aparece em dois estados: vazio e preenchido. Os estados que mais pesam na conversão ficam no meio, como o e-mail digitado errado, o envio que falhou e a tela de confirmação. Quando a gente desenha esses momentos com o texto definitivo, descobre cedo se a mensagem cabe no layout e se o botão diz o que vai acontecer.” - Rafael Andrighetti, Head de Design da Dexa

Como descobrir se o abandono está no texto, no design ou no funcionamento?

Antes de aprovar uma reescrita, a liderança precisa saber onde a perda acontece. O formulário é a última etapa de um funil de conversão, e problemas de etapas anteriores costumam estourar nele. Uma página que atrai buscas informacionais gera visitas sem intenção de pedir orçamento, e nenhum microtexto muda isso.

Um time especializado costuma começar pelo Google Analytics 4. A ferramenta registra dois eventos úteis: form_start, quando alguém interage pela primeira vez com o formulário na sessão, e form_submit, quando envia, segundo a documentação do Google. A comparação entre eles separa quem nem começou de quem começou e desistiu, duas situações com causas diferentes.

Esses números pedem conferência, porque formulários de ferramentas externas podem exigir configuração específica. Para saber em qual campo as pessoas travam, o time configura eventos de erro por campo, sem registrar o que foi digitado, já que o Google exige que nenhuma informação de identificação pessoal seja coletada.

Os dados indicam onde a perda acontece, e os testes de usabilidade mostram por quê. Observar pessoas do público-alvo preenchendo o formulário enquanto falam o que pensam revela dúvidas que nenhum relatório registra, como a hesitação diante do campo de faturamento.

A quantidade de campos também entra na análise. Cada campo novo cobra tempo e uma decisão do visitante, e alguns dados podem ficar para a primeira conversa. Cortar campos e reescrever textos são intervenções diferentes, e aplicá-las ao mesmo tempo impede saber qual delas funcionou.

Quais textos do formulário precisam ser avaliados?

Quando o diagnóstico aponta para o preenchimento, a revisão começa por um inventário dos textos do formulário. Cada um tem uma função, e o problema costuma aparecer quando um elemento tenta cumprir a função de outro.

Por que o placeholder não deve substituir o rótulo?

O placeholder é o texto cinza dentro do campo, que some quando a pessoa começa a digitar. Usado como rótulo, ele obriga o visitante a lembrar o que cada campo pedia. O tutorial de formulários do W3C aponta outros dois problemas: leitores de tela não tratam o placeholder como rótulo, e os navegadores costumam exibi-lo com contraste abaixo do mínimo recomendado.

Para a empresa, o efeito é duplo. O formulário perde contatos e deixa de atender o critério 3.3.2 das WCAG 2.2, as diretrizes de acessibilidade do W3C, que pede rótulos ou instruções sempre que o conteúdo exige entrada de dados. A correção é simples: rótulo visível fora do campo e placeholder reservado para um exemplo, como 'nome@empresa.com.br'.

Por que explicar a finalidade de um dado pedido?

Campos de qualificação, como cargo, porte da empresa ou orçamento previsto, ajudam o comercial a preparar a primeira conversa. Sem explicação, o visitante os lê como triagem. Uma linha de ajuda muda essa leitura: 'Usamos essa informação para indicar uma pessoa do time com experiência no seu segmento'.

O guia de simplificação de formulários do gov.br segue a mesma linha. Ele recomenda explicar a necessidade de cada informação.

A LGPD reforça o raciocínio. O artigo 6º da Lei 13.709/2018 estabelece princípios como finalidade, necessidade e transparência: o tratamento de dados deve ter propósito informado ao titular e se limitar ao mínimo necessário. A adequação jurídica do formulário cabe ao jurídico ou ao encarregado de dados da empresa.

Como escrever instruções e mensagens de erro mais úteis?

Uma revisão bem feita começa por prevenir o erro. Se o campo de CEP aceita só números, a instrução diz isso antes da digitação. Se o telefone exige DDD, um exemplo mostra o formato. Revelar a regra só depois do envio obriga a pessoa a errar para descobrir o que era esperado.

Quando o erro acontece, a mensagem cumpre duas tarefas: explica o que deu errado e diz como corrigir. O GOV.UK Design System, padrão de interface do governo britânico testado em serviços públicos, recomenda exibir a mensagem ao lado do campo e manter tudo o que a pessoa digitou, inclusive as respostas corretas.

O mesmo guia aponta o que atrapalha. Palavras como 'válido' e 'inválido' não acrescentam nada, jargão técnico não ajuda a corrigir, e uma mensagem genérica como 'Campo obrigatório' não diz à pessoa o que fazer em seguida. Outra orientação útil é repetir as palavras do rótulo na mensagem, para que a pessoa ligue o erro ao campo certo.

Exemplos de mensagens de erro: antes e depois

O último exemplo mostra que, às vezes, a melhor mensagem de erro é a que o sistema não exibe, porque o código aceita as variações comuns de formato.

Leia também: Tom de voz da marca: como construir uma linguagem reconhecível e consistente

Como os textos podem esclarecer o que acontece após o envio?

A dúvida sobre o próximo passo pesa justamente no último clique, e o botão é o primeiro lugar para respondê-la. Como recomenda o guia do gov.br, botões com rótulos descritivos, como 'Solicitar proposta' e 'Agendar conversa', dizem o que acontece depois do clique, enquanto 'Enviar' não diz nada sobre o resultado.

Logo abaixo do botão, uma linha curta pode informar quem responde, por qual canal e em quanto tempo. A página ou mensagem de confirmação fecha o ciclo: confirma que o pedido chegou, explica o que acontece em seguida e, quando faz sentido, sugere como a pessoa pode se preparar para a conversa.

Antes: 'Obrigado! Mensagem enviada com sucesso.'

Depois: 'Recebemos seu pedido. Uma pessoa do time de [área] vai ler sua mensagem e responder por e-mail em até [prazo real do comercial]. Para adiantar a conversa, separe o endereço do site atual e o principal objetivo do projeto.'

Os dados entre colchetes são uma decisão de gestão, e não de redação. Prazo, canal e responsável devem corresponder ao processo real do comercial. Se o time responde em até dois dias úteis, prometer retorno em 24 horas troca uma dúvida por uma frustração, que aparece logo no primeiro contato.

Como medir se a revisão de UX writing melhorou o formulário?

Uma revisão só se prova com números comparáveis. Antes de qualquer mudança, o time registra a linha de base dos indicadores por algumas semanas, separando computador e celular e, se possível, origem do tráfego. A lógica é a mesma de ligar métricas de UX a objetivos de negócio: cada número responde a uma pergunta que a liderança faz.

• Taxa de início: sessões com form_start divididas pelas sessões da página. Mostra se o formulário convida ao preenchimento;

• Taxa de conclusão: envios divididos por inícios. É o indicador mais ligado aos rótulos, às instruções, aos erros e ao botão;

• Erros por campo: quantas vezes cada validação dispara. O GOV.UK Design System recomenda acompanhar essa frequência para revisar textos e testar variações;

• Qualidade dos contatos: proporção de envios que o comercial considera aderentes ao perfil de cliente.

Quando o volume de visitas permite, o teste A/B é o caminho mais confiável: parte do tráfego vê a versão atual e parte vê a revisada no mesmo período, o que neutraliza sazonalidade e campanhas. Formulários B2B costumam receber poucos envios por mês, e o teste pode demorar a chegar a um resultado confiável. Nesses casos, a comparação de antes e depois funciona, com períodos equivalentes e sem outras mudanças na página.

O número de envios, sozinho, não julga a revisão. Um formulário que explica melhor para quem o serviço é indicado pode receber menos contatos e gerar mais oportunidades reais.

Por onde começar a revisão do formulário?

Há um teste que qualquer gestor faz em poucos minutos: preencher o próprio formulário no celular, como um visitante faria, cometendo os erros mais prováveis. E-mail sem arroba, telefone com parênteses, campo obrigatório em branco. Cada momento de dúvida vira uma hipótese para o diagnóstico.

Quando a investigação envolve texto, design, desenvolvimento e dados ao mesmo tempo, ajuda ter essas áreas no mesmo projeto. Na Dexa, Experience Design, Enterprise Technology e Digital Growth fazem parte do mesmo time, o que permite testar uma hipótese de escrita sem perder de vista a integração com o CRM ou a origem do tráfego.

Perguntas frequentes sobre UX writing em formulários