Avaliao Heurstica segundo Jakob Nielsen

A avaliao heurstica um mtodo tradicional de avaliao de usabilidade. O mtodo foi utilizado pela primeira vez em uma interface Web em 1994, num estudo para o Web site da Sun Microsystems. Este mtodo foi desenvolvido por Nielsen e Molich e consiste da inspeo sistemtica da interface do usurio com relao sua usabilidade. Basicamente um avaliador interage com a interface e julga a sua adequao comparando-a com princpios de usabilidade reconhecidos, as heursticas. Como certamente um s avaliador no ir encontrar todos os problemas de uma interface, idealmente so utilizados vrios. Nielsen sugere que a melhor relao custo/benefcio alcanada quando se utilizam entre 3 e 5 avaliadores. Cada avaliador deve realizar a sua inspeo individualmente e somente depois de todas avaliaes terem sido concludas, os avaliadores podem se comunicar. Este cuidado importante para garantir avaliaes independentes e sem influncias. Os resultados tanto podem ser registrados por cada avaliador como por um observador presente durante as sesses, onde os avaliadores verbalizam seus comentrios. Ao final de todas as sesses o observador dever reunir todas as avaliaes feitas em um nico documento. Alm disto, o observador poder auxiliar o avaliador em caso de problemas com o prottipo, se este for o caso. Nielsen sugere um conjunto com apenas 10 regras heursticas para guiar a avaliao: 1. Dilogos Simples e Naturais: as interfaces de usurios devem ser o mais simples possvel. Interfaces devem combinar as tarefas do usurio de tal forma que o mapeamento entre os conceitos computacionais e os do usurio seja simples. Deve-se apresentar exatamente a informao que o usurio precisa nem mais nem menos - na hora e lugar exatos onde necessria. Informao que ser usada em conjunto deve ser exibida em conjunto, ao menos na mesma tela. Tanto os objetos de informao quanto s operaes devem ser acessados em uma seqncia que casa com o modo como os usurios iro realizar suas tarefas efetiva e produtivamente. Muitas vezes tais seqncias so foradas pela interface, mas normalmente melhor permitir que o usurio controle o dilogo o mximo possvel, de tal forma que a seqncia possa se ajustar s preferncias do usurio individual. 2. Falar a Linguagem do Usurio: a terminologia da interface deve ser baseada na linguagem do usurio, e no orientada ao sistema. Para tanto, deve-se verificar quais termos so utilizados com maior freqncia plos usurios. As informaes tambm devem ser organizadas conforme o modelo mental que o usurio possui do domnio. 3. Minimizar a Sobrecarga de Memria do Usurio: o software deve exibir elementos de dilogo para o usurio e permitir que o mesmo faa suas escolhas, sem a necessidade de lembrar deste ou daquele comando especfico. Para facilitar a utilizao da interface, deve ser apresentado ao usurio um pequeno nmero de regras que se aplicam por toda a interface. Se o nmero de regras grande o usurio ter de aprender/lembrar todas as regras, o que pode

no ser to simples. Por outro lado, se o software no tiver regra alguma, ento o usurio dever lembrar de cada elemento de dilogo. O uso de comandos genricos uma maneira de se ter um pequeno conjunto de regras. Comandos genricos fazem com que coisas similares ocorram em diferentes circunstncias, sendo suficiente ao usurio aprender poucos comandos para trabalhar com vrios tipos de dados. 4. Consistncia: consistncia um dos princpios bsicos de usabilidade. Se os usurios souberem que um mesmo comando ou uma mesma ao ter sempre o mesmo efeito, eles ficaro mais confiantes no uso do software/ e sero encorajados a fazerem novas descobertas. A mesma operao dever ser apresentada na mesma localizao em todas as telas e dever ser formatada da mesma maneira para facilitar o reconhecimento. 5. Feedback: O sistema dever informar continuamente ao usurio sobre o que ele est fazendo. O tempo de resposta influi no tipo de feedback que deve ser dado ao usurio. Um dcimo de segundo (0,1s) o limite para o usurio pensar que o sistema est reagindo instantaneamente, o que significa que nenhum feedback especial necessrio; um segundo (1.0s) o limite para que o fluxo de pensamento do usurio no seja interrompido, mesmo que o usurio perceba uma certa demora; e dez segundos (10s) o limite para manter a ateno do usurio focalizada no dilogo. s vezes feedbacks especiais so necessrios para contextualizar uma navegao mais demorada do usurio. 6. Sadas Claramente Marcadas: De modo a fazer com que o usurio sinta que pode controlar o software, dever ser fcil sair das situaes mais variadas possveis. Por exemplo, todas as caixas de dilogo devem possuir um boto de cancelar para trazer o usurio para a situao anterior. Muitas vezes, as sadas podem ser fornecidas por meio de uma facilidade de desfazer (undo) a ltima operao para retornar ao estado anterior. Os usurios rapidamente aprendem a confiar neste mecanismo, logo, deve estar disponvel como um comando genrico por todo o software. Neste caso, o usurio poder confiar no aprendizado por explorao, pois saber desfazer eventuais erros. 7. Atalhos: embora deva ser possvel operar a interface conhecendo-se apenas algumas regras gerais, deveria tambm ser possvel para o usurio experiente executar mais rapidamente operaes freqentemente utilizadas, atravs de atalhos. Aceleradores tpicos incluem abreviaes, teclas de funo, dique duplo do mouse, ou botes especiais para funes freqentes. Tambm podem ser apresentados atravs da exibio dos ltimos comandos executados, ou da funo de volta (backtrack) em sistemas de hipertexto. Atalhos so tambm necessrios quando por uma poltica de uma empresa ou organizao a informao que se encontra em uma maior profundidade da rvore navegacional tenha que ser recuperada diretamente pela interface principal 8. Boas mensagens de erro: as mensagens de erro devem seguir algumas regras: linguagem clara e sem cdigos. Devem ser precisas. Devem ajudar o usurio a resolver o problema. No devem intimidar ou culpar o usurio.

9. Prevenir Erros: melhor do que possuir boas mensagens evitar situaes de erro. Conhecendo-se as situaes que mais provocam erro, sempre possvel modificar a interface a tornar muito difcil que este erro ocorra. 10. Ajuda e Documentao: o melhor se ter um software que seja to fcil de usar que no necessite de ajuda ou documentao para complementar a interface do usurio. Alm disto, sabidamente usurios raramente lem a documentao.