Avaliação de interface

1. Avaliação de interface Alexsandro Rodrigues Lopes Professor: Klaus Schlünzen Junior IHC

2. Introdução • É comum a idéia de que a avaliação de interface é uma fase única no processo de desenvolvimento. • É melhor colocar o design sob constante avaliação • Avaliação como papel central. IHC

3. Modelo Estrela de Hix e Hartson IHC

4. Prudência e bom senso • Avaliação constante não significa avaliação extensiva • No início do projeto usar avaliação informal. Exemplo: breve discussão entre os membros. • Nas etapas posteriores intensificar o formalismo. IHC

5. Plano de Avaliação • Estágio do design (início, meio ou fim) • Quão pioneiro é o projeto (bem definido versus exploratório) • Número esperado de usuários • Quão crítica é a interface (por exemplo, um sistema de controle de tráfego aéreo versus um sistema de orientação de um shopping) • Custo do produto e orçamento alocado para o teste • Tempo disponível • Experiência dos designers e avaliadores IHC

6. Grau de incerteza • Aplica-se o plano e depois verifica-se que não ficou perfeito. Aplica-se de novo, fica em loop. Perfeição não é possível, pelo menos em interface. De repente, o que está fantástico para o Zé, estará ruim para a Maria. • Um ponto de equilíbrio precisa ser encontrado. IHC

7. Pretensões • Saber o que o usuário deseja para melhor atendê-lo. • Pergunta necessária: - Meu produto é tão bom ou melhor que o do competidor? IHC

8. Objetivos da avaliação da interface • Qual o impacto do design sobre o usuário? • A existência de funcionalidades garante que uma tarefa possa ser facilmente executada? • Identificar problemas específicos com o design. IHC

9. Métodos de avaliação • Inspeção de usabilidade • Testes de usabilidade • Experimentos controlados • Métodos de avaliação interpretativos IHC

10. Inspeção de usabilidade • Definição: modo de avaliar design de interfaces baseado no julgamento de avaliadores e são sustentados pela confiança depositada em seus julgamentos. • Os critérios de avaliação são definidos pelo julgador e podem variar de acordo com o tipo de interface que está sendo avaliada. IHC

11. Objetivos da inspeção • Encontrar problemas de usabilidade em um design de uma interface de usuário e com base nesses problemas fazer recomendações no sentido de eliminar problemas e melhorar a usabilidade do design. IHC

12. Problemas de usabilidade • Identificar problemas é apenas parte do processo, depois de ser gerada a lista de problemas de usabilidade, a equipe de desenvolvimento precisa fazer um redesign da interface de modo a tentar corrigir a maior quantidade possível de problemas. • Métodos de inspeção são melhores para encontrar problemas do que para sugerir melhoras de interface. Os resultados da avaliação precisam ser analisados pela equipe de desenvolvedores e avaliadores, de modo a executar as mudanças. IHC

13. Graus de severidade • Significa estabelecer prioridades com relação a gravidade de cada problema. Prioridades são necessárias para que não seja despendido esforço desproporcional para corrigir problemas que irão alterar em muito a interação do usuário com a interface. IHC

14. Métodos de inspeção • Avaliação heurística: é tomada como base uma pequena lista de heurísticas de usabilidade. • Revisão de guidelines: a interface é avaliada no sentido de verificar se está de acordo com uma lista de guidelines de usabilidade. • Inspeção de consistência: o avaliador verifica a consistência dentro de uma família de interfaces, quanto a terminologia, cores, layout, formatos de entrada e saída, etc. • Percurso cognitivo: o analisador simula o usuário “caminhando” na interface para executar tarefas típicas. IHC

15. Avaliação heurística • A maioria dos métodos de inspeção terão um efeito significativo na interface final somente se forem usados durante o ciclo de vida do projeto. • Nielsen propõe a engenharia econômica de usabilidade: discount usability engineering. • Métodos baratos, rápidos e fáceis de serem usados. IHC

