Como a colaboração dá vida as palavras
Use o Microcopy Canvas para colaborar, não projetar por comitê.
Esse artigo faz parte da série de artigos UX Translations. Foi escrito originalmente por janeruffino via UX Collective e traduzido para português com intenção de ajudar mais designers e alcançar um público ainda maior.
Você pode conferir o artigo original no link abaixo:
“Um camelo é um cavalo projetado por um comitê”.
Ao que tudo indica, Sir Alec Issigonis, designer automotivo do icônico carro Mini, fez esse comentário se referindo ao que acontece quando equipes não tem clareza. Talvez ele não gostasse de trabalhar em equipe, ou talvez ele fosse alguém que tivesse uma abordagem tirânica, como Steve Jobs para o design. Talvez ele nem tenha dito isso; mas alguém disse, pelo menos desde os anos 50.
Mas não importa o quanto valorizemos o trabalho em equipe e a colaboração, e independentemente de quanto somos colaborativos, todos provavelmente reconhecem essa frustração: vocês estão trabalhando num problema. Todos estão exaustos. As vozes que falam mais alto e as opiniões pessoais mais fortes são ouvidas. Alguém aparece com dados e ninguém liga. Outro, geralmente com uma opinião forte (e quase sempre errada), tenta forçar uma abordagem de “discordo mas me comprometo” para ganhar a discussão, e todos eventualmente e exaustivamente concordam com a pior opção só para poder sair logo da sala. E o que vocês criaram é o projeto equivalente a um camelo, quando o briefing especificamente pedia um pônei.
Agora que muitas equipes de produto e design têm escritores nelas, essa é a realidade de como a escrita é feita (estamos juntos escritores).
Há muitos conselhos sobre como trabalhar juntos. Como co-criar experiências. Estabelecer um tom e voz claro. E há artigos que refletem as frustrações que muitos escritores sentem nas equipes: finalmente, temos lugar na mesa, mas por que precisamos continuar provando o nosso valor, todos os dias, para quem trabalha conosco?
Todos esses pontos são verdadeiros (e recomendo todos os artigos citados), e nenhuma das táticas que estou prestes a sugerir funcionará se o problema fundamental de sua equipe for a falta de respeito pelos escritores (ainda há muito a ser escrito em relação a como os designers esnobam os escritores).
Mas em equipes que estão interessadas em descobrir como incorporar não apenas a escrita, mas também os escritores — eu vejo dois problemas principais que podem ser resolvidos com energia e um espaço dedicado para discussão.
Problema 1: problemas de identidade
Assim como com o design visual, wireframes (se você ainda os usa) e protótipos, todos devem ser empoderados para ter impacto e influência sob as palavras, mas, ao contrário de outras habilidades especializadas da equipe, a maioria das pessoas acha que é capaz de escrever. Alguns designers e desenvolvedores estão sobrecarregados com a tarefa de escrever há muito tempo e, embora até gostem da contratação de um escritor dedicado, pode ser um ataque ter, de repente, alguém cujas habilidades se sobrepõem às suas. Tal trabalho pode deixá-los preocupados se todas as vezes que eles escreveram no passado foram… ruins.
Não é que designers queiram se ver como escritores, mas sim que todos nós queremos nos sentir que fazemos um bom trabalho, especialmente se esse trabalho acabar entrando em contato com o público.
Abrir mão de um trabalho que estava fazendo pode ser difícil, mesmo que não seja uma função que você goste ou sinta capaz de fazer. É ótimo que os escritores possam escrever por você, porque escrever é difícil. Mas também é difícil deixar de lado o que você costumava fazer. Tudo bem, designers, estamos juntos também.
Problema 2: Feedback é difícil
Aprender a dar um feedback que foque nas coisas certas — é difícil. Muito difícil. A maioria que escreve há muito tempo teve que aprender da maneira mais difícil, tanto a dar quanto receber feedbacks que eram inúteis, mesmo quando foram bons.
As minhas habilidades de feedback ficaram melhores depois de passar dois anos intensos em um grupo de escritores, onde tínhamos regras extremamente rígidas sobre o feedback e como nos relacionamos e entendemos. A cada duas semanas, passávamos 5 ou 6 horas sentados em frente à minha pequena lareira, gritando uns com os outros sobre os textos, não para os escritores que éramos, mas os escritores que queríamos ser. Nós éramos como uma pequena família. Nós nos concentramos tanto nas relações pessoais de apoio que um dos caras do grupo acabou entrando comigo no meu casamento. Processos fortes de feedback criam vínculos inquebráveis, mas precisam de um nível de trabalho emocional que a maioria das equipes não está preparada para fazer.
Mas, se escritores profissionais acham difícil lidar com feedback, como podemos esperar que uma equipe faça isso sem nenhum treinamento? Sem tempo gasto aprendendo a falar sobre as palavras uns com os outros?
Não é que nunca seja certo dizer algo como “eu odiei esse copy”, mas é que isso não responde à pergunta:
Essas são as palavras certas, para as pessoas certas, na hora certa, e entregue em um tom de voz que é autêntica e reconhecível a nossa marca?
Em um mundo ideal, teríamos tempo de apresentar nosso conjunto de habilidades para a equipe, talvez até com uma série de workshops e palestras, mas, na realidade, a maioria de nós entra em um momento onde todos estão aprendendo o projeto, aprendendo as ferramentas. e aprendendo uns sobre os outros durante o projeto. Os escritores costumam surpreender a equipe com o que trazem para o processo existente (O que? Você pode escrever insights dos dados de entrevistas qualitativas? Graças a Deus!), mas ainda estamos frustrados com o que não sabem sobre o que fazemos, nossos processos e necessidades.
Especialmente sobre feedback, e é por isso que as pessoas acabam dependendo da opinião pessoal. E é exatamente assim que todos ficam cansados, onde quem faz mais barulho ganha e você não mais “discorda e se compromete”, você “concorda em silêncio e depois sente que quer se comprometer”.
E é assim que, mesmo com um escritor brilhante em sua equipe, você pode acabar com um copy que parece um camelo e faz com que todos se sintam um idiota.
A ferramenta: Microcopy Canvas
O Microcopy Canvas não é uma ferramenta para escrever todo o seu copy, embora você possa fazer assim se tiver tempo e disposição para adotar uma abordagem lenta e ponderada. Foi projetada para ser um artefato para comunicação: entre os escritores, entre escritores e não-escritores, e para equipes que não têm escritores mas ainda precisam escrever. Mesmo que você tenha clareza nas diretrizes de tom de voz — o que significa implementá-las, e onde, quando e por que você precisa dizer de uma forma em vez de outra?
Na verdade, eu não sou fã do termo “microcopy”, porque temo que ela se torne sinônimo de “UX Writing”, do mesmo modo que “wireframes” continuam a atormentar o UX design. Mas o microcopy é uma palavra que parece pequena, alcançável, gerenciável. Algo que você pode fazer enquanto toma café. Não é ameaçador como “Content Strategy” (algo que também fazemos).
Se você é escritor, pode experimentar essa ferramenta com sua equipe para mostrar como é o processo usado na criação do seu copy.
Porque sim, eu sei que ninguém leu seu guia de estilo (me dá um abraço) e mesmo que alguém tenha, as pessoas nem sempre sabem como escritores escrevem, e esperam que eles simplesmente sigam o guia (que, novamente, ninguém leu). É como esperar que cozinhem com a qualidade Michelin apenas porque temos a receita. As pessoas podem apreciar seu resultado quando ele funcionar, mas para elas darem um bom feedback, do tipo que ajuda a evoluir não apenas a sua escrita, mas todo o processo, é preciso que entendam como foi feito também.
Se você faz parte de um time de redatores, você provavelmente tem seu próprio processo, mas pode usar isso para tentar descobrir diferentes abordagens, gastando um pouco mais de tempo no problema antes de cair para uma solução. Testando a forma como você precisa dizer algo em uma modal VS em uma notificação VS em uma confirmação automática por e-mail. O que ajuda a não cair num estado emocional, mas sim refletir dados. Validando com stakeholders para que possam dar um feedback mais concreto e específico.
Se você não tem um escritor, pode usar o Canvas como uma maneira de começar a apreciar como e por que escrever de uma maneira que funcione para os usuários. E, ao fazer isso, você terá documentado algum tipo de lógica ou hipótese, pelo menos para algumas de suas escolhas. Então, quando você descobre da maneira mais difícil que seus usuários não querem que você os parabenize constantemente, ou que eles odeiam suas referências a Star Wars (sério… é só uma página de erro 404), ou que eles não perceberam que eles nunca poderão editar o nome de usuário — você poderá voltar e entender onde foi que errou. Foi uma escolha vaga de palavras, ou você entendeu mal as necessidades deles no momento? Os dados mostram que todos estão vendo isso em um celular, e você projetou para alguém em um computador?
O Microcopy Canvas pode ser uma ferramenta efêmera de discussão, ou você pode usá-lo como parte de sua documentação. E quando todos da equipe se sentem mais seguros para entender a relação entre o que é produzido e têm o framework para isso, eles estão em uma posição melhor para oferecer aos escritores o equilíbrio certo de apoio e autonomia para escreverem copys melhores, terem dias melhores , e terem menos colapsos emocionais (estamos juntos MESMO, escritor).
E é assim que você projeta um pônei.
Se você utilizar o Microcopy Canvas, por favor, compartilhe comigo! Esta é a versão 2.0 e estou ansioso para fazer uma nova versão com base nos feedbacks. Tweet para a Jane, ou você pode encontrá-la no LinkedIn.
Obrigado, Jamie Feola por deixar o Canvas tão lindo. Designers 💜
