Slides em PDF Colorido
Slides em PDF Colorido
Slides em PDF Colorido
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Interacção Hom<strong>em</strong>-Máquina<br />
Avaliação de Usabilidade<br />
Pedro Campos<br />
dme.uma.pt/pcampos<br />
pcampos@uma.pt<br />
Avaliação de Usabilidade<br />
Avaliação Avaliação Avaliação<br />
Análise de<br />
Utilizadores<br />
Análise de<br />
Tarefas<br />
Métricas de<br />
Usabilidade<br />
Design<br />
Conceptual<br />
Design Visual<br />
Fase de Análise<br />
Fase de Design<br />
• Objectivo é testar a usabilidade e funcionalidade do sist<strong>em</strong>a<br />
• Métodos Analíticos<br />
- Avaliação Heurística (avaliação por peritos)<br />
- Avaliação Preditiva (modelos): GOMS, KLM<br />
• Métodos Empíricos (avaliação com utilizadores)<br />
- Requer um protótipo funcional
Avaliação Heurística<br />
• Métodos para avaliar a IU de forma Rápida, Barata e Simples<br />
- Jakob Nielsen, Discount Usability Engineering<br />
• Rápida<br />
- Um dia ou menos para aplicar<br />
• Barata<br />
- Não precisa de laboratórios ou equipamento<br />
• Fácil de Aprender<br />
- pode ensinar-se <strong>em</strong> duas horas ou menos<br />
• Pequeno conjunto de avaliadores (
O Processo de Avaliação Heurística<br />
• Avaliadores “exercitam” a IU várias vezes<br />
- Inspeccionam vários el<strong>em</strong>entos de diálogo<br />
- Comparam com lista de princípios de usabilidade<br />
• Princípios de Usabilidade<br />
- Heurísticas de Nielsen<br />
- Lista supl<strong>em</strong>entar de heurísticas específicas da<br />
categoria<br />
• Usa-se as violações dos princípios para<br />
detectar e corrigir probl<strong>em</strong>as<br />
Heurísticas de Usabilidade<br />
• 1 Tornar o estado do sist<strong>em</strong>a visível<br />
• 2 Falar a linguag<strong>em</strong> do utilizador<br />
• 3 Utilizador controla e livre-arbítrio<br />
• 4 Consistência e adesão às normas<br />
• 5 Evitar Erros<br />
• 6 Reconhecer, <strong>em</strong> vez de l<strong>em</strong>brar<br />
• 7 Flexibilidade e eficiência<br />
• 8 Desenho de ecrã estético e minimalista<br />
• 9 Ajudar o utilizador a reconhecer, diagnosticar e<br />
recuperar dos erros<br />
• 10 Dar ajuda e documentação
Fases da Avaliação Heurística<br />
1. Treino pré-avaliação<br />
• Dar conhecimento aos avaliadores da funcionalidade<br />
• Informação sobre cenários de interacção<br />
2. Avaliação<br />
• Individual, seguida de consolidação de resultados<br />
3. Classificação de severidade<br />
• Determinar a gravidade de cada probl<strong>em</strong>a (prioridade)<br />
• Pode-se fazer primeiro individualmente e depois <strong>em</strong> grupo<br />
4. Relato (Debriefing)<br />
• Discutir resultados com a equipa de projecto<br />
Como conduzir a avaliação<br />
• Pelo menos dois passos por avaliador<br />
- Primeiro para familiarizar com a aplicação<br />
- Segundo para focar <strong>em</strong> el<strong>em</strong>entos específicos<br />
• Sist<strong>em</strong>as “Walk-up & Use” não requer<strong>em</strong> assistência<br />
- Senão, deve-se fornecer cenários de utilização<br />
• Cada avaliador produz lista de probl<strong>em</strong>as<br />
- Explicar com referência à heurística relevante ou outra informação<br />
- Ser específico<br />
- Listar cada probl<strong>em</strong>a <strong>em</strong> separado<br />
- Sugerir solução
Ex<strong>em</strong>plo de Probl<strong>em</strong>as<br />
• Probl<strong>em</strong>a: Campo da data não indica formato<br />
- Viola H-5 ( “Evitar erros” )<br />
- Correção: Substituir campo por calendário<br />
• Probl<strong>em</strong>a: Tipografia mistura letra maiúscula e minúscula e tipos<br />
- Viola H-4 ( “Consistência e adesão às normas” )<br />
- atrapalha utilizadores<br />
- talvez não fosse identificado por testes de utilização<br />
- Correcção: Usar um só tipo <strong>em</strong> toda a interface<br />
Como relatar (Debriefing)<br />
• Sessão com avaliadores, observadores e<br />
equipa de projecto<br />
• Discutir características gerais da IU<br />
• Sugerir possíveis melhoramentos para<br />
resolver os principais probl<strong>em</strong>as de<br />
usabilidade<br />
• Equipa de projecto avalia os custos de corrigir<br />
cada probl<strong>em</strong>a<br />
• Sessão de brainstorming<br />
- Minimizar críticas negativas durante o exercício
Ex<strong>em</strong>plo de Classificação<br />
• Nomes diferentes para a operação “Guardar”<br />
- H-4: Consistência<br />
- Descrição: a interface usa “Salvaguardar” no primeiro ecrã para salvaguardar<br />
ficheiro do utilizador mas usa “Guardar Ficheiro” nos ecrãs subsequentes. O<br />
uso de terminologia diferente para a mesma função pode confundir os<br />
utilizadores.<br />
- Correção: definir uma terminologia e usá-la s<strong>em</strong>pre<br />
- Severidade: 3<br />
Inspecções Colaborativas*<br />
• Revisão estruturada da usabilidade de um produto, com<br />
el<strong>em</strong>entos das técnicas heurísticas, pluralísticas e cognitivas<br />
- Identifica os defeitos da IU e inconsistências<br />
- Designers, programadores, Utilizadores e peritos de usabilidade colaboram<br />
- Papéis são atribuídos, regras sist<strong>em</strong>áticas e processo estruturado tornam-na<br />
eficiente e fiável<br />
- Utilizada com protótipos abstractos, protótipos <strong>em</strong> papel, simulações,<br />
software beta... e repetidamente!<br />
- É possível encontrar 100 defeitos / hora, com experiência<br />
* Constantine & Lockwood
Inspecções Colaborativas<br />
Uma inspecção colaborativa de usabilidade é um processo de inspecção!<br />
O objectivo é encontrar defeitos de usabilidade<br />
Em maior número possível, o mais eficient<strong>em</strong>ente possível<br />
Não é suposto desenhar, debater ou elogiar<br />
designers ou programadores<br />
Mas é boa ideia registar as features que vale a pena preservar<br />
Os defeitos identificados pod<strong>em</strong> ou não ser resolvidos<br />
O redesenho é um probl<strong>em</strong>a distinto para designers e programadores<br />
A escolha sobre corrigir ou não corrigir é uma decisão de negócio<br />
O que é um Defeito de Usabilidade<br />
• Um defeito de usabilidade é um potencial probl<strong>em</strong>a na operação,<br />
aparência ou organização de um sist<strong>em</strong>a que torna o produto final<br />
mais difícil de usar pela população de utilizadores alvo<br />
• Operacionalmente, um defeito é:<br />
- uma violação clara e evidente dos princípios de usabilidade dados como<br />
aceites (princípios como as heurísticas de Nielsen)<br />
- uma causa provável de atraso na execução das tarefas, confusão ou erros<br />
Não é algo que pensamos não gostar!
Graus de severidade dos Defeitos<br />
1. nominal: algo de aborrecido, ligeiramente incorrecto, atraso<br />
insignificante ou pouco frequente, ou pequena probabilidade de<br />
erro do utilizador<br />
2. minor: existe uma hipótese de que o probl<strong>em</strong>a irá afectar o<br />
des<strong>em</strong>penho, perturbar a aprendizag<strong>em</strong> ou aumentar de alguma<br />
forma os erros do utilizador<br />
3. major: quando algumas tarefas são substancialmente mais difíceis<br />
de executar ou aprender; a probabilidade de erro é grande<br />
4. critical: defeito óbvio, significativo, reduz a usabilidade geral do<br />
sist<strong>em</strong>a ou torna o produto substancialmente mais difícil de usar<br />
Sample Defect Logging Card<br />
Formulários ou checklists facilitam e aceleram o registo dos defeitos
Cenários de Utilização para<br />
Inspecções<br />
• Os cenários de inspecção são ex<strong>em</strong>plos completos de utilização<br />
• Organizam o processo de inspecção combinando tarefas básicas<br />
num coerente e correcto guião<br />
• Pod<strong>em</strong> misturar tarefas comuns ou representativas com<br />
interacções excepcionais ou não-usuais, ou eventos de interesse<br />
• Asseguram que a avaliação é realizada no contexto das tarefas<br />
representativas<br />
• Os utilizadores representam os cenários declarando ou<br />
descrevendo acções ou possíveis acções<br />
• Cenários b<strong>em</strong> estruturados cobr<strong>em</strong> um subconjunto planeado da<br />
IU<br />
Das Tarefas aos Cenários<br />
Tarefas discretas ou casos de utilização (essential use cases):<br />
Cenários de Inspecção:<br />
Você quer ver uma determinada<br />
cena de um filme favorito numa<br />
cassette usada. Obtenha uma imag<strong>em</strong><br />
estável ajustando o tracker, encontre<br />
o início da cena e faça play.<br />
avançando para a secção seguinte<br />
retrocedendo para a secção anterior<br />
escolhendo uma determinada cena<br />
ajustando a qualidade de imag<strong>em</strong><br />
gravando um programa futuro<br />
acertando o relógio...<br />
Quer gravar a Floribela 3 dias<br />
seguidos. Você repara que se esqueceu<br />
de acertar o relógio. Acerta-o e depois<br />
programe o vídeo para as gravações.
Definindo os Cenários<br />
• Os cenários são ex<strong>em</strong>plos completos de utilização<br />
• A partir de um modelo de tarefas baseado <strong>em</strong> casos de utilização e<br />
capacidades a ser<strong>em</strong> avaliadas, escolhe-se tarefas para incluir no<br />
cenário:<br />
representativas ou típicas<br />
comuns ou frequentes<br />
críticas ou essenciais<br />
especiais ou excepcionais<br />
• Dispostas <strong>em</strong> combinações plausíveis e prováveis<br />
• Num guião plausível que faça sentido para o utilizador<br />
• Escreve-se uma narrativa que fornece contexto e motiva o utilizador<br />
Dirigir-se ao utilizador na linguag<strong>em</strong> do domínio e <strong>em</strong> termos<br />
de objectivos e intenções, não <strong>em</strong> passos ou acções concretas!<br />
Papéis das Inspecções<br />
• Lead Reviewer<br />
- Coordena a inspecção, conduz a reunião, segue a agenda e o método<br />
- Mantém o processo <strong>em</strong> movimento, faz todos participar<strong>em</strong><br />
- Protege os utilizadores, controla os programadores<br />
• Inspection Recorder<br />
- Regista os defeitos e inconsistências<br />
- Atribui os graus de severidade iniciais (estimados)<br />
- Separadamente regista features boas, possíveis soluções de design, objecções<br />
e opiniões minoritárias<br />
- Organiza, distribui e arquiva os registos
Papéis das Inspecções<br />
• Continuity Reviewer<br />
- Responsabilidade primária: identificar inconsistências na aparência ou<br />
comportamento da interface toda<br />
- Pode também identificar violações às normas<br />
- Pode monitorizar critérios especiais, p.e. regulações governamentais,<br />
requisitos não-funcionais, conformidade aos princípios...<br />
• Usability Specialist<br />
- Designer IHM, especialista <strong>em</strong> usabilidade, especialista <strong>em</strong> ergonomia...<br />
- Assiste o Recorder no que diz respeito à classificação dos defeitos de<br />
usabilidade e estimação dos graus de severidade<br />
- Papel de consultor<br />
- É mau sinal se for frequent<strong>em</strong>ente ignorado<br />
Papéis das Inspecções<br />
• Utilizadores<br />
- Actuam os cenários, comentam primeiro<br />
- Há que encorajá-los, ouvir, tentar compreender<br />
- Apontar ideias e comentários, seguir <strong>em</strong> frente<br />
- Os utilizadores não são designers n<strong>em</strong> têm a palavra final<br />
• Programadores<br />
- Nunca dev<strong>em</strong> explicar ou defender um design<br />
- Nunca dev<strong>em</strong> discutir com os utilizadores<br />
- Nunca dev<strong>em</strong> fazer promessas aos utilizadores
Desenvolvimento baseado na<br />
Arquitectura primeiro!<br />
• PSQ Mínimo! (PSQ Preciso Saber o Quê)<br />
• Design iterativo<br />
- Baseado na análise dos utilizadores, tarefas, design abstracto, mapas de navegação<br />
• Refactoring da arquitectura da IU conforme necessário<br />
Utilizando os Utilizadores<br />
• Mesmo sob pressão, deve-se envolver os utilizadores<br />
• Todo o t<strong>em</strong>po gasto construindo o sist<strong>em</strong>a erradoou<br />
programando as funções erradas é desperdiçado<br />
• Capturar os papéis dos utilizadores b<strong>em</strong> cedo<br />
• Focar-se no Porquê Não deixar que os utilizadores orden<strong>em</strong><br />
no Que parece a IU n<strong>em</strong> Como funciona<br />
• Usar o t<strong>em</strong>po dos utilizadores e programadores de forma<br />
eficiente<br />
• Envolver os utilizadores, mas não <strong>em</strong> tudo! Apenas no que é<br />
importante:<br />
- requisitos, features e proprieades, inspecções de usabilidade, testes de campo
Testes Estatísticos<br />
• Métrica de des<strong>em</strong>penho: Execução < 30 min.<br />
• Teste com 6 utilizadores<br />
- Teste dá: 20, 15, 40, 90, 10, 5<br />
- Média = 30<br />
- Desvio padrão = 32<br />
- Parece OK !<br />
- Errado, nada se pode afirmar!<br />
• Factores que contribu<strong>em</strong> para esta incerteza:<br />
- Pequeno nº de utilizadores no teste (N = 6)<br />
- Resultados muito variáveis (desvio padrão = 32)<br />
• Desvio padrão = dispersão do valor médio [-2; 62]<br />
Testes Estatísticos<br />
• Experimentação Controlada<br />
- Responder a:<br />
• Solução A melhor que Solução B<br />
• Solução cumpre os objectivos<br />
• Procedimento:<br />
- Escolha da população significativa<br />
- Formulação da hipótese nula (H0)<br />
- Realização dos testes<br />
- Conclusão
Grandezas Estatísticas<br />
• Média<br />
• Soma dos quadrados das diferenças<br />
• Graus de liberdade<br />
• Variância<br />
• Desvio padrão<br />
Comparar duas alternativas<br />
• Experiência entre-grupos<br />
- Dois grupos de teste<br />
- Cada grupo usa apenas um dos sist<strong>em</strong>as (ou condições)<br />
• Experiência intra-grupos<br />
- Um grupo de utilizadores<br />
• Cada pessoa usa ambos os sist<strong>em</strong>as<br />
• Não pod<strong>em</strong> usar as mesmas tarefas ou pela mesma ord<strong>em</strong><br />
(aprendizag<strong>em</strong>)<br />
- Melhor para técnicas de interacção básicas<br />
• Entre-grupos requer muitos mais participantes<br />
• Ver se as diferenças são estatisticamente significativas<br />
- Assume distribuição normal e mesmo desvio padrão
Comparar duas amostras - Teste-t<br />
• Objectivo: determinar qual das duas é melhor<br />
- Variância combinada<br />
- Desvio padrão da diferença<br />
- Valor de t<br />
• Se t > t(H0) (da tabela)<br />
- então H0 é falsa (para alfa)<br />
Ex<strong>em</strong>plo: Bilheteira<br />
• Hipótese nula:<br />
- a forma de aquisição do bilhete não t<strong>em</strong> influência no t<strong>em</strong>po de tarefa<br />
• Medidas<br />
- bilheteira: 28, 35, 23, 26, 30, 32 segundos<br />
- máquina: 32, 41, 37, 40, 30 segundos<br />
• Médias<br />
- bilheteira: 27 segundos<br />
- máquina: 36 segundos
Teste-t - Bilheteira<br />
Teste-t - Bilheteira<br />
• Constata-se que:<br />
- as duas amostras têm uma probabilidade de (apenas) 3,6% ser<strong>em</strong> a mesma<br />
amostra<br />
- rejeita-se H0 pois 0.036 < 0.05 (nível de significância p)<br />
• Conclusão:<br />
- a compra de bilhetes <strong>em</strong> máquina é 33% (36/29) mais lenta com uma<br />
probabilidade de 96,4%
Intervalo de Confiança<br />
• Testar uma amostra contra um dado valor limite<br />
• Intervalo de confiança<br />
- 2 extr<strong>em</strong>os entre os quais toda uma população está compreendida com uma<br />
dada probabilidade<br />
• Ex<strong>em</strong>plo<br />
- Uma operação não deve d<strong>em</strong>orar mais do que 25s -> intervalo totalmente<br />
abaixo de 25s<br />
Intervalo de Confiança<br />
• Calcular variância<br />
• Desvio padrão da média<br />
• Determinar t unicaudal para a probabilidade pretendida e grau de<br />
liberdade da amostra<br />
• O intervalo estará compreendido entre<br />
e
Ex<strong>em</strong>plo: Intervalo de Confiança<br />
• Nº de erros, métrica: menos que 5 erros<br />
• Amostra: 13, 6, 8, 11<br />
• Média: 9.5, Variância: 9.67<br />
• Desvio padrão da média: 1.55<br />
• H0: nº de erros superior a 15<br />
• Para p=0.05<br />
t=2.355 (da tabela)<br />
• Intervalo:<br />
- x min = 9.5 - 2.355 x 1.55 = 5.85<br />
- x max = 9.5 + 2.355 x 1.55 = 13.15<br />
• Intervalo abaixo de 15<br />
- Rejeita-se H0: o nº de erros é inferior a 15 com 95% de certeza<br />
Teste do Chi-Quadrado<br />
• Dados correspondentes a uma ou mais categorias<br />
- Exº determinar preferência entre várias opções de escolha<br />
• Procedimento:<br />
- calcula-se a diferença entre as frequências observadas e as<br />
frequências esperadas
Ex<strong>em</strong>plo: Teste do Chi-quadrado<br />
• Qual a opção preferida de entre as três<br />
• H0 = preferência igual pelas três<br />
Opção f esperada f observada Diferença<br />
Quad. da<br />
diferença<br />
/ f esp.<br />
A 10 5 -5 25 2.5<br />
B 10 16 6 36 3.6<br />
C 10 9 -1 1 0.1<br />
• 30 utilizadores<br />
• Graus de liberdade: N = 3 – 1 = 2<br />
• Da tabela obt<strong>em</strong>os 5.99 para p=0.05<br />
x Rejeita-se H0 (5.99 < 6.2)<br />
Exercício:<br />
Desenhe uma experiência para testar se adicionar codificação com<br />
cores irá aumentar a precisão de uma interface.<br />
• Sujeitos experimentais:<br />
- os mais próximos possíveis da população de utilizadores<br />
• Hipótese: a codificação com cores irá tornar a selecção mais precisa<br />
• Variável Independente: codificação com cores<br />
•<br />
Variável Dependente: precisão da interface, medida como o número de erros<br />
• Design: entre-grupos, para assegurar que não há transferência de aprendizag<strong>em</strong> (se<br />
não houver sujeitos suficientes, utilizar intra-grupos)<br />
• Tarefa: interfaces idênticas nas 2 condições, só que na segunda a cor é adicionada.<br />
Apresenta-se aos sujeitos um ecrã com escolhas (ordenadas aleatoriamente) e<br />
indicamos o que dev<strong>em</strong> escolher verbalmente. Há um limite de t<strong>em</strong>po para a selecção.<br />
Conta-se um erro por cada selecção incorrecta ou não realizada.<br />
• Análise: teste-t
Ex<strong>em</strong>plo<br />
• Imagine que está a desenhar um novo programa de processamento<br />
de texto e pretende usar ícones. Está a considerar utilizar um de<br />
dois estilos de ícones: naturais vs. abstractos. Quer saber qual o<br />
design que fará com que os utilizadores melhor se record<strong>em</strong>.<br />
Naturais:<br />
Abstractos:<br />
cut copy paste cut copy paste<br />
• Primeira coisa:<br />
- formular uma hipótese (a hipótese nula):<br />
• Os utilizadores irão l<strong>em</strong>brar-se dos ícones naturais mais facilmente do que<br />
dos abstractos<br />
Ex<strong>em</strong>plo<br />
• Variável Independente:<br />
- t<strong>em</strong> dois níveis: natural / abstracto<br />
• Variável Dependente:<br />
- número de erros na selecção e t<strong>em</strong>po de selecção de um ícone<br />
• Assumimos que a velocidade com que o utilizador selecciona um<br />
ícone é uma indicação da facilidade de l<strong>em</strong>brança do ícone!<br />
• Design de uma tarefa e recolha dos t<strong>em</strong>pos
Ex<strong>em</strong>plo: t<strong>em</strong>pos de conclusão das tarefas<br />
sujeito nº<br />
ord<strong>em</strong> de<br />
apresentação<br />
Naturais (1)<br />
Abstractos<br />
(2)<br />
Média do<br />
sujeito (3)<br />
Natural<br />
(1) - (3)<br />
Abstracto<br />
(2) - (3)<br />
1 AN 656 702 679 -23 23<br />
2 AN 259 339 299 -40 40<br />
3 AN 612 658 635 -23 23<br />
4 AN 609 645 627 -18 18<br />
5 AN 1049 1129 1089 -40 40<br />
6 NA 1135 1179 1157 -22 22<br />
7 NA 542 604 573 -31 31<br />
8 NA 495 551 523 -28 28<br />
9 NA 905 893 899 6 6<br />
10 NA 715 803 759 -44 44<br />
média 698 750 724 -26 26<br />
desvio p. 265 259 262 14 14<br />
estas médias pod<strong>em</strong> ser comparadas com um teste-t!<br />
Ex<strong>em</strong>plo: t<strong>em</strong>pos de conclusão das tarefas<br />
média 698 750 724 -26 26<br />
desvio p. 265 259 262 14 14<br />
A diferença entre as médias é de 52 segundos, mas o erro standard<br />
da diferença é 117 segs.:<br />
o erro s. dif. é uma medida da variabilidade esperada da<br />
diferença entre as médias. Testando o rácio 52/117 na tabela<br />
t-Student, concluimos que a diferença não é significativa.<br />
... contudo, se olharmos para a tabela, v<strong>em</strong>os que <strong>em</strong> quase todos<br />
os casos, o t<strong>em</strong>po de execução com os ícones abstractos é quase<br />
s<strong>em</strong>pre superior ao t<strong>em</strong>po com os ícones naturais... (a variação<br />
entre os indivíduos “escondeu” o efeito).
Resumo:<br />
factores a considerar na escolha de um método de avaliação<br />
• when in cycle is evaluation carried out design vs impl<strong>em</strong>entation<br />
• what style of evaluation is required laboratory vs field<br />
• how objective should the technique be subjective vs objective<br />
• what type of measures are required qualitative vs quantitative<br />
• what level of information is required High level vs low level<br />
• what level of interference obtrusive vs unobtrusive<br />
• what resources are available time, subjects, equipment, expertise<br />
Leitura<br />
• http://www.meandeviation.com/tutorials/stats/<br />
• Cap. 11 do livro principal
Change language