Um usuário está a três segundos da sua métrica de ativação. O formulário está preenchido, o cursor está sobre o botão, e o botão diz Enviar. Ele hesita. O que acontece ao enviar: salva um rascunho, publica para a equipe, começa uma assinatura? Nada na tela responde, então o mais seguro é não fazer nada, e ele fecha a aba. O seu dashboard registra um abandono na etapa quatro. Ninguém na empresa vai saber que uma única palavra custou essa conta.
Isso acontece o tempo todo, e dá para resolver em uma tarde. O microcopy (os rótulos de botões, dicas, estados vazios, mensagens de erro, tooltips e confirmações espalhados pela interface) é o texto que os usuários realmente leem, exatamente nos momentos em que decidem se continuam. E é, caso raro no trabalho de produto, gratuito para mudar e rápido de testar: sem revisão do design system, sem migração, sem um trimestre de engenharia.
Este guia explica o que é microcopy e onde ele aparece, por que tão poucas palavras pesam tanto, as oito superfícies em que o microcopy decide o resultado, mais de quarenta reescritas de antes e depois que você pode aproveitar diretamente, as três fórmulas que fazem textos curtos funcionarem e como publicar e testar mudanças de texto em um produto no ar sem ciclo de release.
Principais pontos
- Microcopy é o texto nos pontos de decisão: botões, dicas, erros, estados vazios, tooltips, confirmações. Ele é curto, mas fica exatamente onde os usuários hesitam.
- Nomeie o resultado, não a mecânica. "Criar meu primeiro relatório" diz ao usuário o que vai acontecer; "Enviar" obriga a adivinhar, e é da adivinhação que vem o abandono.
- Erros precisam de três partes: o que aconteceu, por quê e o que fazer agora, em palavras simples, ao lado do que falhou, sem culpar ninguém.
- Escreva do lado do usuário na tela. As palavras dele, o objetivo dele, o momento dele. Nomes internos de funcionalidades em uma interface de primeiro uso são um imposto sobre a compreensão.
- Estados vazios são onboarding. Uma tela em branco com uma boa frase e um botão converte; uma tela em branco com "Sem dados" é um beco sem saída que você pagou para construir.
- Teste: o microcopy é a única mudança de interface que você publica e mede na mesma semana, principalmente quando a camada de orientação é entregue sem release de código.
O que é microcopy UX? (Definição e onde ele aparece)
Microcopy UX é o texto funcional inserido em uma interface para ajudar as pessoas a usá-la: as palavras nos controles e ao redor deles, e não as palavras que descrevem o produto. Ele é escrito para ser escaneado, não lido; existe para eliminar uma dúvida específica em um momento específico; e é avaliado pela conclusão da ação, não pela elegância da frase.
Microcopy, em uma definição. Os pequenos trechos funcionais de texto de interface (rótulos, dicas, estados, erros, confirmações) que conduzem o usuário pelo produto. O texto de marketing conquista o cadastro. O microcopy conquista tudo o que vem depois.
Ele aparece em mais lugares do que a maioria das equipes tem responsável para cuidar:
| Superfície | O que ela decide | Como costuma falhar |
|---|---|---|
| Rótulos de botões | Se o usuário clica ou não | Verbos genéricos: "Enviar", "OK", "Continuar" |
| Estados vazios | Se um novo usuário chega a começar | "Ainda não há dados" sem caminho a seguir |
| Mensagens de erro | Se o usuário se recupera ou vai embora | Códigos, culpa e nenhum próximo passo |
| Dicas e rótulos de formulário | Taxa de conclusão, qualidade dos dados | Requisitos revelados só depois do erro |
| Tooltips | Se uma funcionalidade é entendida | Repetir o rótulo com mais palavras |
| Textos de onboarding | Tempo até o primeiro valor | Explicar a interface em vez do resultado |
| Confirmações | Confiança após ações irreversíveis | "Tem certeza?" sem dizer a consequência |
| Pedidos de permissão | Taxa de aceitação | Pedir antes de explicar o benefício |
Repare no que a coluna das falhas tem em comum: cada item é um lugar em que o produto sabe algo que o usuário não sabe e prefere não contar. Esse é o diagnóstico inteiro. Trabalhar com microcopy é, na maior parte, a disciplina de escrever o que a sua equipe já sabe, no momento em que o usuário precisa.
Por que poucas palavras rendem mais que um redesign
-
Ele fica exatamente onde os usuários hesitam
O atrito não se espalha por igual pelo produto; ele se concentra em alguns controles, campos e diálogos. O microcopy é o único material de design que mora exatamente nesses pontos, e é por isso que uma reescrita consegue mexer em uma taxa de conclusão que meses de trabalho de layout não tocaram.
-
É a mudança mais rápida que você pode fazer
Sem migração, sem revisão do design system, sem modelo de dados. Dá para escrever as palavras na segunda e medir na sexta, e quando elas são entregues por uma camada de orientação, e não pelo código, nem precisam de release.
-
Ele carrega o modelo mental
Os usuários montam uma teoria de como o seu produto funciona a partir das palavras que ele usa. Nomes consistentes e honestos tornam essa teoria correta; uma terminologia que muda ("workspace" aqui, "projeto" ali, "quadro" na documentação) a torna errada, e um modelo mental errado gera tickets de suporte para sempre.
-
É onde a educação do seu produto fica visível
O tom nos pontos de falha (o erro, o limite, o "você não pode fazer isso") é o que os usuários lembram. Um produto que explica os problemas sem culpar quem está lendo ganha perdão para o próximo.
-
É a correção mais barata para abandonos que você não consegue explicar
Quando o analytics mostra uma parada em uma etapa e o design parece estar certo, as palavras costumam ser as suspeitas. Reescreva antes de reconstruir qualquer coisa: custa um dia e descarta a causa mais provável.
Três fórmulas por trás do microcopy que funciona
Texto curto não se improvisa. Três padrões cobrem a maior parte da interface:
A maior parte do microcopy tem uma de três formas: verbo + resultado para botões, o quê/por quê/próximo passo para erros e para que serve/benefício/ação para estados vazios.
1. Botões: verbo + o resultado do usuário
Não a ação do sistema ("Enviar formulário"), mas o resultado da pessoa ("Enviar meu convite", "Começar teste grátis", "Excluir 3 relatórios"). O rótulo precisa fazer sentido lido sozinho, porque vai ser lido assim, e precisa deixar a consequência óbvia antes do clique, principalmente quando envolve dinheiro ou exclusão.
2. Erros: o que aconteceu + por quê + o que fazer agora
Nessa ordem, na linguagem do usuário, ao lado do que falhou. Nunca comece por um código, nunca use "inválido" e nunca formule como algo que o usuário fez de errado. O teste: a pessoa conseguiria resolver sem sair da tela nem falar com o suporte? Se não, a mensagem está incompleta.
3. Estados vazios: para que serve a tela + o benefício + uma ação
Um estado vazio é a primeira coisa que um novo usuário vê em cada tela, o que faz dele a superfície de onboarding com mais tráfego do produto. Três frases e um botão transformam um beco sem saída em ponto de partida, e o botão deve ser a próxima ação mais útil, não um link para a documentação.
Exemplos de microcopy: mais de 40 reescritas de antes e depois
A mesma tela, duas vezes: primeiro escrita para o sistema, depois escrita para a pessoa que a usa.
Nada mudou além das palavras. A tela da esquerda diz a um novo usuário que o produto está vazio; a da direita diz o que ele está prestes a ganhar e entrega o caminho mais curto até lá.
Botões e chamadas para ação
- "Enviar" → "Criar meu primeiro relatório"
- "OK" → "Excluir 3 relatórios"
- "Continuar" → "Continuar para o pagamento"
- "Salvar" → "Salvar e publicar para a equipe"
- "Começar" → "Conectar minha fonte de dados"
- "Cadastre-se" → "Comece grátis, sem cartão"
- "Confirmar" → "Enviar 12 convites"
- "Saiba mais" → "Ver um exemplo de 60 segundos"
Estados vazios
- "Nenhum resultado encontrado." → "Nenhum relatório corresponde a esses filtros. Tente ampliar o período."
- "Você não tem projetos." → "Projetos separam o trabalho de cada cliente. Crie o primeiro →"
- "Nada por aqui ainda." → "A atividade da sua equipe aparece aqui quando alguém publicar algo. Convide um colega →"
- "0 integrações" → "Conecte uma fonte de dados para ver números reais em vez de exemplos."
- "Caixa de entrada vazia" → "Tudo em dia. Novas solicitações aparecem aqui assim que chegarem."
Mensagens de erro
- "Algo deu errado." → "Não conseguimos salvar suas alterações: a conexão caiu. Seu rascunho está seguro; tente salvar de novo."
- "E-mail inválido." → "Falta um @ nesse endereço; confira se não houve erro de digitação."
- "Falha no upload." → "Esse arquivo tem 12 MB; o limite é 5 MB. Tente compactá-lo ou enviar um CSV."
- "Você digitou um valor inválido." → "Use datas no formato DD/MM/AAAA, por exemplo 24/07/2026."
- "Acesso negado." → "Só administradores do workspace podem alterar o faturamento. Fale com o seu admin ou solicite acesso →"
- "Erro 500." → "Algo quebrou do nosso lado, não do seu. Já fomos avisados; tente de novo em um minuto."
Formulários e campos
- "Nome" → "Nome do workspace: sua equipe vai ver este nome"
- "Senha" → "Senha: pelo menos 10 caracteres" (exibido antes de digitar, não depois do erro)
- "Tamanho da empresa" → "Quantas pessoas vão usar? Usamos isso para definir configurações padrão adequadas."
- "Telefone (opcional)" → "Telefone: só usamos se um relatório falhar durante a noite"
- "URL" → "Endereço do seu site, ex.: app.suaempresa.com.br"
Tooltips e dicas contextuais
- "Filtros" → "Filtre esta lista por plano, data ou responsável"
- "Segmentos" → "Salve um grupo de usuários uma vez e use-o em qualquer tour ou pesquisa"
- "Arquivar" → "Tira da lista sem apagar os dados"
- "Sincronizar" → "Traz as linhas mais recentes do seu data warehouse, leva uns 30 segundos"
Confirmações e ações destrutivas
- "Tem certeza?" → "Excluir este workspace? Os 42 relatórios e o histórico vão junto. Não dá para desfazer."
- "Cancelar assinatura?" → "Cancelar em 30 de agosto? Você mantém acesso total até lá, e seus dados ficam guardados por 90 dias."
- "Descartar alterações?" → "Descartar suas edições neste relatório? A última versão salva continua como estava."
Sucesso e progresso
- "Sucesso!" → "Relatório publicado: sua equipe já pode ver."
- "Salvo." → "Salvo. As alterações já valem para todos neste workspace."
- "Carregando…" → "Processando 40.000 linhas, cerca de dez segundos."
- "Etapa 2 de 5" → "Etapa 2 de 5, faltam dois minutos"
Pedidos de permissão e de consentimento
- "Permitir notificações?" → "Quer um alerta quando um relatório falhar? Só avisamos sobre falhas."
- "Assine nossas novidades" → "Receba um e-mail quando lançarmos algo que você pediu, cerca de uma vez por mês."
- "Aceitar cookies" → "Usamos cookies de análise para saber quais recursos são usados. Você pode recusar e tudo continua funcionando."
O padrão em todos eles: a versão melhorada acrescenta a única informação que o produto já tinha e o usuário não: a consequência, o limite, o formato, o tempo, o benefício. Quase nenhum trabalho de microcopy é escrita criativa. É transparência.
Boas práticas de microcopy: 7 regras
1. Escreva o resultado, não a mecânica
Todo rótulo, dica e título deve responder "o que eu ganho?" antes de "o que isso faz?". Os usuários não querem configurar um segmento; querem parar de mandar e-mail para as pessoas erradas. Comece pela segunda coisa.
2. Use o vocabulário do usuário, não o do seu banco de dados
Nomes internos vazam para a interface assim que ninguém está de olho: "entidade", "objeto de workspace", "gatilho de fluxo". Se um termo aparece no seu banco de dados e no seu onboarding, um dos dois está errado. Repare em como os clientes descrevem a coisa nos tickets de suporte e use essa palavra em todo lugar, de forma consistente.
3. Diga onde a dúvida está
Requisitos ficam ao lado do campo, não em um artigo de ajuda; consequências ficam no botão, não em uma nota de rodapé. O posicionamento contextual é o que separa microcopy de documentação, e é por isso que tooltips e dicas inline funcionam melhor que até mesmo uma ótima central de ajuda para a compreensão no primeiro uso.
4. Coloque primeiro as palavras que carregam o sentido
As pessoas leem as duas ou três primeiras palavras de qualquer coisa. "Conecte o Stripe para ver a receita" sobrevive a uma olhada rápida; "Para poder visualizar os dados de receita, conecte sua conta do Stripe" não. Corte as aberturas que só enrolam ("Observe que", "Para poder", "Agora você pode") e comece pelo verbo ou pelo substantivo que importa.
5. Assuma a culpa, sempre
"Não conseguimos processar isso", e não "Você digitou um valor inválido". O erro do usuário costuma ser uma falha da interface em dizer o que queria, e mesmo quando não é, culpar não muda nada além do que a pessoa sente pelo seu produto no momento em que ela tem menos paciência.
6. Mantenha a terminologia consistente em todas as superfícies
O mesmo conceito deve ter o mesmo nome na interface, nos tooltips, no onboarding, nas notas de versão e nas respostas do suporte. Mantenha um pequeno glossário compartilhado com os 20 termos que o seu produto realmente usa: é a documentação mais barata que a sua equipe vai escrever, e evita a confusão mais cara.
7. Publique, meça, reescreva
O microcopy é a única parte da interface em que dá para fazer um antes e depois de verdade em uma semana: mude as palavras na etapa com o pior abandono, acompanhe a conclusão por sete dias, mantenha ou reverta. Faça isso três vezes no seu fluxo de cadastro e você vai aprender mais sobre os seus usuários do que em um trimestre de entrevistas.
Microcopy UX: o que fazer e o que evitar
✅ Faça
- Nomeie o resultado em todo botão
- Informe os requisitos antes que o usuário erre
- Dê a cada erro um o quê, um por quê e um próximo passo
- Transforme estados vazios em pontos de partida
- Use uma palavra por conceito, em todo lugar
- Coloque o texto onde a dúvida acontece
- Diga o que uma ação irreversível vai apagar
- Teste o texto na etapa com o pior abandono
❌ Evite
- Publicar "Enviar", "OK" ou "Continuar" como rótulos finais
- Mostrar as regras de senha só depois de uma tentativa que falhou
- Começar um erro com um código ou com a palavra "inválido"
- Deixar "Sem dados" como estado vazio
- Deixar nomes internos de objetos chegarem à interface
- Esconder requisitos em um artigo da central de ajuda
- Pedir permissões antes de explicar o benefício
- Tratar o texto como os últimos cinco minutos do design
Publicar e testar microcopy sem ciclo de release
A parte frustrante do trabalho com microcopy não é escrever; é que melhorar uma frase normalmente exige um pull request, uma revisão, um deploy e duas semanas de espera para saber se ajudou. A camada de orientação não precisa funcionar assim. Com a Kompassify você coloca palavras contextuais por cima do seu produto no ar sem mexer no código:
- Escreva dicas onde elas fazem falta. Ancore um tooltip em qualquer elemento e explique-o com as palavras do usuário, publicado na hora, sem ticket de release.
- Resgate telas sem saída. Acrescente orientação e uma próxima ação clara a estados vazios e etapas travadas, para que uma tela em branco vire um ponto de partida.
- Fale de um jeito diferente com cada pessoa. Mostre um texto para usuários em teste e outro para administradores por segmento: o mesmo controle, explicado na linguagem de quem está olhando.
- Meça a reescrita. O analytics integrado mostra a conclusão das etapas em que o seu texto aparece, então "esse texto funciona?" vira um número em vez de uma opinião.
- Mantenha a consistência. Tours, checklists, tooltips e anúncios saem do mesmo lugar, então a sua terminologia continua igual em todas as superfícies de orientação.
A Kompassify está em conformidade com o GDPR, é hospedada na UE, gratuita para menos de 100 usuários ativos mensais, com planos pagos a partir de US$ 129/mês.
Coloque as palavras certas no lugar certo
A Kompassify permite adicionar tooltips contextuais, orientação e textos de onboarding por cima do seu produto atual, sem código e sem ciclo de release. Explique o controle confuso, resgate a tela vazia e meça se o novo texto realmente aumentou a conclusão. Em conformidade com o GDPR, hospedada na UE e gratuita para menos de 100 usuários ativos mensais.
Comece grátis →Perguntas frequentes
O que é microcopy em UX?
Microcopy é o pequeno texto de interface que guia o usuário por um produto: rótulos de botões, dicas de formulário, mensagens de estado vazio, mensagens de erro, tooltips, textos de placeholder, diálogos de confirmação e avisos de sucesso. Ele se chama micro porque cada trecho tem poucas palavras, não porque o impacto seja pequeno: são as palavras que os usuários realmente leem, exatamente no momento em que decidem se vão agir. Enquanto o texto de marketing convence alguém a experimentar um produto, o microcopy determina se a pessoa consegue usá-lo.
Por que o microcopy é importante?
Porque ele fica nos pontos de decisão. Um usuário que hesita diante de um botão, entende errado um campo de formulário ou recebe um erro que não consegue interpretar não abre uma reclamação: ele vai embora, e o seu analytics registra um abandono sem explicação. Reescrever as palavras nesses momentos custa uma tarde e nenhum tempo de engenharia, e elimina um atrito que um redesign levaria um trimestre para resolver. O microcopy também é a coisa mais barata de testar: é a única parte da interface que você pode mudar, medir e mudar de novo na mesma semana.
O que faz um microcopy ser bom?
Quatro coisas. Ele é específico: nomeia o resultado real ("Criar seu primeiro relatório") em vez de um verbo genérico ("Enviar"). Ele é escrito do ponto de vista do usuário, com as palavras que ele usaria, e não com os nomes internos das funcionalidades. Ele chega no momento da dúvida, e não em uma documentação em outro lugar. E ele assume a responsabilidade quando algo dá errado: uma boa mensagem de erro diz o que aconteceu, por quê e o que fazer agora, sem culpar quem está lendo.
Qual a diferença entre microcopy e UX writing?
UX writing é a disciplina; microcopy é o resultado. O UX writing abrange a prática inteira: voz e tom, sistemas de terminologia, design de conteúdo, hierarquia da informação, a decisão de se uma tela precisa de palavras. O microcopy é o texto concreto que essas decisões produzem no nível de um botão, de uma dica ou de um erro. Em equipes pequenas a distinção raramente importa; o que importa é que alguém cuide das palavras com a mesma seriedade dedicada à interface.
Como escrever um bom microcopy de botão?
Nomeie o resultado, do ponto de vista da intenção do usuário. "Começar meu teste grátis" é melhor que "Enviar"; "Enviar convite" é melhor que "Confirmar"; "Excluir 3 relatórios" é melhor que "OK". Daí saem duas regras: o rótulo deve fazer sentido lido sozinho, fora de contexto, porque é assim que ele será escaneado; e deve dizer ao usuário o que vai acontecer depois do clique, principalmente quando a ação é irreversível ou custa dinheiro. Se um botão precisa de uma frase explicativa ao lado, o rótulo está trabalhando pouco.
Como escrever uma boa mensagem de erro?
Três partes, nesta ordem: o que aconteceu, por quê e o próximo passo, em linguagem simples, sem código de erro como título e sem culpa. "Esse arquivo tem 12 MB; o limite é 5 MB. Tente compactá-lo ou enviar um CSV" faz o trabalho todo. Evite as falhas clássicas: a vaga ("Algo deu errado"), a acusadora ("Você digitou um valor inválido") e a técnica ("Erro 422: entidade não processável"). E coloque a mensagem ao lado do que falhou, não em um banner no topo de um formulário longo.
Dá para mudar o microcopy sem um release de código?
Parte dele, sim. O texto embutido nos seus componentes precisa de release, mas a camada de orientação ao redor deles (tooltips, dicas de onboarding, convites em estados vazios, explicações contextuais, textos de anúncios) pode ser entregue por cima do seu produto com uma ferramenta no-code como a Kompassify: escreva as palavras, ancore no elemento, escolha um segmento e publique na hora. Isso torna o microcopy testável em dias, e não em sprints, e é assim que você descobre qual texto realmente melhora as taxas de conclusão. A Kompassify está em conformidade com o GDPR, é hospedada na UE, gratuita para menos de 100 usuários ativos mensais, com planos pagos a partir de US$ 129/mês.