Interfaces Homem-Máquina

Universidade Federal do Tocantins

Curso: Ciência da Computação
Disciplina: Interfaces Homem-Máquina
Professor: Eduardo Ferreira Ribeiro
As 10 Heurísticas de Usabilidade de
Nielsen
Revisao
Quem é Jakob Nielsen ?
 Detém 73 patentes nos EUA;
PHD nas áreas de Design de Interface & Ciência da
Computação;
Escreveu até o momento 10 livros, a maioria deles
na área de Usabilidade;
Atuou como Consultor no projeto de interfaces da
SUN e IBM;
 Inventor do método denominado “Avaliação
Heurística”;
Mais detalhes em:
◦ http://www.useit.com/jakob/
1 - Status do sistema claramente visível
O sistema deve sempre manter os
usuários informados sobre o que está
acontecendo, fornecendo feedback
adequado, dentro de um tempo razoável.
2 - Correspondência entre o sistema e o
mundo real
O sistema deve falar a língua
do usuário, com palavras,
expressões e conceitos que
lhe são familiares, em vez de
utilizar termos orientados ao
sistema. O projetista deve
seguir as convenções do
mundo real, fazendo com
que a informação apareça
em uma ordem natural e
lógica.
3. Liberdade e controle para o usuário
Os usuários freqüentemente escolhem funções do
sistema por engano e precisam de uma “saída de
emergência” claramente marcada para sair do
estado indesejado sem ter que percorrer um diálogo
extenso. A interface deve permite que o usuário
desfaça ou refaça suas ações.
◦ O sistema permite que os usuários saiam com facilidade
de lugares
4. Consistência e padronização
Os usuários não devem ter que se
perguntar se palavras, situações ou ações
diferentes significam a mesma coisa. O
projetista deve seguir as convenções da
plataforma / do ambiente.
5. Prevenção de erros
Ainda melhor do que uma boa mensagem
de erro é um projeto cuidadoso que evite
que um problema ocorra.
 6. Reconhecer, ao invés de decorar
O projetista deve tornar os objetos,
as ações e opções visíveis. O usuário
não deve ter que se lembrar de
informação de uma parte do sistema
quando tiver passado para uma outra
parte da aplicação.
◦ Da mesma maneira, o usuário não deve
ter que se lembrar para que serve um
elemento de interface cujo símbolo não
é reconhecido diretamente.
◦ As instruções de uso do sistema devem
estar visíveis ou facilmente acessíveis
sempre que necessário.
7. Flexibilidade e eficiência no uso
 Aceleradores, imperceptíveis aos usuários novatos, geralmente
tornam a interação de usuários experientes mais rápida,
permitindo que o sistema consiga servir igualmente bem esses dois
tipos de usuários.
 O projetista também deve prover mecanismos que permitam aos
usuários customizar ações freqüentemente realizadas.
◦ Exemplos de aceleradores: barra de ferramentas, teclas de atalho,
mnemônicos, etc.
8. Design minimalista e estético
Os diálogos não devem conter informação que seja
irrelevante ou raramente necessária. Cada unidade extra de
informação em um diálogo compete com as unidades
relevantes de informação e reduz sua visibilidade relativa.
9. Apoio para o usuário reconhecer,
diagnosticar e consertar erros
 As mensagens de erro devem ser expressas
em linguagem simples (sem códigos),
indicar precisamente o problema e sugerir
uma solução de forma construtiva.
10.Ajuda online e documentação
Embora seja melhor que um
sistema possa ser utilizado sem
documentação, é necessário
prover ajuda e documentação
de alta qualidade.
Informações documentais
devem ser facilmente
encontradas, focadas na tarefa
do usuário, enumerar passos
concretos a serem realizados, e
não serem muito extensas.
O que é design?
Projeto (ou design) é “plano ou
concepção intelectual que será executada
posteriormente”
 Nosso foco: design de IHC
