Se você lida com projetos de documentação, com projetos em TI, ou mesmo com projetos no geral, não importa – com certeza você já se deparou com aquele que cria problemas, e não soluções. Aquele que faz questão de, quando confrontado com qualquer tipo de pergunta, por mais simples que seja, te manda avaliar, investigar e aprender em um monte de links e/ou documentos onde, invariavelmente, você demorará uma semana para encontrar uma resposta, se encontrar.

O sistema de gerenciamento eletrônico de conteúdo presta-se, também e principalmente, a este papel – facilitar o acesso democrático às informações. Se você conseguir criar em sua empresa o comportamento necessário com relação ao sistema de ECM (electronic content management), com certeza você verá diminuído o número de obstáculos em suas operações.

E qual é este comportamento?

Incuta na cabeça de seus funcionários, from day one, que eles nem sempre estarão ali, disponíveis. Doenças existem, pessoas tiram férias, bebês nascem, etc. E o que acontece com aquele pedacinho de informação armazenada na máquina da Maria quando os gêmeos nascerem? Bom, das duas uma – ou você liga para ela na maternidade, ou você contrata alguém para quebrar a senha dela. Este tipo de obstáculo é desnecessário e tacanho, eu diria. Principalmente numa empresa que diz trabalhar com tecnologia.

Então, mantenha na mente dos seus funcionários que tudo aquilo que eles criam, toda a informação que eles coletam, deve ser armazenada num local único e que, pelo menos, duas pessoas terão acesso a quaisquer de seus documentos – o próprio autor e o administrador da ferramenta. Com isso, dezenas, centenas de obstáculos à livre circulação de informação dentro de sua empresa serão, com certeza, eliminados.

Junte a isso o incentivo à contribuição: dissemine a cultura de que informação é valor e valor deve ser compartilhado. Quantas vezes um programador fica horas tentando resolver um pequeno bug no sistema quando tudo que ele precisaria seria averiguar, dentro do repositório da empresa, se alguém documentou fato semelhante àquele que ele agora enfrenta? Sim, porque soluções externas podem ser encontradas mas nem sempre servem bem à sua empresa ou tem permissão para serem utilizadas por terceiros.

E, por fim, incentive a comunicação real entre os membros de sua equipe. Se alguém sai, vai para outra área, outro projeto, exija o correto alinhamento da informação, das apresentações e, digamos, do “aclimatamento” daquele que deverá assumir o posto deixado para trás. De nada adianta um maravilhoso sistema de gerenciamento de informações, cheio de fluxos e capacidade de armazenamento, se as pessoas no seu time se vêem como concorrentes ou agem sob a égide do “não-tenho-mais-nada-a-ver-com-isso.”

Quantas empresas compram sistemas de CRM (customer relationship management) porque “querem conhecer melhor seu cliente” e se esquecem que, se não criarem uma cultura de relacionamento com o cliente em seus funcionários, elas não chegarão a lugar algum. Muito pelo contrário – terão gasto alguns milhares de dólares num software que não fará muita diferença, e talvez até crie problemas, para seus negócios. Então vamos manter em mente que qualquer sistema instalado será, em qualquer instância, gerenciado, manuseado e mantido por pessoas.

Vamos então construir pontes, minha gente, pontes… e não obstáculos.

Muitas empresas acreditam que é suficiente gravar tais arquivos num servidor e só. Nesses casos, quase não há controle sobre quem, quando, onde ou o que atuou sobre estes dados. Eu já presenciei casos de grande seriedade, dados perdidos, semanas de trabalho tendo que ser refeitas. Tudo porque o repositório central é um servidor acessado à revelia.

Se você é dono de empresa, stakeholder, gerente, executivo, não importa, compreenda uma coisa: não há real gerenciamento de informação se você não utilizar um sistema ECM (Electronic Content Management).

Conforme uma empresa cresce, o volume de informação produzido também aumenta enormemente. Além disso, seus usuários precisarão de mais e mais informações para atingir seus objetivos e endereçar suas necessidades comerciais. Se a informação não tornar-se um patrimônio bem gerenciado dentro de sua empresa, ela pode tornar-se um estorvo ao invés de ser uma aliada na solução de problemas e no cumprimento de suas metas.