16. Avaliação heurística • São regras gerais que objetivam descrever propriedades comuns de interfaces usáveis: 1)Dialogo simples e natural • Simples significa informação não irrelevante ou raramente utilizada. • Natural refere-se a adequação a tarefa. 2)Falar na linguagem do usuário • Usar conceitos do mundo do usuário • Não usar termos computacionais específicos IHC

17. Avaliação heurística 3) Minimizar a carga de memória do usuário • Não fazer com que o usuário tenha que relembrar coisas de uma ação em uma próxima ação. 4) Ser consistente • Seqüências de ações aprendidas em uma parte do sistema devem poder ser aplicadas em outras partes. 5) Prover feedback • Dar conhecimento aos usuários do efeito que suas ações têm sobre o sistema. IHC

18. Avaliação heurística 6) Saída claramente marcadas • Se o usuário entra em uma parte do sistema que não lhe interessa, ele deve ser capaz de sair rapidamente sem estragar nada. 7) Prover shortcuts • Auxiliar o usuário experiente a evitar extensos diálogos e mensagens de informações que ele não quer ler. IHC

19. Avaliação heurística 8) Mensagens de erro construtivas e precisas • Informar ao usuário qual foi o problema e como corrigi-lo. 9) Prevenir erros • Sempre que encontrar uma mensagem de erro, verificar se aquele erro poderia ser evitado. 10) Help e documentação • Embora seja melhor um sistema que possa ser usado sem documentação, é necessário prover help e documentação. Essas informações devem ser fáceis deencontrar, focalizadas na tarefa do usuário e não muito extensas. IHC

20. Problemas em avaliações heurísticas • Exemplo 1: na primeira versão do Teleduc, a ferramenta de correio não permitia o envio de mensagens sem o preenchimento do corpo do assunto. A maioria dos sistemas de correio permite isso, emitindo apenas um aviso. IHC

21. Problemas em avaliações heurísticas • Exemplo 2: No Windows quando se deseja instalar um novo componente de hardware é iniciado um processo de busca e o indicador de detecção pode ficar parado por muito tempo. O usuário fica perdido por não saber o que significa esse muito tempo e não sabe se deve ou não reiniciar o computador, mesmo porque usuários de sistemas semelhantes sabem quão pouco confiável é a relação da barra de detecção com o real andamento da operação. IHC

22. Problemas em avaliações heurísticas IHC

23. Problemas em avaliações heurísticas • Exemplo 3: o software winzip em uma mesma versão gratuita tem uma tela de abertura onde os botões aparecem em ordem aleatória a cada execução. Arbitrariamente os botões aparecem em ordem trocada a cada execução. IHC

24. Problemas em avaliações heurísticas • Exemplo 4: O Microsoft Word possui, no canto inferior esquerdo da tela quatro botões que servem para selecionar o modo de exibição do texto: normal, layout on-line, layout da página e estrutura de tópicos. IHC

25. Graus de severidade • É a avaliação da gravidade do problema • A gravidade do problema é uma combinação dos seguintes fatores: 1) Com qual freqüência ele ocorre: se é comum ou raro. 2) Impacto: se é fácil ou difícil para ele superá-lo. 3) Persistência: o problema ocorre uma única vez, ou os usuários são repetidamente incomodados por ele. 4) Impacto do problema no mercado. IHC

26. Etapas de uma avaliação heurística • Avaliadores devem percorrer a interface pelo menos duas vezes. Na primeira vez devem se concentrar no fluxo e na segunda nos componentes individuais do dialogo. • A interface deve ser inspecionada com base em uma lista de princípios de usabilidade, as denominadas heurísticas. • Combinar os problemas encontrados por 3 a 5 avaliadores e fazer com que trabalhem individualmente (sem que um influencie o outro). IHC

27. Fechamento da avaliação • Depois do trabalho individual o ideal é ter uma reunião final de discussão, incluindo representantes da equipe de desenvolvimento de forma a se ter sugestões para redesign. • Caso seja necessário graus de severidade são atribuídos aos problemas. IHC

28. Referência Bibliográfica • Rocha, H. V., Baranauskas, M.C. Design eAvaliação de Interfaces Humano-Computador. Campinas, SP: NIED/ UNICAMP, 2003. Pg. 163-187. • Diversos sites na Web. IHC