Microcopy de produto: quem escreve e quando entra no design

Microcopy de produto é o texto que faz a interface funcionar: rótulo de campo, mensagem de erro, estado vazio, confirmação de ação destrutiva e texto de espera. Isso é desenho da interação, não texto de marketing. Quem escreve importa menos que o momento em que o texto entra no processo e o critério com que ele é revisado.

Três tipos de texto, três donos diferentes

Microcopy é o texto mais curto do produto, e o único que muda um estado.

Conteúdo editorial é o texto longo: artigo, página de ajuda, nota de versão. Ele vive em um CMS, é lido em sequência e muda sem deploy.

Texto de marketing pertence à campanha: anúncio, landing page, e-mail. Ele vive em um calendário e morre junto com a campanha.

O erro começa quando os três se misturam. Uma manchete de landing page dentro de um estado vazio transforma o próximo passo em pitch.

O Carbon declara que suas diretrizes de conteúdo são para quem escreve ou revisa texto nas interfaces de produto da IBM (Carbon, Content (em inglês)). E faz sentido. Texto de interface não é tarefa de um departamento à parte.

Por que microcopy faz parte do desenho da interação

O texto não é legenda do componente. Ele é o componente em um estado.

O Material Design diz que todo campo de texto deve ter rótulo, sempre visível e nunca truncado (Material 3, Text fields (em inglês)). A WCAG exige rótulos ou instruções que identifiquem os controles de um formulário (W3C, 3.3.2 Labels or Instructions (em inglês)).

O Nielsen Norman Group resume a divisão de trabalho em uma linha: quem escreve usa palavras no lugar de pixels para se comunicar com o usuário (NN/g, UX Writing Study Guide (em inglês)).

O GOV.UK acrescenta o teste. Se você precisa explicar como a interface funciona, o problema é a interface (GOV.UK, Writing for user interfaces (em inglês)).

Quando o texto entra no processo

O texto vem antes do layout, não depois.

Texto que chega depois da tela desenhada vira legenda de decisões já tomadas. Um estado que ninguém consegue nomear costuma ser um estado que ninguém desenhou.

O Carbon faz as perguntas nessa ordem: como a página fica sem conteúdo e quais passos o usuário pode dar para preenchê-la (Carbon, Empty states (em inglês)).

O GOV.UK pede que o time saiba por que faz cada pergunta e corte o que não precisa (GOV.UK, Question pages (em inglês)).

Escrever o texto primeiro é um teste de escopo. A frase que não dá para escrever costuma ser um estado que não existe. A mesma ordem aparece no trabalho de estado vazio e carregamento e no de formulário de um campo só.

Quem escreve quando não existe UX writer

Quem é dono do estado escreve o texto. Não o designer por padrão, e não a melhor escrita do time.

Na maioria dos times, o designer de produto escreve o rótulo e o estado vazio. O suporte escreve o erro que já explica por ticket, e a engenharia escreve a mensagem que o sistema dispara.

Quem cuida da tela escreve o texto dela, seja qual for o cargo.

Time sem writer não precisa de um cargo novo. Precisa que o texto entre no processo com o mesmo dono do estado que ele descreve.

Mensagem de erro

O GOV.UK exige que a mensagem diga o que deu errado e como corrigir (GOV.UK, Error message (em inglês)).

O mesmo sistema exige um resumo de erros no topo da página e uma mensagem ao lado do campo com erro (GOV.UK, Error summary (em inglês)).

A WCAG pede que o erro seja descrito em texto, com o item em erro identificado (W3C, 3.3.1 Error Identification (em inglês)).

O NN/g acrescenta posição e momento: mostre a mensagem perto da origem e não mostre antes de o usuário terminar (NN/g, Error-Message Guidelines (em inglês)).

O difícil é saber quando ser específico deixa de ajudar. Uma mensagem que lista todas as causas possíveis fica maior que a ação que ela bloqueia.

O Material recomenda trocar o texto de apoio pelo texto de erro, para o layout não pular quando a mensagem aparece (Material 3, Text fields (em inglês)).

Estado vazio

