Testes de Usabilidade e Relatórios

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

• Disciplina: Engenharia Informática/Sistemas Gráficos e Interação
• Autores: Nuno Rodrigues, Alexandrino Gonçalves
• Instituição: DEI/ESTG-IPLeiria, CIIC-IPLeiria

Sumário

• Tipos de avaliação
• Avaliação heurística
• 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

Avaliação

• Avaliar a usabilidade
  • Utilizador: facilidade de aprender, memorizar e usar o sistema
  • Sistema: se os requisitos do utilizador foram satisfeitos, permitindo que o utilizador realize as suas tarefas mais facilmente
• Avaliar a funcionalidade
  • Medição do desempenho do utilizador com o sistema – eficácia do sistema em suportar as tarefas
• 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

Tipos de avaliação

• Métodos analíticos – não envolvem utilizadores
• Métodos empíricos – requerem utilizadores

Avaliação analítica

• Não envolve utilizadores
• Rápido
• Recorre a peritos e métodos de inspeção (avaliação heurística) ou 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

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

Modelos preditivos

• Envolvem a análise das operações físicas e mentais que o utilizador tem de realizar para completar uma 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 num teclado; as opções de um menu)

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
• Utilizando questionários de satisfação e entrevistas
• Tipo de estudo (ex):
  • Estudo controlado – testes realizados num laboratório
  • Estudo de campo – testes realizados no ambiente de trabalho do utilizador

Avaliação formativa e sumativa

• Formativa – ocorre várias vezes ao longo do ciclo de vida do projeto
• Sumativa – realizada apenas no final do processo de design

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 (através de cálculos estatísticos)

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

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, conhecidos 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
• Alternativa aos testes com utilizadores – quando não é possível fazê-los
• Complementar a avaliação com utilizadores
• Pode-se utilizar em qualquer fase do processo de design, desde a fase dos protótipos rudimentares até à fase do produto acabado
• Vantagens: rápido, barato, fácil de usar, relação custo-benefício
• Desvantagem: o perito não é o utilizador típico
• Fases da AH: treino pré-avaliação, avaliação, consolidação, balanço

AH – Treino pré-avaliação

• Reunião de treino que junta a equipa de design e os avaliadores
• Equipa de design apresenta a aplicação aos avaliadores, as funcionalidades e cenários de utilização

AH – Avaliação

• Cada avaliador analisa a interface separadamente, registando os problemas encontrados
• Avaliação individual (importante para garantir avaliações independentes que não forem afetadas pelas avaliações de outros avaliadores)
• Tipicamente cada avaliador leva entre 1 a 2 horas a completar a sua avaliação
• Pode estar presente um observador (tomando notas, ajudando o avaliador com a utilização, anotando situações onde o avaliador encontra dificuldades)
• Os avaliadores devem realizar pelo menos duas inspeções à interface
  • Familiarizar-se com o sistema, fluxo das tarefas, vista geral
  • Focarem-se em cada elemento
• Cada avaliador cria uma lista de problemas (descrever e indicar heurística que viola)
• Atribuir um grau de severidade e sugerir uma solução para cada problema
• Cada problema deve ser listado separadamente (mesmo que corresponda ao mesmo elemento da interface)
• Nem todos os problemas têm as mesmas características (ex: severidade, facilidade de correção)

AH – Consolidação

• 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)
• Identificar problemas duplicados ou semelhantes, atribuir severidade final
• O relatório consolidado deve conter também duas tabelas (número de problemas de usabilidade por heurística, número de violações por grau de severidade)

AH – Balanço

• Reunião para discutir os resultados da avaliação e debater possíveis soluções para os problemas de usabilidade encontrados
• Priorizar os problemas de usabilidade com maior severidade
• Podem-se rever os graus de severidade atribuídos aos problemas
• Podem-se discutir algumas caraterísticas gerais da interface
• A equipa de design é responsável por observar o relatório consolidado e definir a ordem de resolução dos problemas (considerando graus de severidade e recursos disponíveis)

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)
• Posso se acrescentar heurísticas específicas da plataforma onde a interface está a ser desenvolvida

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)

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)

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

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 (ex: Salvar/guardar; Botões OK e Cancel)

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)

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 (ex: utilizar listas em vez de se lembrar do código ou nome; símbolos visuais em botões)

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

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

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

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
• Ex: botão de ajuda bem visível; ajuda contextual

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 problema de usabilidade, de acordo com a escala de 0 a 4
• Graus de severidade são determinados tendo em conta a sua frequência, impacto no desempenho dos utilizadores (número de utilizadores afetados, tempo perdido) e a sua persistência (erro isolado ou recorrente)

