Os bastidores do UX Writing

Como as restrições técnicas podem dar forma aos microtextos

Este texto foi publicado originalmente em inglês. A tradução foi autorizada pela autora Yael Ben-David. 👏

UX writing behind the scenes

As palavras que vemos na tela são somente a ponta do iceberg quando falamos em UX writing. Tem tanta coisa acontecendo abaixo da superfície que a pessoa usuária final nem imagina.

Sou lembrada disso constantemente quando me deparo com prints de alguns microtextos nas mídias sociais, seguidos de longas discussões sobre como eles claramente violam as regras básicas — quando, na verdade, pode haver centenas de motivos para que aquela linha tenha sido a melhor escolha.

Nós não conhecemos todos os fatores que levaram aquele elemento em específico para a interface.

O microtexto que vemos é a última parada de um grande processo. Foto: Annie Spratt no Unsplash

Requisitos regulatórios

Aqui vai um exemplo que me pega todos os dias: por conta de um requisito regulatório, preciso usar a voz passiva em textos nos quais a redatora em mim grita para usar a voz ativa. Mas eu não uso, porque isso faria com que a minha empresa fosse multada — e eu, demitida.

Qualquer dia desses é capaz de eu encontrar um print no Facebook ou no Twitter com algum texto que escrevi e várias críticas sobre como a voz passiva nunca deveria ser usada, muita gente apontando melhorias na escrita, dizendo que foi um trabalho preguiçoso ou desleixado, que é falta de talento ou investimento… e esses trolls até teriam um pouco de razão: geralmente, é realmente melhor evitar a voz passiva.

Mas nem sempre.

Eu trabalho em uma fintech, mercado altamente regulado. Mesmo redatoras e redatores que não têm tantas restrições regulatórias se deparam com muitos obstáculos. É parte do nosso trabalho ter certeza de que qualquer coisa que formos escrever não soe como um compromisso — apesar de frequentemente ser.

Funcionalidade

UX writing ajuda a pessoa a usar o produto, mas não o define.

Por exemplo, recentemente compartilhei um empty state que gostei:

Um empty state bem escrito aproveita para encorajar a pessoa a preenchê-lo.

Alguém disse: “por que não colocaram um botão ‘Criar planilha’?”

Não sei por que não tem um botão desse, mas não tem. Minha opinião foi sobre o microtexto relacionado à funcionalidade já existente. Devo presumir que mais fatores foram levados em consideração para aquele projeto de UX/UI além do efeito que teria no microtexto. E também que a decisão de não usar um botão foi deliberada: solicitaram que a pessoa UX writer escrevesse para esse elemento, não que propusesse outro.

Já escrevi muitos microtextos fantásticos que não eram certeiros, que não descreviam muito bem aquela funcionalidade, mas soavam bem. Porém, eles nunca foram para produção. Na versão aprovada, a pessoa via algo que podia até ser menos elegante, mas que fazia um trabalho melhor de levá-la até o objetivo dela.

Investimento

Já palestrei algumas vezes sobre o ROI (métrica para medir o retorno sobre o investimento) dos microtextos. De maneira geral, é importante investir em UX writing porque, no fim, uma boa escrita vai trazer dinheiro para a empresa.

Mas, olhando caso a caso, nem sempre vale a pena.

Por exemplo, mais de uma vez eu propus linhas que criariam excelentes experiências, utilizando muitas variáveis (como o fuso horário daquela pessoa em específico). Mas, às vezes, escrever as linhas de código para uma experiência customizada dessas não vale a pena. Poderia levar coisa de uma semana para desenvolver e não mudaria um milímetro no ponteiro de receita da empresa.

Daria um ótimo incremento para o meu portfólio, mas não pagaria os custos de desenvolvimento. Da próxima vez que você for criticar um texto, considere que a sua suposta melhor solução pode simplesmente não fazer sentido para o negócio.

Erros técnicos

Também já vi muitos posts nos quais o texto está ruim, mas não é culpa da escrita. Às vezes é só um erro técnico. Pessoas esculacham textos que não foram pensados para aparecer daquela forma. Nesses casos, nenhum UX writer sentou e produziu exatamente o que você viu na tela. Qualquer erro técnico pode deixar a experiência ruim — uma variável que saiu errada ou o banco de dados não respondeu e o placeholder daquela variável ficou ali para todo mundo ver. Isso não significa uma redação ruim. É apenas uma falha. Não é bom, mas é completamente diferente de um problema com o microtexto.

Um erro técnico estragou o assunto.

Não estou dizendo para evitarmos criticar esses textos, jamais. Quero dizer que seria mais proveitoso para todos nós se tivéssemos uma abordagem mais compreensiva e menos rígida.

Quando vemos um texto, devemos primeiro considerar como ele ficou daquele jeito, para início de conversa. Quais foram as considerações nos bastidores quando ele foi escrito? Depois disso, questionar: como eu escreveria sob as mesmas restrições?

Além de ser uma abordagem mais realista e relevante, é mais desafiadora — logo, muito mais divertida :)

Original: Yael Ben-David
Tradução: Danilo Guarniero
Revisão: Gisele Rosati Lourenço da Rocha

👏 Se essa tradução foi útil
💬 Se tiver sugestões ou algo a acrescentar