Se você é daqueles gerentes de TI que pensam que documentação é uma questão de produzir os manuais de usuário em tempo para o release do seu software, pense de novo. Se você, na sua equipe, nunca ouviu falar da figura do redator técnico ou, se ouviu falar, acredita que essa figura seja totalmente dispensável, pense novamente. Se a sua equipe possui aquele programador que “sabe bem inglês” ou que “é bom no português” e que por isso fica responsável por revisar e escrever as mensagens de erro do seu sistema, pare nesse instante.
Muito provavelmente você encara um acréscimo constante de gastos com os diferentes níveis de suporte ao usuário. Seu cliente não entende o produto, e você não sabe mais o que fazer para melhorar a performance do seu sistema e ganhar aquele filão de mercado no qual seu concorrente avança a passos largos.
Se você se encaixa neste perfil, não desespere. Se você tem um bom software, com uma boa base de clientes, e enfrenta esses desafios, muito provavelmente você deveria rever seus conceitos. Seu problema não é performance ou falta de funcionalidades – seu problema é documentação.
E quando eu digo documentação, eu não estou falando do manual de usuário de 500 páginas que sua empresa gasta alguns milhares para produzir e atualizar todos os anos. Documentação de software envolve desde os nomes dos campos na tela, passando pelas mensagens de erro, hover texts, help grids, online helps, até os manuais.
Se os nomes dos campos na tela são ruins, ambíguos, cheios de abreviações ou siglas, seu usuário procurará imediatamente ajuda no “F1”, ele não vai abrir o manual. E então, se o help daquele campo de nome estranho (por exemplo, uma abreviação do tipo “Dt.”) diz apenas “Include the Dt.”, seu usuário ficará frustrado.
E então ele vai tentar entrar com algum dado no campo. Imaginando que “Dt.” seja a abreviação de “Date”, ele vai simplesmente digitar uma data qualquer. E seu sistema então lhe enviará graciosamente uma mensagem de erro que diz “Database error. Please try again.”.
Tudo bem, nesse instante, seu usuário vai recorrer ao Google, ele não vai encarar 500 páginas de manual de usuário para entender o que significa “Dt.” e que tipo de informação o campo espera que ele digite. Aliás, você e eu, como usuários, faríamos a mesma coisa.
Então, antes de cortar gastos com documentação, achando que assim você vai incrementar sua receita, faça o oposto – contrate um bom redator técnico. Alguém que entenda sobre como redesenhar e melhorar sua interface com o usuário. Melhore a diagramação da tela, os nomes dos campos, a clareza de divisão das tarefas dentro de menus e telas.
A partir daí, invista no help online. Coloque a informação certa nas mensagens de erro – não adianta dizer ao seu usuário que ocorreu um erro; isso ele já sabe. Ao invés disso, inclua informações sobre porque o erro ocorreu e como ele poderá solucioná-lo. Se a explicação for grande demais, providencie um link para os detalhes da informação na web, ou pelo menos o número do capítulo e página do manual onde ele encontrará o detalhamento.
Quanto mais amigável, clara e concisa for sua interface com o usuário, melhor e maior será a penetração do seu produto no mercado. E tem mais: o gasto extra com o suporte de um bom redator técnico será suplantado pela redução de custos com suporte ao usuário.
E lembre-se: não importa o quão incríveis sejam as funcionalidades do seu sistema; se o usuário não consegue utilizá-lo com certa facilidade, ele procurará algo no mercado que seja mais simples e mais amigável. Portanto, não menospreze a documentação do seu produto – ela é a “cara”, o cartão de visitas, do seu software.
Leave a Comment