Octadesk
Uma voz para todos os produtos
Criação do primeiro guia de voz e tom da Octadesk para dar mais consistência às experiências e autonomia aos times de produto.
01 - Contexto
Contexto do projeto
Mais do que definir como a empresa deveria escrever, o desafio era transformar decisões individuais em critérios compartilhados.
Quando cheguei à Octadesk, os produtos já tinham textos adequados, mas não havia um guia de tom de voz. Cada profissional tomava decisões de escrita com base no próprio repertório.
Isso fazia com que telas e jornadas variassem em vocabulário, tom, estrutura de mensagens e CTAs. Não era um problema de textos ruins. Era um problema de consistência.
Antes da chegada de UX Writing, cada designer resolvia essas questões como considerava melhor. Depois que entrei, parte das dúvidas passou a chegar até mim, mas muitas decisões continuavam sendo tomadas diretamente pelos times.
02 - Problema
O desafio
Eu era o único UX Writer da empresa e não conseguiria participar de todos os projetos com a mesma intensidade.
Se diferentes pessoas continuariam tomando decisões de conteúdo sem a participação direta de Writing, elas deveriam ao menos partir de uma mesma base.
O objetivo do guia não era ensinar designers a escrever. Era criar critérios para que tomassem decisões com mais autonomia e mantivessem uma experiência mais consistente entre os produtos.
03 - Pesquisa
Buscando referências
Pesquisei como outras empresas transformavam princípios de linguagem em ferramentas utilizáveis pelos times de produto.
Usei materiais que já havia produzido em um trabalho anterior, referências estrangeiras e alguns exemplos brasileiros, como Carrefour e Mercado Livre.
Três características foram especialmente úteis: a organização do conteúdo, os exemplos de certo e errado e a divisão das orientações por componentes de interface.
A ideia não era reproduzir outros guias, mas entender quais formatos tornavam as regras mais fáceis de encontrar e aplicar.
04 - Priorização
Do produto para o guia
Em vez de partir de uma lista abstrata de regras, observei o próprio produto para decidir o que deveria entrar primeiro.
Priorizei os componentes mais frequentes nas interfaces e depois avancei para situações menos recorrentes. Assim, o guia nasceu conectado aos problemas que os designers encontravam no dia a dia.
O resultado foi um material de aproximadamente 50 páginas, tentando contemplar os principais tipos de componente presentes no produto.
05 - Voz
Definindo a voz
Conversei com o principal sócio da empresa para alinhar as características que deveriam permanecer presentes na linguagem.
A Octadesk já transmitia proximidade, simplicidade, leveza e certo bom humor. Essas características precisavam continuar presentes, mas sem tornar a linguagem solta demais. Havia também uma preocupação em transmitir seriedade.
O trabalho foi encontrar esse equilíbrio: uma voz próxima e simples, sem comprometer a confiança no produto.
06 - Aplicação
Decisões na prática
O guia precisava ir além de orientações abstratas como “seja simples” ou “seja próximo”. Esses princípios precisavam aparecer em decisões concretas de interface.
Um dos problemas estava nas mensagens de erro. Em alguns casos, o produto apenas informava que algo estava errado, com mensagens como “Número inválido” ou “Sem conexão”, mas não indicava o que fazer em seguida.
Por isso, uma das orientações passou a ser não apenas comunicar o problema, mas, sempre que possível, indicar uma forma de resolvê-lo ou um próximo passo.
Os CTAs eram outro ponto em que diferentes decisões conviviam no produto. O guia passou a concentrar referências para que essas escolhas deixassem de depender apenas do repertório de quem projetava cada tela.
A intenção não era retirar autonomia, mas oferecer um ponto de partida comum.
07 - Exemplos
Mostrar é melhor do que explicar
Uma das decisões mais importantes foi usar exemplos de “faça” e “não faça”.
O designer conseguia comparar rapidamente uma solução adequada com outra que deveria ser evitada, reduzindo a necessidade de interpretar regras abstratas.
Esse formato também já fazia parte do repertório dos designers, acostumados a padrões semelhantes em design systems e guidelines de interface.
08 - Adoção
Colocando o guia em circulação
Depois de algumas semanas de trabalho, apresentei uma primeira versão para a liderança. O material foi muito bem recebido. Era uma necessidade que a empresa reconhecia, mas ainda não havia estruturado internamente.
Depois da validação, o guia foi apresentado ao time de designers para que passasse a funcionar como referência durante o próprio processo de Design.
09 - Resultado
O que mudou
O guia deu aos designers uma referência comum e aumentou a consistência entre os produtos.
Também trouxe mais autonomia. Pessoas passaram a consultar o material e aplicar suas orientações sem precisar necessariamente falar comigo ou saber quem havia escrito determinada regra.
Parte do conhecimento que antes dependia de uma pessoa passou a existir de maneira compartilhada.
Embora criado principalmente para Design, o material também passou a ser consultado por PMs e desenvolvedores.
10 - Aprendizados
Aprendizados
Criar o guia mostrou que escalar UX Writing não significa estar presente em todas as decisões de conteúdo. Também significa criar sistemas capazes de orientar boas decisões quando o writer não está na sala.
Hoje, eu envolveria mais pessoas durante a construção, entrevistando designers e outros profissionais para entender como percebiam a linguagem dos produtos e quais dificuldades encontravam no dia a dia.
Também investiria mais na divulgação depois do lançamento. Um guia só ganha valor quando passa a fazer parte do trabalho cotidiano, e sua adoção precisa ser tratada como parte do projeto.
O principal aprendizado ficou aí: um guia de conteúdo não é apenas um documento sobre como escrever. É uma maneira de distribuir critérios, reduzir dependências e permitir que diferentes pessoas construam uma mesma experiência de marca.