Copy também é interface

Uma interface pode estar visualmente correta e ainda assim ser difícil de usar.

O botão está no lugar certo.

A hierarquia funciona.

Os componentes são consistentes.

O fluxo tecnicamente faz sentido.

Mas o usuário continua sem saber exatamente o que vai acontecer quando clicar.

Às vezes, o problema não está no design.

Está nas palavras.

Durante a construção de produtos, é comum tratar texto como algo que entra depois.

Primeiro resolvemos a interface.

Depois colocamos um título.

Uma descrição.

Alguns botões.

Uma mensagem de erro.

No fim, parece apenas conteúdo preenchendo espaços que já estavam definidos.

Só que texto dentro de uma aplicação não ocupa apenas espaço.

Ele orienta comportamento.

E isso faz da copy uma parte da interface.

Um botão nunca é apenas um botão

Imagine uma ação relativamente simples.

Existe um modal e, no final, dois botões:

Cancelar

e

Confirmar

Visualmente, não existe necessariamente nada errado.

O problema é que “confirmar” pode significar praticamente qualquer coisa.

Confirmar exclusão?

Confirmar pagamento?

Confirmar publicação?

Confirmar alteração?

Quanto maior a consequência de uma ação, mais importante fica deixar explícito o que vai acontecer.

Compare:

Confirmar

com

Excluir projeto

O segundo exige praticamente o mesmo espaço, mas reduz uma dúvida importante no momento da decisão.

Esse tipo de detalhe parece pequeno.

Mas produtos são feitos de centenas dessas pequenas decisões.

E cada uma delas pode adicionar ou remover fricção.

Clareza reduz trabalho mental

Boa parte da experiência de uma interface está relacionada ao quanto o usuário precisa interpretar sozinho.

Quando a linguagem é vaga, ele precisa completar aquilo que o produto não explicou.

“O que isso faz?”

“Posso voltar depois?”

“Essa alteração já foi salva?”

“Vou perder meus dados?”

“Por que não consigo continuar?”

Nenhuma dessas perguntas deveria exigir investigação.

Ainda assim, aparecem o tempo inteiro em produtos digitais.

Não necessariamente porque a interface esteja mal desenhada.

Às vezes, simplesmente faltou informação no momento certo.

Uma boa copy não existe para explicar toda a aplicação.

Existe para remover dúvidas onde elas realmente importam.

A diferença entre informar e orientar

Considere uma mensagem bastante comum:

Ocorreu um erro.

Ela informa uma coisa verdadeira.

Algo deu errado.

Mas isso ajuda muito pouco quem está tentando concluir uma tarefa.

O que aconteceu?

O usuário fez algo errado?

Os dados foram perdidos?

Vale tentar novamente?

Precisa entrar em contato com alguém?

Existe uma diferença importante entre comunicar o estado do sistema e ajudar alguém a decidir o que fazer em seguida.

Uma mensagem melhor poderia ser:

Não foi possível salvar as alterações. Tente novamente em alguns instantes.

Agora existe um problema, mas também existe direção.

Dependendo do caso, podemos ser ainda mais específicos:

Esse e-mail já está sendo usado por outra conta.

Nesse cenário, “ocorreu um erro” seria tecnicamente correto.

Mas praticamente inútil.

Copy dentro de produto funciona melhor quando responde à dúvida que nasce naquele momento.

Mensagens de erro também fazem parte da experiência

No artigo anterior desta série, falamos sobre como erros fazem parte do fluxo.

A maneira como escrevemos esses erros é uma continuação natural dessa decisão.

Existe uma tendência de transformar mensagens internas do sistema em mensagens para o usuário.

Invalid request.

Unauthorized.

Validation failed.

Something went wrong.

Essas mensagens talvez façam sentido para quem está depurando a aplicação.

Para quem está usando, geralmente não.

O usuário não precisa conhecer a abstração que falhou.

Precisa entender a consequência.

Se uma sessão expirou, talvez a mensagem precise dizer que ele deve entrar novamente.

Se um arquivo ultrapassou o limite permitido, precisamos dizer qual é o limite.

Se determinado campo está inválido, precisamos explicar o que esperamos dele.

Isso parece trabalho de texto.

Mas o impacto é diretamente funcional.

Uma mensagem ruim pode transformar um problema recuperável em abandono.

Um estado vazio pode ensinar

Estados vazios são outro lugar em que texto tem um papel muito maior do que simplesmente preencher a tela.

Imagine uma área de projetos sem nenhum registro.

Podemos escrever:

Nenhum projeto encontrado.

Está correto.

Mas não necessariamente é útil.

Se aquele é o primeiro acesso do usuário, talvez a verdadeira mensagem seja outra:

Você ainda não criou nenhum projeto. Crie o primeiro para começar.

Agora o sistema não está apenas descrevendo o estado.

Está ajudando o usuário a entender o próximo passo.

Existe uma diferença importante entre ausência de informação e orientação.

O design pode criar espaço para isso.

A copy transforma esse espaço em entendimento.

O problema das palavras internas

Quem constrói um produto passa muito tempo olhando para ele.

Com isso, começa a desenvolver um vocabulário próprio.

Sabemos o que significa workspace.

Pipeline.

Instance.

Environment.

Integration.

Workspace member.

Deploy target.

Para nós, esses termos começam a parecer óbvios.

Para quem chega pela primeira vez, talvez não sejam.

Esse é um problema recorrente porque o produto acaba sendo escrito a partir do modelo mental de quem construiu o sistema.

E não necessariamente de quem está tentando utilizá-lo.

