Coloque o tech writer na sala e faça um produto melhor

Desde que eu e Juliana Meyer começamos a gravar episódios para o nosso podcast, The Manu<script>, já tivemos a chance de conversar com profissionais de conteúdo incríveis, como Tom Johnson, Mark Baker e Christopher Gales.

É claro que cada um deles tem pensamentos diferentes sobre muitos aspectos do trabalho de escrita técnica, mas uma reflexão em particular apareceu em cada uma dessas conversas (talvez, confesso, por conta do meu próprio interesse no tema). Ela pode ser resumida assim:

Considerar o desenvolvimento do produto por uma lente que coloca o conteúdo no início do processo não melhora apenas a documentação; melhora o próprio produto.

Então, vamos falar um pouco sobre isso. Pense em um time de produto reunido em uma sala para discutir as primeiras etapas de um projeto que acabarão por levar ao desenvolvimento de um novo produto ou feature. Quem são as pessoas dentro da sala? Você provavelmente vê um gerente de produto; talvez o CEO, se o produto é realmente importante ou a empresa é uma pequena startup; designers; desenvolvedores; um engenheiro de suporte? Talvez alguém do controle de qualidade? Se você tiver muita sorte, talvez até um ux writer.

Você sabe aonde estou indo com isso: a pessoa que você provavelmente não verá na sala é a technical writer. E isso não é porque ninguém gosta dela, mas porque a documentação geralmente não é vista como parte de um produto digital em si. Na maioria das vezes, ela é vista como um apêndice. E quando você desenha uma linha do tempo do projeto no quadro branco e pergunta às pessoas onde o apêndice entra, a resposta óbvia será “no final”, depois que tudo que for essencial e importante tiver sido descoberto, desenvolvido, melhorado e lançado.

E o curioso é que muitas vezes o que é realmente um apêndice acaba sendo incluído no início, simplesmente porque é fácil pensar sobre ele. O bicicletário antes do projeto da usina nuclear.

O que acontece quando o technical writer é finalmente chamado, talvez você já tenha vivido na pele: uma série de tropeços desnecessários. Afinal, o produto ou feature está supostamente pronto, então agora o time precisa decidir se:

• Ele será lançado sem documentação - “dá pra fazer depois”).
• Eles vão segurar o lançamento enquanto o tech writer se apressa para criar um arremedo de documentação (uma maneira ineficiente de trabalhar, que provavelmente levará a uma documentação superficial e que, a propósito, mostra pouco respeito pelo trabalho do redator).
• Simplesmente não haverá documentação - “problema do usuário”.

Para além disso, me diz o seguinte: se não estava trabalhando na documentação do produto, o que aquele tech writer preguiçoso estava fazendo enquanto a equipe do produto trabalhava duro para desenvolver a coisa toda? Bem, ele estava tentando cobrir as inconsistências nos produtos e features anteriores da empresa, que também foram desenvolvidos sem um trabalho síncrono de documentação. Porque - justamente por terem sido desenvolvidos assim - eles nasceram com uma série de defeitos.

Agora você pode estar pensando que garantir o bom uso é o trabalho dos designers - e eles estavam na sala durante a primeira reunião. Minha resposta é que você está subestimando o impacto do trabalho do technical writer no desenvolvimento do produto. Os designers são definitivamente essenciais, mas estão tão próximos do produto que dificilmente conseguem assumir a posição do usuário. Os engenheiros de controle de qualidade também são essenciais, mas eles estão lá para garantir que o resultado esperado aconteça. Eles também não deveriam assumir o lugar do usuário.

O technical writer, por outro lado, está em posição de assumir o lugar do usuário. De fato, o tech writer geralmente é o primeiro de todos os usuários. Ele tem o privilégio de olhar para o produto com a ignorância e a curiosidade que levam às perguntas necessárias para gerar conhecimento correspondente ao modelo mental do usuário. Porque ele não é o estrategista, nem o construtor, nem o testador. Ele é o aprendiz. Enquanto os desenvolvedores e designers criam, o tech writer usa, aprende, se frustra, pergunta, usa mais um pouco… Tudo isso para ser a pessoa que, de tanto pensar sobre o produto (novamente, do ponto de vista do usuário), torna-se capaz de virar o professor que passará esse conhecimento adquirido adiante.

“Technical writer” ou “documentarian” talvez sejam nomes enganosos quando se trata de avaliar o impacto real dessa posição, quando bem utilizada. Coloque o tech writer na sala e você terá um ótimo aliado para criar um produto que seus usuários de fato conseguirão usar.