Avaliação Por Inspeção. Professora Estelamaris Pellissari

Transcrição

1 Avaliação Por Inspeção Professora Estelamaris Pellissari

2 O que é avaliação por Inspeção (ou Preditiva)? Avaliar por inspeção significa utilizar uma série de métodos de avaliação através dos quais os avaliadores inspecionam ou examinam aspectos de uma interface de usuário relacionados a usabilidade. Com objetivo de buscar problemas de usabilidade em um projeto de interface existente e analisar estes problemas e fazer recomendações para consertá-los e melhorar a usabilidade do projeto. identificar os problemas; selecionar os problemas e corrigir. [Mack e Nielsen, 1994]

3 Tipos de Avaliação por Inspeção percurso cognitivo; percurso pluralista; revisão de diretrizes e padrões; avaliação heurística teste de usuário avaliação por acessibilidade Quem avalia? especialistas em usabilidade; consultores de desenvolvimento de software especializados em um determinado estilo de interface; usuários finais conhecedores do domínio e da tarefa.

4 Percurso Cognitivo (Walkthrough Cognitivo)

5 Percurso Cognitivo Consiste na avaliação de tarefas típicas realizadas pelos usuários da interface, a fim de encontrar problemas, relacionados à facilidade de aprendizagem dos passos necessários para realizar as tarefas. Os especialistas simulam o percurso das tarefas realizadas pelos usuários, verificando se a cada passo o usuário conseguiria alcançar o objetivo correto, evoluindo na interação com a interface.

6 A aplicação da técnica Para essa avaliação é preciso definir: quem são os usuários da interface, analisando suas características e comportamentos. as tarefas típicas que serão analisadas. a sequência de ações para a realização correta de cada tarefa. a interface a ser analisada, que é a descrição de informações necessárias para que as tarefas sejam realizadas, como requisitos, regras funcionais etc.

7 Questões respondidas pelos especialistas 1. Os usuários farão a ação correta para atingir o resultado desejado? Dada a decomposição de uma tarefa em sub-tarefas, o usuário saberá por onde começar? Saberá qual é o próximo passo? O que o usuário vai tentar fazer a cada momento? 2. O usuário perceberá que a ação correta está disponível? Onde está o elemento de interface correspondente ao próximo passo? Que ações a interface torna disponíveis?

8 Questões respondidas pelos especialistas: 3. O usuário associará o elemento de interface correto à meta a ser atingida? O elemento de interface revela seu propósito e comportamento? O usuário consegue identificar os elementos de interface? 4. Se a ação correta é tomada, o usuário perceberá que progrediu em direção à solução da tarefa? Como a interface apresenta o resultado de cada ação? O resultado apresentado tem correspondência com o objetivo do usuário?

9 Percurso Pluralístico (Walkthrough Pluralista)

10 Percurso Pluralístico Criado por quem? Pela equipe da IBM Austin. Com qual objetivo? Aumentar a eficiência da avaliação dos métodos existentes na época.

11 Quem participa? Especialistas em Usabilidade Desenvolvedores do Software Usuários Representativos BIAS, (1994)

12 Como que é feito? Utiliza um conjunto de painéis; Cópias das interfaces da tarefa que está sendo avaliada; Apresentados na ordem de execução; Onde cada participante anota nos painéis a ação que tomaria; Após a autorização do mediador, o usuário avança ao próximo painel. Bias, (1994) Obs: todos os participantes, durante a avaliação, assumem o papel de usuários representativos e preenchem todos os painéis.

13 Passos do Percurso Percurso pluralístico deve seguir os seguintes passos... (Bias, 1994)

14 Primeiro O especialista deve fornecer instruções sobre as regras do método, além do cenário e a descrição da tarefa. Mediador Comenta a importância da avaliação: sobre a opinião dos usuários, com o objetivo de deixá-los a vontade; sugere aos desenvolvedores que aceitem as críticas, pois o intuito é avaliar o software e obter a melhor interface possível. BIAS, (1994)

15 Segundo O desenvolvedor explica alguns conceitos e características do produto. Desenvolvedor Essa explicação tem a finalidade: de simular a apresentação do manual que acompanhará o software; assegurar que os participantes tenham todo o conhecimento que um usuário final terá.

16 Terceiro É solicitado aos participantes que escrevam as ações que tomariam para realizar a tarefa, diante de cada da interface presente no conjunto de painéis.

17 Quarto O desenvolvedor apresenta seu pensamento: a resposta da proposta no desenvolvimento do software; e o conjunto de ações que os usuários deveriam realizar. Desenvolvedor