Nem sempre precisamos simplificar tudo.

Produtos técnicos podem (e muitas vezes devem) utilizar linguagem técnica.

A questão é outra:

o usuário entende esse termo no contexto em que ele aparece?

Se a resposta depende de conhecer como o sistema foi implementado internamente, talvez exista uma distância entre a linguagem do produto e a linguagem de quem o utiliza.

Copy também define expectativa

Um dos trabalhos mais importantes da interface é ajudar o usuário a prever consequências.

E palavras têm um papel enorme nisso.

Considere:

Salvar

Salvar rascunho

Publicar

Enviar para revisão

Os quatro podem, tecnicamente, atualizar um registro no banco de dados.

Mas representam expectativas completamente diferentes.

Quando a ação é clara, o usuário consegue decidir com mais confiança.

Quando não é, aparecem hesitação e medo.

Principalmente em ações difíceis de desfazer.

Excluir.

Cancelar.

Publicar.

Enviar.

Cobrar.

Transferir.

Quanto maior a consequência, menor deveria ser a ambiguidade.

Essa é uma das razões pelas quais copy não deveria ser tratada apenas como acabamento editorial.

Ela participa diretamente da arquitetura de decisão da interface.

Confirmação também precisa de contexto

Outro padrão comum é adicionar confirmações para evitar erros.

Tem certeza?

É provavelmente uma das mensagens mais utilizadas em interfaces.

E também uma das menos informativas.

Tenho certeza de quê?

O que acontece depois?

Existe como desfazer?

Quais dados serão afetados?

Uma confirmação mais útil poderia dizer:

Excluir este projeto?

Todos os dados associados a ele serão removidos permanentemente. Essa ação não pode ser desfeita.

Agora existe uma decisão real.

O usuário entende a ação, a consequência e a reversibilidade.

Isso muda completamente a qualidade da escolha.

O modal pode ser exatamente o mesmo.

O que mudou foi a informação disponível para decidir.

Nem toda copy precisa explicar

Existe um risco importante nessa discussão.

Quando percebemos o valor do texto, podemos começar a colocar explicações em todos os lugares.

Tooltips.

Descrições.

Hints.

Alertas.

Textos auxiliares.

Modais.

De repente, a interface que deveria ficar mais clara se torna mais pesada.

Boa copy não é necessariamente mais copy.

Muitas vezes, é menos.

Se o botão já é evidente, não precisamos explicar o botão.

Se o campo já possui um label claro, talvez uma descrição adicional seja desnecessária.

Se a interface exige um parágrafo para explicar como uma interação funciona, talvez o problema não seja de texto.

Talvez seja da própria interação.

Copy também precisa saber quando sair do caminho.

Escrever depois pode ser tarde demais

Quando o texto entra somente no final, aparecem situações curiosas.

O design prevê espaço para uma palavra.

A ideia precisa de uma frase.

O componente aceita duas linhas.

O conteúdo precisa de quatro.

O botão foi desenhado para “Salvar”.

A ação real precisa dizer “Salvar e enviar para aprovação”.

Então começamos a ajustar o conteúdo para caber no design.

Quando talvez devêssemos fazer o contrário.

Conteúdo real testa interface.

Assim como nomes longos, números grandes e diferentes idiomas testam layout, mensagens reais também revelam limitações da composição.

Por isso, trabalhar com copy durante o processo ajuda a descobrir problemas antes.

Não é apenas uma questão de escrever melhor.

É uma maneira de testar se a interface consegue comunicar aquilo que precisa comunicar.

Frontend também toma decisões de linguagem

Isso é especialmente interessante quando pensamos no trabalho de frontend.

Na prática, muitas decisões de copy acabam acontecendo durante a implementação.

Uma validação nova precisa de mensagem.

Um estado inesperado aparece.

Um botão precisa de label.

Uma API retorna um erro que ainda não estava previsto no design.

E alguém precisa decidir o que mostrar.

É por isso que tratar linguagem como responsabilidade exclusiva de uma etapa anterior nem sempre funciona em produtos reais.

Não significa que todo desenvolvedor precisa virar copywriter.

Significa que precisamos reconhecer quando estamos tomando uma decisão de comunicação.

Porque escrever:

Falha na requisição

ou

Não conseguimos carregar seus projetos. Tente novamente.

é também uma decisão de produto.

Palavras fazem parte do comportamento

Uma interface não se comunica apenas através de formas, cores e movimento.

Ela também conversa.

Diz o que está acontecendo.

Explica o que é possível.

Bloqueia determinadas ações.

Confirma consequências.

Ajuda alguém a se recuperar.

Mostra o próximo passo.

Quando essas palavras são vagas, o produto exige interpretação.

Quando são precisas, a interface parece mais simples.

Não porque tenha menos complexidade.

Mas porque parte dessa complexidade foi organizada para quem está usando.

Indo além da criação

É fácil olhar para uma interface pronta e enxergar seus componentes.

Botões.

Inputs.

Cards.

Modais.

Menus.

Mas existe uma segunda camada atravessando todos eles.

As palavras que dizem o que cada coisa significa.

Às vezes, mudar uma frase resolve uma fricção que parecia exigir uma nova tela.

Às vezes, um botão mais específico evita um erro.

Uma mensagem mais clara reduz suporte.

Um estado vazio bem escrito ensina o produto.

Uma confirmação explícita evita uma decisão irreversível.

Nenhuma dessas mudanças chama tanta atenção quanto um redesign.

Mas todas mudam a forma como o produto é entendido.

Copy não entra depois da interface.

Copy é uma das coisas que fazem a interface funcionar.