Realizar uma avaliação através de heurísticas significa seguir uma estratégia baseada em parâmetros. Assim, para realizar uma avaliação heurística, deve-se escolher este conjunto de parâmetros. Esta é a grande diferença entre guidelines e heurísticas, pois as primeiras são regras para resolver um problema, como se fossem uma receita para construir uma boa interface. As segundas, por sua vez, são mais flexíveis, permitindo que o designer encontre sua própria solução. Provavelmente o conjunto mais conhecido seha o de Molich e Nielsen (1990)*, que originalmente continha nove heurísticas, atualizadas em 1994*, contando dez heurísticas. Para chegar ao conjunto original, Molich e Nielsen realizaram uma pesquisa com 77 designers e programadores, da indústria e acadêmicos, investigando se eles conseguiam encontrar problemas de usabilidade em uma interface. Sobre a avaliação com heurísticas, Nielsen e Molich afirmam que o sucesso da análise está intimamente relacionado à qualidade do avaliador, e profissionais experientes e com formação em ergonomia têm melhor performance que especialistas em computação. Além disso, afirmam que algumas interfaces são mais difíceis da avaliar heuristicamente do que outras, e que esta diferença acentua ainda mais a importância de avaliadores experientes. Também afirmam que este tipo de avaliação não deve ser feito por um único avaliador (recomendam de três a cinco profissionais). Ainda citam algumas vantagens do uso deste método: é rápido e barato; é fácil motivar a equipe a conduzir um experimento deste tipo e pode ser usado desde cedo no processo de desenvolvimento.
A lista atualizada (a de 1994) está abaixo**:
- Visão do estado do sistema: O sistema deve sempre manter os utilizadores informados acerca do que é que se está a passar através de feedback apropriado.
- Ligação entre o sistema e o mundo real: O sistema deve falar a linguagem dos utilizadores, usar palavras, frases e conceitos familiares para o utilizador.
- Liberdade e Controle: Pode acontecer que o utilizador escolha alguma função por engano e necessite de cancelar ou simplesmente ?Sair sem gravar alterações?. Sempre que possível deve implementar-se undo e redo.
- Consistência e Standards: Devem seguir-se convenções, normas definidas e normas de facto estabelecidas, de maneira a que o utilizador se sinta familiarizado com a forma de interagir com o sistema em qualquer parte deste.
- Prevenção de Erros: Melhor do que boas mensagens de erro é o desenho cuidado que previne que esses erros aconteçam. Não deixar que seja possível cometer o erro.
- Reconhecer em vez Recordar: Minimizar a necessidade do utilizador ter de se lembrar de algo (ex: qual a tecla para ver o documento X), disponibilizando visualmente objectos, opções ou acções. Não deve ser necessário decorar nada de uma janela para outra. As instruções devem estar acessiveis fácilmente e sempre que necessário.
- Flexibilidade e eficiência na utilização: Teclas de atalho (que normalmete não são usadas por utilizadores novatos). Estas poderão aumentar a velocidade de interacção para utilizadores mais experientes. Permitir aos utilizadores criar atalhos para acções mais frequentes.
- Design Simples: As janelas não devem conter informação irrelevante ou raramente necessária. Todas as informações extra disponibilizadas, competem com a informação relevante, diminuindo a sua visibilidade.
- Ajudar os utilizadores a reconhecer, diagnosticar e recuperar dos erros: As mensagens de erro devem ser expressas numa linguagem comum (sem códigos). Devem indicar precisamente qual o problema e a sugestão para a sua solução.
- Ajuda e Documentação: Mesmo que seja melhor que o sistema possa ser usado sem documentação, esta pode ser necessária. Deve ser possível pesquisar qualquer informação. Focar a ajuda mediante a tarefa que o utilizador pretende executar. A documentação deve ser simples (passo-a-passo) e não extensa.
Segundo Stanton e Young (2003), a avaliação através de heurísticas é um método extremamente simples e rápido de aplicar, podendo ser empregada em qualquer estágio do desenvolvimento do produto. Os autores recomendam apenas que o avaliador esteja familiarizado com o produto em análise. Por outro lado, os autores ressaltam a carga subjetiva da análise, o que resulta em baixa confiabilidade: avaliadores diferentes produzem resultados diferentes. Este não é o caso do KLM (veja o post sobre KLM aqui), que, segundo Stanton e Young tem alta confiabilidade.
Porém, a avaliação heurística tem uma funçao diferente da avaliação com o KLM: ela informa a qualidade da interface de uma forma mais geral, abrangendo outros aspectos além do tempo de execução da tarefa. Desta forma, ela se contitui numa referência importante para a escolha entre duas interfaces. Sendo assim, as interfaces mostradas nas figuras 1 e 2 serão submetidas à avaliação.
Figura 1. Interface com drag n´drop. O usuário arrasta um conceito para a área ao lado da tree, e o local (y) onde ele largou o conceito define o quanto o material está associado ao conceito.
Figura 2. Interface com HSlider. O usuário seleciona um item na Tree. Na tela ao lado, há uma HSlider, que o usuário usa para dizer o quanto o conceito se asssocia com o material. Na Tree se podem ser, ao lado dos conceitos que estão associados com o material, o quanto (%) o conceito se associa ao material.
A avaliação das duas interfaces é apresentada nas tabelas 1 e 2. Para cada item do conjunto de heurísticas foi atribuído um valor de -3 a 3. Ao final, os valores são somados para gerar uma “pontuação”.
| Heurística | Interface A | Motivo |
| Visão do estado do sistema | 3 | Não é preciso abrir a árvore para saber quais conceitos estão associados ao material, nem o quanto o conceito está associado. |
| Ligação entre o sistema e o mundo real (usar palavras, frases e conceitos familiares para o utilizador)
|
0 | Não se aplica, pois não há diálogos |
| Liberdade e Controle | 1 | É moderadamente difícil se recuperar de um erro, pois é necessário avaliar a posição que corresponde ao valor desejado. Para excluir o conceito é preciso notar a caixa de lixo. Este valor poderia aumentar se outras formas de exclusão fossem implementadas, como interpretar como excluão arrastar o conceito para fora do Canvas. |
| Consistência e Standards | 1 | Drag n drop tem pouca visibilidade: como saber que deve-se iniciar um drag? |
| Prevenção de Erros | 3 | Não é possível arrastar para outro local além do canvas. Se o uusário arrastou para um local que não corresponde à posição desejada, ele é “avisado” pelas datatips que ficam ao lado do conceito enquanto ele é arrastado. |
| Reconhecer em vez Recordar | 3 | É mais fácil associar a posição do que um número à importância. O usuário vê a importância relativa do conceito, e lembra da imagem geral, do mapa, ao invés de valores individuais |
| Flexibilidade e eficiência na utilização | 0 | Não será avaliado, pois foi avaliado pelo KLM. |
| Design Simples (não contem informação irrelevante ou raramente necessária)
|
3 | Não há informação irrelevante, e a posição dos elementos segue o fluxo da ação. |
| Ajudar os utilizadores a reconhecer, diagnosticar e recuperar dos erros | 0 | Não se aplica. |
| Ajuda e Documentação | 0 | Não se foi desenvolvido |
| TOTAL | 14 |
Tabela 1. Avaliação da Inteface A, que sugere a implementação de um comportamento de Drag n´Drop.
| Heurística | Interface B | Motivo |
| Visão do estado do sistema | 0 | É preciso abrir a árvore para saber quais conceitos estão associados ao material. É difícil saber qual o conceito mais associado ao material, e muito difícil ordenar os coneitos em ordem crescente / decrescente. |
| Ligação entre o sistema e o mundo real (usar palavras, frases e conceitos familiares para o utilizador) |
0 | Não se aplica, pois não há diálogos |
| Liberdade e Controle | 2 | É fácil se recuperar de um erro, pois o valor da associação está sempre visível, de forma numérica. Para excluir o conceito é preciso atribuir o valor zero à associação, o que pode não ser uma ação óbvia. |
| Consistência e Standards | 3 | Clicar em um objeto de uma árvore e ver as informações relevantes a este objeto em outra área é um comportamento esperado. |
| Prevenção de Erros | 3 | Se o usuário arrastou para um local que não corresponde à posição desejada, ele é “avisado” pelo valor da barra deslizante, que é atualizado em tempo real. |
| Reconhecer em vez Recordar | 1 | É difícil, pois o estado do sistema fica escondido dentro da árvore. O usuário precisa fazer uma buscar serial por cada dado. |
| Flexibilidade e eficiência na utilização | 0 | Não será avaliado, pois foi avaliado pelo KLM. |
| Design Simples (não contem informação irrelevante ou raramente necessária) |
3 | Não há informação irrelevante, e a posição dos elementos segue o fluxo da ação. |
| Ajudar os utilizadores a reconhecer, diagnosticar e recuperar dos erros | 0 | Não se aplica. |
| Ajuda e Documentação | 0 | Não se foi desenvolvido |
| TOTAL | 12 |
Tabela 2. Avaliação da Inteface B, que sugere a implementação de uma barra deslizante.
A pontuação das interfaces A e B foi, respectivamente, 14 e 12. Os itens em que a interface A teve desempenho melhor foram “Visão do estado do sistema” e “Reconhecer em vez Recordar“. Já a interface B se saiu melhor no item “Consistência e Standards“. Como a diferença – mais uma vez – foi pequena (cerca de 15%) em favor da interface A, o teste com usuários e um protótipo funcional é recomendado.
Acompanhe!
* MOLICH, R.; NIELSEN, J. Improving a Human-Computer Dialogue: What designers Know About Traditional Interface Design. Communications of the ACM, v. 33, p. 338-342, 1990.
* Para ver as dez heurísticas: http://www.useit.com/papers/heuristic/heuristic_list.html
** Tradução de bartolom.eu
*** Stanton, N. & Young, M. (2003). A Guide to Methodology in Ergonomics: Designing for Human Use. 2nd edition, Taylor & Francis. ISBN: 0-7484-0703-0