18 Quinto Os usuários discutem suas respostas e problemas; Os desenvolvedores do software observam; Os especialistas em usabilidade mediam a discussão; Os desenvolvedores devem estar abertos a possíveis críticas; O especialista em usabilidade deve deixar um clima agradável. Usuários Mediador Desenvolvedores

19 Sexto O desenvolvedor é convidado a dar explicações sobre o projeto de interface; Desenvolvedor Levando em consideração as opiniões dos usuários, mas não significa que devem refazer a interface.

20 Sétimo - último Os participantes respondem a um questionário sobre a usabilidade software, baseados na experiência de interação. Especialistas em Usabilidade Desenvolvedores do Software Usuários Representativos

21 CHECKLISTS (Revisão de diretrizes)

22 Revisão de Diretrizes (Guidelines Review) Neste método de avaliação, a interface é inspecionada a fim de verificar se a mesma está de acordo com uma série de diretrizes (guidelines) bastante específicas. Estas diretrizes costumam estar dispostas em listas de checagem (checklists), nas quais o avaliador indica se determinado item está conforme ou não a dada diretriz. As listas de diretrizes (checklists), costumam ter centenas de itens o que, dependendo do tamanho da aplicação a ser verificada, pode levar dias ou semanas para efetuar uma avaliação completa.

23 Exemplos de (quantidade) de diretrizes Brown 1988: Smith & Moisier 1986: Marshall et al. 1987: Mayhew 1992: 302 diretrizes; 944 diretrizes; 162 diretrizes; 288 diretrizes.

24 Ex: Projeto ERGOLIST O projeto ErgoList tem por objetivo conceber, projetar, desenvolver e disponibilizar via Web/Internet uma ferramenta para a avaliação autônoma da facilidade de uso de dispositivos de software interativo. PRESSUPOSTOS Um checklist para a avaliação ergonômica representa uma ferramenta especialmente adequada para que projetistas, sem uma formação específica em ergonomia, possam conceber dispositivos de software corretos sob o ponto de vista da interação com o usuário. Compatibilidade (21) Significados (12) Consistência (11) Correção de erros (5) Mensagens de erro (9) Proteção contra erros (7) Experiência do Usuário (6) Flexibilidade (3) Controle do Usuário (4) Ações Explícitas (4) Ações Mínimas (5) Densidade Informacional (9) Concisão (14) Legibilidade (27) Feedback (12) Agrup. por formato (17) Presteza (17) Agrup. por localização (11) ERGOLIST 194 diretrizes

25

26

27

28

29 W3C: visa desenvolver padrões para a criação e a interpretação de conteúdos para a Web

30 Avaliação Heurística

31 Avaliação Heurística Este método foi criado como uma alternativa rápida e de baixo custo para encontrar problemas de usabilidade em um projeto de interface. Quem avalia? 4 a 5 avaliadores; pode ser necessário um especialista do sistema para esclarecer eventuais dúvidas dos avaliadores (cenários de uso típicos, listando passos que um usuário deve seguir para realizar uma amostra realista de tarefas, também podem ajudar). Quando? Durante quanto tempo? nas etapas iniciais do ciclo de projeto e desenvolvimento (uso de maquetes/protótipos/produto pronto). uma sessão deve durar de uma a duas horas. Caso a interface seja muito complexa, pode-se realizar mais de uma sessão. [Barbosa, 2002; Nielsen, 1994 (a)]

32 Como? cada avaliador deve examinar a interface individualmente (avaliações independentes e livres de tendências) e gerar um relatório por escrito de suas descobertas e comentários; o avaliador percorre a interface diversas vezes (pelo menos duas: uma para ganhar uma visão de conjunto; e outra para examinar cuidadosamente cada elemento, inspecionado os diversos elementos de interface e comparando-os com a lista de princípios ( heurísticas ) de usabilidade; depois das avaliações terem sido feitas, os avaliadores devem se reunir e gerar um relatório de suas descobertas combinadas. Este relatório irá conter uma lista dos problemas encontrados: para cada elemento de interface, cada problema encontrado deve ser detalhado e justificado, fazendo alusão às heurísticas que foram violadas, e ter sua severidade avaliada). [Barbosa, 2002]

33 Severidade de um Problema de Usabilidade Quando avaliar a severidade? Após as sessões, cada avaliador responde a um questionário contendo a lista completa dos problemas encontrados por todos os avaliadores (os problemas devem estar detalhados, se possível com uso de ilustrações e capturas de telas). Combinação de três fatores: a freqüência com que o problema ocorre: É um problema comum ou raro? o impacto do problema, se ocorrer: Será fácil ou difícil para os usuários superarem o problema? a persistência do problema: É um problema que ocorre apenas uma vez e que os usuários conseguem superar facilmente ou os usuários serão incomodados pelo problema repetidas vezes? [Nielsen, 1994 (a)]

