Capítulo 01 Fundamento
O texto é interface
Numa aplicação, quase tudo o que a pessoa vê são palavras. Tratá-las como conteúdo a preencher no fim é a origem da maior parte da má experiência que se atribui ao desenho.
1.1 Conte as palavras do próximo ecrã que desenhar
Abra qualquer aplicação que use e olhe para um ecrã: o título, os rótulos dos menus, os nomes dos botões, os cabeçalhos das colunas, os textos de ajuda, as mensagens de estado. Tire tudo o que é palavra e fica uma grelha de caixas cinzentas onde ninguém sabe o que fazer. Tire toda a cor e o layout, deixe só as palavras, e ainda se percebe bastante.
O texto carrega mais informação por pixel do que qualquer outro elemento do interface — e é a única parte que costuma ser escrita depois de tudo estar decidido, muitas vezes por quem não esteve na conversa. É por isso que "lorem ipsum" é um problema de método e não um detalhe: um ecrã desenhado com texto falso foi desenhado sem a parte que faz o trabalho.
1.2 O que é microcópia
| É microcópia | Não é |
|---|---|
| O nome de um botão, um rótulo de campo, uma mensagem de erro, um estado vazio, um texto de confirmação, um cabeçalho de tabela, um tooltip | Um artigo do blogue, a narrativa da marca, o texto da página inicial, um email de campanha |
| Lê-se em menos de um segundo, no meio de uma tarefa, por alguém que não quer estar a ler | Lê-se com atenção, por alguém que decidiu ler |
| Falha silenciosamente: a pessoa hesita, clica no sítio errado, desiste | Falha visivelmente: ninguém partilha, ninguém converte |
1.3 O lugar disto no catálogo
Esta apostila é sobre o texto dentro do produto. Storytelling trata da narrativa de marca, que é outro ofício com outras regras. Guia de Elementos de Interface descreve os componentes — esta apostila trata do texto que vive dentro deles. Pesquisa com Utilizadores é como se descobre que uma palavra não está a funcionar, e Acessibilidade & WCAG cobre o texto que só é lido por leitores de ecrã, que aqui aparece no capítulo 11.
1.4 Três reescritas para dar o tom
Antes
"Ocorreu um erro. Código: 0x8007007E"
A pessoa não sabe o que aconteceu, de quem é a culpa, nem o que fazer.
Depois
"Não conseguimos guardar as alterações — a ligação caiu. O rascunho está guardado; tente outra vez."
O que falhou, porquê, o que se perdeu (nada) e o passo seguinte.
Antes
Botão: Submeter
Submeter o quê, a quem, e o que acontece a seguir?
Depois
Botão: Enviar candidatura
O botão diz o que vai acontecer. Custa duas palavras.
Escolha um ecrã do produto onde trabalha e transcreva só as palavras, por ordem de leitura, sem formatação nenhuma. Dê a lista a alguém de fora e pergunte o que aquele ecrã faz. O que essa pessoa não perceber é microcópia por corrigir, não desenho por melhorar.
Capítulo 02 Fundamento
Claro, breve, agradável — nesta ordem
Há três critérios para julgar microcópia e a ordem entre eles não é negociável. Quase todo o mau texto de interface vem de trocar a ordem.
2.1 A hierarquia
| Ordem | Critério | Sacrifica-se quando… |
|---|---|---|
| 1.º | Claro — a pessoa percebe o que acontece se clicar | Nunca |
| 2.º | Breve — não gasta o tempo de quem lê | Quando encurtar torna ambíguo |
| 3.º | Agradável — soa a gente, não a formulário | Sempre que colide com os dois de cima |
Breve antes de claro: "Aplicar" em vez de "Aplicar desconto a esta encomenda". Poupou três palavras e criou uma hesitação de dois segundos, multiplicada por todas as pessoas que veem o ecrã.
Agradável antes de claro: "Ups! Alguma coisa correu mal 🙈". Não diz o que correu mal, não diz o que fazer, e a piada gasta-se à segunda vez — enquanto o erro não se gasta. É o defeito mais comum das equipas que descobriram o tom de voz antes de descobrirem a clareza.
2.2 O teste do meio da tarefa
Toda a microcópia é lida por alguém que está a meio de outra coisa, com pressa, provavelmente irritado, e que não vai reler. É um contexto de leitura completamente diferente daquele em que o texto é escrito — calmamente, por alguém que já sabe tudo sobre o sistema.
Leia a sua frase uma só vez, depressa, e pergunte: consigo dizer o que vai acontecer? Se precisou de reler, não passa. Reler é gratuito para si, que a escreveu; não é para quem chega ali pela primeira vez com um problema.
2.3 As palavras que não significam nada
| Evite | Porquê | Use |
|---|---|---|
| Submeter | Vocabulário de formulário em papel; não diz o que acontece | Enviar pedido / Guardar / Publicar |
| Processar | Descreve o que a máquina faz, não o que a pessoa consegue | Pagar / Converter / Gerar relatório |
| Inválido | Diz que está errado sem dizer o quê | "Faltam 2 dígitos" / "Esta data já passou" |
| Gerir | Rótulo-guarda-chuva: cabe tudo, logo não orienta | Editar equipa / Ver faturas |
| Configurações avançadas | Sinaliza "não é para si" e esconde coisas banais | Nomear pelo que lá está dentro |
| Otimizar a sua experiência | Não tem conteúdo; costuma esconder recolha de dados | Dizer o que se faz e porquê |
2.4 Escrever do lado de quem lê
A microcópia má descreve o sistema; a boa descreve a pessoa e o objetivo dela. É a mesma correção, aplicada mil vezes:
- "A sincronização falhou" → "As suas notas não subiram para a nuvem"
- "Utilizador não encontrado" → "Não há nenhuma conta com este email"
- "Sessão expirada" → "Passou demasiado tempo. Entre outra vez para continuar"
- "Sem permissões" → "Só quem administra a equipa pode alterar isto. Peça a [nome]"
Repare que a última faz mais do que traduzir: dá o passo seguinte. É o padrão a que voltamos no capítulo 5.
Procure no seu produto três textos que sacrificaram a clareza pela brevidade e um que a sacrificou pela graça. Reescreva os quatro. Se o quarto não existir, ainda bem — mas procure nos estados de erro antes de concluir que não há.
Capítulo 03 Prática
Botões e rótulos: o texto que promete uma ação
Um botão é uma promessa sobre o que vai acontecer a seguir. Se a promessa for vaga, a pessoa hesita; se for falsa, perde-se a confiança de vez.
3.1 Verbo mais objeto
A regra que resolve a maioria dos casos: o botão diz o que vai acontecer, na voz de quem clica. Verbo primeiro, objeto a seguir, sem mais nada.
| Fraco | Melhor | Porquê |
|---|---|---|
| OK | Apagar conversa | "OK" concorda com o quê? Obriga a reler o diálogo |
| Sim / Não | Sair sem guardar / Continuar a editar | Sim e não respondem a uma pergunta que já se esqueceu |
| Continuar | Ir para pagamento | Continuar para onde? É o rótulo mais usado e o menos informativo |
| Guardar alterações | Guardar alterações | Este está bem — verbo e objeto, sem ambiguidade |
Tape tudo menos o botão. Ainda se percebe o que faz? Se não, o botão está a apoiar-se no texto à volta — e vai falhar em todos os contextos onde esse texto não é lido, que são quase todos. É também o teste que os leitores de ecrã fazem por si, ao permitirem navegar de botão em botão sem o resto (cap. 11).
3.2 A ação primária diz-se, a secundária também
Num par de botões, os dois carregam informação. O erro comum é escrever bem o primário e deixar o secundário em "Cancelar" — quando "Cancelar" é ambíguo em qualquer ecrã onde já houve uma ação em curso: cancelar a subscrição, ou cancelar este diálogo?
Ambíguo
Cancelar assinatura
[ Cancelar ] [ OK ]
Qual dos dois cancela a assinatura?
Claro
Cancelar assinatura
[ Manter assinatura ] [ Sim, cancelar ]
Ambos os botões dizem o resultado.
3.3 Rótulos de navegação e de campo
- Use as palavras de quem lê, não as da base de dados. "Entidade", "registo", "instância" e "item" são palavras internas. Se a equipa lhe chama tenant, o cliente chama-lhe empresa.
- Uma coisa, um nome, em todo o lado. Se o menu diz "Faturas", o título da página não pode dizer "Documentos de cobrança" nem o botão "Nova nota". Voltamos a isto no capítulo 12, no glossário.
- Rótulos paralelos. Numa lista de opções, ou são todas verbos ou são todas substantivos. Misturar "Exportar", "Definições" e "Partilhar ficheiro" faz o olho tropeçar sem que se perceba porquê.
- Não numere o que não tem ordem, e não abrevie o que não é óbvio: "Config." poupa quatro caracteres e custa uma dúvida.
3.4 O botão que mente
Caso · "Experimentar grátis"
Um botão dizia Experimentar grátis. Ao clicar, o primeiro passo pedia um cartão de crédito. Tecnicamente verdade — não há cobrança nos 14 dias. Na prática, a taxa de abandono nesse ecrã era de 71%, e o apoio ao cliente recebia mensagens irritadas com a palavra "enganar".
A correção foi de três palavras: Experimentar grátis 14 dias — pede cartão. O abandono naquele ecrã subiu, porque quem não queria dar o cartão parou mais cedo. As ativações completas subiram, e as mensagens de reclamação desapareceram.
Microcópia honesta piora as métricas de topo do funil e melhora tudo o resto. Quem defende texto claro tem de saber isto de antemão — e medir o passo certo, não o primeiro (Experimentação & A/B).
Liste todos os rótulos de botão do seu produto num ficheiro. Ordene alfabeticamente. Vai encontrar três coisas: sinónimos para a mesma ação, "OK" e "Continuar" em sítios onde não deviam estar, e pelo menos um botão cujo nome ninguém consegue explicar.
Capítulo 04 Prática
Formulários: onde as palavras fazem mais diferença
Um formulário é uma sequência de perguntas feitas por escrito, sem ninguém para esclarecer. Quase tudo o que corre mal aí é texto.
4.1 Rótulo, dica, ajuda, erro — quatro coisas distintas
| Elemento | Serve para | Erro habitual |
|---|---|---|
| Rótulo | Dizer o que é o campo. Sempre visível. | Ser substituído pelo placeholder |
| Dica (placeholder) | Exemplo de formato: "AA-00-BB" | Conter a pergunta, que desaparece ao escrever |
| Ajuda | Explicar porque se pede, ou onde encontrar | Estar escondida num ícone de interrogação |
| Erro | Dizer o que corrigir e como | Dizer "inválido" |
Quando o rótulo vive dentro do campo e desaparece ao escrever, acontece tudo isto: quem se distrai a meio já não sabe o que estava a preencher; quem revê o formulário antes de enviar vê uma lista de valores sem perguntas; o contraste do texto cinzento costuma falhar os mínimos de WCAG; e o preenchimento automático do navegador enche campos que ficam sem identificação visível. É elegante numa maquete de três campos e indefensável num formulário real.
4.2 Explicar porque se pede
Todo o campo que pede algo pessoal ou inesperado precisa de uma linha a justificar. Não é cortesia: é a diferença entre preencher e fechar o separador.
- Telefone → "Só usamos para avisar de atrasos na entrega."
- Data de nascimento → "Para confirmar que tem idade para abrir conta."
- NIF → "Aparece na fatura. Pode deixar em branco e adicionar depois."
A terceira faz mais uma coisa importante: diz que é reversível. Boa parte da hesitação em formulários não é sobre partilhar o dado — é o medo de ficar preso a uma escolha.
4.3 Obrigatório, opcional, e o que se pede a mais
Marque o que é raro
Se quase tudo é obrigatório, marque os opcionais. Se quase tudo é opcional, marque os obrigatórios. Um asterisco em doze campos de catorze não informa nada.
Cada campo defende-se
Para cada campo, alguém tem de saber que decisão muda com aquele dado. Os que não passam neste teste são os que fazem o formulário parecer interminável — e a percepção de comprimento é o que faz desistir, não o comprimento.
4.4 Validação: quando e como falar
Enquanto escreve: nada. Marcar um email como inválido à terceira letra é acusar alguém de erro a meio de uma frase.
Ao sair do campo: valide o formato e diga logo. É o momento certo: a pessoa ainda está naquele contexto.
Ao enviar: resuma no topo o que falta, com ligações para cada campo, e leve o foco para o primeiro. Uma lista de erros no topo sem ligações é uma caça ao tesouro.
Sempre: se corrigir sozinho — espaços a mais, maiúsculas, o "+351" —, corrija em silêncio em vez de recusar. Não peça a uma pessoa que faça o trabalho que o programa faz melhor.
4.5 Palavras-passe
O campo onde a microcópia falha mais: as regras aparecem depois de a pessoa falhar. Mostre os requisitos antes de escrever, verifique-os em tempo real, e evite regras que já não se defendem (trocar a palavra-passe de 90 em 90 dias produz palavras-passe piores, não melhores).
E o pior texto do género inteiro: "A palavra-passe não cumpre os requisitos." Quais? Diga qual falta, uma a uma.
Preencha o formulário mais importante do seu produto errando de propósito em cada campo, um de cada vez. Anote a mensagem que recebe. Conte quantas dizem apenas que está errado sem dizer como corrigir. É quase sempre mais de metade.
Capítulo 05 Prática
Erros: as três partes de uma mensagem que serve
Uma mensagem de erro apanha alguém no pior momento possível. É o texto do produto com maior efeito na confiança e o que menos atenção recebe.
5.1 A fórmula
1. O que aconteceu — em linguagem de quem lê, não do sistema.
2. Porquê, se ajudar — só se a razão orientar a próxima ação.
3. O que fazer agora — a parte que quase sempre falta, e a única que resolve alguma coisa.
E uma quarta, invisível: o que aconteceu ao que a pessoa já tinha feito. Dizer "o rascunho está guardado" vale mais do que todo o resto da mensagem.
| Antes | Depois |
|---|---|
| "Erro ao carregar ficheiro." | "Este ficheiro tem 32 MB e o limite é 10 MB. Comprima-o ou envie em partes." |
| "Pagamento recusado." | "O banco recusou o pagamento. Costuma ser saldo ou um limite de compras online — confirme com o banco ou use outro cartão. Não foi cobrado nada." |
| "Não foi possível concluir a operação." | "Não conseguimos publicar agora. O texto está guardado; tentamos de novo daqui a pouco." |
5.2 De quem é a culpa
| Situação | Postura | Exemplo |
|---|---|---|
| Falhou do lado do sistema | Assuma, sem drama | "Não conseguimos guardar. A falha é nossa e já estamos a ver." |
| A pessoa escreveu algo que não serve | Neutro, sem acusar | "Esta data já passou — escolha uma futura." (não: "Data inválida") |
| Falta uma permissão | Diga quem pode | "Só quem administra pode convidar pessoas. Peça a Ana Silva." |
| Erro de segurança (senha errada) | Vago de propósito | "Email ou palavra-passe incorretos." Dizer qual dos dois falhou entrega informação a quem tenta entrar |
A última linha é a exceção que confirma a regra: é o único caso em que a clareza cede, e cede a uma razão concreta, não ao hábito.
5.3 Onde a mensagem aparece
- Junto do problema. Um erro de um campo pertence ao campo, não a uma barra no topo.
- Que não desapareça sozinha. Um aviso que some ao fim de três segundos falha para quem lê devagar, para quem estava distraído e para quem usa leitor de ecrã.
- Sem bloquear, se der. Um erro que exige fechar um diálogo para reler o formulário obriga a memorizar.
- Uma vez. O mesmo erro repetido no topo, no campo e num toast não é ênfase — é ruído.
5.4 O código de erro tem lugar
Códigos técnicos não são inimigos: são inúteis como mensagem e valiosos como apêndice. Ponha a frase humana em primeiro plano e o código pequeno, copiável, no fim — o apoio ao cliente precisa dele, e quem não precisa não o lê.
E quando não sabemos mesmo o que aconteceu?
Acontece, e é legítimo. O que não é legítimo é fingir precisão nem despachar com "algo correu mal". Diga o que sabe e o que não sabe: "Alguma coisa falhou do nosso lado e ainda não sabemos o quê. O seu trabalho está guardado. Tente daqui a alguns minutos; se continuar, escreva-nos com o código ABC-123." Três coisas úteis — o estado dos dados, o passo seguinte e a via de escape — sem inventar uma causa.
Peça aos registos as dez mensagens de erro mais mostradas no último mês. Reescreva-as com a fórmula das três partes. É o trabalho de microcópia com melhor retorno que existe, porque atinge exatamente as pessoas que já estão em dificuldade.
Capítulo 06 Prática
Os estados que ninguém escreve
Todo o ecrã tem quatro versões e a maioria das equipas desenha uma. As outras três aparecem em produção, escritas à pressa por quem estava a implementar.
6.1 O inventário dos estados
| Estado | Quando | O que o texto tem de fazer |
|---|---|---|
| Vazio de primeira vez | A conta é nova; ainda não há nada | Explicar para que serve e dar o primeiro passo |
| Vazio por escolha | Apagou tudo, arquivou tudo | Confirmar que está tudo bem — é uma conquista, não uma falha |
| Sem resultados | Filtrou ou procurou e não encontrou | Dizer o que se procurou e como alargar |
| A carregar | Está a demorar | Dizer o que está a acontecer e se pode sair |
| Erro parcial | Carregou metade | Dizer o que falta e como tentar só essa parte |
| Sucesso | Correu bem | Confirmar o que aconteceu e oferecer o passo seguinte |
Um ecrã de tarefas vazio na primeira sessão precisa de ensinar. O mesmo ecrã vazio porque a pessoa terminou tudo precisa de dizer "está tudo feito". Usar o mesmo texto para os dois casos transforma uma vitória num tutorial — e é dos erros mais frequentes e mais fáceis de corrigir.
6.2 O estado vazio como melhor sítio para ensinar
É o único momento em que a pessoa está a olhar para um ecrã sem nada que a distraia e com uma pergunta na cabeça: e agora?. Nenhum tutorial em sobreposição consegue essa atenção.
Desperdiçado
Uma ilustração grande e "Ainda não tem projetos."
Repete o que a pessoa já vê.
Aproveitado
"Um projeto guarda ficheiros, prazos e a equipa num sítio só."
[ Criar o primeiro projeto ]
"Ou comece por um modelo: Campanha · Website · Evento"
Diz o que é, dá a ação, e oferece um caminho para quem não sabe por onde começar.
6.3 Sem resultados: devolver a pesquisa
- Repita o que se procurou. "Nada para «faturas 2023»" — muitas vezes o erro está ali à vista, e a pessoa não o vê no campo de pesquisa.
- Diga que filtros estão ativos. A maior parte dos "não encontro nada" é um filtro esquecido de outra sessão. Ofereça limpá-los num clique.
- Ofereça a saída. Sugestões próximas, ou "procurar em todos os arquivos em vez de só neste".
- Não peça desculpa. "Lamentamos, não encontrámos nada" gasta uma linha em emoção e nenhuma em ajuda.
6.4 A carregar, e a espera longa
Abaixo de um segundo não escreva nada — um texto que pisca é pior que espera nenhuma. Acima de dez segundos, o texto passa a ser o principal instrumento para a espera ser tolerável:
- Diga o passo, não a percentagem inventada. "A converter as páginas 12 de 40" informa; uma barra que salta de 30% para 90% destrói a confiança em todas as barras seguintes.
- Diga se pode sair. "Pode fechar esta janela — avisamos por email quando terminar" liberta a pessoa e é, muitas vezes, a melhor frase do ecrã inteiro.
- Nada de piadas em rotação. Divertem à primeira e irritam à quinta, que é precisamente quando a espera já é longa.
6.5 Sucesso: não desperdice a confirmação
"Guardado com sucesso" gasta um momento de atenção para dizer o que a pessoa já supunha. O mesmo espaço pode confirmar o efeito concreto e abrir o passo seguinte: "Fatura 2024/318 enviada para ana@empresa.pt. Ver fatura · Enviar outra."
Ao desenhar qualquer ecrã, escreva as seis versões do texto antes de desenhar uma. Demora vinte minutos, e é a diferença entre um produto que parece cuidado e um que parece cuidado só no caminho feliz.
Pegue no ecrã principal do seu produto e escreva os seis estados da tabela de 6.1. Depois vá ver quantos existem mesmo no código. O habitual é dois.
Capítulo 07 Prática
Confirmar, avisar, destruir
A caixa de confirmação é o instrumento mais usado e menos eficaz para prevenir erros. Vale a pena perceber quando funciona e o que funciona melhor.
7.1 Porque é que ninguém lê a confirmação
Quem clica em "Apagar" já decidiu apagar. O diálogo que aparece a seguir é lido pelo corpo, não pelos olhos: a mão vai para o botão da direita antes de o texto ser processado. E quanto mais vezes o diálogo aparece — inclusive em ações inofensivas — mais rápido se torna esse automatismo. Confirmações a mais tornam as confirmações importantes invisíveis.
1. Tornar reversível — desfazer, lixo, versões. Resolve o problema em vez de o adiar.
2. Tornar visível — mostrar o que vai desaparecer, com nome e quantidade.
3. Tornar difícil — escrever o nome para confirmar; só para o que é mesmo irreversível.
4. Perguntar — o diálogo. É o mais fraco dos quatro, e é o primeiro que toda a gente usa.
Um "Anular" durante dez segundos previne mais erros do que qualquer diálogo, e não custa nada a quem acertou.
7.2 Se tiver mesmo de perguntar
Título: a pergunta concreta, com o nome da coisa. "Apagar «Campanha de Natal»?" — não "Tem a certeza?".
Corpo: a consequência que a pessoa não vê. "Apaga também 34 ficheiros e o histórico de mensagens. Não é possível recuperar."
Botões: ambos dizem o resultado. [ Manter ] [ Apagar campanha ]. Nunca [ Cancelar ] [ OK ].
Se for irreversível e grande: peça para escrever o nome. É atrito de propósito, e é o único sítio onde o atrito é a funcionalidade.
7.3 Não seja o botão vermelho de tudo
| Ação | Tratamento certo |
|---|---|
| Arquivar | Sem confirmação. É reversível. |
| Apagar um item, com lixo | Sem confirmação, com "Anular" durante alguns segundos. |
| Apagar 200 itens de uma vez | Confirmação com a contagem visível. |
| Apagar a conta / o espaço de trabalho | Escrever o nome, dizer o que se perde, e — se possível — apagar só ao fim de 30 dias. |
| Sair sem guardar | Guarde o rascunho e não pergunte nada. É a melhor resposta de todas. |
7.4 Padrões enganosos: a fronteira
Onde a microcópia deixa de ser desenho e passa a ser manipulação
Três exemplos que aparecem em produtos sérios, escritos por pessoas que não pensaram nisso como manipulação:
- Culpabilizar a recusa. "Não obrigado, prefiro pagar mais caro." Envergonhar quem recusa é o padrão mais comum, e é o mais fácil de eliminar: escreva simplesmente "Agora não".
- Assimetria de esforço. Subscrever com um clique, cancelar com um telefonema. Em várias jurisdições isto já é ilegal, e em todas custa reputação.
- Botão pré-selecionado a favor da casa. A opção mais cara ou a caixa do marketing já marcada. Se a escolha não é neutra, não é uma escolha.
Se explicasse a mecânica à pessoa, ela acharia bem? É a única linha que separa persuasão de engano, e funciona porque quase todo o padrão enganoso depende de não ser percebido para funcionar.
Escolha uma caixa de confirmação do seu produto e proponha substituí-la por "Anular" durante dez segundos. Estime o custo de implementação. É quase sempre menor do que parece, e é a melhoria de microcópia que exige menos microcópia.
Capítulo 08 Método
Tom de voz sem cair na personalidade
A maior parte dos guias de tom de voz diz que a marca é «amigável, mas profissional», o que não ajuda ninguém a escolher uma palavra. Há uma forma melhor de fazer isto.
8.1 O problema dos três adjetivos
"Somos claros, humanos e confiantes." Nenhuma equipa do mundo diz que é obscura, robótica e hesitante — portanto os adjetivos não distinguem nada, e no momento de escrever um botão não resolvem a dúvida.
Um traço de tom só é útil se excluir uma alternativa que outra marca escolheria:
- "Direto, não abrupto." — dizemos o preço na primeira frase; não dizemos "recusado" sem explicar.
- "Calmo, não entusiasmado." — sem pontos de exclamação; a boa notícia diz-se pelo conteúdo.
- "Técnico quando é preciso, não condescendente." — dizemos "chave de API"; não dizemos "aquela coisa secreta".
O "não" é o que faz o trabalho. Sem ele é decoração.
8.2 O tom muda com o momento
| Momento | Registo | Porquê |
|---|---|---|
| Boas-vindas | Pode ter calor e alguma leveza | A pessoa está curiosa e sem pressa |
| Tarefa a meio | Neutro e curto | Está concentrada; qualquer graça é interrupção |
| Erro | Sóbrio, prestável, sem piadas | Está irritada; humor lê-se como troça |
| Perda de dados / falha grave | Sério e específico. Nada de emoji | É o momento em que a confiança se ganha ou perde de vez |
| Conclusão de algo difícil | Pode celebrar, brevemente | Foi mérito da pessoa; reconhecer é justo |
Uma marca não tem um tom: tem um registo que se ajusta ao estado de quem lê. É a mesma pessoa a falar, com a sensibilidade de perceber o momento — que é o que se espera de qualquer colega.
8.3 O humor e a sua data de validade
Escreva a piada, depois imagine-a na quinta vez que a mesma pessoa vê aquele ecrã — que, tratando-se de um erro, é a quinta vez que alguma coisa lhe correu mal. Se ainda funciona, fica. Quase nunca fica.
O humor pertence aos sítios que se visitam uma vez ou por vontade própria: o 404, o ecrã de boas-vindas, uma página "sobre nós". Não pertence ao caminho crítico nem a nada que se repita.
8.4 Português europeu: decisões que têm de estar escritas
- Tratamento. "Você", terceira pessoa impessoal ("pode alterar"), ou infinitivo nos rótulos? Escolha uma e aplique em todo o lado. A mistura nota-se mesmo quando ninguém sabe explicar porquê.
- Nós ou o produto? "Não conseguimos guardar" tem dono; "Não foi possível guardar" é ninguém. A primeira é melhor quando a culpa é nossa.
- Anglicismos. Alguns já são a palavra real de quem usa (email, software, upload); outros são preguiça (deletar, submeter, startar). Decida caso a caso e registe no glossário — o critério é o que a pessoa diz em voz alta, não o que soa técnico.
- Género. Reformular é quase sempre possível e melhor: "Bem-vindo(a)" torna-se "Que bom tê-lo por cá" ou, melhor ainda, "Bem-vindo à Uniana" só se souber; senão, "Olá, Ana" resolve tudo. Nomes de utilizador servem para isto.
8.5 Um guia de tom que cabe numa página
Estrutura mínima e suficiente
1. Três pares "é X, não Y", com um exemplo real de cada.
2. A tabela de registo por momento (8.2).
3. Vinte palavras: as que usamos e as que não usamos, com a alternativa.
4. Cinco pares antes/depois retirados do produto verdadeiro.
5. Onde perguntar quando há dúvida.
Guias de tom com quarenta páginas não são consultados por ninguém no momento de escrever um botão — e é esse o único momento que interessa.
Escreva os três pares "é X, não Y" do seu produto. Depois procure no produto uma frase que viole cada um. Se não encontrar nenhuma, os pares provavelmente não excluem nada.
Capítulo 09 Método aplicado · Demo
Um ecrã reescrito cinco vezes
Role devagar. O mesmo momento — um pagamento que falhou — em cinco versões, cada uma a corrigir uma camada diferente do problema.
"Transaction failed. Code: DECLINED_51"
Isto não foi escrito: foi deixado passar. É a resposta do fornecedor de pagamentos, mostrada tal e qual porque ninguém decidiu o contrário. Metade da má microcópia do mundo tem esta origem — não é texto mau, é texto de outra pessoa a aparecer no seu produto.
Nesse instante a pessoa tem três perguntas: o que falhou, fui cobrada, e o que faço agora. O ecrã responde a zero.
Traduzir para português não é reescrever
"O pagamento falhou. Tente novamente." Está em português, é curto, e é onde a maior parte das equipas dá o trabalho por feito. Mas "tente novamente" é um conselho errado: com o mesmo cartão vai falhar outra vez, porque o problema nunca foi a tentativa.
Uma instrução que não funciona é pior que nenhuma — a segunda falha custa mais confiança do que a primeira.
Uma causa provável vale mais que uma causa exata
O sistema muitas vezes não sabe porque o banco recusou — os códigos são deliberadamente vagos. Isso não impede de dizer o que costuma ser: saldo, ou um limite para compras online. É honesto ("costuma ser"), é acionável, e cobre a maioria dos casos.
E os botões deixaram de ser "OK": passaram a ser as duas coisas que a pessoa pode mesmo fazer. Compare com a regra do capítulo 3 — cada botão diz o resultado.
"Não foi cobrado nada. A sua encomenda está guardada."
É a linha que muda o ecrã, e é a que quase nunca é escrita — porque quem escreve sabe que não houve cobrança e que o carrinho persiste, e por saber não imagina a dúvida. É a maldição do conhecimento em duas frases.
As duas perguntas reais naquele segundo não eram sobre o cartão. Eram: perdi dinheiro? e perdi o trabalho que já fiz?. Responder-lhes é o que baixa as chamadas ao apoio, mais do que qualquer explicação sobre o banco.
A melhor mensagem de erro é a que ninguém lê
Chegados a uma boa versão 4, vale a pena a pergunta que devia ter vindo primeiro: este ecrã tem de existir? Validar o cartão antes; guardar um cartão alternativo e repetir sozinho; avisar mais cedo, quando ainda dá para trocar sem perder o contexto.
É o limite do ofício e convém dizê-lo com todas as letras: a microcópia excelente serve muitas vezes para tapar um problema que era de desenho ou de engenharia. Escrevê-la bem é o trabalho; saber quando propor eliminá-la é o que separa quem escreve interfaces de quem escreve textos.
Pegue no pior erro do seu produto e escreva as cinco versões desta demo, por ordem. Depois leve a versão 5 a uma pessoa de engenharia e pergunte quanto custa. Uma das três perguntas é quase sempre barata.
Capítulo 10 Prática
Números, datas, nomes: a microcópia que não é frase
Grande parte do texto de um produto não são frases — são valores formatados. É onde estão os erros que passam despercebidos até irritarem toda a gente.
10.1 Tempo: relativo ou absoluto
| Distância | Formato | Porquê |
|---|---|---|
| Menos de uma hora | "há 12 minutos" | Relativo é imediatamente compreensível |
| Hoje | "às 14:32" | A hora exata é útil e curta |
| Esta semana | "terça, 14:32" | O dia da semana localiza melhor que a data |
| Mais antigo | "14 mar 2026" | "há 8 meses" obriga a fazer contas de cabeça |
| Sempre | Data completa no tooltip | Quem precisa do exato, tem-no sem poluir a lista |
Um prazo apresentado sem fuso é uma armadilha para equipas distribuídas — e "termina amanhã" numa página que ficou aberta desde ontem à noite está simplesmente errado. Datas absolutas envelhecem bem; textos relativos gerados no servidor não.
10.2 Zero, um, muitos
- "1 ficheiros" é o erro mais visível de um produto por acabar. O plural tem de ser tratado, e em português não basta acrescentar um "s" — "1 país / 2 países", "1 opção / 2 opções".
- O zero merece frase própria. "0 mensagens" é feio e frio; "Sem mensagens novas" é uma frase.
- Números grandes arredondam-se. "1 248 391 visitas" pede um esforço que ninguém quer fazer; "1,2 M de visitas" lê-se de relance. Guarde o exato para quem clicar.
- Não misture precisões na mesma coluna: 3,50 € ao lado de 12 € parece um erro de dados.
10.3 Dinheiro e unidades, em português europeu
Convenções
Vírgula decimal e espaço nos milhares: 1 234,56 €. O símbolo depois do valor, com espaço. Percentagem com espaço: 15 % — embora "15%" seja hoje tão comum que qualquer das duas passa, desde que seja sempre a mesma.
Preços
Diga sempre se inclui IVA — é a pergunta número um do apoio ao cliente em lojas portuguesas. E o preço mensal de um plano anual escreve-se com a condição colada: "9 €/mês, faturado anualmente", nunca só "9 €/mês" com a condição num asterisco.
10.4 Nomes de pessoas
- Um campo, não dois. "Primeiro nome" e "Apelido" quebram-se com nomes portugueses de cinco elementos, com nomes de uma só palavra, e com metade do mundo. Se só precisa de saudar, peça "como quer ser tratado".
- Não trunque no meio. Um nome cortado a meio de uma palavra parece um erro do sistema; corte por elemento ou use reticências no fim.
- Não presuma o género pelo nome. "Bem-vinda, Alex" é pior do que "Bem-vindo à Uniana, Alex" — e melhor ainda é "Olá, Alex".
- Acentos e caracteres não latinos existem. Se o produto os estraga, o problema aparece primeiro no texto e a causa está na base de dados.
10.5 Truncar bem
Toda a interface trunca alguma coisa. As regras que evitam os piores casos:
- Corte pelo fim, exceto quando o fim é o que distingue. Em nomes de ficheiro, "Relatório trimestral 2026 Q1 — v…" perde exatamente o que importa; corte pelo meio: "Relatório trimestr…— v3 final.pdf".
- O texto completo tem de estar disponível — tooltip, título, ou expandir. Truncar sem escape é esconder dados.
- Nunca trunque um valor numérico. Um preço cortado é um erro grave; deixe-o quebrar o layout, que é um problema menor e mais visível.
Encha o seu produto com: zero itens, um item, 1 248 391 itens, um nome com 60 caracteres, um nome com 2, e um preço de 0,00 €. Fotografe o que se parte. Quase tudo o que encontrar é microcópia, não CSS.
Capítulo 11 Prática
O texto que a máquina lê
Parte da microcópia nunca aparece no ecrã: é lida em voz alta por leitores de ecrã, indexada por motores de busca, ou traduzida por outra pessoa a meio mundo de distância.
11.1 Escrever para quem ouve o interface
Um leitor de ecrã não vê o layout: percorre os elementos por ordem e lê o que encontra. Isso muda o que uma palavra tem de conter.
| No ecrã | Ouvido isoladamente | Correção |
|---|---|---|
| Um botão "Ver mais" repetido em 12 cartões | "Ver mais, botão" doze vezes seguidas | Texto acessível distinto: "Ver mais sobre Design de Serviços" |
| Um ícone de lixo, sem texto | "Botão" — e nada mais | aria-label="Apagar fatura 2024/318" |
| "Clique aqui" | Não diz para onde vai | O texto do link descreve o destino |
| Erro a vermelho junto ao campo | Pode nunca ser anunciado | Associar ao campo e anunciar a mudança |
Todo o elemento interativo tem de fazer sentido lido sozinho, fora de contexto. É o mesmo teste do botão tapado do capítulo 3 — o que é boa microcópia visual é, quase sempre, boa acessibilidade. Os detalhes técnicos estão em Acessibilidade & WCAG.
11.2 Texto alternativo de imagens
- Descreva a função, não a aparência. Num botão de guardar com uma disquete, o alternativo é "Guardar", não "disquete".
- Imagem decorativa leva alternativo vazio (
alt=""). Descrever uma textura de fundo só acrescenta ruído a quem ouve. - Num gráfico, dê o achado. "Gráfico de barras" não serve; "As vendas subiram 40% entre janeiro e março, com queda em fevereiro" é a informação que o gráfico transporta (Comunicação de Dados).
- Não comece com "imagem de". O leitor já anuncia que é uma imagem.
11.3 Linguagem simples não é linguagem infantil
Escrever de forma acessível é escolher a palavra comum quando ela serve, não empobrecer o conteúdo. "Utilizar" → "usar". "Efetuar o pagamento" → "pagar". "Proceder à submissão" → "enviar". O ganho é para toda a gente, e é maior para quem lê numa segunda língua, para quem tem dislexia, e para quem está com pressa — que é toda a gente, a maior parte do tempo.
Termos técnicos corretos não devem ser trocados por aproximações vagas. Chamar "aquela chave secreta" a uma chave de API não simplifica: impede a pessoa de procurar ajuda, porque lhe tirou a palavra que precisava para procurar. Simplifique a sintaxe, não o vocabulário exato.
11.4 Escrever para ser traduzido
| Problema | Porquê | O que fazer |
|---|---|---|
| Frases montadas por pedaços | "Apagar" + " " + nome + " " + "agora?" quebra-se em línguas com outra ordem | Frase inteira com um marcador: "Apagar {nome} agora?" |
| Texto sem contexto para quem traduz | "Estado" é substantivo ou verbo? Cabeçalho ou rótulo? | Nota junto à chave: onde aparece e que espaço tem |
| Layouts justos | O alemão cresce 30% e o português cerca de 20% face ao inglês | Desenhar com folga; testar com a língua mais longa |
| Trocadilhos | Não sobrevivem à tradução; produzem frases estranhas | Guardar para conteúdo de marca, não para interface |
| Género e plural no código | "1 ficheiro(s) selecionado(a)" | Formas plurais próprias da língua, não parênteses |
11.5 Títulos que também são resultados de busca
O título de uma página é lido em três sítios: no ecrã, no separador do navegador e no resultado de pesquisa. O mesmo texto serve os três se for específico e começar pelo que distingue — "Fatura 2024/318 · Uniana", não "Uniana · Área de cliente · Faturação · Detalhe".
Ative o leitor de ecrã do sistema (VoiceOver no macOS, Narrador no Windows) e percorra um fluxo do seu produto de olhos fechados, só pelo teclado. Conte quantas vezes ouve "botão" sem saber que botão é. É a hora mais desconfortável e mais produtiva desta apostila.
Capítulo 12 Operação
Como se trabalha isto
Microcópia boa não sai de talento: sai de estar na conversa a tempo, de ter um sítio onde as decisões vivem, e de se poder testar como qualquer outra parte do desenho.
12.1 Chegar a tempo
| Quando o texto entra | O que acontece |
|---|---|
| Depois do ecrã desenhado | Escreve-se para caber na caixa. A caixa foi dimensionada com lorem ipsum, portanto a caixa está errada. |
| Ao mesmo tempo que o ecrã | O texto muda o desenho e o desenho muda o texto. É aqui que se descobre que o ecrã precisa de menos elementos e não de uma frase mais curta. |
| Antes do ecrã | Escrever o fluxo todo em texto simples — só as frases, por ordem — expõe os buracos de lógica antes de custarem alguma coisa. É o método mais barato do capítulo. |
Escreva o fluxo como se fosse um diálogo entre a pessoa e o produto, em texto corrido, sem pensar em ecrãs. Onde a conversa ficar estranha — o produto a pedir a mesma coisa duas vezes, a anunciar algo que ninguém perguntou — há um problema de fluxo, não de redação. Dez minutos, e apanha o que a maquete esconde.
12.2 Testar texto
Teste dos cinco segundos
Mostre o ecrã cinco segundos e pergunte o que aquele botão vai fazer. Barato, rápido, e apanha a maioria das ambiguidades.
Teste da árvore
Só os rótulos de navegação, sem interface: "onde procuraria X?". Isola problemas de vocabulário dos de desenho.
Comparação A/B
Para textos vistos por muita gente — botões de conversão, assuntos de email. Mede quanto, não porquê (Experimentação).
Ler em voz alta
O teste gratuito que ninguém faz. Se tropeçar a ler, quem lê também tropeça — e frases que soam a comunicado dão-se logo a conhecer.
Todos estes vêm de Pesquisa com Utilizadores; a única diferença é que a tarefa incide sobre uma palavra em vez de um fluxo.
12.3 O glossário: uma coisa, um nome
O documento mais útil e mais barato do ofício. Três colunas e nada mais:
| Usamos | Não usamos | Porquê |
|---|---|---|
| Espaço de trabalho | Workspace, organização, conta | É o que os clientes dizem ao telefone |
| Convidar | Adicionar utilizador, provisionar | A pessoa convidada tem de aceitar |
| Arquivar | Apagar, remover, ocultar | Arquivar é reversível; apagar não |
A terceira coluna é a que faz o glossário sobreviver: sem o porquê, a decisão é rediscutida de seis em seis meses por cada pessoa nova.
12.4 O texto como parte do sistema
Se a equipa tem um sistema de desenho, a microcópia pertence-lhe: cada componente documentado leva o texto exemplar e as suas regras — o que um toast pode dizer e em quantos caracteres, o que um estado vazio tem de incluir, que verbos usam os botões primários. Escrito uma vez no componente, aplica-se em cem ecrãs sem passar por ninguém (Design Systems & Tokens, Guia de Elementos de Interface).
12.5 IA para escrever interfaces
| Serve bem | Serve mal |
|---|---|
| Gerar dez variantes de um rótulo para escolher e cortar | Escolher — a decisão exige saber o que a pessoa está a fazer naquele momento |
| Encontrar todas as inconsistências de vocabulário no produto inteiro | Decidir qual é o termo certo: isso vem do que os clientes dizem, não do que é mais comum na internet |
| Traduzir um primeiro rascunho para revisão humana | Traduzir sem contexto: sem saber onde a frase aparece, a tradução é uma aposta |
| Aplicar regras explícitas: eliminar "submeter", encurtar para 40 caracteres | Escrever mensagens de erro sozinha — não sabe se houve cobrança nem se o rascunho ficou guardado, que é a linha que interessa (cap. 9) |
A IA é boa a produzir opções e má a produzir critério. E a microcópia é quase toda critério: quem lê, em que estado, com que pressa, e o que perde se falhar. Um texto gerado sem essa informação soa bem e resolve pouco — o que o torna mais difícil de rejeitar numa revisão.
12.6 Para onde ir a seguir
- Pesquisa com Utilizadores — como se descobre que uma palavra não está a funcionar, e as palavras que as pessoas usam de verdade.
- Guia de Elementos de Interface — os componentes onde este texto vai viver.
- Acessibilidade & WCAG — a parte técnica do capítulo 11.
- Design Systems & Tokens — como fazer uma decisão de texto valer em cem ecrãs.
- Apresentar e Defender Design — para o caso, muito comum, de a discussão sobre um botão ser na verdade uma discussão sobre outra coisa.
- Storytelling — o outro ofício de escrita, com outras regras.
Escreva as dez primeiras linhas do glossário do seu produto, com as três colunas. Leve-o à equipa. Vai descobrir que pelo menos três termos são discutíveis — e essa discussão, feita uma vez, poupa cem correções.