Heurísticas de Nielsen: Avalição heurística

Nielsen (1994) descreve que avaliações heurísticas é um método para encontrar problemas de usabilidade na interface através de um pequeno processo de iteração durante o desenvolvimento. Elas podem tanto orientar a concepção quanto a avaliação da maioria dos sistemas interativos. A avaliação envolve um pequeno número de avaliadores que examinam a interface e julgam o que está de acordo com as os princípios de usabilidade, as heurísticas. A avaliação se destaca pelo baixo custo e agilidade. Nielsen (1994) propõe 10 heurísticas de usabilidade, em tradução livre:

1. Visibilidade de status do sistema: O sistema sempre deve informar ao usuário

sobre o que está acontecendo, com feedback apropriado e em um tempo razoável;

2. Relacionamento entre a interface e o mundo real: o sistema deve falar a

linguagem do usuário, com frases, palavras e conceitos familiares ao usuário, em termos orientados ao sistema;

3. Liberdade e controle do usuário: usuários podem escolher opç es erradas por

engano e precisão de funções de “saída de emergência” de maneira clara, por exemplo, suporte a desfazer e refazer;

4. Consistência e padrões: usuários não devem ter que se questionar se as

mesmas palavras, situações e funções representam a mesma coisa, deve existir uma convenção para o sistema;

5. Prevenção de erros: Um projeto cuidadoso que impede que um problema

ocorra, eliminando condições passíveis de erros, apresentar opção de confirmação antes da execução da ação;

6. Reconhecimento ao invés de memória: Minimizar a carga de memória do

usuário, através de objetos, ações e opções visíveis. O usuário não deve ter que se lembrar de informações a partir de um diálogo para outro. As informações devem estar visíveis o tempo todo ou serem de fácil recuperação;

7. Flexibilidade e eficiência no uso: O sistema deve ser fácil de utilizar por

usuários iniciantes, mas prover atalhos e ser flexível para usuários avançados;

8. Design minimalista: Os diálogos não devem ter informações irrelevantes ou

raramente necessárias. Cada unidade de informação indesejada compete com os relevantes, o que atrapalha o entendimento e diminui a visibilidade;

9. Ajudar os usuários a reconhecer, diagnosticar e reparar erros: As mensagens

de erro do sistema devem ser simples, informar precisamente o problema e sugerir uma solução;

10. Ajuda e documentação: Mesmo que seja melhor utilizar o sistema sem a

necessidade de documentação, o acesso a ajuda de documentação pode ser valioso. Qualquer informação deve ser fácil de pesquisar, focada em tarefas do usuário, através de listas concretas e não extensas.

A Avaliação heurística ajuda a encontrar problemas de usabilidade mais cedo, e mesmo que não sejam encontrados nessa fase, podem ser descobertos em uma avaliação formativa, com usuários, por exemplo. Nielsen (1994) faz indicações sobre a quantidade de avaliadores a serem utilizados, possibilitando, assim, identificar a maior parte de problemas de ergonomia.

Especialistas em usabilidade e domínio de sistemas são os que apresentam os melhores resultados quanto ao número de problemas identificados. Com cinco avaliadores desse tipo são capazes de identificar 95% dos problemas de ergonomia de um software. Cinco avaliadores especialistas apenas em usabilidade identificam 85%. O mesmo número de avaliadores novatos identifica 50% desses problemas.

Para Galitz (2007) um processo rigoroso de testes de usabilidade é importante por diversas razões, incluindo as seguintes:

 Desenvolvedores e usuários possuem diferentes perfis - Desenvolvedores e usuários possuem diferentes perfis e níveis de conhecimento. Desenvolvedores possuem conhecimento especializado do sistema permitindo que eles saibam lidar com situações complexas ou ambíguas, algo que não é possível para usuários comuns. Desenvolvedores também usam