34 Heurística Básica 1. visibilidade do estado do sistema; 2. correspondência entre o sistema e o mundo real; 3. controle e liberdade do usuário; 4. consistência e padronização; 5. prevenção de erros; 6. reconhecimento em vez de lembrança; 7. flexibilidade e eficiência de uso; 8. projeto estético e minimalista; 9. auxilia os usuários a reconhecerem, diagnosticarem e se recuperarem de erros; 10. ajuda e documentação. [Nielsen, 1994 (a,b)]

35 Severidade de um Problema de Usabilidade Escalas de Severidade: 0 Não concordo Que isto seja um problema. (Eu não concordo que isso é um problema de usabilidade.) 1 Cosmético Não precisa ser consertado a menos que haja tempo (Extra, precisa ser corrigido somente se sobrar algum tempo no projeto.) 2 Pequeno O conserto deve receber baixa prioridade (Corrigí-lo deve ter prioridade baixa.) 3 Grande Importante de ser consertado; deve receber alta prioridade. (Importante corrigí-lo.) 4 Catastrófico É imperativo consertar antes de se lançar o produto. (A sua correção é urgente, antes do produto ser liberado.)

36 Redesigner da interface O especialista dá uma sugestão de Redesigner como seria a interface para resolver o problema encontrado.

37 Avaliação de Teste com Usuários

38 Objetivos Minimizar o custo de chamadas ao suporte técnico; Aumentar as vendas e a probabilidade de fidelidade do cliente; Adquirir uma vantagem competitiva; Minimizar riscos. [Rubin, 1994]

39 Limitações Situações artificiais, ou seja, não reais; Resultados positivos não aprovam que um produto funciona; Os participantes raramente são representativos da população alvo; [Rubin, 1994]

40 Elementos básicos destes métodos Formulação de hipóteses sobre os problemas ou objetivos do teste. Uso de uma amostra representativa de usuários finais que podem ser escolhidos aleatoriamente ou não; Representação do ambiente real de trabalho, incluindo o produto que se deseja testar; Observação dos usuários finais que utilizam ou revisam uma representação deste produto. Captura de medidas quantitativas e qualitativas de desempenho e preferências. Recomendação de melhorias ao design do produto. [Rubin, 1994]

41 Tipos de testes Teste exploratório Feito na fase de análise do problema; Objetivo: examinar e explorar a qualidade dos conceitos preliminares de design; Foco: por que o usuário faz o que faz? Teste de apreciação Feito em etapas intermediárias do ciclo de desenvolvimento; Objetivo: avaliar a usabilidade de operações e aspectos mais concretos do produto; Foco: avaliar com que grau de sucesso o usuário pode realizar tarefas reais e identificar de interação específicas. [Rubin, 1994]

42 Teste de validação Feito nas etapas finais; Tipos de testes Objetivo: verificar a satisfação de critério estabelecidos no início do projeto e o sucesso da integração do produto com sua documentação; Foco: capturar dados quantitativos de desempenho. Teste comparativos Pode ser feito em diversos pontos do ciclo de desenvolvimento; Objetivo: comparar diversos estilos de interface. [Rubin, 1994]

43 Planejamento, realização e análise das tarefas Etapas: Desenvolver o experimento; Orientar as sessões de avaliação; Coletar dos dados; Analisar os dados; Tirar conclusões; Reprojetar e implementar a interface revisada. Vamos ver em detalhe cada uma dessas etapas. [Hix e Hartson, 1993]

44 Desenvolvendo o experimento: plano de teste: O objetivo do teste: o que se deseja obter? Onde e quando o teste terá lugar? Qual a duração prevista de cada sessão de teste? Qual software precisa estar a disposição? Qual deverá ser o estado do sistema no início do teste? Qual deve ser o tempo de resposta / carga do sistema / rede? Quem será o experimentador (avaliador)? Quem serão os usuários e como serão conseguidos? Quantos usuários e como serão conseguidos? Quantos usuários são necessários? Quais as tarefas que serão solicitadas aos usuários? Qual o critério será utilizados pra definir que os usuários terminarem cada tarefa corretamente? O quanto o experimentador poderá ajudar o usuário durante o teste? Quais os dados serão coletados e como serão analisados uma vez que tenham sido coletados? Qual o critérios para determinar que a interface é um sucesso? Por ex: nenhum problema de usabilidade novo com severidade maior ou igual a 3). [Nielsen, 1993]

45 Desenvolvendo o experimento: orçamento do teste: Especialistas em usabilidade para planejar, executar e analisar o teste; Assistentes administrativos para agendar sessões de teste, coletar dados etc; Desenvolvedores do software para modificar código; Tempo dos usuários; Computadores usados durante o teste e durante a análise; Videotapes e outros recursos. [Nielsen, 1993]

