Como escrever rótulos para menus, botões e outros microtextos para UIs

Tem sido uma jornada bastante produtiva e interessante criar o design system aqui na Labcodes: os desafios são constantes, assim como os aprendizados. Uma das coisas que estamos fazendo é documentar nossas referências de pesquisa e estudo, assim como as escolhas para que tenhamos consistência dentro dos componentes do projeto e, principalmente, uma conexão uníssona com nossos princípios de design.

Um assunto que sempre me atraiu muito foi a escrita de microtextos para interfaces, e, no nosso design system, fui responsável pela criação dos componentes de notificação, botões e menus dropdown. Em comum, eles requerem guias e regras para a escrita dos seus rótulos, no caso de menus e botões, e mensagens mais longas, para banners e toasts.

Lembro que muito tempo atrás, logo nas primeiras versões de algum aplicativo móvel que não lembro qual, eu li em algum lugar na internet (desculpem a falta de referências) sobre uma mudança feita na interface: o termo “minha biblioteca” foi ajustado para “sua biblioteca”. Tá! Mas o que tem de interessante nisso?

Foi naquele momento que o software começou a se comunicar diretamente com seus usuários. No exemplo, ao invés de considerar a biblioteca pertencente ao sistema, o sistema agora informa que a biblioteca pertence ao usuário. Essa mudança mostra como detalhes de microtextos mudam a percepção do leitor sobre um produto. Mais abaixo retomarei esse assunto.

Escrevendo rótulos

Os rótulos são comandos aplicados a elementos de interface como menus, tags, botões, entradas de texto e outros elementos de interface. Eles se dirigem diretamente aos usuários, comunicando algo ou solicitando uma ação. Estes comandos estão associados com fluxos interativos, normalmente mudam o estado do sistema e devem ser breves, informativos e extremamente claros. (adaptado de n/n group)

Cada empresa normalmente, em seu guia de marca, apresenta o tom e voz da comunicação escrita dessa organização. Utilize como base esse guia para escrever de acordo como sua empresa faz. Aplique essas regras, assim como outras boas práticas de escrita, para chegar a bons resultados. Aqui na Labcodes temos o nosso próprio guia de escrita, que nos ajuda bastante.

Seguindo este raciocínio, os botões do nosso design system possuem rótulos que:

• Devem comunicar exatamente o que acontecerá quando o usuário interagir com determinado componente.
• Apenas a primeira letra da frase que compõe o rótulo é maiúscula, assim como qualquer outro substantivo específico que exija capitalização.
• São o mais curtos possível, com, de preferência, no máximo 3 palavras.

Por mais que seja difícil reduzir para apenas 3 palavras, escolhemos manter o desafio para treinar nossa habilidade de síntese e buscar comunicar o que realmente importa.

Para os menus de ação, usamos algumas regras específicas, mas elas também são aplicáveis aos botões e a outras categorias de rótulos:

• Use verbos e frases imperativas para descrever a ação que acontecerá com a interação. Nunca coloque apenas um verbo sozinho, mas sempre com um substantivo. Por exemplo: “Mover item”, “Editar descrição”, “Obter ajuda”.
• Use substantivos para ações que levam para outras páginas (ações de navegação/links). Por exemplo: “Atalhos do teclado”, “Editor de perfil”, “Configuração do sistema”.
• Não use artigos. Eles podem confundir algo que é mais simples, aumentando o comprimento de uma linha, além de gerar outros efeitos indesejados. Por exemplo: escreva “Adicionar marcação” ao invés de “Adicionar uma marcação”. Esta última frase apresenta uma cacofonia devido ao uso do artigo, e se, assim como eu, você usa corretores de texto, é possível que ele te avise.

Voltemos o que mencionei anteriormente sobre a importância dos microtextos na percepção do produto. Atenção ao nomear itens de propriedade do sistema ou do usuário! Um bom exemplo é escrever “Suas configurações” ao invés de “Minhas configurações”, já que estamos falando de preferências do usuário, que, mesmo sendo gravadas no sistema, são escolhas pessoais. Essa escolha mostra delicadeza ao explicitar valores do produto e mostrar quem está no comando.

O diálogo entre sistema e seus usuários deve ser direto, claro e amigável. Ao redigir textos para interface, imagine o sistema como uma pessoa técnica experiente conversando com uma pessoa não técnica que precisa saber o que fazer a seguir, explicando uma questão de forma compreensível, sem tornar a experiência densa ou assustadora.

