Avaliação - Engenharia Informática/Sistemas Gráficos e Interação

Apoio ao estudo Avaliação Engenharia Informática/Sistemas Gráficos e Interação Nuno Rodrigues Alexandrino Gonçalves DEI/ESTG...

Apoio ao estudo Avaliação Engenharia Informática/Sistemas Gráficos e Interação Nuno Rodrigues Alexandrino Gonçalves DEI/ESTG-IPLeiria CIIC-IPLeiria DEI Departamento de Engenharia Informática  Sumário Tipos de avaliação Avaliação heurística Avaliação preditiva – Modelo GOMS – Modelo KLM Avaliação com utilizadores – Métodos de avaliação com utilizadores – Planeamento dos testes – Participantes – Tarefas e medidas de usabilidade – Testes-piloto – Fases da sessão de testes 2 Avaliação Avaliar a usabilidade – Utilizador: saber a facilidade de aprender, memorizar e usar o sistema – Sistema: saber se os requisitos do utilizador foram satisfeitos permitindo que este realize as suas tarefas mais facilmente 3 Avaliação Avaliar a funcionalidade – Medição do desempenho do utilizador com o sistema – eficácia do sistema em suportar as tarefas 4 Avaliação Avaliar a experiência de interação do utilizador e o impacto que esta tem nele – Satisfação do utilizador – Medidas emocionais e de entretenimento 5 Tipos de avaliação Métodos analíticos – não envolvem utilizadores Métodos empíricos – requerem utilizadores 6 Avaliação analítica Não envolve utilizadores Rápidos de realizar Recorre a peritos e métodos de inspeção (avaliação heurística) ou a modelos preditivos (avaliação preditiva) para avaliar a usabilidade do sistema Desvantagens – Apenas fornecem estimativas do tempo para realizar uma tarefa – Apenas preveem eventuais problemas de usabilidade 7 Métodos de inspeção O perito desempenha o papel do utilizador Analisa a interface procurando identificar todos os eventuais problemas de usabilidade (a partir de uma lista de princípios de usabilidade) Normalmente usados para avaliar os sistemas como um todo 8 Modelos preditivos Envolvem a análise das operações físicas e mentais que o utilizador tem de realizar para completar uma determinada tarefa Com base na análise, estimar o tempo necessário para completar uma tarefa Mais utilizados para testar aspetos específicos de uma interface (ex: a distribuição das teclas de um teclado; as opções de um menu) 9  Testes com utilizadores Envolve a medição de desempenho e a satisfação de utilizadores típicos a realizarem tarefas típicas Medidas de desempenho (exs:) – Tempo para concluir as tarefas – Números de erros cometidos Filmar os utilizadores e/ou tomar nota dos seus comentários e sugestões Registar as suas interações num log 10 Testes com utilizadores Para recolher as opiniões utilizam-se questionários de satisfação e entrevistas Tipo de estudo – Estudo controlado – quando os testes são realizados num laboratório – Estudo de campo – quando os testes são realizados no ambiente de trabalho do utilizador 11 Avaliação Formativa – Pode ocorrer várias vezes ao longo do ciclo de vida do projeto Sumativa – realizada apenas no final do processo de design 12 Avaliação sumativa Tem o objetivo de avaliar o sucesso de um produto acabado, comparando com os critérios de usabilidade estabelecidos na fase inicial de design Geralmente usa métodos que recolhem medidas quantitativas e qualitativas da usabilidade Serve para comparar alternativas de design e para realizar comparações competitivas entre várias soluções (habitualmente através de cálculos estatísticos) 13 Avaliação formativa Os resultados servem melhorar o design da interface Procura identificar aspetos da interface que apresentem problemas de usabilidade Pode ser aplicada a vários tipos de protótipos (papel, funcionais, final) A avaliação heurística é um método típico deste tipo de avaliação 14 Avaliação Heurística (AH) Técnica de inspeção Peritos verificam se a interface está de acordo com um conjunto de princípios de usabilidade, conhecidas como heurísticas Perito examina a interface colocando-se no lugar do utilizador Perito: alguém que conhece e percebe as heurísticas a serem usadas e já usou e pensou em várias interfaces 15 Avaliação Heurística Alternativa aos testes com utilizadores – quando não é possível fazê-los Complementar a avaliação com utilizadores – Normalmente consegue identificar problemas não encontrados nos testes com utilizadores Pode-se utilizar em qualquer fase do processo de design, desde a fase dos protótipos rudimentares até à fase do produto acabado 16 AH - vantagens É rápida – 1 dia ou menos para ficar concluída É barata – não precisa de utilizadores, laboratórios ou equipamentos especiais É fácil de usar – pode ensinar-se em pouco mais de 2 horas De acordo com alguns estudos, é a mais eficaz: apresenta a melhor relação custo-benefício, com um custo de usabilidade mais barato do que os outros métodos de avaliação alternativos 17 AH - desvantagem O perito não é o utilizador típico 18 Fases da AH Treino pré-avaliação Avaliação Consolidação Balanço 19 AH – Treino pré-avaliação Reunião de treino que junta a equipa de design e os avaliadores Equipa de design – Apresenta, aos avaliadores, a aplicação que vai ser avaliada – As principais funcionalidades que esta irá oferecer – Os cenários de utilização 20 AH - Avaliação Cada avaliador analisa a interface separadamente dos outros avaliadores, registando os problemas encontrados – esta avaliação individual é importante para garantir avaliações independentes que não foram afetadas pelas avaliações de outros avaliadores Tipicamente cada avaliador leva entre 1 a 2 horas a completar a sua avaliação 21 AH - Avaliação Pode estar também presente um observador que vai tomando notas dos comentários e sugestões do avaliador. O observador também pode ajudar o avaliador com a utilização da interface, se necessário. Neste caso, deve- se tomar nota da situação em que isto aconteceu – em princípio será devido a um problema da interface e provavelmente os utilizadores também terão problemas 22 AH - Avaliação Os avaliadores devem realizar pelo menos duas inspeções à interface 1) Para se familiarizarem com o sistema, perceberem o fluxo de realização das tarefas e obterem uma vista geral 2) Focarem-se em cada um dos elementos que fazem parte da interface 23 AH - Avaliação 1) Cada avaliador cria uma lista de problemas – Descrever cada problema de usabilidade separadamente – Indicar a heurística que viola 2) Atribuir um grau de severidade e sugerir uma solução para cada problema 24 AH - Avaliação Cada problema deve ser listado separadamente (mesmo que corresponda ao mesmo elemento da interface) – Nem todos os problemas têm as mesmas caraterísticas (ex: severidade, facilidade de correção) 25  AH - Avaliação No final da avaliação deve ser criado um relatório com a seguinte informação para cada problema: – Designação do problema – breve descrição do que é o problema – Heurística(s) violada(s) – enumerar as heurísticas violadas – Descrição do problema – justificação de como é que a heurística é violada e por que razão é um problema de usabilidade – Proposta de correção – solução possível para o problema encontrado – Grau de severidade – qual a gravidade do problema para a realização da tarefa pelo utilizador – Imagem da interface com o problema assinalado (sempre que possível) 26 Exemplo 27 AH - Consolidação 1) Juntar os problemas identificados pelos vários avaliadores numa única lista de problemas (pode ser feito apenas pela equipa de design ou em conjunto com os avaliadores). 2) Devem-se identificar problemas duplicados ou semelhantes nos vários relatórios e atribuir-lhes uma severidades final (média das severidades) 28 AH – Consolidação O relatório consolidado deve conter também duas tabelas: 1) Número de problemas de usabilidade por heurística 2) Número de violações por grau de severidade 29 AH – Balanço No final da avaliação para discutir os resultados da avaliação e debater possíveis soluções para os problemas de usabilidade encontrados Reúne: – A equipa de design – Os avaliadores – Os observadores (quando os há) 30 AH – Balanço Dar prioridade aos problemas de usabilidade com severidade mais elevada Podem-se rever os graus de severidade atribuídos aos problemas Podem-se discutir algumas caraterísticas gerais da interface 31 AH – Balanço No final da reunião de balanço a equipa de design é responsável por observar o relatório consolidado, definir uma ordem de resolução dos problemas (tendo em conta os graus de severidade e recursos disponíveis) 32 Heurísticas de usabilidade Regras práticas que: – Os designers de interfaces utilizador usam para orientar a conceção de uma interface – Os avaliadores usam para avaliar a usabilidade de uma interface existente Existem vários conjuntos de heurísticas de usabilidade (ex: 16 princípios de Bruce Tognazzini, princípios de design de Norman, oito regras de ouro de Shneiderman, heurísticas de Nielsen) Ao conjunto de heurísticas podem-se acrescentar heurísticas específicas da plataforma onde a interface está a ser desenvolvida 33 1 – Tornar o estado do sistema visível O sistema deve manter sempre os utilizadores informados, em tempo útil, do que se está a passar Ex: barra de progresso, mudança de cursor 34 1 – Tornar o estado do sistema visível 35 2 – Correspondência entre o sistema e o mundo real O sistema deve utilizar a linguagem do utilizador com os conceitos que são familiares (frases, palavras, etc.). Fazer a informação aparecer numa ordem natural e lógica. Ex: se utilizador fala português a interface deve estar em português. Erro 0xc0000013 36 2 – Correspondência entre o sistema e o mundo real 37 3 – Utilizador tem controlo e liberdade Os utilizadores frequentemente escolhem opções por engano e precisam de “caminhos de saída” bem assinalados, sem terem de percorrer um caminho longo pré-determinado. Suportar Undo/Redo. 38 3 – Utilizador tem controlo e liberdade Os utilizadores frequentemente escolhem opções por engano e precisam de “caminhos de saída” bem assinalados, sem terem de percorrer um caminho longo pré-determinado. Suportar Undo/Redo. 39 4 – Consistência e standards O utilizador não deve ter de adivinhar se diferentes palavras, situações ou ações significam o mesmo. Devem-se utilizar as convenções das plataformas Exs: Salvar/guardar; Botões OK e Cancel 40 5 – Prevenção de erros Melhor que boas mensagens de erros é um design que previne os problemas. Eliminar situações de erro ou detetar os erros pelos utilizadores e apresentar mensagens de confirmação ao utilizador antes de concluir a ação Ex: escolher dados em vez de escrever 41 5 – Prevenção de erros 42 6 – Reconhecimento em vez de lembrança Minimizar a necessidade de memorização tornando visíveis os objetos, ações e opções da interface. Tornar a informação e instruções visíveis sempre que necessário Exs: utilizar listas em vez de se lembrar do código ou nome; símbolos visuais em botões 43 6 – Reconhecimento em vez de lembrança 44 7 – Flexibilidade e eficiência Os aceleradores, invisíveis para os utilizadores principiantes, podem acelerar a interação dos utilizadores peritos, sendo assim apto a ambos os tipos de utilizadores atalhos 45 8 – Estética e desenho minimalista Os diálogos não devem conter informação irrelevante ou raramente necessárias. Cada unidade de informação num diálogo compete com as unidades relevantes de informação e diminui a sua visibilidade relativa 46 8 – Estética e desenho minimalista 47 8 – Estética e desenho minimalista 48 9 – Ajudar os utilizadores a reconhecer, diagnosticar e recuperar de erros As mensagens de erro devem utilizar linguagem que o utilizador compreenda (sem códigos), a indicar precisamente o problema e a dar sugestões construtivas de solução Exs: utilizar a linguagem do utilizador nas mensagens de erro; indicar como corrigir o erro; colocar o cursor no local do erro 49 9 – Ajudar os utilizadores a reconhecer, diagnosticar e recuperar de erros 50 10 – Ajuda e documentação Embora seja melhor se o sistema puder ser utilizado sem documentação, pode ser necessário fornecer ajuda e documentação. Esta informação deve ser fácil de pesquisar e focada na tarefa, listar os passos concretos para executar a tarefa e não ser demasiado extensa Exs: botão de ajuda bem visível; ajuda contextual 51 Graus de severidade Por vezes não é possível resolver todos os problemas – necessidade de os ordenar por prioridade Atribuir graus de severidade, a cada um dos problemas de usabilidade encontrados, de acordo com a escala de 0 a 4 52  Graus de severidade 0. não existe consenso de que seja um problema de usabilidade 1. Problema estético apenas – não precisa de ser resolvido, a não ser que ainda exista tempo e recursos 2. Problema de usabilidade menor – deve ser dada uma prioridade baixa à correção deste problema 3. Problema de usabilidade importante – é importante que seja corrigido, logo deve atribuir-se uma prioridade elevada 4. Catástrofe de usabilidade – é imperativo corrigir este problema antes de lançar o produto 53 Graus de severidade Os graus de severidade são determinados tendo em conta: – A sua frequência – quantas vezes acontecem – O seu impacto no desempenho dos utilizadores – nº de utilizadores que serão afetados pelo problema e quanto tempo irão perder por causa dele – A persistência – é um erro isolado ou recorrente 54 Graus de severidade 55  Avaliadores Embora uma avaliação heurística possa ser feita apenas por um avaliador, estudos indicam que a quantidade de problemas de usabilidade identificados é apenas de cerca de 35% do total de problemas existentes Avaliadores diferentes tendem a identificar problemas diferentes O aumento do número de avaliadores-nº de problemas encontrados não é linear Mais avaliadores → maiores custos 56 Avaliadores – quantos? Segundo alguns estudos o máximo da relação custo- benefício está entre 3 a 5 avaliadores que permitem encontrar cerca de 65% a 75% dos problemas existentes numa interface Atenção aos sistemas críticos 57 Avaliadores – experiência Experiência dos avaliadores também afeta o número de problemas encontrados Bons avaliadores conseguem identificar os problemas fáceis e os difíceis “Menos bons” avaliadores conseguem apenas detetar os problemas mais fáceis 58  Avaliação preditiva Permite recolher informação sem recorrer a utilizadores Recorre a modelos cognitivos e físicos para estimar quanto tempo uma pessoa leva a realizar uma determinada tarefa Usados principalmente para comparar soluções alternativas e não tanto para estimar o desempenho real que os utilizadores irão ter com a interface Permite avaliar uma interface mesmo antes de ela existir (mesmo protótipos de papel) 59  Avaliação preditiva Fácil de utilizar Barata Útil apenas para sistemas com tarefas previsíveis Duas fases 1) Identificar a sequência pela qual a atividade é realizada e quais os passos que esta comporta 2) Analisar os vários passos e determinar medidas de usabilidade (ex: tempo necessário para completar cada um dos passos, passos onde podem ocorrer erros) 60 Avaliação preditiva – modelo GOMS GOMS (Goals, Operators, Methods and Selection rules) Modelo de processamento mental Utilizadores atingem objetivos resolvendo subobjetivos (“dividir para conquistar”) 61 Avaliação preditiva – modelo GOMS Goals – O que os utilizadores querem atingir (exemplo: apagar uma frase) – Objetivos podem ser divididos em subobjetivos (exemplo: apagar frase → selecionar frase; apagar texto selecionado) 62 Avaliação preditiva – modelo GOMS Operators – Processos cognitivos e as ações físicas que os utilizadores têm de fazer para atingir os objetivos (ou subobjetivos) → ações básicas para usar o sistema – Podem afetar apenas o estado mental do utilizador (ex: escolher rato ou teclado para fazer a seleção) ou o sistema (ex: carregar na tecla delete, mover o rato) 63  Avaliação preditiva – modelo GOMS Methods – Sequências de passos (operadores) necessários para atingir um objetivo ou subobjetivo – Quando temos métodos alternativos devemos usar a palavra select para indicar que são alternativos Exemplo: GOAL: APAGAR-TEXTO-SELECIONADO [select GOAL: APAGAR-COM-TECLADO Carregar-Tecla-Delete GOAL: APAGAR-COM-RATO Carregar-Botão-Direito Mover-Cursor-Opção-Delete Carregar-Botão-Esquerdo ] 64  Avaliação preditiva – modelo GOMS Selection rules – Selecionar qual o método a utilizar quando existem vários disponíveis para atingir o mesmo objetivo – Uma regra de seleção determina qual dos métodos deve ser usado em função do contexto do utilizador – Exemplo: Regra 1: Usar APAGAR-COM-TECLADO se o utilizador usar o teclado Regra 2: Usar APAGAR-COM-RATO se o utilizador usar o rato 65  Avaliação preditiva – modelo GOMS Descrição GOMS – Consiste num objetivo de alto nível, decomposto numa sequência de tarefas unitárias (subobjetivos) – Cada tarefa unitária pode ser decomposta em operadores básicos – A decomposição requer o conhecimento: Da estratégia utilizada pelos utilizadores para resolver o problema Da tarefa Do domínio do problema 66 Avaliação preditiva – modelo GOMS Descrição GOMS – A análise da descrição GOMS permite obter medidas de desempenho – O número de objetivos e subobjetivos pode ser usado para estimar as necessidades da memória de curto prazo – O modelo GOMS está feito para utilizadores experientes 67 Avaliação preditiva – modelo GOMS 68 Avaliação preditiva – modelo KLM KLM (Keystroke Level Model) Mesmos autores do GOMS Modelo físico que prevê o tempo que os utilizadores irão gastar na realização de tarefas simples Considera que os utilizadores são peritos O método é dado 69 Avaliação preditiva – modelo KLM Decompõe a fase de execução em: – Cinco operadores físico-motores – Um operador mental – Um operador relacionado com a resposta do sistema 70  Avaliação preditiva – modelo KLM K (físico-motor): premir um tecla, incluindo SHIFT e outras teclas modificadoras B (físico-motor): carregar num botão do rato P (físico-motor): apontar e mover o rato (ou similar) para um alvo H (físico-motor): localizar o rato ou teclado (passar as mãos de um dispositivo para outro) D (físico-motor): desenhar linhas utilizando o rato M (mental): preparação mental para realizar uma ação física R (sistema): resposta do sistema às ações do utilizador (nos casos em que o utilizador não tem de esperar por ele, pode ser ignorada) 71 Avaliação preditiva – modelo KLM A execução de uma tarefa envolve a ocorrência intercalada de vários destes operadores Normalmente o KLM é usado em conjunto com o GOMS, de modo a tirar partido da divisão das tarefas do GOMS → facilita a aplicação dos tempos a cada operador e o cálculo do tempo total de execução Para calcular o tempo total de execução de uma tarefa somam-se os tempos dos vários operadores 72 Avaliação preditiva – modelo KLM 73 Avaliação preditiva – modelo KLM 74 Avaliação preditiva – modelo KLM 75 Avaliação com utilizadores Utilizadores reais – potenciais utilizadores do sistema Medição de desempenho a realizar tarefas típicas Recolha de dados de usabilidade Mais cara e demorada do que a Avaliação Heurística (AH) Normalmente produz melhores resultados que a AH 76 Métodos de avaliação com utilizadores Entrevistas de grupo Observação direta Questionários ou entrevistas “Pensar em voz alta” Observação indireta 77 Métodos de avaliação com utilizadores A escolha do(s) método(s) depende do tipo de avaliação (formativa/sumativa) e da informação que se pretende recolher 78 Exemplo 1 Avaliação formativa em que objetivo principal é identificar problemas de usabilidade para melhorar a interface (em detrimento de obter medidas de desempenho) – Observação direta, “pensar em voz alta” ou observação indireta 79 Exemplo 2 Avaliação sumativa em que se pretende avaliar o desempenho da versão final do sistema ou realizar um teste comparativo com outra solução (recolha principalmente de medidas de desempenho): – Observação direta complementada por questionários e entrevistas 80  Testes com utilizadores - SUS Criado em 1986, o SUS (System Usability Scale), é um questionário amplamente usado para avaliar a usabilidade em sistemas de TI Usa uma escala de Likert (de 1 a 5) nas 10 questões que o compõem No final, é obtida uma pontuação (0 - 100) - SUS Score - para o sistema 81 Testes com utilizadores - SUS 82 Testes com utilizadores – SUS (PT) 83 Testes com utilizadores – SUS Score Definir a pontuação para cada uma das 10 perguntas: Todas as perguntas geram uma pontuação de 0 a 4 O valor resultante das perguntas ímpares, é o valor da cotação dessa pergunta -1 O valor resultante das perguntas pares, é 5 - o valor da cotação dessa pergunta Exemplo: 84 Testes com utilizadores – SUS Score SUS Score = (valor perguntas pares + valor perguntas ímpares) * 2,5 Em termos de usabilidade, um bom sistema obtém um SUS Score acima dos 71,1. Pontuações abaixo deste valor poderão indiciar que o sistema é seriamente ineficiente em termos de usabilidade 85  SUS – Inquérito caracterização utilizadores Exemplo de inquérito de caracterização dos utilizadores Dever ser feito imediatamente antes do SUS 86  Testes com utilizadores – NASA-TLX Permite efetuar uma avaliação da carga mental de tarefas. Esta avaliação resulta numa pontuação de carga de trabalho em seis dimensões: – Exigência mental – Exigência física – Exigência temporal – Desempenho – Esforço – Frustração 87 Testes com utilizadores – NASA-TLX 88 Testes com utilizadores – NASA-TLX Depois do teste anterior, os utilizadores efetuam uma comparação entre pares para aferir quais as dimensões que mais contribuíram para a carga de trabalho da tarefa. Esta comparação permite realizar alguns cálculos que culminam na obtenção de uma classificação, entre 0 e 100 pontos, da carga da respetiva tarefa. Apesar de a avaliação obtida ser subjetiva, e mesma tem sido usada com algum sucesso na avaliação de tarefas dos mais diversos sistemas informáticos. 89 Planeamento dos testes Planeamento deve ser rigoroso para não se desperdiçar tempo/dinheiro Preparar tudo com antecedência Garantir que todos os utilizadores realizam os testes nas mesmas condições Formulários de consentimento 90 Planeamento dos testes Guião de testes Questionários de recolha de informação Questionários de satisfação Perguntas para a entrevista Vídeos, diapositivos, etc. 91 Planeamento dos testes Objetivo: o que se pretende atingir com o teste? – Solução mais rápida que a concorrência? – Atingiram-se os objetivos estabelecidos no início do desenvolvimento? – Utilizadores cometem menos erros? – Utilizadores conseguem realizar mais tarefas? 92 Planeamento dos testes Onde – Laboratório? – Sala? – No local onde será utilizado o sistema? 93 Planeamento dos testes Quando – Datas e horas? – Datas/horas para cada utilizador? 94  Planeamento dos testes Duração – Sessão no total? – Cada uma das partes da sessão? Introdução Explicação do sistema Realização das tarefas Preenchimento dos questionários Balanço final – A duração máxima recomendada para uma sessão de avaliação com utilizadores é de 1 hora 95 Planeamento dos testes Equipamento – Desktop? – Laptop? – Tablet? –... 96 Planeamento dos testes Software – Para além do sistema, são necessários outras aplicações (ex: calculadora, processador de texto, etc.)? 97 Planeamento dos testes Estado – qual deve ser o estado do sistema no início do teste? – Sistema já está em execução ou deve ser o utilizador a iniciá- lo? – Utilizadores têm de se autenticar ou iniciam no ecrã a seguir ao à autenticação? 98 Planeamento dos testes Tempo de resposta – Qual a carga e tempo de resposta do sistema onde corre a nossa aplicação? 99 Planeamento dos testes Coordenador e observador – Qual o membro da equipa de desenvolvimento que irá conduzir a sessão de testes e interagir com os utilizadores? – Quem será responsável pela observação? 100 Planeamento dos testes Utilizadores – Serão principiantes ou peritos? – Quantos homens e quantas mulheres? – Qual a faixa etária? 101 Planeamento dos testes Tarefas – Quais? – Quantidade? – Por que ordem? 102 Planeamento dos testes Fim correto: que critério será utilizado para determinar o fim da execução de uma tarefa corretamente? – Quando o ecrã indica? – Quando o utilizador o indica no ecrã? 103 Planeamento dos testes Ajuda – Que ajudas estão disponíveis para o utilizador? – A ajuda é apenas digital ou também em papel? – Também pode haver alguém a ajudar os utilizadores? Em que situações? 104 Planeamento dos testes Dados – Que dados serão recolhidos e como serão analisados? – Que medidas de usabilidade (ex: tempo, erros, número de cliques)? 105 Planeamento dos testes Sucesso – Qual será(ão) o(s) critério(s) que ditará(ão) que a interface é um sucesso? 106 Participantes Considerações éticas – As sessões de teste colocam alguma pressão nos utilizadores Centro das atenções Frustração pelos erros cometidos e pela dificuldade em realizar as tarefas Muitas vezes os utilizadores estão a fazer-nos um favor ao participar nos testes 107 Participantes Considerações éticas – Tempo Respeitar o tempo dos utilizadores ao não desperdiçá-lo Fazer testes-piloto antes para avaliar completamente o guião dos testes 108  Participantes Considerações éticas – Conforto Ambiente calmo e sem distrações Clarificar que quem está a ser avaliado é o sistema Dar uma tarefa de cada vez ao utilizador Não sobrecarregar o utilizador com tarefas A primeira tarefa deve ser simples Agradecer aos utilizadores no fim 109 Participantes Considerações éticas – Informação Dar aos utilizadores toda a informação que precisam ou querem saber sobre os testes (que não influenciem os resultados dos mesmos) → para que possam dar um consentimento informado Não esconder dados dos utilizadores desnecessariamente Informar os utilizadores se vão ser filmados ou fotografados Informar caso hajam mais observadores “escondidos” 110 Participantes Considerações éticas – Privacidade Não se deve registar o desempenho do utilizador de forma a que se consiga facilmente identificar quem fez determinado teste Ao divulgar resultados de testes deve-se garantir que não se se está a divulgar nenhum utilizador específico Quando há recolha de elementos multimédia não se devem divulgar sem ter autorizações escritas dos utilizadores envolvidos 111 Participantes Considerações éticas – Controlo Os utilizadores devem poder decidir se querem ou não participar nos testes Devem poder desistir – Desistir de uma tarefa e passar para a seguinte – Desistir e abandonar o teste 112 Que utilizadores Utilizadores dos testes devem representar os potenciais utilizadores do sistema – Público-alvo (ex: faixa etária, sexo) – Conhecimento das tarefas e do vocabulário 113 Testes intergrupo e intragrupo Quando está mais do que um sistema em avaliação (em concorrência) 114 Testes intergrupo e intragrupo Distribuição dos utilizadores pelos dois sistemas – Testes intergrupos Dividem-se em dois grupos (A e B) Grupos devem ter as mesmas características (ex: média de idades, proporção homens/mulheres, experiência, etc.) Cada grupo usa apenas um dos sistemas (X ou Y) Resultados comparados entre os dois grupos (exemplo: calculando as médias) Desvantagem: exige o dobro dos utilizadores 115  Testes intergrupo e intragrupo Distribuição dos utilizadores pelos dois sistemas – Testes intragrupos Os utilizadores fazem todos parte do mesmo grupo Os utilizadores usam os dois sistemas (X ou Y) Metade começa pelos sistema X, a outra metade pelo sistema Y – para reduzir a influência da aprendizagem nos resultados obtidos (quando chegam à segunda aplicação já saberiam realizar as tarefas) Resultados comparados ao nível do utilizador: calcula-se a média das diferenças de cada utilizador e verifica-se se é maior que zero 116 Quantos utilizadores? Depende do tipo de avaliação (formativa/sumativa) Depende da disponibilidade Depende do tempo disponível Depende do orçamento 117 Quantos utilizadores? Avaliação formativa (de acordo com alguns estudos) – 1 utilizador: ~1/3 dos problemas identificados – 15 utilizadores: ~99% dos problemas identificados – Alternativa: em vez de 15 utilizadores a identificarem cerca de 99% dos problemas numa só iteração, ter 5 utilizadores a identificarem cerca de 85% dos problemas em três iterações do design da interface 118 Quantos utilizadores? Avaliação sumativa – Amostra suficientemente grande para ser representativa da população e que permita utilizar algumas medidas estatísticas: 10-20 utilizadores 119 Tarefas As tarefas devem ser as mesmas que foram identificadas na análise de tarefas No caso da avaliação sumativa, onde se esteja a comparar a nossa solução com uma concorrente deve-se ter cuidado para não escolher as tarefas que favorecem a primeira 120 Medidas de usabilidade Existem várias medidas de usabilidade, algumas das mais utilizadas são: – Tempo para completar as tarefas – Número de erros cometidos – Número de tarefas concluídas com sucesso – Número de cliques – Satisfação do utilizador 121 Testes-piloto Realizados com 2-3 pessoas que não precisam de pertencer aos potenciais utilizadores Para testar e validar todo o processo experimental antes realizar os testes com utilizadores Verificar se as instruções do guião são percetíveis Se o enunciado das tarefas é percetível Se as tarefas se conseguem fazer no tempo estipulado 122 Testes-piloto Se as perguntas do questionário da entrevista se percebem Se as respostas vão ao encontro do esperado Se o fim das tarefas é claro Se o tempo estimado para a sessão de testes é suficiente... 123 Testes-piloto Vantagens dos testes – Descobrir tempos mortos – Alterar partes confusas na explicação do sistema – Descobrir tarefas inexequíveis – Ajustar os tempos de cada tarefa – Rever as perguntas do questionário – Praticar os papéis de coordenador e observador da sessão de testes 124 Fases da sessão de testes Preparação – Tudo pronto antes da chegada do utilizador – Tudo o que pode interromper ou distrair o utilizador deve ser desligado (ex: Screensavers, Skype, Facebook, e-mail, etc.) 125 Fases da sessão de testes Introdução – O coordenador começa por se apresentar e dar as boas vindas – Explicar os objetivos do teste – Qual o procedimento e fases – Indicar que nos estão a ajudar a testar o sistema e que os resultados servirão para o melhorar – Deixar claro que é o sistema que está a ser avaliado 126  Fases da sessão de testes Introdução – Explicar o objetivo de cada um dos elementos do teste (ex: câmara de vídeo) – Eventualmente poderá ser feita uma demonstração do sistema (poderá ser um vídeo) se não interferir com os objetivos do teste – Se não interferir com os objetivos do teste poderá também ser dado algum tempo ao utilizador para se ambientar com o sistema – Antes do teste deve apresentar o formulário de consentimento – Deve deixar claro que não poderá dar nenhum tipo de ajuda ao utilizador durante o teste e se tiver questões as deve esclarecer antes de iniciar o teste 127 Fases da sessão de testes Realização do teste – Duas pessoas da equipa de design: no papel de coordenador e de observador – Coordenador Conduzir os testes Explicar objetivos Interagir com o utilizador 128  Fases da sessão de testes Realização do teste – Duas pessoas da equipa de design: no papel de coordenador e de observador – Observador Observar e tomar notas sobre o que se vai passando – Comentários – Problemas de usabilidade – Sugestões – Anotar medidas de desempenho –... 129  Tarefas e medidas de usabilidade Balanço – Depois de realizados os testes deve-se pedir ao utilizador para preencher o questionário de satisfação (antes de qualquer discussão sobre o sistema) – Pedir de forma informal comentários e sugestões sobre o sistema – Responder a perguntas – Discutir algum comportamento interessante que tenha sido observado – Agradecer aos utilizadores a sua participação – Depois do utilizador sair, verificar se toda a informação recolhida está corretamente identificada com o utilizador que esteve a realizar o teste 130 Tarefas e medidas de usabilidade Balanço – Redigir relatório (o mais cedo possível) Objetivos da avaliação Breve descrição do sistema Ambiente em que as tarefas foram realizadas Descrição dos participantes Metodologia utilizada 131 Tarefas e medidas de usabilidade Balanço – Redigir relatório (o mais cedo possível) Tarefas do teste Lista de medidas recolhidas Questionários utilizados Análise dos dados recolhidos Lista dos problemas encontrados – ordenados por prioridades 132 Bibliografia Fonseca, M., Campos, P. e Gonçalves D., “Introdução ao design de Interfaces”, FCA Editora, 2017 133