46 Desenvolvendo o experimento: escolhendo o usuário: Devem ser representativos; Usuários novatos X usuários experts; Considerar a necessidade de um treinamento inicial dos usuários (por ex: no uso do mouse, no uso de janelas múltiplas); Para comparar a usabilidade de dois ou mais sistemas; Cada usuário testa um único sistema X cada usuário testa todos os sistemas. [Nielsen, 1993]

47 Desenvolvendo o experimento: escolhendo os avaliadores: Devem ter conhecimento extenso sobre a aplicação e a respectiva interface de usuário: Não precisa saber como o sistema foi implementado, mas deve saber como lidar com problemas que levem o sistema a cair. Podem ser o designers Problemas: Ajudar os usuários sem querer; Antecipar explicações sobre os erros. [Nielsen, 1993]

48 Desenvolvendo o experimento: aspectos éticos: Usuário são humanos: Profundo respeito as suas emoções e bem-estar; Geralmente se sentem sob muita pressão na situação de teste: Aprendem mais lentamente; Fazem mais erros: Se sentem estúpidos quanto experimentam essas dificuldades; Lembrar sempre: o sistema é que está sendo testado e não o usuário. [Nielsen, 1993]

49 Desenvolvendo o experimento: escolha das tarefas: Representativas Cobertura razoável das partes mais significativas da interface; Devem poder ser completadas no tempo definido para uma sessão de teste; Devem ser descritas por escrito; Tarefas não devem ser ofensivas; Devem ser tão realistas quanto possível e inseridas em um cenário; Devem ter grau de dificuldade gradativa para dar mais confiança ao usuário Planejada para que possam ser interrompidas a qualquer tempo; Fornecer uma tarefa de cada vez. [Nielsen, 1993]

50 Orientar as sessões de avaliação: Preparação Tudo deve estar pronto antes do usuário chegar; Cuidado em limpar o computador (de resultados de outros testes, alarmes, etc); Introdução O propósito do teste é avaliar o sistema e não o usuário; Os usuários não devem se preocupar em ferir sentimentos dos experimentadores (designers) com suas observações; Os resultados do teste servirão para melhorar a interface do usuário; Relembrar que o sistema é confidencial e não deve ser comentado com outros (inclusive podem vir a ser futuro usuários de teste); Os resultados do teste não serão colocados publicamente e o anonimato do usuário estará garantido. Explicar sobre o uso de gravações de vídeo ou áudio que estejam sendo feitas (o ideal é não gravar a face do usuário). Explicar que o usuário pode fazer qualquer pergunta durante o teste, mas que nem sempre o experimentador irá ajudá-los ou responder suas questões. Instruções específicas sobre a forma do teste (por ex.: falar em voz alta, ou fazer as atividades o mais rápido que puder, etc..). [Nielsen, 1993]

51 Orientar as sessões de avaliação: (continuação) O teste Evitar qualquer tipo de comentário ou expressões sobre a performance ou observações do usuário; Evitar ajudar o usuário, a não ser que ele esteja realmente com dificuldades muito severas; Se existir mais de um experimentador, somente um fala para não gerar confusão. Pós-teste Preencher questionários de satisfação subjetiva; Deixar os usuários livres para fazerem quaisquer sugestões/observações/críticas. [Nielsen, 1993]

52 Coletar os dados Observação direta Assistir ao usuário em seu trabalho... Observação indireta Gravação em vídeo ou por software de captura de tela Usuário verbaliza seus pensamentos. Mostra sua interpretação (já diz porque está fazendo algo...). Observador tem que levar o usuário a falar sem interferir no uso do sistema pelo usuário. [Nielsen, 1993]

53 Analisar os dados Análise baseada em tarefas Como ele realizou; Análise baseada em desempenho O tempo que ele levou. [Nielsen, 1993]

54 Ex. laboratórios de usabilidade

55 Ex. laboratórios de usabilidade

56 Ex. laboratórios de usabilidade

57 Ex. laboratórios de usabilidade

58 Ex. laboratórios de usabilidade

59 Ex. laboratórios de usabilidade

60

61

62

63 Exercício 7 Responda 1. Resuma com suas palavras o que é Avaliação por inspeção. 2. Resuma com suas palavras o que é Avaliação Percurso cognitivo 3. Resuma com suas palavras o que é Avaliação Percurso pluralista 4. Resuma com suas palavras o que é Avaliação Revisão de diretrizes e padrões 5. Resuma com suas palavras o que é Avaliação heurística 6. Resuma com suas palavras o que é Avaliação com Teste de usuário