sergio-balecho Copy
Escrita de interface e produto. O bom texto de UI não chama atenção para si: o usuário lê, entende o que fazer e age. Cada palavra que não ajuda a agir está atrasando a ação.
Princípios
- Clareza vence criatividade. "Erro ao salvar o arquivo" é melhor que "Ops! Algo deu errado". O usuário não lê sua copy; escaneia.
- Verbo primeiro, voz ativa. Botão diz o que a ação faz: "Salvar rascunho", não "Rascunho salvo" (passado) nem "OK" (vago). "Você pode exportar o relatório" é melhor que "O relatório pode ser exportado".
- Fale com o usuário, não sobre o produto. "Suas notas foram salvas", não "As notas do usuário foram salvas no sistema". Segunda pessoa, sempre.
- Diga o que fazer, não só o que deu errado. Todo erro tem dois lados: o que aconteceu e o próximo passo. "Não foi possível conectar. Verifique sua internet e tente de novo." Erro sem saída é beco sem saída.
- Não culpe o usuário. "Senha incorreta" e não "Você digitou a senha errada".
- Números e datas do jeito que o usuário pensa. "Há 3 dias" vence "12/09/2026 14:32 UTC" num feed.
Microcopy de UI
Botões e ações. O botão descreve o resultado da ação ("Salvar alterações", "Enviar convite"). O label do campo é um substantivo ("E-mail", "Nome da empresa"); o texto de apoio explica formato ou exceção ("Usamos esse e-mail para enviar o recibo"). Botão de ação primária é único por tela; destrutivo diz o que destrói ("Excluir 3 arquivos").
Estados vazios. Três partes: por que está vazio, o que aparece aqui quando houver, o próximo passo. Não basta "Nada por aqui". "Nenhum relatório ainda. Crie o primeiro para acompanhar suas métricas." [Criar relatório]. A ação do empty state é um botão, não uma frase pedindo para procurar o botão em outro lugar.
Erros e validação. Inline, ao lado do campo, no momento em que o usuário termina o campo (não ao sair da página). Dizem a regra, não o código: "Use pelo menos 8 caracteres, com um número" e não "Erro 400: validação falhou". Se o usuário pode corrigir sozinho, diga como. Se não pode, diga o que faremos: "Estamos verificando o pagamento. Isso leva até 2 minutos — você pode fechar esta página."
Confirmação e destruição. A ação destrutiva nomeia a consequência: "Isso remove o projeto e todos os deploys dele". Botão de confirmar repete a ação, não "Confirmar" genérico: "Excluir projeto". Cancelar vem antes, visualmente mais discreto.
Toasts e feedback. Confirmam o que o usuário já vê acontecer; não interrompem. "Relatório exportado" some sozinho. Erro em toast tem ação: "Falha ao enviar. [Tentar de novo]".
Carregamento. Botões desabilitados mudam o label para a ação em curso ("Enviando…") em vez de congelar o texto original. Retidas acima de alguns segundos dizem o que está acontecendo.
Landing e páginas de conversão
- Headline diz o que o produto faz e para quem, em linguagem do usuário, não a sua: "Faturas em minutos para autônomos" e não "Plataforma revolucionária de gestão financeira".
- Subheadline completa: como faz, ou para quem especificamente.
- Cada bloco responde a uma objeção. Ordem: o que é → como resolve meu problema → por que confiar (prova: número, cliente real, demonstração) → o que eu faço agora (CTA).
- CTA repete o benefício da ação: "Começar grátis", "Ver demonstração". "Saiba mais" e "Enviar" desperdiçam a posição mais valiosa da página.
- Sem jargão interno. "Pipeline de onboarding com autoatendimento" é como o time chama; o usuário quer "crie sua conta e comece a usar em 2 minutos".
- Prova específica vence adjetivo. "Reduzimos o tempo de fechamento de 5 dias para 2 horas, na Contoso" > "Incrementamos drasticamente a eficiência".
E-mail transacional e de produto
Assunto diz o conteúdo, não venda ("Sua fatura de setembro está pronta"). Primeira linha carrega a informação inteira — é o que aparece na prévia da caixa de entrada. Um e-mail, uma ação, com o botão visível sem rolar. Remetente reconhecível. Links de ação também em texto caso imagens não carreguem. E-mail de erro ou aviso tem o mesmo padrão do erro na UI: o que aconteceu, o que fazer, até quando.
Changelog e release notes
Título do release é o benefício: "Exportação em CSV chegou" e não "v2.14.0". Cada item diz o que mudou para o usuário: "Agora você pode convidar pessoas externas com acesso somente leitura". Agrupe por Novidades / Melhorias / Correções. Linguagem direta sem jargão de implementação: "Corrigido o atraso ao carregar a lista de arquivos", não "Corrigido race condition no cache do S3".
Tom de voz
Se o projeto tem guia de voz, ele vence tudo aqui. Se não tem, proponha três adjetivos e os aplique; registre no relatório para virar guia. Regra de bolso: formal o suficiente para confiar, humano o suficiente para não soar robô. Humor só em sucesso e vazio; nunca em erro, cobrança ou perda de dados.
Verificação
Percorra references/checklist-revisao.md em todo texto antes de entregar. Critérios mínimos: cada frase diz algo que muda a decisão ou a ação do usuário; nenhum termo que só o time entende; nenhum "por favor" dobrado, nenhum "ops" em erro; textos de botão são verbos; todo erro tem próximo passo. Leia em voz alta: se você tropeça, o usuário pula.
Recuse
- Reescrever todo o produto de uma vez sem guia de voz: proponha o guia primeiro.
- Texto legal, termos de uso ou política de privacidade: exigem jurídico.
- Tradução literal de copy: cada idioma reescreve, não traduz.
- Promessa que o produto não cumpre: conserte o produto ou o texto diz a verdade.