Desde que me tornei technical writer, ou redatora técnica, tenho tido a oportunidade de desbravar um mundo completamente fora da minha realidade como jornalista: o da tecnologia.
E aqui, quando me refiro à tecnologia, quero dizer todo o ecossistema envolvido nela, desde o ciclo de vida de um software, os bastidores do desenvolvimento de uma solução e, principalmente, o desafio de criar uma documentação intuitiva, que oriente futuros usuários a utilizar aquele produto e entender seus atributos e features técnicos.
Por isso, decidi compartilhar um pouco a minha trajetória até aqui como forma de, quem sabe, incentivar potenciais comunicadores a se desbravarem nesse mundo, além, é claro, de fortalecer essa comunidade ainda em crescimento no Brasil.
Antes de tudo, quero deixar claro que a redação técnica não se restringe à área da tecnologia. Isso significa que existem technical writers, por exemplo, na Medicina e em áreas que exijam conteúdos com estilo técnico mais aprofundado. Mas, para este artigo, vou focar todos os meus exemplos na área tech por ser nela que atuo.
Mas afinal, o que é technical writing?
De acordo com a Society for Technical Communication, o Technical Writing é um campo, dentro da comunicação técnica, que possui, pelo menos, uma das seguintes características:
- Comunicar sobre assunto técnicos e especializados, como por exemplo aplicações (ou apps), softwares, entre outras ferramentas que possam ser instaladas, adicionadas ou configuradas.
- Utilizar de meios tecnológicos, como sites, arquivos ou redes sociais para comunicar sobre o produto;
- Prover instruções sobre como realizar algo, independente de quão técnica seja a ação ou de qual tecnologia seja necessária para realizar a tarefa.
Em outras palavras, a redação técnica é quando escrevemos, de forma clara e intuitiva, sobre instruções ou orientações para que, quem esteja lendo, possa entender mais facilmente sobre como usar uma solução/software/produto.
As entregáveis do technical writer
Considerando que nosso principal objetivo é tornar mais fácil o uso de alguma solução e/ou produto, os principais materiais que um redator técnico produz são:
- Documentações técnicas de softwares e/ou soluções
- Manuais de instrução
- Guias de uso
Arrisco dizer que a principal delas é a documentação.
No universo de technical writing, ela é o elo entre quem usa e quem produz um software ou sistema. A “interface” que pode potencializar a experiência em usar aquela solução.
E, por isso, é fundamental que a documentação (ou doc, como costumamos chamar) seja bem escrita, com exemplos de uso e explicações conceituais e técnicas para facilitar o entendimento de como usar o produto.
Como me tornei redatora técnica?
Assim como boa parte dos redatores técnicos que conheço, eu entrei na área por acaso.
No início deste ano, quando a pandemia nem sonhava em ser realidade, eu recebi uma proposta da Zup Innovation. Na época, tudo indicava que eu teria uma atuação bem parecida com a vinha fazendo, no caso, a de UX Writer ou Redatora UX.
O que sabia, até então, é que eu precisaria ser bastante organizada e ter experiência prévia em documentar processos e produtos.
Porém, quando eu comecei a trabalhar, já nos primeiros dias entendi que estava lidando com algo totalmente novo. O desafio era – e continua sendo – escrever as documentações das soluções open source que a Zup vem lançando na comunidade de desenvolvedores.
Isso significa que eu precisei entender a fundo sobre termos e expressões de programação, além de conhecer, tecnicamente, como o produto funcionava para que eu pudesse explicá-lo na documentação. Aliás, tive que entender sobre três produtos que envolvem três áreas distintas – ainda que correlatas – dentro de tecnologia.
Para completar, as equipes dos produtos para os quais precisava escrever ficavam em Uberlândia (MG), enquanto eu moro em São Paulo (SP). E aí vocês devem imaginar como o desafio aumentou, certo?
Inclusive, se vocês quiserem, eu faço outro artigo só contando estes bastidores. Mas, o que posso adiantar aqui, é que foram meses de bastante aprendizado enquanto, literalmente, ia escrevendo cada linha dessas documentações
Alguns dos aprendizados que tive (até agora)
Como disse, essa trajetória tem me feito colher muitos frutos e aprender sobre processos de trabalho e assuntos da área de tecnologia que nem sonhava em me envolver.
Abaixo, listo o que já aprendi e que se você, um dia, quiser trabalhar com redação técnica, é importante ter em mente:
1. Pense como um desenvolvedor
Se você, como eu, estiver trabalhando em uma empresa de tecnologia, é bem provável que seu público-alvo seja formado por desenvolvedores, arquitetos ou engenheiros de software.
Logo, é interessante que você mergulhe no universo desses profissionais para entender como eles consomem informações técnicas e quais seus formatos favoritos de conteúdo.
Isso significa pesquisar e aprender sobre temas comuns à área, como APIs, Git, Github, infraestrutura, ambientes, linguagens de programação, linhas de comando, entre outros.
Existem vários cursos online da Udemy que tratam desses temas. Eu, por exemplo, comecei a fazer recentemente um chamado “Git and Github for Writers”. Mas você pode encontrar outros que te interessem e façam mais sentido para seu atual momento 🙂
2. Escreva perto de quem desenvolve o produto
Não existe uma boa documentação, seja ela escrita ou codificada, sem um trabalho multidisciplinar.
Por mais que você, enquanto redator técnico, compreenda o universo do produto, faz toda diferença quando você traz desenvolvedores, analistas de QA e demais envolvidos no desenvolvimento do software/solução para contribuir.
Dessa forma, a documentação se enriquece com estudos de caso, exemplos de códigos e demais informações técnicas que irão agregar na experiência de leitura do arquivo.
No começo, ainda mais se a empresa não tiver tech writers, é normal que os times de produto tenham resistência. Mas use de suas skills de comunicação a seu favor, garanto que o resultado será ainda melhor 😉
3. English first
Talvez esse seja meio óbvio, mas não custa reforçar: todo o universo de tecnologia, inclusive de softwares e soluções, são criados dando preferência ao inglês.
Caso você trabalhe, ou for trabalhar, em uma empresa que pretende ampliar o alcance de seu produto, então minha recomendação é que você invista no inglês para ganhar segurança em tradução e escrita da documentação, principalmente.
4. Concilie usabilidade e conhecimento técnico
Para mim, esse é o aprendizado mais desafiador. Como não sou desenvolvedora, minha vivência sempre me coloca em uma posição de questionar o quão intuitivo e claro está o conteúdo. Ao mesmo tempo, não posso deixar de tratar tecnicamente do assunto.
No dia a dia, é como uma balança em que precisamos, o tempo todo, avaliar como está esse equilíbrio. Por um lado, não podemos ser didáticos demais a ponto de esquecer do técnico, tampouco ser técnico demais de modo que não fique claro sobre o que estamos dizendo.
Aqui, nesse caso, não existe fórmula: é necessário sempre validar a documentação, revisando e testando com sua audiência.
5. A doc é um documento vivo
Mesmo que você finalize o processo de documentação, ele nunca irá acabar. Isso porque, vira e mexe, vai ter uma atualização no software e você precisa divulgá-la (que são o que chamamos de release notes).
No caso de soluções open source, então, é sempre importante que o redator técnico acompanhe as contribuições que a solução vai receber via repositório, além de necessárias revisões ou inclusões de features à medida que o produto estiver evoluindo.
Onde encontro mais informações?
A área de technical writing no Brasil, como falei no começo do artigo, ainda está crescendo e existem muitas oportunidades para profissionais que se interessem pela área.
Se quiserem saber mais, vou deixar abaixo recomendações de livros e também link para dois grupos (um brasileiro e outro estrangeiro) para vocês se conectarem com outros profissionais.
Livros
- The Product is Docs
- Docs Like Code
- Every page is page One
- Developing Quality Technical Information
- Design for How People Learn
Grupos
- Technical Writing Brasil, aqui no Linkedin.
- Write the Docs, no Slack.
EXTRA ⚠: PODCAST
Eu não podia deixar de divulgar o The Manu<script>, podcast criado pelos technical writers Breno Barreto e Juliana Meyer, ambos da VTEX.
Ele está disponível nos principais tocadores e cada episódio é uma verdadeira aula sobre os desafios da área e percepções do mercado – inclusive, com a participação especial de alguns dos autores dos livros que listei acima.
Espero que vocês tenham entendido um pouco desse universo complexo e apaixonante do Technical Writing. Pretendo escrever mais artigos em breve, então, se quiserem, podem ficar à vontade para enviar sugestões de temas relacionados aqui nos comentários. Será um prazer falar sobre eles.