O Carbon avisa que estado vazio costuma ser tratado como detalhe de última hora, e pede título escrito como afirmação positiva (Carbon, Empty states (em inglês)).

A mesma página também põe um limite. Mais conteúdo não é solução melhor, porque cada linha na página tem custo cognitivo.

O NN/g trata o estado vazio de aplicação complexa como problema próprio, com três diretrizes (NN/g, Designing Empty States in Complex Applications (em inglês)).

O estado vazio é o único lugar onde um texto mais longo costuma valer a pena. Tem espaço, o usuário não tem nada para ler e a próxima ação é a mensagem. Quanto texto uma pessoa lê de fato na tela tem medição própria, reunida em tipografia e leitura na tela.

Rótulo de campo

O Material mantém o rótulo visível, alinhado ao texto digitado, curto e nunca truncado (Material 3, Text fields (em inglês)).

O GOV.UK pede uma pergunta por página e marca o campo opcional como opcional (GOV.UK, Question pages (em inglês)).

O rótulo também é o nome acessível do campo, e é por isso que a WCAG o exige (W3C, 3.3.2 Labels or Instructions (em inglês)).

O limite: rótulo que precisa de um parágrafo de explicação é campo que não deveria existir. O GOV.UK enuncia a regra como comece com menos (GOV.UK, Writing for user interfaces (em inglês)).

Confirmação de ação destrutiva

O Material afirma que diálogos são interrupções por definição, então devem ser usados com parcimônia (Material 3, Dialogs (em inglês)).

O NN/g alerta contra confirmação de rotina, porque diálogo que todo mundo dispensa não protege ninguém, e pede especificidade com o nome e a quantidade de registros (NN/g, Confirmation Dialogs (em inglês)).

A WCAG pede que envios legais, financeiros e de dados sejam reversíveis, verificáveis ou confirmados (W3C, 3.3.4 Error Prevention (em inglês)).

O rótulo do botão é o controle mais barato. Excluir 3 registros evita mais erro que um diálogo repetindo a palavra excluir.

Texto de espera

O NN/g mediu três limites: 0,1 segundo para manipulação direta, 1 segundo para o fluxo de raciocínio e 10 segundos para a atenção (NN/g, Response Time Limits (em inglês)).

Abaixo de um segundo, texto de retorno só acrescenta ruído.

O Carbon coloca esqueleto de carregamento em contêiner, indicador de progresso quando a espera passa de um instante e notificação quando o processo leva minutos (Carbon, Loading (em inglês)).

A regra: o texto existe para responder o que a interface não consegue responder visualmente. Quando a tela já mostra movimento, a palavra carregando é decoração.

O critério de revisão

Revisão acontece por critério, não por preferência. Quatro checagens pegam a maior parte do texto ruim de uma interface.

O texto nomeia o estado. Nenhum resultado nomeia, e Algo deu errado esconde.

O texto diz qual é a próxima ação. Mensagem sem próximo passo é um beco sem saída, só que educado.

O texto é a versão mais curta que ainda funciona. O GOV.UK enuncia a regra como comece com menos (GOV.UK, Writing for user interfaces (em inglês)).

O texto sobrevive à tradução e ao leitor de tela. Texto que só funciona em um idioma não está pronto, que é o mesmo problema descrito em design system depois do lançamento.

A pergunta de tom vem depois dessas quatro, não antes.

Quando a mensagem genérica é a resposta certa

Quatro casos em que o curto e genérico ganha.

A causa é desconhecida, ou a lista sairia errada. Mensagem que chuta ensina o usuário a desconfiar de todas as outras.

O texto específico confirmaria informação que o sistema não deve confirmar. Login, recuperação, existência de conta.

O estado já foi aprendido. Quem viu o mesmo erro três vezes não lê a quarta.

O texto específico é maior que a ação que ele protege. Sua sessão expirou, entre novamente com as credenciais usadas antes perde para Sessão expirada, entrar de novo.

O GOV.UK afirma que não há motivo para dizer desculpe em mensagem de validação. Também diz que não há lugar para humor em serviço que a pessoa usa sob estresse (GOV.UK, Writing for user interfaces (em inglês)).

A regra é sobre custo, não sobre tom.