Para isso, a segurança torna-se a chave mestra do gerenciamento de informações. Um ambiente tecnológico inseguro eventualmente causará a perda da informação ou a quebra de seu sigilo. A sua ferramenta de gerenciamento eletrônico de documentação deve então ser confiável, fornecer bons mecanismos de busca e recuperação das informações, bem como uma capacidade de armazenamento compatível com o volume de dados produzido.

Se seus funcionários acham difícil localizar um documento, levando de meia hora há dias para fazê-lo; se seu “repositório” de informações normalmente depende de pessoas e não de uma ferramenta segura e bem gerenciada; se seus funcionários enfrentam situações de stress for terem seus arquivos perdidos ou apagados por acidentes, prejudicando projetos e suas datas de entrega; ou se seus funcionários já perderam tempo e esforço atualizando cópias de documentos que na verdade não eram as mais autais ou que por ventura foram atualizadas por duas ou três pessoas ao mesmo tempo; acredite, você precisa urgentemente de uma ferramenta ECM.

Um sistema ECM, ou sistema de gerenciamento eletrônico de conteúdo, é uma ferramenta que gerencia todo o conteúdo ou informação não estruturado de sua empresa. Este conteúdo pode existir em muitos formatos digitais, tais como arquivos de texto, arquivos de áudio e vídeo, gráficos, desenhos, arquivos XML, etc. A ferramenta ECM gerencia este conteúdo criando esquemas de categorização, metadata, e tags que fazem da busca e recuperação destas informações algo rápido, eficiente e seguro.

O mercado considera que um bom sistema ECM seja um conjunto de aplicações distintas, mas relacionadas entre si, tais como: o enterprise document management (EDM), para o gerenciamento de arquivos texto; o web content management (WCM); o enterprise records management (ERM), que gerencia registros e formulários em forma de banco; o business process management (BPM), que gerencia seus processos de negócio; e muitos outros.

A solução FileNet da IBM possui tudo isso e muito mais. Mas você não precisa dispor de todos eles para efetivamente gerenciar seu conteúdo não estruturado. Boas ferramentas ECM podem inclusive ser softwares livres, como o ECM Suite da Alfresco. No entanto, uma coisa é certa: gerenciar é preciso.

No próximo post, mais sobre gerenciamento de conteúdo. Até lá!

Nesse sentido, tento sempre não documentar o óbvio, fugir do “romanceamento” e ir direto ao ponto, onde a ferida dói. É muito mais difícil documentar os processos complexos, e é justamente por isso que a maioria dos manuais se mantém no “arroz com feijão”.

Ao invés disso, faz-se do manual técnico uma seqüência de informações óbvias, sem objetivo de negócios e extremamente cansativas de se ler. Literalmente chamam o usuário de imbecil e, na hora que ele mais precisa, o deixam na mão. Quantas vezes você precisou saber algo numa ferramenta, entrou no help, fez sua busca, mas só achou aquilo que você já sabia, que estava “na cara”?

Pessoas lindas do meu Brasil varonil, aprendam: não documentem o óbvio! Não digam ao usuário aquilo que ele já está vendo na interface gráfica do seu produto. A célebre frase “Clique no botão X. A janela XYZ abre.” é a coisa mais esdrúxula possível e, no entanto, 9 em cada 10 manuais seguem este padrão.

Lembrem-se que, geralmente, seu usuário consulta o manual ou o help quando ele está usando a ferramenta. Então, quando ele clicar no botão X, a janela estará lá! Ou seja, são 4, 5 ou 10 palavras a mais que você poderia ter poupado seu usuário de ler. E mais – se você implementar e traduzir para 10 línguas, serão 40, 50 ou 100 palavras a menos no seu custo de produção. E se você multiplicar isso por todas as vezes que essa frase foi incluída na sua documentação… bom, vocês entenderam onde tudo isso vai dar.

Então a dica aqui é: parem de documentar o óbvio! Antes disso, analisem o conteúdo daquilo que será aresentado ao usuário. As célebres perguntinhas “who – what – when – how – why?” devem estar presentes no seu planejamento de documentação:

