Quase tudo o que se publica em português sobre UX writing fala com quem quer virar UX writer: o que estudar, quanto ganha, que curso fazer, quais princípios decorar. Para quem está mudando de carreira, é material útil. Para a empresa que tem um site com formulário de contato, uma área de cliente ou uma loja on-line, falta a parte que importa no dia a dia.
Essa parte é concreta. O texto que aparece dentro da interface — o rótulo do campo, o botão, a mensagem de erro, o aviso de que deu certo — não é só questão de estilo. Uma fatia dele é critério verificável de acessibilidade, com número e nível, e no Brasil a lei manda seguir esse tipo de diretriz. É dessa fatia que este artigo trata, com exemplos para reescrever ainda esta semana.
O que é UX writing?
UX writing é a escrita do texto que a pessoa lê enquanto usa um produto digital: site, aplicativo, sistema, caixa eletrônico, painel de cliente. Rótulos de campo, botões, menus, mensagens de erro, avisos de confirmação, telas vazias, instruções de senha. São frases curtas, quase sempre lidas no meio de uma tarefa, por alguém que quer terminar logo o que começou.
A sigla UX vem de user experience, experiência do usuário. O nome diz o objetivo: o texto existe para que a experiência funcione, não para chamar atenção. Um bom texto de interface quase nunca é notado; um ruim é notado sempre, porque é nele que a pessoa trava, desiste ou liga para o atendimento.
Na prática, UX writing responde a uma pergunta só: o que essa pessoa precisa saber, neste ponto exato da tela, para dar o próximo passo sem errar? Tudo o que não ajuda a responder isso sobra. Tudo o que falta para responder isso é defeito — e, como se verá adiante, alguns desses defeitos têm nome técnico.
O que faz um UX writer — e quem escreve isso na sua empresa?
Em empresas de produto digital grandes, o UX writer é a pessoa que define o texto de cada tela junto com design e desenvolvimento. Ele mapeia o fluxo, escreve as variações de cada estado (vazio, carregando, erro, sucesso), mantém um guia de voz e tom e testa com usuários se as frases são entendidas como deveriam.
Na maioria das empresas brasileiras de médio porte, esse cargo não existe. O texto da interface é escrito por quem estiver mais perto na hora: o desenvolvedor que montou o formulário, o designer que desenhou a tela, o fornecedor do plugin de e-commerce, o tema pronto em inglês traduzido às pressas. O resultado é o site que diz "Campo obrigatório" em vermelho sem dizer qual campo, ou o botão "Enviar" que ninguém sabe se envia um pedido ou só uma dúvida.
Não é preciso contratar um UX writer para resolver isso. É preciso que alguém seja dono do texto da interface, com um critério para revisar. A boa notícia é que parte desse critério já está escrita, é pública e é gratuita.
Qual a diferença entre UX writing, copywriting e content design?
Os três são texto, e muitas vezes a mesma pessoa escreve os três. O que muda é a pergunta que cada um responde e a régua que mede se funcionou. Misturar as réguas gera o botão que tenta vender ("Quero transformar meu negócio!") quando deveria só dizer o que acontece ao clicar.
| UX writing | Copywriting | Conteúdo | |
|---|---|---|---|
| Objetivo | Fazer a pessoa concluir a tarefa | Levar a pessoa a uma ação | Informar e construir confiança |
| Momento | Durante o uso | Na decisão | Antes da decisão |
| Tamanho típico | De uma palavra a duas frases | Do título à página longa | Do post ao guia completo |
| Tom | Neutro, direto, previsível | Persuasivo, com pedido explícito | Explicativo, com profundidade |
| Métrica | Conclusão, erros, chamados ao suporte | Clique, pedido, conversão | Tráfego qualificado, retorno, citação |
| Regra externa | Critérios de acessibilidade (WCAG) | Código do consumidor e autorregulação publicitária | Direito autoral e veracidade da informação |
Content design é um termo mais amplo, usado sobretudo em equipes de produto: em vez de começar pelo texto, começa pela necessidade do usuário e decide se a resposta é uma frase, uma tabela, um vídeo ou uma mudança no próprio fluxo. Na prática, quem faz content design também faz UX writing; a diferença está em quanto da decisão de formato fica com quem escreve.
Se a sua empresa está decidindo por onde começar, a sequência mais segura é: primeiro, o texto que impede a pessoa de concluir uma tarefa (UX writing); depois, o texto que convence (copy); por fim, o texto que atrai e educa (conteúdo). Um formulário que ninguém consegue preencher anula o melhor anúncio. Sobre o lado persuasivo, vale ler o nosso artigo sobre copywriting e a promessa que precisa de prova.
Por que o texto da interface virou critério de acessibilidade?
Porque, para muita gente, o texto é a única parte da interface que chega. Quem usa leitor de tela não vê a borda vermelha em volta do campo errado; ouve o que estiver escrito. Quem não distingue vermelho de verde não percebe o ícone colorido. Quem tem dificuldade de leitura, ou está no celular com uma mão só, precisa de frases que digam exatamente o que fazer.
As Diretrizes de Acessibilidade para Conteúdo Web, a WCAG, organizam isso em critérios de sucesso testáveis, cada um com nível A (o mínimo), AA (o patamar que a maioria das legislações e contratos exige) ou AAA. Vários desses critérios falam diretamente do texto: não pedem um tom de voz, pedem que certa informação esteja escrita.
Repare no detalhe: "em texto". Uma mensagem de erro que só existe como cor, ícone ou campo tremendo não cumpre o critério, por mais bonita que seja. E "identificado" significa que a pessoa precisa saber qual campo está errado — "Há erros no formulário" no topo da página, sem apontar onde, não basta.
O que a WCAG exige, critério por critério, do texto de um formulário?
Os critérios mais diretamente ligados ao texto ficam na diretriz 3.3, "Assistência de entrada", e em mais alguns pontos espalhados pelo documento. A tabela resume o que cada um pede ao redator, em linguagem de quem escreve, não de quem programa.
| Critério | Nível | O que o texto precisa fazer |
|---|---|---|
| 3.3.1 Identificação do erro | A | Dizer qual campo está errado e descrever o erro em texto |
| 3.3.2 Rótulos ou instruções | A | Ter rótulo ou instrução em todo campo que pede dado |
| 3.3.3 Sugestão de erro | AA | Dizer como corrigir, quando a correção é conhecida |
| 3.3.4 Prevenção de erros | AA | Em compromisso legal ou financeiro, permitir revisar, corrigir ou desfazer |
| 2.4.6 Cabeçalhos e rótulos | AA | Títulos e rótulos que descrevem o assunto ou a finalidade |
| 2.5.3 Rótulo no nome | A | O nome técnico do botão contém o texto que aparece nele |
| 4.1.3 Mensagens de status | AA | Avisos de sucesso ou de erro anunciados sem mover o foco |
| 3.1.5 Nível de leitura | AAA | Versão mais simples quando o texto exige leitura avançada |
A exceção é importante e tem bom senso: na tela de login, o sistema sabe que a senha está errada, mas não deve sugerir qual é a certa. Fora casos assim, se o sistema sabe que a data está no formato errado, o texto precisa dizer qual é o formato certo. Se sabe que o CEP tem sete dígitos em vez de oito, precisa dizer isso, e não apenas "CEP inválido".
Dois critérios da tabela merecem atenção especial em sites comerciais. O 3.3.4 vale para qualquer página em que a pessoa assume compromisso legal ou financeiro — fechar pedido, assinar plano, aceitar contrato — e pede uma etapa de revisão, verificação ou desfazer. E o 4.1.3 cobre o aviso que aparece sem recarregar a página, como "Item adicionado ao carrinho": ele precisa ser anunciado para quem usa leitor de tela, o que depende tanto de quem escreve quanto de quem programa.
O texto do site precisa seguir regras de acessibilidade no Brasil?
Sim. Não existe uma lei brasileira específica sobre mensagens de erro, mas existe uma lei que obriga o site da empresa a ser acessível e remete às diretrizes internacionais — e a WCAG é a principal delas.
Três pontos dessa redação interessam a quem escreve o site. O primeiro: a obrigação é da empresa que mantém o site, não da agência nem do fornecedor da plataforma. O segundo: vale para quem tem sede ou representação comercial no país, o que inclui praticamente toda empresa que vende para brasileiros. O terceiro: o critério de cumprimento não é inventado caso a caso; são as diretrizes adotadas internacionalmente.
Isso não transforma cada "Campo inválido" em processo judicial. Mas muda a natureza da conversa interna: reescrever a mensagem de erro deixa de ser "melhoria de UX quando sobrar tempo" e passa a ser parte do que o site deve cumprir. Para as falhas técnicas que não dependem do texto — contraste, navegação por teclado, imagens sem descrição —, veja o nosso artigo sobre as falhas de acessibilidade digital mais comuns em sites.
Como escrever uma mensagem de erro que cumpre a WCAG?
Uma mensagem de erro boa tem quatro partes, nem sempre todas visíveis: onde está o problema, o que é o problema, como resolver e a garantia de que nada foi perdido. O antes e depois abaixo mostra a diferença no mesmo campo, com o mesmo erro de digitação.
1. Diga onde está o erro
A mensagem fica colada ao campo, e o nome do campo aparece nela quando há mais de um erro na tela. Se o formulário é longo, um resumo no topo lista os campos com problema e leva até cada um. "Corrija os erros abaixo" sem dizer quais não identifica nada.
2. Descreva o erro com as palavras de quem preenche
"Formato inválido" é a linguagem do sistema. "O CPF tem 10 números; ele precisa ter 11" é a linguagem de quem está com o documento na mão. Evite códigos, jargão técnico e frases que culpam a pessoa ("Você digitou errado"). O erro é um fato a resolver, não uma falha de caráter.
3. Ofereça a correção quando o sistema souber qual é
Esse é o passo que separa o nível A do AA. Se a data precisa estar no formato dia/mês/ano, mostre um exemplo. Se a senha precisa de oito caracteres, diga quantos faltam. Se o e-mail parece ter um erro comum de domínio, sugira a versão provável e deixe a pessoa confirmar.
4. Não dependa só da cor nem apague o que foi digitado
A borda vermelha é um reforço, não a mensagem. O texto do erro precisa existir por escrito e ser lido junto com o campo por tecnologias assistivas. E o formulário que volta em branco depois do erro obriga a pessoa a redigitar tudo — o tipo de atrito que faz alguém desistir no meio de um pedido de orçamento.
5. Avise antes, sempre que der
A melhor mensagem de erro é a que não precisa aparecer. Instruções curtas antes do campo ("Use só números", "Mínimo de 8 caracteres") cumprem o critério 3.3.2 e reduzem o erro na origem. Só não exagere: instrução em todo campo vira ruído, e ninguém lê ruído.
Quais são as boas práticas de UX writing além da mensagem de erro?
O erro é o ponto mais crítico, mas o mesmo raciocínio vale para o resto da interface. As práticas abaixo aparecem em praticamente todo guia de UX writing; o que muda aqui é o motivo de cada uma, que vai além do gosto.
- Rótulo visível e fixo. O texto de exemplo dentro do campo, que some quando a pessoa começa a digitar, não substitui o rótulo. Quem é interrompido no meio do preenchimento volta e não sabe mais o que aquele campo pedia.
- Botão que diz o que acontece. "Pedir orçamento", "Baixar o PDF", "Finalizar compra de R$ 240". "Enviar", "OK" e "Continuar" obrigam a pessoa a adivinhar, e o critério 2.4.6 pede rótulos que descrevam a finalidade.
- Mesma palavra para a mesma coisa. Se o menu diz "Pedidos", a tela não pode dizer "Compras" e o e-mail "Encomendas". Para quem usa leitor de tela, três nomes podem parecer três lugares diferentes.
- Confirmação que confirma. "Recebemos sua mensagem. Respondemos em até um dia útil pelo e-mail informado." vale mais que "Sucesso!". A pessoa precisa saber o que aconteceu e o que esperar.
- Tela vazia que orienta. "Você ainda não tem pedidos" é verdade, mas não ajuda. "Seus pedidos aparecem aqui depois da primeira compra" com um caminho para começar ajuda.
- Frase curta, ordem direta. Sujeito, verbo, complemento. A ação primeiro, a explicação depois. Interface não é lugar de oração subordinada.
Um bom texto de interface quase nunca é notado; um ruim é notado sempre.
Quais os erros mais comuns no texto de formulários?
Em formulários de sites institucionais e lojas, alguns problemas se repetem com frequência. Nenhum deles exige redesenho; todos se resolvem reescrevendo.
- Mensagem genérica para todos os erros. O formulário tem uma única frase — "Preencha corretamente" — que aparece para qualquer problema em qualquer campo.
- Asterisco sem legenda. O campo obrigatório é marcado com um asterisco vermelho, e em lugar nenhum está escrito o que o asterisco significa.
- Mensagem do plugin em inglês ou em português de Portugal. "This field is required" ou "Por favor, introduza um endereço válido" num site brasileiro. Ninguém revisou o texto que veio de fábrica.
- Regra de senha escondida. A exigência de caractere especial só aparece depois da terceira tentativa, como erro, em vez de estar escrita antes do campo.
- Erro que some sozinho. O aviso aparece por dois segundos no canto da tela e desaparece antes de a pessoa terminar de ler — ou antes de o leitor de tela anunciá-lo.
- Botão de envio sem retorno. A pessoa clica, nada visível acontece, ela clica de novo e o comercial recebe o mesmo pedido em duplicidade.
Se o formulário em questão é o de contato, há outro problema que costuma vir junto: campos demais. Tratamos isso no artigo sobre o campo do formulário de contato que ninguém usa.
Como usar IA em UX writing sem perder o controle?
A IA generativa é boa em produzir variações de microtexto: dez versões de um botão, cinco de uma mensagem de erro, o mesmo aviso em tom mais formal ou mais próximo. Também ajuda a revisar um conjunto grande de mensagens buscando inconsistência de termos, frases longas demais ou linguagem técnica.
O que ela não sabe sozinha é o contexto: qual regra o sistema realmente valida, qual correção é conhecida, o que acontece depois do clique, que palavra a sua empresa usa para cada coisa. Peça "uma mensagem de erro para CPF" sem esse contexto e você recebe uma frase plausível e genérica — exatamente o defeito que o critério 3.3.3 quer evitar.
O uso que funciona tem três passos. Primeiro, liste para a IA as regras de validação de cada campo e o glossário da empresa. Depois, peça as mensagens no formato "o que aconteceu + como corrigir", com limite de caracteres. Por fim, uma pessoa revisa cada frase no fluxo real, de preferência testando com leitor de tela, antes de publicar.
Como medir se o texto da interface melhorou?
UX writing tem uma vantagem sobre quase todo outro tipo de texto: o efeito aparece em números que o site já registra, ou pode registrar com pouco esforço. A métrica certa depende do que a tela pede à pessoa.
- Taxa de conclusão do formulário: quantos começam a preencher e quantos enviam. É a métrica principal.
- Erros por campo: quantas vezes cada mensagem de erro é exibida. O campo campeão de erros é o primeiro a reescrever — a instrução está faltando ou a regra está confusa.
- Abandono por campo: em que campo as pessoas param. Ferramentas de análise de comportamento mostram isso sem identificar ninguém.
- Chamados ao suporte sobre a tarefa: "não consigo me cadastrar", "o site não aceita meu CEP". Cada chamado desses é um texto de interface que falhou.
- Auditoria de acessibilidade: a lista de critérios da WCAG aplicada às telas principais, com teste manual em leitor de tela, porque as ferramentas automáticas não avaliam se a mensagem faz sentido.
Meça antes de reescrever. Sem o número de partida, a melhoria vira opinião, e a próxima pessoa que mexer no site pode desfazer o trabalho sem saber.
Por onde começar hoje?
Pelo formulário que mais importa para o negócio: o de orçamento, o de cadastro ou o de finalizar compra. Liste cada campo, cada mensagem que ele pode exibir e cada botão. Para cada mensagem de erro, confira as três perguntas da WCAG: diz onde, diz o quê, diz como corrigir? O que falhar entra na fila de reescrita, com o número de erros daquele campo ao lado.
Se quiser um olhar de fora, a Alliance revisa o texto de formulários, fluxos e páginas como parte do serviço de Conteúdo & Copywriting. E, para entender onde o texto do site pesa no conjunto da operação de marketing, o diagnóstico de marketing gratuito mostra em poucos minutos quais áreas estão mais fracas.