44
AVALIAÇÃO HEURÍSTICA Eduardo Novais - UFC - 2011 quarta-feira, 11 de maio de 2011

Avaliacao Heuristica

Embed Size (px)

DESCRIPTION

Aula sobre avaliacao heuristica

Citation preview

AVALIAÇÃO HEURÍSTICAEduardo Novais - UFC - 2011

quarta-feira, 11 de maio de 2011

AVALIAÇÃO HEURÍSTICA

quarta-feira, 11 de maio de 2011

Avaliação heurística é um método não empírico de engenharia de usabilidade de interfaces que utiliza como parâmetro, como modelo de uma boa interface, as heurísticas.

quarta-feira, 11 de maio de 2011

quarta-feira, 11 de maio de 2011

HEURÍSTICAS

quarta-feira, 11 de maio de 2011

•As heurísticas são regras gerais que parecem descrever propriedades comuns de interfaces usáveis.

quarta-feira, 11 de maio de 2011

AS 10 HEURÍSTICAS DE NIELSEN

quarta-feira, 11 de maio de 2011

1. Feedback

2. Falar a linguagem do usuário

3. Saídas claramente demarcadas

4. Consistência

5. Prevenir erros

6. Minimizar a sobrecarga de memória do usuário

7. Atalhos

8. Diálogos simples e naturais

9. Boas mensagens de erro

10. Ajuda e documentaçãoquarta-feira, 11 de maio de 2011

• Refere-se ao fato do sistema manter os usuários informados sobre o que eles estão fazendo, com feedback imediato.

•O sistema deve informar continuamente ao usuário sobre o que ele está fazendo.

1) FEEDBACK

quarta-feira, 11 de maio de 2011

2) FALAR A LINGUAGEM DO USUÁRIO

• A terminologia deve ser baseada na linguagem do usuário e não orientada ao sistema. As informações devem ser organizadas conforme o modelo mental do usuário.

quarta-feira, 11 de maio de 2011

3) SAÍDAS CLARAMENTE DEMARCADAS

• Estão relacionados à situação em que os usuários escolhem as funções do sistema por engano e então necessitam de “uma saída de emergência” clara para sair do estado não desejado sem ter de percorrer um longo diálogo, ou seja, é necessário suporte a undo e redo.

quarta-feira, 11 de maio de 2011

4) CONSISTÊNCIA

• Referem-se ao fato de que os usuários não deveriam ter acesso à diferentes situações, palavras ou ações representando a mesma coisa. A interface deve ter convenções não ambíguas.

• Um mesmo comando ou ação deve ter sempre o mesmo efeito.

• A mesma operação deve ser apresentada na mesma localização e deve ser formatada/apresentada da mesma maneira para facilitar o reconhecimento.

quarta-feira, 11 de maio de 2011

5) PREVENIR ERROS

•O erros são as principais fontes de frustração, ineficiência e ineficácia durante a utilização do sistema.

• Evite situações de erro.

• Conheça as situações que mais provocam erros e modificar a interface para que estes erros não ocorram.

quarta-feira, 11 de maio de 2011

6) MINIMIZAR A SOBRECARGA DE MEMÓRIA DO USUÁRIO

•O sistema deve mostrar os elementos de diálogo e permitir que o usuário faça suas escolhas, sem a necessidade de lembrar um comando específico.

quarta-feira, 11 de maio de 2011

7) ATALHOS

• Para usuários experientes executarem as operações mais rapidamente.

• Abreviações, teclas de função, duplo clique no mouse, função de volta em sistemas hipertexto.

• Atalhos também servem para recuperar informações que estão numa profundidade na árvore navegacional a partir da interface principal.

quarta-feira, 11 de maio de 2011

8) DIÁLOGOS SIMPLES E NATURAIS

•Os diálogos não deveriam conter informações que são irrelevantes ou raramente necessárias. Cada nova informação em um diálogo compete com as informações relevantes, diminuindo sua relativa visibilidade.

quarta-feira, 11 de maio de 2011

9) BOAS MENSAGENS DE ERRO

• As mensagens devem ser expressas em linguagem simples (sem códigos), indicando o problema e sugerindo uma solução.

• Linguagem clara e sem códigos.

•Devem ajudar o usuário a entender e resolver o problema.

•Não devem culpar ou intimidar o usuário.

quarta-feira, 11 de maio de 2011

10) AJUDA E DOCUMENTAÇÃO

•O ideal é que um software seja tão fácil de usar (intuitivo) que não necessite de ajuda ou documentação.

• Por melhor que seja a interface, pode ser necessário fornecer ajuda e documentação. Qualquer informação deveria ser fácil de achar, e estar focalizada nas tarefas do usuário. Também deve estar disponível uma lista das etapas concretas a serem realizadas (informações breves).

quarta-feira, 11 de maio de 2011

AS FASES DA AVALIAÇÃO HEURÍSTICA

quarta-feira, 11 de maio de 2011

1. Treinamento

2. Avaliação

3. Análise de severidade

4. Discussão com projetistas

quarta-feira, 11 de maio de 2011

• forneça aos avaliadores conhecimento sobre o domínio do sistema e cenários

1) TREINAMENTO

quarta-feira, 11 de maio de 2011

•Quantidade de avaliadoresA sugestão de Nielsen é utilizar de 3-5 avaliadores, uma vez que não se ganha tanta informação adicional usando números maiores de avaliadores. O número exato de avaliadores para usar vai depender de uma análise custo-benefício.