Quem é o seu usuário? É o programador, o administrador de banco de dados, o digitador? Qual o nível de experiência e de intimidade desse usuário com o mundo tecnológico?

Do que ele precisa? Ele precisa que você o ensine como ligar o computador? Precisa que você o diga como e onde entrar com usuário e senha no sistema? Ou precisa que você lhe dê opções de parâmetros que o ajudem a melhorar seu trabalho e performance?

Quando e como ele precisa dessa informação? Ele fica online e poderá buscá-la na internet? Você deverá fornecê-la em arquivo para que ele possa acessá-la offline? Ele vai precisar dela antes da instalação ou mesmo durante o processo, quando não poderá acessá-la na tela, e portanto deverá fornecê-la em PDF?

Porque ele precisa dessa informação? É uma questão de negócios? É puramente técnico, para melhoria de performance ou debugging? Ele precisa resolver um erro que já aconteceu? Ou ele está tentando prevenir uma situação antes que ela ocorra?

Se o seu time de documentação mantiver essas questões em mente, tenha certeza, seu usuário vai continuar não lendo seus manuais. Mas, quando ele precisar deles, terá uma grata surpresa!

Confuso? Então vamos simplificar.

O processo de documentação em DITA é aquele em que a informação é dividida em pequenos tópicos que, por si mesmos, podem ser compreendidos. Cada um deles explica uma tarefa, um conceito ou uma referência em particular, e tem começo, meio e fim. É o que chamamos de redação baseada em tópicos, ou topic-based authoring.
A partir destes pequenos tópicos, são criados mapas que, basicamente, contém a sequência na qual eles serão exibidos ao usuário. Os formatos de exibição incluem o formato web (xhtml, html), documentos (.pdf, .rtf) e arquivos de help (Eclipse, JavaHelp, Oracle). Esses mapas incluem também tabelas de relacionamento que fazem com que cada um dos tópicos possa interligar-se a outros, formando referências entrecruzadas que melhoram, e muito, a navegabilidade do usuário online.

O padrão DITA é um padrão aberto, criado inicialmente pela IBM (2001) e aprovado como padrão OASIS em Junho de 2005. O padrão DITA é, em muitos aspectos, similar ao processo de adapatação evolucionária descrita pelo naturalista Charles Darwin, por permitir a adição de novos tópicos a cada nova versão de informação lançada, melhorando-a.

A melhoria contínua do conteúdo, a facilidade na geração de outputs diversos, e a forma extremamente estruturada de desenvolvimento da informação, fazem do padrão DITA (na minha humilde opinião) a fórmula perfeita para a geração de conteúdo técnico.

Se você gostou de tudo que leu até aqui e pensa em adotar o padrão DITA na sua empresa, é importante que você observe alguns pontos.

Tempo de adaptação
Escrever em DITA é algo que exige aprendizado e, sobretudo, adaptação. Existem vários editores de texto no mercado que permitem a produção de conteúdo em DITA, e basicamente escreve-se o texto aplicando-se tags que formatam o conteúdo a ser exibido. No entanto, o redator deve ser capaz de separar a informação em tópicos curtos, auto-suficientes. As frases devem ater-se ao que importa, evitando-se o uso de advérbios, adjetivos e adjuntos desnecessários. O autor deve deixar o “romance” de lado, indo direto ao ponto, sem rodeios. Um exemplo? Se seu redator costuma escrever “Hoje está um lindo dia de sol.”, ele terá que treinar o cérebro para dizer apenas “Faz sol.”, e isso leva tempo e treino… muito treino.

Adaptabilidade do conteúdo
O seu conteúdo deve ser passível de transformar-se em tópicos DITA. O primeiro processo então deve ser a avaliação de seus manuais, verificando se é possível manter sua coesão após a conversão. Cada tópico deve conter uma parte mínima do todo, como se fossem células formando em organismo maior. Eles devem fazer sentido tanto isolados quanto em grupo, e portanto seu time deve ser capaz de montar mapas que apresentem a informação de maneira que ela possa ser lida e compreendida. O reuso também é importante – identificar quais partes da informação podem ser generalizadas e então reutilizadas em diferentes níveis torna-se inevitável em DITA, pois uma de suas melhores características é o reuso da informação.