◦ design de “produtos interativos que forneçam
suporte às atividades cotidianas das pessoas,
seja no lar ou no trabalho”.
Design Centrado no Usuário: Mudança
de Paradigma
Por que envolver usuários no design de
interação?
Gerenciamento de expectativas
◦ expectativas realistas
◦ No surprises, no disappointments
◦ Treinamento antecipado
◦ Comunicação, e não “marketing”
Sentimento de “propriedade”
◦ Usuários como participantes ativos
◦ Mais propícios a perdoar ou entender problemas
◦ Pode fazer a diferença no sucesso e aceitação do
produto
Abordagem centrada no usuário
Baseada em:
◦ Focar desde cedo nos usuários e tarefas: estudar
diretamente características cognitivas,
comportamentais, antropomórficas, etc
◦ Medição empírica: reações e performance dos
usuários em relação aos cenários, manuais,
simulações e protótipos são observadas, gravadas
e analisadas
◦ Design iterativo: ao encontrar problemas com os
testes com usuários, corrigi-los e fazer mais
testes
4 atividades básicas do Design de
Interação
1. Identificar necessidades e estabelecer
requisitos
2. Desenvolver designs alternativos
3. Construir versões interativas dos
designs
4. Avaliar designs
Questões
 Quem são os usuários?
◦ Obviamente, quem usa o sistema.
◦ Mas também, quem tem relação direta com quem usa (por
exemplo: superiores ou subordinados, clientes, etc.)
 Quais são as “necessidades”?
◦ Todo o apoio computacional que um sistema pode oferecer
para as atividades do usuário.
◦ relacionado com as atividades atuais do usuário; ou
◦ relacionado com as novas oportunidades que o sistema pode
criar.
 Deonde vem as alternativas?
 Como escolher dentre as alternativas?
Quem são os usuários ?
Não é tão óbvio quanto você imagina:
◦ quem interage diretamente com o produto
◦ quem gerencia o usuário direto
◦ quem recebe output do produto
◦ quem toma a decisão de comprar o produto
◦ quem usa produto concorrente
Sistema de caixa de supermecado:
usuários
O que são “necessidades dos usuários” ?
Identificar as necessidades dos usuários
significa conhecer o máximo possível
sobre eles, seu trabalho e o contexto desse
trabalho para definirmos a forma como o
sistema em desenvolvimento pode
fornecer-lhes suporte na realização dos
seus objetivos.
◦ (Preece et al., 2005)
Quais são as “necessidades”?
Usuários raramente sabem o que é possível
 Usuários não sabem dizer o que precisam
 Ao invés disso, observe as tarefas existentes:
◦ contexto
◦ que informações elas precisam?
◦ quem colabora na execução da tarefa?
◦ porque a tarefa é feita dessa maneira?
Tarefas “adicionais”:
◦ Podem ser incluídas no novo cenário
◦ Podem ser descritas para futuros cenários
O que são “requisitos dos usuários” ?
“Um requisito consiste em uma
declaração sobre um produto pretendido
que especifica o que ele deveria fazer ou
como deveria operar” (Preece et al., 2005
p.224)
Não precisa ser muito rígido, mas é
preciso estar certo de que os requisitos
não irão se alterar radicalmente durante o
processo de design.
Como estabelecer requisitos?
De forma bem geral temos que:
◦ Coletar dados sobre os usuários, seus objetivos,
seu trabalho, o contexto de uso, suas capacidades
cognitivas, seu conhecimento prévio sobre o
domínio, sistema similares, tecnologia, e etc.;
◦ Interpretá-los, isto é, decidir quais são importantes
para o sistema sendo desenvolvidos e de que
forma; e
◦ Extrair os requisitos, ou seja, construir sentenças
sobre o que o sistema deve fazer e como.
Estabelecer requisitos
Concentrar-se na identificação das necessidades dos
usuários envolvidos
 Considerar TODO o grupo de usuários envolvidos:
certificar-se de que dispõe de todos os pontos de
vista das pessoas certas
 Envolver mais de um representante de cada grupo
 Combinar técnicas de coletas de dados 