Avaliadores

• Uma avaliação heurística pode ser feita por apenas um avaliador, mas estudos indicam que a quantidade de problemas 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ão é linear, mas maiores custos
• De acordo com alguns estudos ο 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
• Experiência dos avaliadores afeta o número de problemas encontrados (bons avaliadores identificam problemas fáceis e difíceis, menos bons avaliadores apenas detetam os problemas mais fáceis)

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)

Avaliação preditiva - modelo GOMS

• GOMS (Goals, Operators, Methods and Selection rules)
• Modelo de processamento mental
• Utilizadores atingem objetivos resolvendo subobjetivos ("dividir para conquistar")
• Goals: o que os utilizadores querem atingir (exemplo: apagar uma frase)
  • Objetivos podem ser divididos em subobjetivos (apagar frase → selecionar frase; apagar texto selecionado)
• Operators: processos cognitivos e ações físicas para atingir objetivos
  • Podem afetar apenas o estado mental do utilizador ou o sistema (ex: escolher rato ou teclado para fazer a seleção, carregar na tecla delete, mover o rato)
• Methods: sequências de passos (operadores) necessários
• Selection rules: selecionar qual ο método a utilizar quando existem vários disponíveis para atingir o mesmo objetivo
• Descrição GOMS: objetivo, decomposição em tarefas unitárias, operadores básicos, estratégia utilizada pelos utilizadores, tarefa e domínio do problema
• A análise da descrição GOMS permite obter medidas de desempenho e o número de objetivos pode ser usado para estimar as necessidades da memória de curto prazo
• O modelo GOMS está feito para utilizadores experientes

Avaliação preditiva - modelo KLM

• KLM (Keystroke Level Model)
• Mesmo autores do GOMS
• Modelo físico que prevê o tempo que os utilizadores irão gastar na execução de tarefas simples
• Considera que os utilizadores são peritos
• O método é dado
• Decompõe a fase de execução em: cinco operadores físico-motores, um operador mental e um operador relacionado com a resposta do sistema
• K (físico-motor): premir um tecla. B (físico-motor): carregar botão do rato. P (físico-motor): apontar e mover o rato. H (físico-motor): localizar o rato ou teclado. D (físico-motor): desenhar linhas. M (mental): preparação mental. R (sistema): resposta do sistema

Planeamento dos testes

• Planeamento rigoroso para não desperdiçar tempo/dinheiro
• Preparar tudo com antecedência
• Garantir mesmas condições a todos os utilizadores
• Guião de testes, questionários de recolha de informação, questionários de satisfação, perguntas para a entrevista, vídeos, diapositivos, etc.
• Objetivo do teste: solução mais rápida que a da concorrência? Objetivos estabelecidos no início do desenvolvimento atingidos? Utilizadores cometem menos erros? Utilizadores conseguem realizar mais tarefas?
• Onde: laboratório? sala? local de utilização do sistema?
• Quando: datas e horas? datas/horas para cada utilizador? Duração recomendada: sessão de 1 hora (Introdução, explicação do sistema, realizações das tarefas, preenchimento dos questionários, balanço final)
• Equipamento: desktop? laptop? tablet?
• Software: para além do sistema, são necessários outras aplicações?
• Estado: qual o estado inicial do sistema? Autenticação necessária?
• Tempo de resposta: qual a carga e tempo de resposta do sistema?
• Coordenador e observador: quem conduz e observa?
• Utilizadores: são principiantes ou peritos? quantos homens e mulheres? qual a faixa etária?
• Tarefas: quais? quantidade? por que ordem?
• Fim correto: o que indica o fim da execução de uma tarefa?
• Ajuda: que ajudas estão disponíveis? ajuda digital ou em papel? alguém a ajudar? situações?
• Dados: que dados serão recolhidos e como serão analisados? Que medidas de usabilidade (ex: tempo, erros, número de cliques)?
• Sucesso: qual será ο critério que determina se a interface é um sucesso?