Armazenamento e padronização
Invista no armazenamento de sua informação. De nada adianta todo esse esforço se sua empresa não for capaz de rastrear e manter esses tópicos de maneira adequada. Ferramentas de gerenciamento eletrônico de conteúdo, como o FileNet, são um bom exemplo. Através deles você será capaz de armazenar seus arquivos, gerenciar versões, e até interagir de maneira a criar pacotes que possam ser publicados através de scripts padronizados, ou enviados para teste e/ou tradução automaticamente.
Ainda nessa linha de pensamento, a padronização da linguagem utilizada por seus redatores, a maneira como certos tipos de informação serão apresentadas, quais tags serão utlizadas em quais situações, e até mesmo a nomenclatura dos seus arquivos DITA, devem ser padronizados e conhecidos por todos. Então invista na definição de padrões e sua conseqüente disseminação dentro do time.

Com tudo isso, você pode pensar – ah, muito trabalho! Sim, você tem toda razão. Mas, acredite que o retorno em termos de facilidade de alteração de conteúdo, variedade de formatos e publicações, melhoria de interação com clientes e usuários, rapidez no time-to-market, entre outros itens, valem cada centavo e minuto gastos.
Nada se compara a trocar o nome do produto num arquivo conref (content reference) e vê-lo automaticamente mudar em todos os seus tópicos ao mesmo tempo. Ou pedir ao seu redator que monte um PDF somente com informações de troubleshooting e receber o livro pronto no mesmo dia. Ou poder determinar, no momento em que o tópico é escrito, que partes da informação não devem ser traduzidas.
As possibilidades são infinitas e ficam melhores e mais confortáveis conforme sua equipe torna-se mais especializada no assunto. Então, porque não tentar à maneira de Darwin?

Agora, imaginem a quantidade de mal-entendidos que se pode gerar a partir de reuniões como estas? Pois é, por conta disto, a redatora técnica era convocada, e eu passava horas tomando nota, resumindo, construindo infográficos, tabelas, fluxos, ilustrações, enfim, tudo que pudesse auxiliar aquelas 50-60 pessoas a chegarem num consenso.

Naquelas circunstâncias, produzir uma ilustração, um gráfico que ilustrasse o processo de negócio do cliente, era praticamente obrigatório. Mesmo porque, impossível explicar todos os detalhes do business simplesmente com palavras.

Meus gráficos e ilustrações faziam muito sucesso, uma vez que meu background como desenhista facilitava o processo de captação das informações e conseqüente transformação delas em tabelas, desenhos e fluxos. Por conta delas fui chamada especificamente para cobrir reuniões de definição de escopo de projetos de tecnologia de ponta, como foi a implantação da portabilidade numérica em operadoras celulares norte-americanas.

Mas esse post não se presta a falar dos meus dotes como ilustradora. Ele pretende discutir até que ponto uma ilustração faz sentido em documentação. Tem gente que acredita que um bom manual precisa incluir cada uma das telas do software, ilustrar todos os ícones e botões, exibir todas as mensagens de erro em suas respectivas telinhas. Outros defendem que o usuário não precisa de nada disso e que devemos erradicar todo e qualquer tipo de ilustração num manual técnico.

Eu digo – sigamos o caminho do meio. Como em tudo na vida, o equilíbrio e o bom senso devem prevalecer. Eu já revisei documentos que continham, por exemplo, um screenshot da tela de login do software, mostrando que onde estava escrito “Nome”, o usuário deveria digitar seu username; e onde estava escrito “Senha”, o usuário deveria digitar sua password. Desnecessário dizer que eu marquei o texto todo, e a figura, para ser removido, certo? Qualquer usuário de internet que tenha uma conta de email sabe para que servem aqueles dois campos na tela de login.