perspectivas diferentes
Oferecer apoio adequado a sessões de coletas
◦ Descrições das tarefas, descrições dos protótipos
 Sessão piloto
 Registrar os dados
Desenvolver designs alternativos
Design conceitual: como representar?
◦ Representações abstratas (em notações gráficas ou
textuais)
◦ Representações “em discurso” (textos
descritivos/narrativos em português ou outra língua,
com/sem ilustrações gráficas)
Como criar?
◦ Examinar problemas similares e suas respectivas soluções
 Adaptar soluções correntes
 Construir uma (ou mais) solução(soluções) nova(s)
◦ Não havendo problemas similares
 Inventar uma solução e explorar alternativas para ela
De onde vem as alternativas?
Humanos tendem a optar pelo que eles sabem que
funciona
Mas considerar alternativas é importante para “quebrar
a caixa”
◦ “The best way to get a good idea, is to get lots of ideas”
(Linus Pauling)
Designers são treinados para considerar alternativas;
engenheiros de software não
Como gerar alternativas?
◦ Pesquisa e síntese
◦ Busca por inspiração: olhar produtos similares e produtos
bastante diferentes
Como escolher dentre as alternativas?
Avaliação com usuários ou colegas, e.g.
protótipos
 Viabilidade técnica: alguns não são possíveis
 Garantia de qualidade
◦ Critérios de usabilidade definidos desde o início e
verificados constantemente
 segurança: quão seguro?
 utilidade: que fuinções são supérfluas?
 efetividade: provê suporte apropriado à gama de tarefas
que quero realizar? A informação está disponível?
 Eficiência: medidas de performance
Prototipação para escolher melhor
alternativa
Questões úteis sobre inovação
(Scott Berkun, autor de The Myths of Innovation)
Por que isso é feito assim?
Quem iniciou isso, e por quê?
Que alternativas foram consideradas, ou que idéias
essa nova idéia substituiu?
Quais são as principais reclamações (minhas, dos
meus amigos, ...) sobre como isso funciona/ocorre?
 Como isso é feito em outras cidades, países,
culturas, ou épocas?
Que diferentes suposições fizeram ou quais restrições
tinham?
Como posso aplicar essas coisas a o que eu faço?
Construir versões interativas
Construir
versões interativas (avaliáveis,
mesmo que como esboço ou maquete) dos
designs
◦ Design físico: como representar?
 Esboços ou maquetes
 Protótipos (de baixa ou de alta fidelidade, parciais
ou completos)
Modelos de ciclo de vida
 Mostram como as atividades se relacionam umas com
as outras
 Descrição dos resusltados de cada atividade.
 Descrição de quando e como se mover de uma
atividade para outra.
 Modelos de ciclo de vida são:
◦ Ferramentas de gerenciamento
◦ Versões simplificadas da realidade
Vários modelos de ciclo de vida existem, por ex.:
◦ Da Engenharia de Software: waterfall, espiral, JAD/RAD,
Microsoft, Desenvolvimento Ágil, etc
◦ De IHC: Star, usability engineering
Um modelo simples de design de
interação

Exemplifica a abordagem centrada no usuário

O tradicional ciclo ‘waterfall’ (em
cascata)
Ciclo de Vida em Cascata
Modelo Espiral de Boehm
Recursos importantes:
◦ Análise de Risco
◦ Prototipação
◦ Iterativo: ideias podem ser verificadas e
avaliadas
◦ Encoraja explicitamente a consideração de
alternativas
◦ Bom para projetos grandes, mas não para
projetos simples
Ciclo de vida em espiral (Boehm, 1986)
Modelo Espiral
Ciclo de vida estrela (Star)
Sugerido por Hartson e Hix (1989)
Características importantes:
◦ Avaliação é o centro das atividades
◦ Não há ordenação das atividades;
desenvolvimento pode começar por qualquer
uma
◦ Derivado de estudos empíricos com
desenvolvedores de interface
Star (Hartson and Hix, 1989)
ISO 13407