Participantes

• Considerações éticas
  • Tempo: respeitar o tempo dos utilizadores. Fazer testes-piloto.
  • Conforto: ambiente calmo, sem distrações. Clarificar para o utilizador que o sistema está a ser avaliado. Dar uma tarefa de cada vez. Não sobrecarregar com tarefas. A primeira tarefa deve ser simples. Agradecer a participação.
  • Informação: dar toda a informação necessária, não esconder dados desnecessariamente, informar se os utilizadores serão filmados/fotografados ou se há mais observadores.
  • Privacidade: não registar o desempenho para identificar utilizadores. Divulgar resultados mas assegurar que utilizadores especificos não são revelados. Recolha de media sem autorizações.
  • Controlo: os utilizadores devem poder decidir se querem participar nos testes e têm de poder desistir

Que utilizadores?

• Devem representar os potenciais utilizadores do sistema (Público-alvo – faixa etária, sexo; conhecimento das tarefas e do vocabulário)

Testes intergrupo e intragrupo

• Quando há mais do que um sistema em avaliação, a distribuição dos utilizadores pelos sistemas serve para reduzir a influência da aprendizagem em relação ao desempenho
• Testes intergrupos: dividem-se em dois grupos (A e B) com mesmas características, cada grupo usa um sistema, comparam-se os resultados (ex: média), desvantagem exige o dobro dos utilizadores
• Testes intragrupos: utilizadores fazem todos parte do mesmo grupo, metade usa um sistema e a outra metade usa o outro sistema, reduz influência da aprendizagem, compara-se os dados individualmente ao nível dos utilizadores (ex: média das diferenças).

Tarefas

• As tarefas devem ser as mesmas que foram identificadas na análise de tarefas
• No caso da avaliação sumativa, deve-ser cuidado para não escolher as tarefas que favoreçam o primeiro sistema

Medidas de usabilidade

• 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

Testes-piloto

• Realizados com 2-3 pessoas (não precisam de pertencer ao público-alvo).
• Validar todo o processo (guião, instruções, tarefas, tempo).
• As perguntas do questionário e a entrevista devem fazer sentido. As respostas devem ser as esperadas. O fim das tarefas deve ser claro e o tempo estimado deve ser suficiente.
• Vantagens dos testes-piloto: descobrir tempos mortos, alterar partes confusas na explicação do sistema, descobrir tarefas inexequíveis, ajustar tempos de cada tarefa, rever as perguntas do questionário, praticar os papéis de coordenador e observador

Fases da sessão de testes

• Preparação (tudo pronto antes da chegada do utilizador, desligar distrações)
• Introdução (apresentação, objetivos, procedimentos, quem está a ser avaliado)
• Realização do teste (duas pessoas; coordenador e observador). Coordenador: conduzir testes, explicar objetivos, interagir com o utilizador. Observador: tomar notas, observar, comentários, problemas de usabilidade, sugestões, metidas de desempenho
• Balanço (após os testes: pedir dados, comentários, sugestões; discussão, relatório, objetivos da avaliação, breve descrição, ambiente, descrição dos participantes, metodologia, tarefas do teste, lista das medidas de usabilidade, análise dos dados e, finalmente, lista dos problemas encontrados, ordenados por prioridade - tudo documentado)

Bibliografia

• Lista de referências usadas no estudo, incluindo o título "Introdução ao design de interfaces" de Fonseca, Campos e Gonçalves.

Este quiz explora os aspectos fundamentais de testes de usabilidade e como elaborar um relatório eficaz. As perguntas abordam desde os passos a seguir após os testes até as melhores práticas para mensagens de erro e priorização de problemas. Teste seus conhecimentos sobre metodologias e características essenciais na ajuda ao usuário.