É importante avaliar que um screenshot é um objeto estático na documentação. Todas as vezes que um campo mudar de nome, ou de posição, ou se cores forem alteradas, ou o tipo de letra, você deverá investir para que aquela ilustrção seja trocada. Sem falar nos processos de globalização, que exigirão de cada um dos tradutores que eles naveguem pelo sistema em sua língua natal e capturem os mesmos objetos do original – ou seja, a mudança de uma única tela pode significar muito, mas muito tempo e dinheiro gasto.

A mesma coisa vale para seus ícones preferidos. Aquelas pequenas ilustrações de lupas, binóculos, folhinhas de calendário, etc., definitivamente não precisam fazer parte do seu documento. Eles são ícones já aceitos pelo mercado, são ícones padrão – todo mundo sabe que a lupa é um ícone de busca, que o binóculo significa filtro e que a folhinha com números é um calendário.

Então, o que ilustrar? Em documentação técnica, menos é mais, sempre. Sua equipe de documentação deve ser orientada a ater-se àquilo que não é padrão de mercado; que façam fluxos dos procedimentos complexos e pouco usuais; ilustrem ícones diferentes e específicos do seu produto; ao invés de ilustrarem uma tela inteira para mostrar um pequeno campo, que façam “cortes” da tela e exibam com orgulho aquilo que somente seu software tem ou faz.

Não caia na armadilha do “uma imagem vale mais que mil palavras”. Elas podem falar mais do que deveriam…

Você gasta demais com revisão do material e tradução a cada nova versão lançada e, ainda assim, seus manuais nunca estão realmente atualizados?

Se você respondeu sim a pelo menos duas das questões acima, está na hora de você conhecer o Progressive Disclosure (liberação progressiva, em tradução livre) aplicado à documentação de sistemas.

Primeiro lembre-se que documentar um software não se trata somente de escrever manuais – documentação engloba nomes de campos, abas, telas, mensagens de erro, helps online, enfim, tudo aquilo que seja tecnicamente escrito para o seu usuário final.

Segundo lembre-se que um bom redator técnico é meio caminho andado para ter êxito na documentação do seu sistema.

Tendo tudo isso em mente, determine as “camadas” de informação que você providenciará ao seu usuário. Por exemplo, na primeira camada, teremos os nomes dos campos e de todos os outros elementos na tela, incluindo algumas frases que possam resumir o propósito de uma certa janela ou aba (chamados help grids). Esta primeira camada deve ser simples, bem estruturada e clara, o que significa que você deve fugir das abreviações e das siglas o máximo possível.

Na segunda camada teremos o hover text e o field help. Lembrando que estes também devem manter clareza e dar ao usuário uma visão do que se trata o campo, que tipo de informação ele espera e qual o resultado de escolher-se este ou aquele tipo de input. Aqui também poderíamos incluir as mensagens de erro, que sempre devem fornecer ao usuário qual a solução do problema, ou pelo menos definir exatamente onde ele pode encontrá-la.

Na terceira camada poderemos colocar o help online e os manuais que devem então ter seu foco alterado – não mais descreverão campos, telas e procedimentos indiscriminadamente, mas sim as tarefas que o usuário deseja efetuar (user goals). Neste momento pare e pense “onde o usuário quer chegar?” e esqueça-se do seu software. Não se permita cair na armadilha de descrever aquilo que o usuário vê na tela, mas sim procedimentos, referências e conceitos que o auxiliem a atingir um objetivo de negócio.

Neste contexto, qualquer mudança feita nos labels da interface (quase) não afetará sua documentação. As partes relativas a campos e outras entidades do tipo estarão bem na frente do cliente, ele não precisará correr atrás de explicações num manual. Com a correta aplicação do progressive disclosure, o usuário ganha rapidez, não perde o foco, e você e sua empresa ganham mercado e rentabilidade.

E você agora deve estar pensando: “mas isso é o paraíso!” Bom, nem tanto. Aplicar um processo de progressive disclosure bem estruturado depende de tempo, maturidade tanto do produto quanto de seus profissionais e processos de desenvolvimento, uma equipe engajada, e do buy-in da alta gerência. Engloba principalmente a alteração da maneira de pensar de sua equipe de documentação, testes e desenvolvimento. Enfatiza falhas nos processos do sistema, uma vez que cada um de seus profssionais passa a atuar com foco na maneira como o cliente vê o produto, e não mais com os olhos técnicos de quem simplesmente o desenvolve.