frequentemente terminologias que nem sempre são compreendidas pelos usuários;

 As intuições dos desenvolvedores não estão sempre corretas – A intuição dos designers, por melhor que eles sejam no que fazem, sobre a forma como o usuário utilizará o sistema, é propensa a erros. Intuição é algo muito superficial para ser levada em consideração;

 Não há usuários iguais – Todos se diferem, em aparência, sentimentos, habilidades motoras, habilidades intelectuais, habilidades de aprendizado e rapidez, preferências em controle de dispositivos e assim por diante. Em uma tarefa de entrada de dados do teclado, por exemplo, os melhores operadores provavelmente são mais rápidos e cometem menos erros do que os operadores menos habilidosos. O sistema deve permitir que usuários com características muito diferentes, de forma satisfatória e confortável, aprendam a executar a tarefa desejada;

 É impossível prever a usabilidade pela aparência - Assim como é impossível julgar a personalidade de uma pessoa pelo jeito com que ela se parece, é impossível prever a usabilidade do sistema pela sua aparência;

 As normas de design e diretrizes não são suficientes – Normas de design e diretrizes são um importante componente para um bom design, que estabelece as bases para a consistência. Mas, normas de design e diretrizes com frequência são vitimas de conflito de escolha. Elas também não podem resolver todas as interações dos inúmeros elementos de design que ocorrem dentro de um sistema completo;

 Feedback informal é inadequado – Feedback informal é inadequado pois partes do sistema podem ser completamente ignoradas e problemas em outras partes podem não ser documentados;

 Produtos de peças embutidas quase sempre possuem inconsistências em nível de sistema - Isso é um resultado normal e esperado quando diferentes desenvolvedores trabalham em diferentes aspectos de um sistema. Também,

pode-se dizer que os desenvolvedores se diferem, cada um tem sua maneira de pensar e desenvolver;

 Problemas encontrados tarde são mais difíceis e caros de se consertar. A menos que os problemas encontrados sejam realmente severos, eles não serãoconsertados;

 Problemas consertados durante o desenvolvimento reduzem os custos com suporte no futuro – Os custos de suporte são diretamente proporcionais aos problemas de usabilidade que permanecem após o desenvolvimento. Quanto mais problemas, mais elevados os custos com suporte;

 Vantagens sobre um produto competitivo pode ser alcançada.

Os produtos mais bem-sucedidos são aqueles que permitem fazer algo facilmente. Dentre as razões para se avaliar a qualidade de uso de sistemas computacionais interativos, Tognazzini (2000) destaca:

 Os problemas de IHC podem ser corrigidos antes e não depois de o produto ser lançado;

 A equipe de desenvolvimento pode se concentrar na solução de problemas reais, em vez de gastar tempo debatendo gostos e preferências particulares de cada membro de equipe a respeito do produto;

 Os engenheiros sabem construir um sistema interativo, mas não possuem conhecimentos adequados para discutir sobre a qualidade de uso;

 O tempo para colocar o produto no mercado diminui, pois, os problemas de IHC são corrigidos desde o início do processo de desenvolvimento, assim que aparecem, exigindo menos tempo e esforço para serem corrigidos;

 Identificar e corrigir os problemas de IHC permite entregar um produto mais robusto, ou seja, a próxima versão corretiva não precisa começar a ser desenvolvida no momento do lançamento do produto no mercado.

O ensino de IHC pode promover uma visão crítica sobre a importância da abordagem do projeto voltado ao usuário. Ou seja, ainda há uma área vasta do conhecimento a ser explorada dentro do conteúdo de Interação Humano- Computador.

A lista de recomendações heurísticas, que serve como base para esse tipo de inspeção, é uma combinação de regras gerais ou princípios reconhecidos, que buscam apontar prioridades em termos de usabilidade de interfaces interativas. Na verdade, ela representa um julgamento de valor, feito por especialistas, sobre as qualidades ergonômicas de uma interfaces e podem enfocar os seguintes aspectos: intuitividade (Inspeção Cognitiva), gestão de erros (Inspeção Preventiva) ou de usabilidade em geral (Heurísticas de Usabilidade) (NIELSEN, 1993; CYBIS, 2000).