Testes de Usabilidade e Relatórios

Podcast

Play an AI-generated podcast conversation about this lesson

Questions and Answers

Qual é o primeiro passo a ser realizado após os testes de usabilidade serem concluídos?

Discutir os resultados com a equipe de desenvolvimento

Pedir ao utilizador que preencha um questionário de satisfação (correct)

Redigir um relatório detalhado sobre o teste

Agradecer aos utilizadores pela sua participação

Qual informação deve ser verificada após a saída do utilizador que participou do teste?

Se a metodologia utilizada foi eficaz

Se o sistema funcionou corretamente durante o teste

Se os participantes estão satisfeitos com o sistema

Se toda a informação recolhida está corretamente identificada com o utilizador (correct)

O que deve ser incluído em um relatório de usabilidade?

Lista de funcionários que participaram do teste

Descrição detalhada do sistema e tarefas realizadas (correct)

Feedback dos desenvolvedores sobre o sistema

Planos de atualizações futuras do sistema

O que é essencial ao redigir um relatório de usabilidade?

Listar todos os problemas encontrados ordenados por prioridade Signup and view all the answers

Quais metodologias devem ser descritas em um relatório de testes de usabilidade?

Metodologia de coleta de dados utilizada durante os testes Signup and view all the answers

Qual é a melhor prática para mensagens de erro em um sistema?

Utilizar linguagem que o utilizador compreenda. Signup and view all the answers

Quais características devem ser consideradas na ajuda e documentação de um sistema?

Facilidade de pesquisa e foco na tarefa. Signup and view all the answers

Como deve ser abordada a priorização de problemas de usabilidade?

Problemas devem ser atribuídos de acordo com seu grau de severidade. Signup and view all the answers

Qual é um exemplo de design minimalista?

Interface limpa com opções limitadas e foco no essencial. Signup and view all the answers

Qual é a principal vantagem de reconhecer em vez de lembrar?

Reduz a carga cognitiva do utilizador. Signup and view all the answers

O que caracteriza um problema de severidade 2?

Tem prioridade baixa e deve ser corrigido se houver tempo. Signup and view all the answers

Qual dos seguintes não é um princípio de ajuda ao utilizador?

Deixar o utilizador sem opções de assistência. Signup and view all the answers

Qual é a implicação de cada unidade de informação competindo num diálogo?

A importância relativa da informação diminui. Signup and view all the answers

Qual dos seguintes aspectos deve ser considerado na prevenção de erros durante uma sessão de testes?

Proporcionar feedback imediato ao utilizador Signup and view all the answers

Ao implementar reconhecimento em vez de lembrança, qual das seguintes estratégias é mais eficaz?

Utilizar menus e botões visíveis que apresentem opções Signup and view all the answers

Qual das afirmações é correta em relação à flexibilidade e eficiência de uso em testes?

Os utilizadores devem ter opções para personalizar sua experiência Signup and view all the answers

Qual é uma característica importante de estética e design minimalista em uma interface?

Informação organizada de forma clara e concisa Signup and view all the answers

O que deve ser incluído na documentação de ajuda para garantir suporte aos utilizadores?

Ajuda acessível tanto digitalmente quanto em papel Signup and view all the answers

Na fase de testes, qual deve ser um dos critérios para determinar o sucesso de uma interface?

O número total de cliques necessários para completar uma tarefa Signup and view all the answers

Durante os testes com utilizadores, qual a importância de conhecer o estado do sistema?

Para garantir que todos os utilizadores tenham a mesma experiência Signup and view all the answers

Qual é uma consideração importante ao planejar as tarefas para uma sessão de testes?

Definir a ordem e a quantidade de tarefas a serem realizadas Signup and view all the answers

Study Notes

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.

Studying That Suits You

Use AI to generate personalized quizzes and flashcards to suit your learning preferences.

Description

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.