Com certeza é uma grande mudança… para melhor.

No fim das contas, aplicar, desenvolver e manter um processo desses prova que sua empresa não menospreza seu usuário final – faz dele o foco principal de seu produto.

Então eu quero hoje conversar sobre a responsabilidade do seu time no que concerne a documentação. Imagine que seu produto chega às prateleiras e é vendido ao Zé da Silva. O Zé chega na casa dele, abre o pacote, prepara-se para a instalação do produto.

Logo de cara, o processo abre um wizard de instalação, uma tela bonita, bem desenhada. Como o seu produto é vendido também para outros 10 ou 12 países, todo o original é produzido em inglês e depois você terceiriza o processo de tradução. O Zé, que fala português muito bem, pois é professor universitário e tem uma taxa de leitura acima da média, logo percebe a quantidade de erros crassos, bem ali, na primeira tela do seu lindo wizard.

E os erros se repetem, embora não impeçam o Zé de continuar o processo de instalação e utilização do software. Mas o Zé fica incomodado – para ele, aquela falta de cuidado com a Língua Portuguesa é algo imperdoável, provocativo demais. Em alguns momentos, os erros chegam a atrapalhar sua concentração na tarefa que executa. Ele se frustra, se indigna, e acaba por fazer uma busca por outros produtos que possam lhe dar as mesmas funcionalidades, mas que demonstrem um pouco mais de respeito por seu idioma. Ele também faz uma propaganda negativa entre seus colegas de universidade, e deixa de indicar o produto como uma boa opção aos alunos.

Entenderam o cenário? Perceberam que, aquilo que para uns foi um simples errinho, algo na tela que não diminui em nada a capacidade do software de produzir bons resultados, para outros se torna uma afronta pessoal?

O processo de tradução de um software faz parte do ciclo de vida da sua documentação. O cuidado ao escolher seus fornecedores, medindo seu nível de qualidade e comprometimento com o resultado, é algo imprescindível se você quiser ter um bom produto final em outros idiomas. Mais uma vez, não importa o quão maravilhoso é o produto, tudo que o usuário vê é aquilo que está na tela. Um bom conteúdo embalado em papel de pão amassado não causará o impacto de mercado necessário a uma boa penetração.

Portanto, responsabilize-se – meça periodicamente a qualidade da tradução do seu produto. Se sua empresa não tem tamanho e condições de manter uma equipe in-house que garanta esta qualidade, procure por serviços terceirizados de empresas com background garantido e validado pelo mercado.

Sua equipe de redação técnica também pode auxiliá-lo no trabalho. Em muitos casos, esses profissionais são proficientes em mais de um idioma e podem fazer validações sobre samples do produto final da tradução. Entenda que o redator técnico não é um tradutor e não deveria, no geral, fazer trabalhos de tradução end-to-end. No entanto, a verificação dos resultados pode, e deve, fazer parte de suas atribuições, uma vez que é ele o responsável pelos originais da documentação.

Se sua equipe de testes recebe o software traduzido para verificação geral da funcionalidade, peça que um ou dois no time atenham-se a verificação do produto traduzido, dentro de seus conhecimentos do idioma. Também é comum, em times de TI globalizado, que muitos sejam descendentes de italianos, espanhóis, japoneses, alemães. Se você for um gestor que conhece bem seu time, será razoavelmente simples para você atribuir a tais pessoas algumas horas de verificação do produto final traduzido.

Esse procedimento dará ao time como um todo o senso de responsabilidade pelo produto final apresentado ao cliente. Explicar e evidenciar ao seu time que aquilo que vocês vendem não é código, ou testes, ou manuais, mas sim um pacote completo, lhes dará um senso de comprometimento que, além de ser benéfico para a empresa, será importante para a elevação do moral e da integração de todos.

Não permita que cada um viva apenas “no seu mundinho”. Responsabilidade é o nome do jogo, e ela deve começar por você.

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.