Algo importante para se considerar na escrita de rótulos de botões é o uso de termos como “Ok”, “Sim”, “Não”, “Concluir”, que não têm um significado explicito de suas ações. Pode ser legal explicitar as ações que serão realizadas, porque o uso de termos genéricos pode gerar dificuldades de compreensão ou levar o usuário a tomar uma ação que vá se arrepender.

A maioria dos usuários normalmente aperta botões ou seleciona ações sem prestar muita atenção no que estão fazendo. Para evitar esses transtornos, em ações potencialmente destrutivas ou que possam causar um erro, sempre forneça uma maneira de desfazer a ação e use rótulos claros que ajudem o usuário a reconhecer as opções de “Desfazer”, “Cancelar”, “Interromper”. Em alguns casos, pode ser útil adicionar uma segunda camada de confirmação para evitar perdas de dados.

Em casos comuns, simplesmente não há espaço suficiente numa aplicação para acomodar comandos com rótulos longos, por isso a repetição do lembrete de manter tudo muito simples. Considere como um mantra e sempre se pergunte se um rótulo pode ser simplificado mais ainda sem perder a clareza. Dê preferência a rótulos com apenas uma linha de texto que contenham até 4 palavras.

O modelo de design para textos de interface

A Microsoft tem um artigo muito interessante sobre um modelo de design para textos de interfaces. Como não encontrei facilmente materiais com essa temática em português, coloco logo aqui abaixo, em tradução livre, com algumas adaptações:

Ao pensar em texto para interfaces e seu posicionamento na tela, considere esses fatos:

• Durante uma leitura imersiva e focada, as pessoas leem da esquerda para direita, e de cima para baixo (em culturas ocidentais).
• Ao usar softwares, os usuários não estão imersos na interface, mas em seu trabalho. Consequentemente, eles não leem os textos apresentados na tela, eles fazem uma varredura.
• Ao fazer essa varredura, os usuários podem parecer estar lendo os textos, mas, na verdade, eles o estão filtrando. Geralmente, eles não compreendem verdadeiramente o texto apresentado, a menos que percebam a necessidade de parar o que estão fazendo e ler com atenção.
• Dentro de uma janela, diferentes elementos da interface do usuário recebem diferentes níveis de atenção. Os usuários tendem a ler os rótulos de comandos primeiro, especialmente aqueles que parecem relevantes para a conclusão da tarefa que estão realizando no momento

Os usuários tendem a ler texto estático apenas quando supõem que precisam.

Para um modelo mais inclusivo, não suponha que os usuários leem cuidadosamente o texto da esquerda para a direita e de cima para baixo. Em vez disso, suponha que eles fazem uma varredura rápida de toda a janela e, em seguida, leem os textos da interface aproximadamente nessa ordem:

• Controles interativos no centro.
• Botões de confirmação.
• Controles interativos encontrados em outras áreas.
• Instrução principal.
• Explicações suplementares.
• Título da janela (quando disponível).
• Outro texto estático no corpo principal.
• Notas de rodapé.

Você também deve presumir que, uma vez que os usuários decidem o que fazer, eles imediatamente param de ler qualquer texto e partem para a ação.

Seguindo adiante

Comportamento, para mim, é sempre algo muito fascinante e que prende minha atenção. Sempre busco, assim como toda a equipe, produzir conteúdo de fácil compreensão.

Tornar clara a informação disponível é crucial para o processo de tomada de decisões e orientação em interfaces, e em muitos casos a informação é escassa, truncada ou o ambiente apresenta informações deslocadas, erradas ou contraditórias, levando o usuário a recorrer a técnicas mais instintivas como tentativa e erro, ou sorte.

Você já tinha parado para pensar que o processo de orientação dentro de uma interface depende, além da sua estrutura, da forma que os textos e microtextos são escritos?

Enquanto isso, ficou alguma dúvida, tem alguma sugestão ou quer iniciar um debate? A seção de comentários está aberta e queremos saber o que você pensa e suas experiências com escrita para interfaces! Até a próxima :)

Referências (em inglês):

Messages - Atlassian Design System
Select - Atlassian Design System
Dropdown menu - Atlassian Design System
Messaging guidelines - Lightning DS
Alerts - Lightning DS
Action labels - Carbon DS
UI Copy - n/n group
Windows 7 interface text writing guide - Microsoft