2. Iremos iniciar o estudo de alguns métodos de avaliação de
IHM, sendo eles:
• Avaliação através de inspeção;
• Avaliação através de observação;
• Avaliação Heurística.
Introdução
4. Avaliações de IHC não são testes de
software!
Servem para verificar se o sistema apoia o
usuário a atingir seus objetivos.
5. • Determinar o valor de algo.
• Apreciar.
• Julgar.
• Ponderar, examinar, considerar.
• Calcular, estimar.
O que é avaliar?
6. É uma atividade profissional especializada:
• Não é uma emissão de opinião;
• Não é baseada em preferências ou conjecturas.
• Tem por objetivo julgar a qualidade de interação de um
sistema ou artefato computacional:
• Usuário sempre têm opiniões e julgamentos, mas isso
não é uma avaliação de IHM.
O que é avaliação de IHM?
7. A realização de uma atividade profissional depende de
conhecimentos técnicos.
Conhecimentos requeridos:
• Conceitos de IHM;
• Métodos de avaliação;
• Modos e meios de aplicação de conceitos e métodos;
• Disciplina e rigor para realizar a coleta de dados;
• Cuidados éticos.
Definição de uma atividade profissional
8. O sistema sempre será avaliado, ao menos informalmente,
toda vez que um usuário utilizá-lo.
Logo, precisamos:
• Consertar problemas antes e não depois do lançamento
do projeto;
• Colocar a questão humana em meio à exatidão da área de
computação;
• Comercializar produtos mais sólidos no mercado.
Importância da avaliação em IHM
Avaliação Contínua
9. Aspectos cognitivos e funcionais relativos à realização das
tarefas apoiadas pelo sistema:
É rápido? - Velocidade
É fácil aprender? - Facilidade de aprendizado
O sistema é confiável e opera de maneira consistente?-
Confiabilidade
Permite reverter facilmente erros cometidos? - Capacidade
de desfazer ações
Permite ser lembrado depois de algum tempo sem usar? -
Memorabilidade
O que devemos avaliar?
10. • Verificar o entendimento dos projetistas sobre as
necessidades e preferências do usuário;
• Investigar como a interface afeta a forma de trabalho;
• Comparar alternativas de interação ou de interface;
• Identificar problemas potenciais ou reais;
• Verificar conformidade com um padrão ou conjunto de
heurísticas;
• Elaborar material de apoio e treinamento.
Objetivos da avaliação
11. • Rápido e rasteiro
▪ Prima pela informalidade
• Testes de usabilidade
▪ Experimentos controlados
• Estudos de campo
▪ São realizados nos contextos naturais de uso das
tecnologias avaliadas
• Avaliação preditiva
▪ Baseada em conhecimento heurístico ou teórico de
um avaliador especialista
Paradigmas para a avaliação de IHM
12. Prática comum no design de IHM.
Designers pedem apreciações formais do que fizeram ou
estão fazendo.
São avaliações literalmente rápidas e, por isso, podem se
repetir em vários pontos do ciclo de desenvolvimento.
Oferecem feedback imediato, mas não são muito
cuidadosas e informativas.
O paradigma“Rápido e rasteiro”
13. Toda boa avaliação deve ser guiada por objetivos e
questões claras , pois, do contrário, existirá grande
chance do trabalho ser uma perda de tempo.
14. Podemos não envolver usuários, apenas“advogar”por
eles:
▪ Avaliação por Inspeção (inspeção de interface)
Podemos envolver usuários, observá-los e entrevistá-los:
▪ Avaliação por Observação (teste de interface)
Abordagens para Avaliação
15. • A inspeção é feita por um especialista:
▪ Inspeção baseada em conhecimento prático e/ou
teórico.
• Tentaantever as consequências de decisões de design.
• A Avaliação Heurística é um exemplo de avaliação por
inspeção.
• No caso de produtos:
▪ Inspecionar as características do artefato.
• No caso de processos:
▪ Inspecionar as condições de uso do artefato.
Avaliação por Inspeção
16. • Há o envolvimento de usuários:
▪ Com ou sem apoio de tecnologia.
• Coleta dados sobre situações em que os participantes realizam
suas
atividades:
▪ Em laboratório;
▪ Em campo.
• Identifica problemas reais e não apenas problemas
potencialmente previstos.
• Ex: Teste de Usabilidade, Avaliação da Comunicabilidade,
Prototipação em papel.
Avaliação por Observação
17. • Método de inspeção:
▪ Não envolve usuários;
▪ Realizada por um especialista.
• Baseada em conhecimento prático:
▪ Princípios gerais de bom design de interfaces.
• Proposta por Jacob Nielsen em 1994 (material disponível
em
www.useit.com/papers/heuristic).
• O avaliador identifica situações onde uma ou mais das
“10 heurísticas de Nielsen”é violada.
Avaliação Heurística
18. • Os usuários devem ser mantidos informados sobre o que
está acontecendo e no tempo real
1- Visibilidade do Estado do Sistema
19. • O sistema deve utilizar palavras, expressões e conceitos que
são familiares ao usuário.
• Ex: o programa CSE HTML Validator v3.05 verifica erros de
sintaxe em documentos HTML, não deixando claro o que cada
“flag” significa.
2 – Correspondência entre o sistema e o
mundo real
20. • O sistema precisa fornecer alternativas para o usuário
sair de uma situação indesejada.
3 – Controle e liberdade do usuário
21. • O design deve seguir as convenções da plataforma ou do
ambiente computacional.
• No programa abaixo, a cor dos textos estáticos e dos botões (ou
do próprio painel) foge do padrão do ambiente computacional.
4 – Consistência e padronização
22. • A interface deve apresentar claramente os objetos,
ações e opções, pois o usuário não deve precisar
“decorar” formas de acionamento do sistema. No
exemplo abaixo, a ordenação da lista está no menu
“Table”.
5 – Reconhecimento em vez de memorização
23. • As ações de interface devem ter diferentes formas de
ser acionadas.
• Ex: além de fazer uso excessivo de abas, o que diminui a
eficiência, as categorias são acessadas apenas com o
mouse.
6 – Flexibilidade e eficiência de uso
24. • A interface não deve conter informação irrelevante ou
raramente necessária, deve-se manter“clean”.
• Ex: mais de uma heurística pode ser violada em uma
mesma situação.
7 – Projeto estético e minimalista
25. • O sistema deve evitar que enganos e erros ocorram, sempre
que possível.
7 – Projeto estético e minimalista
8 – Prevenção de erros
26. • O sistema deve ter mensagens de erros claras e informativas,
que ajudem a entender o que houve e reparar erros.
9 – Ajude os usuários a reconhecerem,
diagnosticarem e se recuperarem de erros
27. • Acesso rápido e claro a conteúdo informativo, focado na
tarefa do usuário.
10 - Ajuda e Documentação
28. • Recomenda-se envolver de 3 a 5 avaliadores.
• Atividades:
1) Preparação;
2) Coleta de dados;
3) Interpretação;
4) Consolidação dos resultados;
5) Relato dos resultados.
Aplicação da Avaliação Heurística
29. • Preparação:
▪ Todos os avaliadores aprendem sobre a situação atual
e selecionam as partes da interface que devem ser
avaliadas.
• Coleta de dados e Interpretação:
▪ Cada avaliador inspeciona a interface para
identificar violações das heurísticas, indicando
local, gravidade, justificativa e recomendações
de solução.
Aplicação da Avaliação Heurística
30. • Local do problema:
▪ Em um único local?
▪ Em dois ou mais locais?
▪ Na estrutura geral da interface?
▪ Não está lá! Precisa ser incluído.
• Severidade ou gravidade do problema:
▪ Frequência: 1) comum, 2) raro
▪ Impacto: 1) fácil superação, 2) difícil superação
▪ Persistência: 1) uma vez e é superado, 2) atrapalhará muitas
vezes
▪ Severidade: 1)cosmético, 2)pequeno, 3)grande, 4)catastrófico
Coleta de dados e Interpretação
31. • Consolidação dos resultados e Relato dos resultados:
▪ Todos os avaliadores revisam os problemas
encontrados, julgam suas interpretações e geram um
relatório consolidado.
Aplicação da Avaliação Heurística
33. Método de avaliação por inspeção:
• Não envolve usuários.
• Realizada por um especialista.
Baseado na Engenharia Semiótica:
• Teoria que investiga a comunicação entre designers,
usuários e sistemas.
Avalia a comunicabilidade de uma solução de IHM.
Inspeção Semiótica
34. Considera o ponto de vista do designer.
Inspeciona a interface para identificar, interpretar e
analisar os signos contidos na mesma.
Faz um julgamento da comunicabilidade por meio da
análise dos signos.
Papel do avaliador
35. Signos estáticos:
• Comunicam o seu significado integral em telas fixas
(estáticas) do sistema.
Signos dinâmicos:
• Comunicam o seu significado em sequências de
telas ou com o tempo (dinamicamente).
Signos metalinguísticos:
• Explicam ou ilustram outros signos estáticos e
dinâmicos.
Tipos de Signos
36. Não precisa mais que um avaliador; caso mais de um
esteja envolvido, eles devem trabalhar em conjunto.
Atividades:
1)Preparação;
2)Coleta de dados;
3)Interpretação;
4)Consolidação dos resultados;
5)Relato dos resultados.
Aplicação da Inspeção Semiótica
37. • Identificar perfis de usuários.
• Identificar objetivos apoiados pelo sistema.
• Definir as partes da interface que serão avaliadas.
• Escrever cenários de interação para guiar a avaliação
(chamado “cenário de inspeção”).
Preparação
38. • Inspecionar a interface simulando interações conforme
o cenário.
• Analisar os signos metalinguísticos.
• Analisar os signos estáticos.
• Analisar o signos dinâmicos.
Coleta dos dados e interpretação
47. • O usuário poderia interpretar este signo ou esta
mensagem diferente do previsto pelo designer? Como?
Por quê?
• Essa outra interpretação ainda seria consistente com a
interação do designer (cenário de interação)?
• É possível formar classes de signos estáticos e dinâmicos
a partir das análises realizadas? Quais?
Perguntas que auxiliam a comparação
48. Relatar a avaliação da comunicabilidade sob o ponto de vista
do emissor da mensagem.
Conteúdo do relatório:
• Breve descrição do método de Inspeção Semiótica;
• Definição e justificativa do foco e cenário de inspeção;
• Apreciação geral da comunicabilidade do design de
IHM;
• Detalhamento dos pontos em que a comunicabilidade
não está boa;
• Anexos de evidências (imagem, vídeo, etc).
Relato dos resultados
49. • Faça a Avaliação Heurística de todo ou parte de um
sistema/site que você está acostumado a utilizar.
• Procure por violações das heurísticas de Nielsen.
• Indique o local e grau de severidade dos problemas
encontrados.
• Recomende soluções para as violações encontradas.
Exercício
50. 1. Fazer uma Inspeção Semiótica em qualquer simulador
existente em um site bancário (com exceção do simulador
da CEF utilizado nesta aula).
2. Analise as três classificações dos signos, identificando
possíveis problemas na comunicabilidade da interface.
Exercício
51. PREECE, J.; ROGERS, Y.; SHARP, H. Design de interação: além da
interação homem-computador. Porto Alegre: Bookman, 2013.
Referências Bibliográficas