Postagem em destaque

Procurando Profissional em Análise de Processos de Negócios, BPM, BPMS e Melhoria de Processos, para atuar na Região Metropolitana de Belo Horizonte?

Marco Gandra Brasileiro – Casado 41 anos - CNH B Nascido em Belo Horizonte e-mail gandraribeiro@gmail.com ...

Pesquisar neste blog

19 de dez de 2011

Não menospreze o usuário!

Por: Sarah Siqueira
Em: http://www.tiespecialistas.com.br/2011/12/nao-menospreze-o-usuario/

Não menospreze o usuário!

Se você respondeu sim a pelo menos duas das questões acima, está na hora de você conhecer oProgressive Disclosure (liberação progressiva, em tradução livre) aplicado à documentação de sistemas.
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?O seu projeto de documentação baseia-se em (a) descrever todos os bits and bytes numa tela; (b) fazer com que todas as telas apareçam no manual; (c) ter um bom manual que ensina tudo, até como digitar o nome de usuário e senha?

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 deprogressive 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.

Nenhum comentário:

Postar um comentário