Apoio ao estudo

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

Nuno Rodrigues
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
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.

37
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

38
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

39
5 – Prevenção de erros

40
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

41
6 – Reconhecimento em vez de
lembrança

42
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

43
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

44
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

47
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

48
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
a4

49
 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

50
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

51
Graus de severidade

52
 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

53
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

54
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

55
 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)

56
 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)

57
Avaliação preditiva – modelo GOMS

●
GOMS (Goals, Operators, Methods and Selection rules)
●
Modelo de processamento mental
●
Utilizadores atingem objetivos resolvendo subobjetivos
(“dividir para conquistar”)

58
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)

59
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)

60
 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 ]

61
 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

62
 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

63
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

64
Avaliação preditiva – modelo GOMS

65
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

66
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

67
 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)

68
 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

69
Avaliação preditiva – modelo KLM

70
Avaliação preditiva – modelo KLM

71
Avaliação preditiva – modelo KLM

72
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

73
Métodos de avaliação com utilizadores

●
Entrevistas de grupo
●
Observação direta
●
Questionários ou entrevistas
●
“Pensar em voz alta”
●
Observação indireta

74
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

75
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

76
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

77
 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

78
Testes com utilizadores - SUS

79
Testes com utilizadores – SUS (PT)

80
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:

81
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

82
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

83
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.

84
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?

85
Planeamento dos testes

●
Onde
– Laboratório?
– Sala?
– No local onde será utilizado o sistema?

86
Planeamento dos testes

●
Quando
– Datas e horas?
– Datas/horas para cada utilizador?

87
 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

88
Planeamento dos testes

●
Equipamento
– Desktop?
– Laptop?
– Tablet?
– ...

89
Planeamento dos testes

●
Software
– Para além do sistema, são necessários outras aplicações (ex:
calculadora, processador de texto, etc.)?

90
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?

91
Planeamento dos testes

●
Tempo de resposta
– Qual a carga e tempo de resposta do sistema onde corre a
nossa aplicação?

92
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?

93
Planeamento dos testes

●
Utilizadores
– Serão principiantes ou peritos?
– Quantos homens e quantas mulheres?
– Qual a faixa etária?

94
Planeamento dos testes

●
Tarefas
– Quais?
– Quantidade?
– Por que ordem?

95
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ã?

96
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?

97
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)?

98
Planeamento dos testes

●
Sucesso
– Qual será(ão) o(s) critério(s) que ditará(ão) que a interface é
um sucesso?

99
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

100
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

101
 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

102
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”

103
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

104
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

105
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

106
Testes intergrupo e intragrupo

●
Quando está mais do que um sistema em avaliação (em
concorrência)

107
 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

108
 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

109
Quantos utilizadores?

●
Depende do tipo de avaliação (formativa/sumativa)
●
Depende da disponibilidade
●
Depende do tempo disponível
●
Depende do orçamento

110
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

111
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

112
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

113
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

114
 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

115
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
●
...

116
 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

117
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.)

118
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

119
 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

120
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

121
 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
– ...

122
 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

123
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

124
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

125
Bibliografia

●
Fonseca, M., Campos, P. e Gonçalves D., “Introdução ao
design de Interfaces”, FCA Editora, 2017

126