quarta-feira, 11 de maio de 2011

quarta-feira, 11 de maio de 2011

quarta-feira, 11 de maio de 2011

quarta-feira, 11 de maio de 2011

2) AVALIAÇÃO

• A avaliação heurística é realizada com um observador e um avaliador por vez. Somente após todas as avaliações completadas é que os avaliadores podem se comunicar e ter seus resultados (escritos ou verbais) agregados.

quarta-feira, 11 de maio de 2011

•DuraçãoNormalmente, uma sessão de avaliação heurística para um avaliador individual dura uma ou duas horas.

quarta-feira, 11 de maio de 2011

•Processo de avaliaçãoDurante a sessão de avaliação, o avaliador percorre a interface diversas vezes e inspeciona vários elementos e compara-os com uma lista de princípios de usabilidade reconhecidos.

quarta-feira, 11 de maio de 2011

•Processo de avaliaçãoAo menos duas vezes para cada avaliador:

1. Sentir o sistema

2. Focar em elementos específicos

Usar cenários e tarefas, se necessário

quarta-feira, 11 de maio de 2011

•Processo de avaliaçãoAlém da lista de heurísticas gerais, ao avaliador é permitido considerar quaisquer princípios de usabilidade adicional ou resultados que vêm à mente que podem ser relevantes para qualquer elemento de diálogo específico.

quarta-feira, 11 de maio de 2011

•Processo de avaliaçãoAlém disso, é possível desenvolver categorias de heurísticas específicas para uma classe específica de produtos como um suplemento para as heurísticas gerais.

quarta-feira, 11 de maio de 2011

•Descrição dos problemasA saída do método de avaliação heurística é uma lista de problemas de usabilidade na interface com referências aos princípios de usabilidade que foram violados pelo projeto em cada caso, na opinião do avaliador.

quarta-feira, 11 de maio de 2011

•Descrição dos problemasNão é suficiente para o avaliadores simplesmente dizer que ele não gosta de alguma coisa, ele deve explicar o porquê com referência às heurísticas ou outros resultados de usabilidade.

quarta-feira, 11 de maio de 2011

•Descrição dos problemasOs avaliadores devem tentar ser o mais específico possível e listar cada problema de usabilidade separadamente. Se há três problemas em um único elemento, os três deveriam ser listados com referência a cada heurística não cumprida.

quarta-feira, 11 de maio de 2011

• Serve para alocar recursos para a nova solução e para estimar a necessidade esforço empregado na busca da solução de cada problema de usabilidade.

3) ANÁLISE DE SEVERIDADES

quarta-feira, 11 de maio de 2011

A gravidade de um problema de usabilidade é uma combinação de três fatores:

•A freqüência com que ocorre o problema: É comum ou raro?

•O impacto do problema, quando ocorrer : Será que vai ser fácil ou difícil para o usuário superar?

•A persistência do problema: É um problema uma vez que os usuários podem superar uma vez que eles sabem sobre ele ou os usuários repetidamente ser incomodado pelo problema?

quarta-feira, 11 de maio de 2011

•Finalmente, é preciso avaliar o impacto de mercado do problema, já que certos problemas de usabilidade podem ter um efeito devastador sobre a popularidade de um produto.

quarta-feira, 11 de maio de 2011

•Escala de nível de severidadeA seguinte escala de pontuação 0-4 pode ser utilizada para avaliar a gravidade dos problemas de usabilidade:

quarta-feira, 11 de maio de 2011

0 = não concordo que este é um problema de usabilidade

1 = problema cosmético: não precisa ser consertado a menos que exista tempo disponível

2 = problema menor: a fixação deveria ser dada em prioridade baixa

3 = maior problema: importante para corrigir, deve ser dada prioridade

4 = catástrofe: imperativo para corrigir antes do produto pode ser liberado

quarta-feira, 11 de maio de 2011

•As classificações de gravidade podem ser coletadas através do envio de um questionário aos avaliadores após as sessões de avaliação propriamente dita, listando o conjunto completo dos problemas de usabilidade que foram descobertas, e pedindo-lhes para classificar a gravidade de cada problema.

quarta-feira, 11 de maio de 2011

• Uma possibilidade para a extensão do método de avaliação heurística é realizar uma sessão de esclarecimento com avaliadores, observadores e desenvolvedores do projeto, na forma de brainstorming, após a sessão da última avaliação.

4) FASE DE DISCUSSÃO

quarta-feira, 11 de maio de 2011

•Conduzida entre avaliadores e projetistas

•Discute-se as características gerais da interface

•Sugere-se melhoramentos potenciais para solucionar problemas principais

•Os projetistas avaliam o esforço para concertar os problemas

quarta-feira, 11 de maio de 2011

REFERÊNCIAS

quarta-feira, 11 de maio de 2011

•Dias, Claudia. Usabilidade na Web: Criando portais mais acessíveis. Rio de Janeiro: Alta Books, 2003.

•Nielsen, Jakob. Heuristic Evaluation. Disponível em <http://www.useit.com/papers/heuristic/>. Última visualização em: 10 de abril de 2011.

•Amstel, Frederick van. As 10 heurísticas de Nielsen. Disponível em: <http://usabilidoido.com.br/as_10_heuristicas_de_nielsen_.html>. Última visualização em: 10 de abril de 2011.

quarta-feira, 11 de maio de 2011