Slides Livro de IHC - Barbosa e Silva

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

cap07.pptx
Design de IHC
Capítulo 7
A
Barbosa e Silva 2010
1
Representações e Aspectos de IHC
‹#›
Barbosa e Silva 2010
Cenários de Interação
não devem conter detalhes da interface propriamente dita, como textos, rótulos e tipos de elementos de interface (widgets) utilizados.
fornecem mais detalhes sobre as ações do usuário e as respectivas respostas do sistema necessárias para o usuário alcançar seus objetivos
‹#›
Barbosa e Silva 2010
Exemplo de Cenário de Interação
Cadastro de projetos finais pelos professores
Atores: Joana (secretária), Fernando Couto (aluno), Marcos Correa (professor, orientador principal do projeto final), Pedro Melo (coorientador externo)
Na primeira semana de aula, Joana, secretária do curso de Engenharia Ambiental, precisa se certificar de que os projetos finais dos alunos iniciados no período atual estão cadastrados. Como costumam ser entre 20 e 30 projetos, e seu cadastramento deve ser efetuado numa época em que o pessoal da secretaria está sobrecarregado de trabalho, cada professor deve cadastrar os projetos dos seus alunos. Para isso, Joana envia uma mensagem a todos os professores solicitando que cadastrem os projetos sob sua orientação e informando que eles têm apenas uma semana para fazê-lo, sob risco de os alunos terem suas matrículas em Projeto Final I canceladas. Ao receber a mensagem de Joana, Marcos Correa entra no sistema para cadastrar o projeto final do seu aluno Fernando Couto. Ele informa o nome e a matrícula do aluno, além do título e do formato de entrega do seu trabalho (e.g., relatório ou software). Ao informar os dados do coorientador externo (nome completo, e-mail e CPF), percebe que não possui o CPF do seu colega, Pedro Melo... (continua no livro)
‹#›
Barbosa e Silva 2010
Design Centrado na Comunicação
Objetivo
Na engenharia semiótica, o objetivo do design da interação é completar a segunda parte da metamensagem do designer para o usuário:
O designer deve comunicar aos usuários sua visão de design para dar-lhes melhores condições de entender e aprender sobre o sistema projetado e como podem utilizá-lo.
Este é o meu entendimento, como designer, de quem você, usuário, é, do que aprendi que você quer ou precisa fazer, de que maneiras prefere fazer, e por quê. Este, portanto, é o sistema que projetei para você, e esta é a forma como você pode ou deve utilizá-lo para alcançar uma gama de objetivos que se encaixam nesta visão.
‹#›
Barbosa e Silva 2010
Design Centrado na Comunicação
O que significa interação e o projeto de interação?
A interação é vista como uma conversa entre designer e usuário através da interface, durante a conversa usuário-sistema.
 
Projetar a interação significa definir as conversas que o usuário poderá travar com o preposto do designer para alcançar seus objetivos.
‹#›
Barbosa e Silva 2010
Design Centrado na Comunicação
O que é uma conversa?
Toda conversa tem um tópico, que é o assunto geral por ela endereçado. 
Essa conversa pode se desdobrar em diálogos, que endereçam subtópicos relacionados ao tópico da conversa. 
Os diálogos são compostos por falas do usuário e do prepostos.
Cada fala faz uso de signos. 
‹#›
Barbosa e Silva 2010
Design Centrado na Comunicação
Exemplo de conversa
tópico > subtópico (diálogo)
falas e signos
cadastrar trabalho
U: Preciso cadastrarum trabalhopara os meus alunos de IHC.
> informar dados do trabalho
D: Qual éo títuloea descriçãodo trabalho?Até quandodeve ser entregue?
Pode ser feitoem grupo? Quantospontosvale o trabalho?
> consultar datas importantes
U: Antes, quero consultaros prazos da universidadeeferiadosdesse semestre.
D: Ei-los.
> informar dados do trabalho
U: Preciso de uma semana para corrigir os trabalhos, e preciso entregar as notas até dia 2 de junho. Então vou pedir para os alunos entregarem os trabalhos até o dia 26 de maio (data de entrega). Eles devem receber umlembrete do prazo de entrega.
D: OK, o trabalho deverá ser entregue até o dia 26 de maio e os alunos serão lembrados no dia 23 de maio (três dias antes).
> informar dados do trabalho
D: E qual éo títuloea descriçãodo trabalho? Pode ser feitoem grupo?
Quantospontosvale o trabalho?
U: O trabalho pode ser feito em dupla, e vale 20% da nota.
O título é (...) e a descrição é (...).
D: OK,o trabalho já foi cadastrado.
conferir cadastro do trabalho
> examinar dados do trabalho
U: Deixa eu conferir os dados do trabalho... Estão OK.
notificaralunos
U: Agora quero avisar aos alunos de que o enunciado do trabalho já está disponível.
D: OK, posso enviar amensagem padrão?
> informar conteúdo da mensagem
U: Sim.
conferir mensagem > conteúdo e destinatários da mensagem
D: A mensagem (...)foi enviada paraos alunos (...).
‹#›
Barbosa e Silva 2010
Mapa de Objetivos dos Usuários
Tipos de objetivo
tipo de objetivo
formulação :
você (usuário no papel <Papel>)...
final
quer utilizar o sistema para <atingirobjetivoFinal>
instrumental
quer <atingir objetivo instrumental> para <atingir objetivo Final> [de forma mais eficiente/fácil/flexível...]
instrumental direto
quer <atingir objetivo instrumental> para <atingir objetivo Final> [de forma mais eficiente/fácil/flexível...]agora
instrumental indireto
quer <atingir objetivo instrumental> para <atingir objetivo Final> [de forma mais eficiente/fácil/flexível...]no futuro
‹#›
Barbosa e Silva 2010
Exemplo de Mapa de Objetivos dos Usuários
‹#›
Barbosa e Silva 2010
Esquema Conceitual de Signos: Conteúdo
‹#›
Barbosa e Silva 2010
Esquema Conceitual de Signos: Conteúdo
À medida que o design avança, é possível definir mais informações acerca dos signos
‹#›
Barbosa e Silva 2010
Prevenção e Recuperação de 
Rupturas Comunicativas (1/2)
prevenção passiva (PP): o preposto do designer tenta evitar que haja uma ruptura, fornecendo explicações sobre a linguagem de interface. Por exemplo, apresenta uma dica de formato como “(dd/mm/aaaa)” ao lado de um campo de data; ou uma instrução explícita como “asterisco (*) indica campo obrigatório”;
prevenção ativa (PA): o preposto do designer impede que o usuário emita falas inválidas que causem uma ruptura. Por exemplo, habilita ou desabilita um botão de acordo com o estado atual do sistema ou impede que o usuário digite letras ou símbolos em campos numéricos;
prevenção apoiada (ou alerta, AL): o preposto do designer, ao identificar uma situação como causa potencial de uma ruptura, descreve a situação e solicita que o usuário tome uma decisão informada sobre os rumos da interação. Geralmente esse mecanismo é concretizado na interface por diálogos de confirmação (por exemplo, “Arquivo já existe, deseja sobrescrevê-lo?”; “Foram feitas alterações no trabalho. Deseja armazená-las?”);
‹#›
Barbosa e Silva 2010
13
Prevenção e Recuperação de 
Rupturas Comunicativas (2/2)
recuperação apoiada (RA): após uma ruptura ter ocorrido, o preposto do designer auxilia o usuário a se recuperar da ruptura. Ele descreve a ruptura e oferece ao usuário a oportunidade de retomar a conversa de forma produtiva. Por exemplo, quando o usuário preenche um campo incorretamente, o preposto apresenta uma mensagem descrevendo o erro no preenchimento e destaca o campo a ser corrigido, esperando que o usuário assim o faça;
captura de erro (CE): após uma ruptura ter ocorrido, o preposto do designer identifica que o usuário não pode se recuperar dela através da interface do próprio sistema. Nesse caso, o preposto descreve a ruptura e, se possível, indica ao usuário algo que ele possa fazer fora do sistema para retomar uma conversa produtiva com o sistema no futuro. Por exemplo, no caso de um arquivo corrompido, o preposto pode apresentar a mensagem “O arquivo está corrompido. Tente copiá-lo novamente da sua origem”.
‹#›
Barbosa e Silva 2010
14
Exemplo
de Prevenção e Recuperação 
de Rupturas Comunicativas
‹#›
Barbosa e Silva 2010
15
Modelo Hierárquico de Tarefas Adaptado
sequencial
independente de ordem
alternativa
iterativa
ubíqua
opcional
‹#›
Barbosa e Silva 2010
Modelagem de Interação
MoLIC (Modeling Language for Interaction as Conversation) 
é uma linguagem para a modelagem da interação humano-computador como uma conversa
‹#›
Barbosa e Silva 2010
Construção dos diagramas MoLIC
Os designers devem refletir sobre as seguintes questões:
tópicos das conversas ƒem direção a um objetivo
conversas alternativas em direção a um mesmo objetivo, possivelmente endereçando as necessidades e preferências de diferentes perfis de usuários
mudanças de tópico relativas a objetivos instrumentais diretos ƒ
conversas para a recuperação de rupturas, i.e., mecanismos para os usuários se recuperarem de problemas na comunicação com o preposto do usuário
a consistência entre caminhos de interação semelhantes ou análogos
‹#›
Barbosa e Silva 2010
Construindo um diagrama MoLIC: partindo dos objetivos do usuário
‹#›
Barbosa e Silva 2010
Construindo um diagrama MoLIC: 
falas de transição
mudanças de tópico em determinados momentos da interação (cenas)
‹#›
Barbosa e Silva 2010
Construindo um diagrama MoLIC: 
definindo acessos ubíquos
mudanças de tópico em qualquer momento da interação
‹#›
Barbosa e Silva 2010
Construindo um diagrama MoLIC: 
pontos de abertura e encerramento
por onde começar e terminar a conversa?
‹#›
Barbosa e Silva 2010
Construindo um diagrama MoLIC: 
processo do sistema
o sistema decide o rumo da conversa de acordo com o que o usuário disse
‹#›
Barbosa e Silva 2010
Construindo um diagrama MoLIC: 
cena de alerta ou captura de erro
o preposto comunica um alerta ou captura de erro
‹#›
Barbosa e Silva 2010
Construindo um diagrama MoLIC: comparando soluções alternativas
é possível refletir sobre as vantagens e desvantagens de diferentes soluções de interação.
objetivos semelhantes deveriam ter soluções de interação semelhantes?
‹#›
Barbosa e Silva 2010
Construindo um diagrama MoLIC: detalhamento da conversa
definindo diálogos e signos das cenas
cena com diálogos
cena com diálogos e signos
‹#›
Barbosa e Silva 2010
Design de Interface
o design de interface envolve:
escolha dos estilos de interação do sistema
definir como a conversa projetada será representada na interface
‹#›
Barbosa e Silva 2010
Estilos de Interação
linguagem de comando
usuário precisa memorizar e se lembrar dos comandos
interação tende a ser rápida depois que o usuário aprende
‹#›
Barbosa e Silva 2010
Estilos de Interação
linguagem natural
fácil de usar por pessoas inexperientes
grandes desafios de implementação
‹#›
Barbosa e Silva 2010
Estilos de Interação
interação através de menus
pode ser mais fácil se lembrar das opções
pode levar mais tempo para mover mãos e braços do que digitar um comando 
Além das barras de menu, barras de navegação e menus contextuais (pop-up), Shneiderman também considera conjuntos de botões de seleção (checkboxes) e opção (radio buttons) como formas de interação por menu
‹#›
Barbosa e Silva 2010
Estilos de Interação
interação através de formulário
‹#›
Barbosa e Silva 2010
Estilos de Interação
manipulação direta
aproxima a interação da manipulação dos objetos no mundo real 
estimula a exploração com o mouse: clique, duplo clique, clicar e arrastar
mais difícil para usuários com limitações visuais ou motoras
‹#›
Barbosa e Silva 2010
Estilos de Interação
 WIMP (Windows, Icons, Menus, and Pointers)
‹#›
Barbosa e Silva 2010
Representações da Interface com Usuário
esboços, wireframes
modelos, como as linguagens de descrição de interfaces com usuário: UIML, UsiXML, XAM, etc. 
protótipos funcionais
‹#›
Barbosa e Silva 2010
Representações da Interface com Usuário
interface abstrata
define agrupamentos e características dos elementos de interface
exemplo 
conjunto de itens com seleção simples
interface concreta
define posicionamento e elementos de interface interativos (widgets) 
exemplo 
representar a entrada de dados como 
ou
‹#›
Barbosa e Silva 2010
Representações da Interface com Usuário
esboço em baixa fidelidade
‹#›
Barbosa e Silva 2010
Representações da Interface com Usuário
esboço em baixa fidelidade elaborado em ferramenta computacional
‹#›
Barbosa e Silva 2010
Representações da Interface com Usuário
esboço em alta fidelidade
‹#›
Barbosa e Silva 2010
Da Interação para o Design de Interface
acessos ubíquos geralmente são mapeados para menus e barras de navegação
‹#›
Barbosa e Silva 2010
Da Interação para o Design de Interface
é comum mapear uma cena para unidade de apresentação (tela ou página web )
‹#›
Barbosa e Silva 2010
Da Interação para o Design de Interface
uma cena também pode ser mapeada para mais de uma unidade de apresentação
‹#›
Barbosa e Silva 2010
Da Interação para o Design de Interface
cena Consultar material mapeada para unidade de apresentação 
Materiais didáticos (nº 1)
diálogo ver materiais mapeado para a tabela de materiais didáticos (nº 2)
fala de usuárioƒ u: cadastrar novo material mapeada para link Cadastrar novo material didático (nº 3)
fala de usuário u: editar material X mapeada para os links na tabela (nº 4)
cena Editar material mapeada para duas unidades de apresentação semelhantes, conforme a fala de transição de usuário que leva até ela:
Cadastrando novo material didático, destino da fala u: cadastrar novo material didático (nº 5)
Editando material didático, destino da fala u: editar material X (nº 6)
‹#›
Barbosa e Silva 2010
42
Da Interação para o Design de Interface
falas do preposto geralmente são representadas como mensagens de erro ou de status e de status
a fala d: material gravado foi mapeada para mensagem de status na unidade de apresentação correspondente à cena de destino (nº 1)
a fala d: problema na gravação foi mapeada para uma unidade de apresentação diferente (nº 2)
‹#›
Barbosa e Silva 2010
Esquema Conceitual de Signos: Expressão
‹#›
Barbosa e Silva 2010
Projeto do Sistema de Ajuda
O sistema de ajuda é uma forma de comunicação privilegiada entre designer e usuários, uma vez que é uma comunicação direta
O designer deve tentar antecipar as dúvidas dos usuários para registrar durante o design respostas adequadas
exemplos de dúvidas comuns:
‹#›
Barbosa e Silva 2010
Atividades extraclasse
Leitura do Capítulo 7
Realização das atividades do Capítulo 7 
‹#›
Barbosa e Silva 2010
cap09.pptx
Planejamento da Avaliação de IHC
Capítulo 9
A
Barbosa e Silva 2010
1
O que é avaliação de IHC? 
A avaliação de IHC é um momento onde o avaliador:
faz um julgamento de valor sobre a qualidade de uso 
da solução de IHC e 
identifica problemas na interação e na interface que prejudiquem a experiência particular do usuário durante 
o uso do sistema
‹#›
Barbosa e Silva 2010
Por que avaliar?
nem sempre os produtos de um processo de fabricação são de qualidade
matéria prima com defeito ou de má qualidade
pode acontecer um erro humano, etc.
no desenvolvimento de sistemas interativos, os problemas costumam ocorrer:
na coleta, interpretação, processamento e compartilhamento de dados entre os interessados no sistema (stakeholders)
na implementação do sistema
projetado
A avaliação do produto final possibilita entregar um produto com uma garantia maior de qualidade
‹#›
Barbosa e Silva 2010
3
Por que avaliar em diferentes perspectivas?
Um sistema interativo deve ser avaliado na perspectiva de 
quem concebe, constrói e de quem o utiliza
para quem concebe e utilizada, deve-se verificar se o sistema apoia adequadamente os usuários a atingirem seus objetivos em um contexto de uso – avaliações de IHC
para quem constrói, 
deve-se verificar se o sistema funciona de acordo com especificação de requisitos – testes da Engenharia de Software
‹#›
Barbosa e Silva 2010
4
Por que avaliar em diferentes perspectivas?
As diferenças entre quem concebe e quem utiliza 
não podem ser desprezadas
Os usuários podem ou não 
compreender e concordar com a lógica do designer, 
julgar a solução de IHC apropriada e melhor do que as soluções existentes, 
incorporá-la no seu dia a dia, quando tiverem escolha 
É importante avaliar IHC do ponto de vista dos usuários, preferencialmente com a participação deles
‹#›
Barbosa e Silva 2010
5
Por que avaliar a qualidade de uso?
problemas de IHC podem ser corrigidos antes e não depois de o produto ser lançado
a equipe de desenvolvimento pode se concentrar na solução de problemas reais, em vez de gastar tempo debatendo gostos e preferências particulares de cada membro da equipe
engenheiros sabem construir um sistema, mas não sabem e não estão em uma posição adequada para discutir sobre a qualidade de uso. 
‹#›
Barbosa e Silva 2010
6
Por que avaliar a qualidade de uso?
Quem será o advogado do usuário para defender seus interesses durante o processo de desenvolvimento?
O tempo para colocar o produto no mercado diminui, pois os problemas de IHC são corrigidos desde o início do processo de desenvolvimento.
Identificar e corrigir os problemas de IHC permitem entregar um produto mais robusto, ou seja, a próxima versão corretiva não precisa já começar a ser desenvolvida no momento do lançamento do produto no mercado.
‹#›
Barbosa e Silva 2010
7
O que avaliar?
É importante definirmos quais são os objetivos da avaliação, 
a quem eles interessam e por quê
Os objetivos de uma avaliação determinam quais aspectos relacionados ao uso do sistema devem ser investigados
Alguns objetivos de avaliação comuns são:
apropriação de tecnologia pelos usuários, incluindo o sistema computacional a ser avaliado mas não se limitando a ele;
ideias e alternativas de design; ƒ
conformidade com um padrão; ƒ
problemas na interação e na interface.
Os objetivos precisam ser detalhados em perguntas mais específicas para torná-los operacionais
‹#›
Barbosa e Silva 2010
Exemplos de perguntas que uma avaliação de IHC pode responder
‹#›
Barbosa e Silva 2010
Quando avaliar o uso de um sistema?
avaliação formativa, antes de termos uma solução pronta
geralmente utilizada para:
analisar e comparar ideias e alternativas de design 
identificar problemas na interação e na interface
artefatos que podem servir de insumo: 
cenários de uso, 
esboços de tela, 
storyboards, 
modelagem da interação e 
protótipos do sistema em diferentes níveis de detalhe e fidelidade 
em diferentes momentos do processo de desenvolvimento, dependendo dos dados disponíveis sobre a solução de IHC sendo concebida
‹#›
Barbosa e Silva 2010
Quando avaliar o uso de um sistema?
avaliação somativa (ou conclusiva), depois que a solução estiver pronta 
utilizada para avaliar qualquer objetivo de avaliação 
a solução de IHC final pode ser representada:
por um protótipo de média ou alta fidelidade, ou 
até mesmo pelo sistema interativo implementado
em diferentes momentos do processo de desenvolvimento, dependendo dos dados disponíveis sobre a solução de IHC sendo concebida
‹#›
Barbosa e Silva 2010
Onde coletar dados sobre experiências de uso?
avaliação em contexto de uso
fornece dados de situações típicas de uso que não seriam percebidos em uma avaliação em laboratório
permite entender melhor como os usuários se apropriam da tecnologia no seu cotidiano e quais problemas podem ocorrer em situações reais de uso
é difícil controlar sua execução para assegurar que certos aspectos do sistema sejam analisados
As avaliações de IHC que envolvem a participação dos usuários podem ser realizadas em contexto real de uso ou em laboratório
‹#›
Barbosa e Silva 2010
Onde coletar dados sobre experiências de uso?
avaliação em laboratório
oferece um controle maior sobre as interferências do ambiente na interação usuário–sistema 
facilita o registro de dados das experiências de uso com a solução de IHC avaliada
uma sala de reunião com mesa e cadeiras é um ambiente adequado para utilizar os métodos de grupo de foco e prototipação em papel
ambientes de observação são adequados o teste de usabilidade e o método de avaliação de comunicabilidade
As avaliações de IHC que envolvem a participação dos usuários podem ser realizadas em contexto real de uso ou em laboratório
‹#›
Barbosa e Silva 2010
Onde coletar dados sobre experiências de uso?
ambiente de observação (laboratório)
possui 2 salas: 
uma onde o usuário vai utilizar o sistema (sala de uso) 
outra onde o avaliador vai observá-lo através de um vidro espelhado (sala de observação)
‹#›
Barbosa e Silva 2010
Que tipos de dados coletar e produzir?
Os dados coletados e produzidos em uma avaliação de IHC podem ser classificados de diferentes maneiras. 
As classificações mais comuns são: 
nominais, ordinais, de intervalo e de razão; 
dados qualitativos e quantitativos; 
dados subjetivos e objetivos. 
Cada método de avaliação de IHC privilegia dados e resultados de diferentes tipos
‹#›
Barbosa e Silva 2010
15
Que tipos de dados coletar e produzir?
dados nominais representam conceitos na forma de rótulos ou categorias, por exemplo: a origem étnica de uma pessoa pode ser africana, hispânica, asiática, etc.
dados ordinais representam conceitos com relações que definem algum tipo de ordem entre eles, por exemplo uma lista de sites que um usuário mais utiliza
dados de intervalo representam períodos, faixas ou distâncias entre os dados ordinais, por exemplo faixa etária 
dados de razão são dados que possuem um valor zero verdadeiro, por exemplo o tempo que uma pessoa leva 
para realizar uma tarefa, ou o número de erros cometidos.
‹#›
Barbosa e Silva 2010
16
Que tipos de dados coletar e produzir?
dados qualitativos representam conceitos que não são representados numericamente. Por exemplo, os dados nominais e as respostas livres, tais como expectativas, explicações, críticas, sugestões e outros tipos de comentário. 
dados quantitativos representam numericamente uma quantidade, ou seja, uma grandeza resultante de uma contagem ou medição, tais como: o tempo e número de passos necessários para alcançar determinado objetivo ou quantas vezes a ajuda on-line e o manual de uso foram consultados. Nessa classificação se encaixam os dados ordinais, intervalares e de razão.
‹#›
Barbosa e Silva 2010
17
Que tipos de dados coletar e produzir?
dados objetivos podem ser medidos por instrumentos ou software, por exemplo, as músicas que ele mais ouviu no último mês no seu computador ou o tempo que ele levou para realizar uma tarefa numa sessão de teste. 
dados subjetivos precisam ser explicitamente expressos pelos participantes da avaliação, como opiniões e preferências. 
‹#›
Barbosa e Silva 2010
18
Qual tipo de método de avaliação escolher?
Os métodos de investigação (inquiry) envolvem o uso de questionários, a realização de entrevistas, grupos de foco e estudos de campo, entre outros. 
Esses métodos permitem ao avaliador ter acesso, interpretar e analisar concepções, opiniões, expectativas e comportamentos do usuário relacionados com sistemas interativos.
Os métodos de avaliação de IHC podem ser classificados em: métodos de investigação, de observação de uso e de inspeção
‹#›
Barbosa e Silva 2010
Qual tipo de método de avaliação escolher?
Os métodos de observação fornecem dados sobre situações em que os usuários realizam suas atividades, com ou sem apoio de sistemas interativos. 
Através do registro dos dados observados, esses métodos permitem identificar problemas reais que os usuários enfrentaram durante sua experiência de uso do sistema sendo avaliado.
Os métodos de avaliação de IHC podem ser classificados em: métodos de investigação, de observação de uso e de inspeção
‹#›
Barbosa e Silva 2010
Qual tipo de método de avaliação escolher?
Os métodos de inspeção permitem ao avaliador examinar (ou inspecionar) uma solução de IHC para tentar antever as possíveis consequências de certas decisões de design sobre as experiências de uso. 
Esses métodos geralmente não envolvem diretamente usuários e, portanto, tratam de experiências de uso potenciais, e não reais.
Os métodos de avaliação de IHC podem ser classificados em: métodos de investigação, de observação de uso e de inspeção
‹#›
Barbosa e Silva 2010
Como avaliar?
Os métodos de avaliação de IHC possuem as seguintes atividades básicas: 
preparação 
coleta de dados 
interpretação 
consolidação 
relato dos resultados 
‹#›
Barbosa e Silva 2010
Por onde começar?
aprenda sobre a situação atual, que inclui o domínio do problema, os papéis e perfis dos usuários, seus objetivos e atividades, e o contexto em que o sistema é ou será utilizado
conheça as interfaces dos sistemas complementares ou semelhantes com os quais os usuários estejam acostumados a utilizar, além de, é claro, a interface do próprio sistema ou protótipo a ser avaliado 
sempre que possível, busque saber quais são os comportamentos e as dificuldades típicos dos usuários durante o uso de sistemas interativos semelhantes. 
esse conhecimento é necessário para planejar a avaliação adequadamente e facilita a coleta e análise dos dados 
‹#›
Barbosa e Silva 2010
Preparação da avaliação
no planejamento de uma avaliação de IHC precisamos definir:
os objetivos e questões específicas de investigação 
escopo da avaliação: quais partes da interface, caminhos de interação, tarefas devem fazer parte da avaliação
os métodos a serem utilizados
os perfis e o número de participantes
‹#›
Barbosa e Silva 2010
Preparação da avaliação
Depois é preciso:
refletir sobre as questões éticas e definir os cuidados que devem ser tomados
alocar pessoal, recursos e equipamentos 
preparar e imprimir o material de apoio:
termo de consentimento
questionário (ou roteiro de entrevista) pré e pós-teste
instruções e cenários para orientar os participantes sobre as tarefas a serem realizadas;
roteiro de acompanhamento da observação, de modo a facilitar a captura de dados e anotações
preparar todo ambiente, hardware e software
realizar um teste-piloto
recrutar participantes
‹#›
Barbosa e Silva 2010
Coleta de dados
depende dos objetivos e método de avaliação planejados
‹#›
Barbosa e Silva 2010
Coleta de dados
avaliação por inspeção
envolve apenas avaliadores que:
utilizam o material preparado para seguir o método
examinam a interface para identificar 
prever experiências de uso ou
discrepâncias com padrões 
‹#›
Barbosa e Silva 2010
Coleta de dados
avaliação por observação ou investigação
envolve a participação dos usuários para:
relatar experiências de uso vivenciadas ou 
permitir a observação de experiências reais de uso
‹#›
Barbosa e Silva 2010
Coleta de dados
orientações gerais para uma sessão de observação em laboratório
dê oportunidade e tempo para o participante se acostumar com o ambiente e reduzir sua ansiedade:
seja cordial e deixe o participante à vontade
estabeleça um conversa “quebra-gelo”
apresente o laboratório, incluindo a sala de observação
ofereça água, café, oportunidade para ir ao toalete
apresente a avaliação ao participante:
explique os objetivos do estudo, o sistema de interesse, o procedimento da avaliação
informe os cuidados éticos sendo tomados
esclareça qualquer dúvida do participante
entregue o termo de consentimento
‹#›
Barbosa e Silva 2010
Coleta de dados
orientações gerais para uma sessão de observação em laboratório
caso o participante aceite, inicie a sessão de observação:
entregue o formulário pré-teste
ative softwares e hardwares que registram os dados
apresente o sistema avaliado
se for o primeiro contato, permita um explora livre do sistema
entregue as instruções e os cenários das tarefas
esclareça as eventuais dúvidas
o participante passa a realizar as tarefas solicitadas
observe o participante:
um avaliador na sala de uso e outro na sala de observação
anote qualquer acontecimento relevante
não interfira, questione ou interrompa os participantes enquanto realizam as tarefas
‹#›
Barbosa e Silva 2010
Coleta de dados
orientações gerais para uma sessão de observação em laboratório
depois de concluídas as tarefas:
realize a entrevista pós-teste para esclarecer as dúvidas
‹#›
Barbosa e Silva 2010
Interpretação
deve ser orientada pelo método de avaliação utilizado e 
pelo planejamento da avaliação
os métodos de avaliação costuma apontar:
os focos de análise (i.e., quais dados devem ser analisados sob quais perspectivas de análise) e 
os tipos de interpretações mais frequentes
por exemplo, 
o método de avaliação heurística enfatiza a análise de um conjunto de heurísticas
o método de avaliação de comunicabilidade investiga problemas na recepção da metamensagem
análise do material registrado para atribuir significado 
aos dados coletados
‹#›
Barbosa e Silva 2010
Interpretação
inicia com a interpretação dos dados de cada participante, ou seja: uma análise intrassujeito ou intraparticipante
pode ser feita de forma automática ou manual
análise do material registrado para atribuir significado 
aos dados coletados
http://www.dasilva.org.br 
‹#›
Barbosa e Silva 2010
Consolidação dos resultados
busca recorrências nos resultados de todos os participantes acordo com o método selecionado. 
os resultados comuns a vários participantes de um grupo permitem fazer uma distinção entre características representativas do grupo e das específicas de cada participante
busca responder ou justificar por que alguma resposta não foi encontrada para as questões de investigação
a generalização dos resultados exige muito cuidado, pois sempre são fortemente influenciados pelo ambiente de avaliação e pelas características, preferências, interesses e necessidades dos participantes individuais
os resultados individuais são consolidados e analisados em conjunto, em uma análise denominada de intersujeito ou interparticipante
‹#›
Barbosa e Silva 2010
Relato dos resultados
caso não sejam encontrados problemas durante a avaliação, também não podemos afirmar categoricamente que o sistema tenha alta qualidade de uso
podemos afirmar apenas que o estudo não revelou problemas num determinado escopo do sistema avaliado com base em um certo planejamento
os resultados de uma avaliação de IHC normalmente indicam tendências de problemas, e não uma certeza de que eles vão ocorrer durante o uso do sistema
‹#›
Barbosa e Silva 2010
Relato dos resultados
o relato dos resultados costuma incluir:
os objetivos e escopo da avaliação; ƒ
a forma como a avaliação foi realizada (método de avaliação empregado); ƒ
o número e o perfil de usuários e avaliadores que participaram da avaliação;
um sumário dos dados coletados, incluindo tabelas e gráficos; ƒ
um relato da interpretação e análise dos dados; ƒ
uma lista dos problemas encontrados; ƒ
um planejamento para o reprojeto do sistema.
‹#›
Barbosa e Silva
2010
O framework DECIDE
(Preece et al., 2002)
‹#›
Barbosa e Silva 2010
Atividades extraclasse
Leitura do Capítulo 9
Realização das atividades do Capítulo 9 
‹#›
Barbosa e Silva 2010
cap02.pptx
Conceitos Básicos
Capítulo 2
A
Barbosa e Silva 2010
1
Barbosa e Silva 2010 • Interação Humano-Computador
Situação Típica de Uso
‹#›
Barbosa e Silva 2010
Identifique e analise cada elemento presente numa situação típica de uso: contexto, usuário, objetivo, interação, interface e sistema.
Todos estão relacionados e se influenciam mutuamente.
2
Barbosa e Silva 2010 • Interação Humano-Computador
Interação
é um processo de...
sequência de estímulos e respostas
operação de máquina
comunicação com/por meio da máquina
Norman (1986) interpreta a interação como um processo através do qual o usuário formula uma intenção, planeja suas ações, atua sobre a interface, percebe e interpreta a resposta do sistema e avalia se seu objetivo foi alcançado
de Souza (2005) interpreta a interação com um processo de comunicação entre pessoas (incluindo o designer e os usuários), mediada por sistemas computacionais.
‹#›
Barbosa e Silva 2010
3
Barbosa e Silva 2010 • Interação Humano-Computador
Perspectivas de Interação (1/2)
Kammersgaard (1988) 
‹#›
Barbosa e Silva 2010
As perspectivas de interação descrevem formas de se interpretar a interação usuário-sistema, caracterizando o papel de ambos nesse processo. Elas foram criadas ao longo do tempo, conforme as TICs se desenvolveram. Um único sistema pode conjugar essas quatro perspectivas.
4
Barbosa e Silva 2010 • Interação Humano-Computador
Perspectivas de Interação (2/2)
perspectiva
significado de interação
fatores de qualidade mais evidentes
sistema
transmissão de dados
eficiência (tal como indicado pelo tempo de uso e número de erros cometidos)
parceiro de discurso
conversa usuário-sistema
adequação da interpretação e geração de textos
ferramenta
manipulação da ferramenta
funcionalidades relevantes ao usuário, facilidade de uso
mídia
comunicação entre usuários e designer-usuário
qualidade da comunicação mediada e entendimento mútuo
‹#›
Barbosa e Silva 2010
Compare as perspectivas e explore exemplos de interface em cada uma delas. No livro, você encontra alguns exemplos, mas procure outros nos sistemas que utiliza ou próximos da sua realidade.
5
Barbosa e Silva 2010 • Interação Humano-Computador
Interface (1/2)
interface
único meio de contato entre usuário e sistema
toda a porção do sistema com a qual o usuário mantém contato físico (motor ou perceptivo) 
ou conceitual durante a interação (Moran, 1981)
‹#›
Barbosa e Silva 2010
Interface (2/2)
hardware
software
‹#›
Barbosa e Silva 2010
Affordance
O que é possível fazer com esses elementos de interface? 
características de um objeto capazes de revelar aos seus usuários as operações e manipulações que eles podem fazer com ele (Norman, 1988)
‹#›
Barbosa e Silva 2010
8
Barbosa e Silva 2010 • Interação Humano-Computador
Cuidado com falsas affordances
O que é possível fazer com esses elementos de interface?
 Ler um número? 
 Editar um número? 
 Pressionar um botão para acionar uma ação do sistema? 
‹#›
Barbosa e Silva 2010
9
Barbosa e Silva 2010 • Interação Humano-Computador
Qualidade de Uso em IHC
critérios de qualidade de uso
usabilidade
experiência do Usuário
acessibilidade
comunicabilidade
‹#›
Barbosa e Silva 2010
Usabilidade (1/2)
na ISO/IEC 9126 (1991) para qualidade de software:
na ISO 9241-11 (1998) para ergonomia:
um conjunto de atributos relacionados com o esforço necessário para o uso de um sistema interativo, e relacionados com a avaliação individual de tal uso, por um conjunto específico de usuários
o grau em que um produto é usado por usuários específicos para atingir objetivos específicos com eficácia, eficiência e satisfação em um contexto de uso específico
‹#›
Barbosa e Silva 2010
Usabilidade (2/2)
para Nielsen (1993), a usabilidade é um conjunto de fatores:
facilidade de aprendizado (learnability) 
facilidade de recordação (memorability) 
eficiência (efficiency) 
segurança no uso (safety) 
satisfação do usuário (satisfaction)
‹#›
Barbosa e Silva 2010
Experiência do Usuário
envolve o modo como o uso de sistemas interativos afetam os sentimentos e as emoções do usuário
exemplos de aspectos positivos e negativos da experiência de uso sobre a subjetividade dos usuários:
satisfação, prazer, diversão, entretenimento, interesse, motivação, estética, criatividade, surpresa, desafio
cansaço, frustração e ofensa
‹#›
Barbosa e Silva 2010
Acessibilidade (1/2)
oferecer meios para que o usuário acesse o sistema e interaja com ele, sem que a interface imponha obstáculos
pessoas com e sem limitações possuem igual importância, sejam limitações na capacidade de movimento, de percepção, de cognição ou de aprendizado 
cuidar da acessibilidade permite que mais pessoas usem o sistema (tanto sem quanto com limitações), e não apenas poucas pessoas com características específicas
‹#›
Barbosa e Silva 2010
Acessibilidade (2/2)
é lei
... será obrigatória a acessibilidade nos portais e sítios eletrônicos da administração pública na rede mundial de computadores (Internet), para o uso das pessoas portadoras de deficiência visual, garantindo-lhes o pleno acesso às informações disponíveis.
decreto presidencial nº 5.296 de 2004, art. 47
‹#›
Barbosa e Silva 2010
Comunicabilidade (1/2)
a interface deve comunicar ao usuário a lógica do design: 
a quem se destina o sistema, 
para que ele serve, 
qual a vantagem de utilizá-lo, 
como ele funciona e 
quais são os princípios gerais de interação com o sistema
permite que os usuários tirem melhor proveito do sistema, por comunicar estratégias de uso adequadas a cada situação
conceito proposto pela engenharia semiótica, uma teoria de IHC (de Souza, 2005)
‹#›
Barbosa e Silva 2010
16
Barbosa e Silva 2010 • Interação Humano-Computador
Comunicabilidade (2/2)
a versão XP apresenta apenas o nome do comando associado
a versão 2007 apresenta também o significado do comando, as teclas de atalho associadas, uma estratégia de uso para aplicá-lo em múltiplos locais do documento e informações sobre como obter mais ajuda
MS Office XP
MS Office 2007
‹#›
Barbosa e Silva 2010
Qualidade de Uso em IHC
envolve critérios distintos, porém interligados, que afetam uns aos outros
nem sempre é possível satisfazer todos os critérios de qualidade de uso
é importante definir quais critérios devem ser priorizados no design de IHC 
‹#›
Barbosa e Silva 2010
Atividades extraclasse
Leitura do Capítulo 2
Realização das atividades do Capítulo 2 
‹#›
Barbosa e Silva 2010
�
objetivo
 
usuário
sistema
interface com usuário
processo de interação
contexto de uso
inclui tempo e ambiente físico, social e cultural
�
sistema
usuário como computador
// @ #
¤ « &
parceiro de discurso
computador como pessoa
mídia
 
usuário
sistema
 
usuário
sistema
Texto�
�
�
�
�
�
Buscar�
Inserir Texto�
�
�
Texto�
Inserir Texto�
�
�
Texto�
�
�
�
�
�
Resultado: 357 itens processados
Resultado: itens processados
Resultado: itens processados
357�
357�
cap05.pptx
Identificação de Necessidades 
dos Usuários e Requisitos de IHC
Capítulo 5
A
Barbosa e Silva 2010
1
Que dados coletar? (1/6)
Dados sobre
 
o próprio usuário,
sua relação com tecnologia, 
seu conhecimento do domínio do produto, 
seu conhecimento das tarefas que deverá realizar e
suas motivações e valores
‹#›
Barbosa e Silva 2010
Que dados coletar? (2/6) 
Dados sobre o próprio usuário 
dados demográficos: idade, sexo, status socioeconômico;
educação: grau de instrução, área de formação, cursos realizados, alfabetismo. O quão bem o usuário lê? Ele tem dificuldade com informação impressa? Tem experiência com textos complexos? Está disposto a ler texto ao utilizar produtos como o que está sendo projetado? Prefere aprender com outras pessoas? Prefere aprender fazendo?
idiomas e jargões: Que idiomas o usuário conhece e utiliza fluentemente? Ele possui um jargão profissional particular, um vocabulário próprio da empresa, da sua atividade ou de algum grupo social relevante para o seu projeto?
‹#›
Barbosa e Silva 2010
Que dados coletar? (3/6)
Dados sobre sua relação com tecnologia
experiência com computadores: alfabetismo computacional, habilidade com computadores, anos de experiência. Que sistemas computacionais o usuário conhece? Quais deles costuma utilizar? Que hardware costuma utilizar?
experiência com um produto específico ou ferramentas semelhantes: experiência com produtos concorrentes e outros produtos específicos do domínio, hábitos de uso, preferências e descontentamentos
tecnologia disponível: hardware (tamanho e resolução do monitor, velocidade do processamento etc.), software e outras ferramentas aos quais tem acesso 
‹#›
Barbosa e Silva 2010
Que dados coletar? (4/6)
Dados sobre seu conhecimento do domínio
conhecimento do domínio: O que e quanto o usuário conhece sobre o assunto em questão? É especialista? É esperado que se torne um especialista?
‹#›
Barbosa e Silva 2010
Que dados coletar? (5/6)
Dados sobre suas tarefas
objetivos: Quais são os principais objetivos dos usuário? Como eles são alcançados atualmente?
tarefas: Quais tarefas do usuário precisam ser apoiadas? Quais dessas são consideradas primárias, e quais são secundárias? Há quanto tempo realiza essas tarefas? São tarefas frequentes ou infrequentes? São tarefas inovadoras? Que experiência ele possui em tarefas semelhantes?
experiência no cargo que ocupa: cargo atual, experiência nesse cargo, tempo na empresa, responsabilidades, trabalhos e cargos anteriores, plano de carreira;
gravidade dos erros: em geral, as possíveis consequências dos erros de um usuário;
‹#›
Barbosa e Silva 2010
Que dados coletar? (6/6)
Dados sobre suas motivações e valores
motivação para o trabalho: O usuário se limita a cumprir a carga horária ou trabalha além do expediente, por prazer? Gosta da interação social no local de trabalho? Tem ambição de ser promovido?
treinamento: O quanto o usuário valoriza treinamento? Prefere um estilo de aprendizado visual, auditivo ou outro? Pode investir tempo aprendendo a utilizar o produto em questão?
atitudes e valores: preferências de produto, medo de tecnologia etc. O usuário costuma assumir riscos e explorar novas formas de fazer o mesmo trabalho? Ou evita novas experiências, preferindo caminhos já percorridos e testados? Ou prefere que alguém lhes mostre cada passo de uma nova tarefa sendo aprendida?
‹#›
Barbosa e Silva 2010
De quem coletar dados?
dos usuários finais e de pessoas interessadas no sistema (stakeholders)
é importante investigar:
Quem utilizará o sistema? 
Quem será afetado por ele? 
Quem é responsável por decidir quais objetivos o sistema deve apoiar e quais funcionalidades ele deve ter? 
Quem definiu os processos a serem apoiados pelo sistema?
...
‹#›
Barbosa e Silva 2010
Aspectos éticos (1/4)
Precisamos cuidar dos aspectos éticos em qualquer pesquisa envolvendo pessoas direta ou indiretamente
Pesquisas científicas envolvendo pessoas devem seguir a Resolução nº 196/96 do Conselho Nacional de Saúde
Pesquisas com objetivos técnicos podem se orientar por essa resolução
‹#›
Barbosa e Silva 2010
Aspectos éticos (2/4)
A Resolução 196/96 recomenda os seguintes princípios:
princípio da não maleficência, que envolve a garantia de evitar danos previsíveis relacionados à pesquisa, tanto os imediatos quanto os tardios
princípio da justiça e equidade, relacionado à relevância social da pesquisa, com vantagens significativas para os participantes da pesquisa e minimização do ônus para os participantes vulneráveis
‹#›
Barbosa e Silva 2010
Aspectos éticos (3/4)
A Resolução 196/96 recomenda os seguintes princípios:
princípio da autonomia, que envolve o consentimento livre e esclarecido dos indivíduos e a proteção a grupos vulneráveis e aos legalmente incapazes, tais como: menores de idade, alunos ou subordinados
princípio da beneficência, que envolve a ponderação entre riscos e benefícios, tanto atuais como potenciais, individuais ou coletivos, comprometendo-se com o máximo de benefícios e o mínimo de danos e riscos
‹#›
Barbosa e Silva 2010
Aspectos éticos (4/4)
Na prática, geralmente:
explicamos os objetivos aos participantes 
garantimos a confidencialidade e a privacidade dos dados brutos coletados
garantimos o anonimato nos dados divulgados
solicitamos permissão para gravar dados dos usuários 
realizamos o estudo apenas com o consentimento livre e esclarecido, geralmente atestado com um termo de consentimento assinado
asseguramos que os participantes têm o direito e a liberdade de recusar ou desistir de participar da pesquisa a qualquer momento
‹#›
Barbosa e Silva 2010
Como coletar dados dos usuários?
Entrevistas
Questionários
Grupos de Foco
Brainstorming de Necessidades e Desejos dos Usuários
Classificação de Cartões
Estudos de Campo
Investigação Contextual
‹#›
Barbosa e Silva 2010
Entrevista
permite coletar muitas informações detalhadas e profundas de usuários individuais, mais do que questionários e grupos de foco
entrevistas não estruturadas, semiestruturadas, estruturadas
é necessário treinar os entrevistadores
leva tempo para entrevistar muitos usuários
é uma conversa guiada por um roteiro de perguntas ou tópicos, na qual um entrevistador busca obter informações de um entrevistado
‹#›
Barbosa e Silva 2010
Parte de um Roteiro de Entrevista
Experiência como professor de curso (tempo – área – nível): ƒ
Há quantos anos? Que área(s)? 
Que nível (graduação/pós-graduação/extensão)?
Função (atividades – frequência – satisfação) ƒ
Quais as principais atividades? Quais as mais frequentes? E as menos frequentes?
De quais gosta mais de realizar? E de quais gosta menos? Por quê?
Divisão de responsabilidades (divisão – responsável – satisfação – desejos) ƒ
[professor, coordenação, suporte, universidade]
Quem faz o quê (definição do programa, critério de avaliação)? 
Satisfação com a divisão atual? Delegaria o quê? Centralizaria o quê?
Utilização de tecnologias computacionais para apoiar o seu trabalho ƒ
(tecnologia/atividade – frequência – satisfação – desejos)
Usa?
SIM: Quais? Para quê? Com que frequência?
 O que mais gosta? O que menos gosta? O que faria diferente?
NÃO: Já usou? Por que não usa (mais)? O que precisaria ter para você usar?
Sistema ideal ƒ
Comentários adicionais ƒ
‹#›
Barbosa e Silva 2010
 Roteiro (parcial) de entrevista para um professor universitário.
15
Perguntas Abertas e Fechadas
perguntas abertas de natureza exploratória sem restringir o tipo ou tamanho das respostas
perguntas fechadas fornecem um conjunto predefinido de respostas dentre as quais o entrevistado deve selecionar
Quais são suas principais atividades? 
Você costuma...
( ) lecionar na graduação
( ) lecionar na pós-graduação
( ) orientar alunos de iniciação científica
( ) orientar alunos de mestrado
( ) coordenar o curso de graduação
‹#›
Barbosa e Silva 2010
Nas entrevistas, as perguntas abertas são mais comuns. 
16
Questionário
permite
coletar rapidamente dados de muitos usuários
geralmente é um meio rápido, fácil e barato se obter e analisar dados em maior escala
tende a ser menos detalhado e mais superficial, quando comparado a entrevistas e grupos de foco
quem elaborar o questionário deve ser experiente para evitar perguntas ambíguas ou que induzam certas respostas
é um formulário com perguntas a serem respondidas
‹#›
Barbosa e Silva 2010
Tipos de Perguntas de Questionário (1/3)
escolha de um ou mais valores
faixa de valores
‹#›
Barbosa e Silva 2010
escala de Likert
escala de diferenciais semânticos
Tipos de Perguntas de Questionário (2/3)
‹#›
Barbosa e Silva 2010
perguntas abertas
Tipos de Perguntas de Questionário (3/3)
‹#›
Barbosa e Silva 2010
Grupo de Foco
permite obter, em pouco tempo, múltiplos pontos de vista de um grupo de pessoas
o moderador deve assegurar que pessoas mais quietas ou tímidas participem e evitar que as extrovertidas e agressivas dominem a discussão
diversas pessoas (geralmente entre três e dez) são reunidas por uma ou duas horas numa espécie de discussão ou entrevista coletiva, guiada por um moderador experiente
‹#›
Barbosa e Silva 2010
Questões Típicas de Grupos de Foco
um “dia típico” de um usuário ou o dia de trabalho mais recente
as tarefas que os usuários realizam e como eles as realizam
o domínio em geral (terminologia, procedimentos etc.)
preferências e aversões dos usuários
resultados desejados ou objetivos dos usuários
reações, opiniões ou atitudes dos usuários sobre um determinado produto ou conceito
resultados desejados para novos produtos ou funcionalidades
‹#›
Barbosa e Silva 2010
Brainstorming de Necessidades e Desejos dos Usuários
pode ser utilizado para aprender sobre as informações, tarefas ou características desejadas num produto
cada sessão geralmente envolve de 8 a 12 usuários orientados por um moderador
o moderador introduz o tema do brainstorming, orienta uma parte individual e depois uma coletiva
os participantes não devem se censurar ou aos outros
o objetivo é explorar necessidades e desejos dos usuários, 
e não projetar o sistema (não é design participativo)
busca levantar de forma bastante livre um conjunto grande e abrangente de opiniões dos participantes em torno de um tema
‹#›
Barbosa e Silva 2010
Classificação de Cartões
 
permite aprender sobre como as pessoas pensam em categorias e conceitos, como os descrevem e quais informações pertencem a quais categorias
é utilizada principalmente para informar ou guiar o projeto da arquitetura de informação de um produto. Por exemplo:
estrutura de menus e submenus numa aplicação
navegação em um Web site e 
navegação em um sistema de ajuda on-line
um conjunto de cartões ou fichas são preparados com amostras ou descrições de conteúdo e fornecidos a um grupo de pessoas que devem organizá-los em grupos, de acordo com a similaridade entre os cartões
‹#›
Barbosa e Silva 2010
Atividades para Classificação de Cartões
 
decidir o que queremos descobrir
selecionar o método (individual ou em grupo; presencial ou remoto; manual ou por software)
selecionar o conteúdo 
selecionar e convidar os participantes 
conduzir a sessão de classificação de cartões e registrar os dados 
analisar os resultados 
utilizar os resultados no seu projeto
‹#›
Barbosa e Silva 2010
Estudos de Campo
permite entender o comportamento natural do usuário final no contexto do seu próprio ambiente de atuação
fornece informações que afetam o uso de um produto — incluindo interrupções, distrações e outras demandas de tarefa — e contexto adicional que não podem ser capturados ou replicados num ambiente de laboratório
Durante um estudo de campo, um pesquisador visita usuários finais no seu próprio ambiente (e.g., lar ou local de trabalho) e os observa enquanto desempenham uma atividade
‹#›
Barbosa e Silva 2010
Formas de Estudos de Campo
Existem várias formas de estudo de campo. 
Alguns exemplos são:
observação pura, sem interação do observador com os participantes
observação participante, com interação do observador
entrevistas no ambiente do usuário
diários de atividades
investigação contextual 
‹#›
Barbosa e Silva 2010
Investigação Contextual
obtém dados sobre a estrutura do trabalho na prática, em vez de uma caracterização de marketing abstrata ou dissociada da prática real
torna explícito o conhecimento tácito e não articulado sobre o trabalho, para que os designers, que não o realizam, possam entendê-lo
permite conhecer os detalhes do trabalho que se tornaram habituais e invisíveis
um estudo de campo com o envolvimento intenso do investigador como um participante aprendiz, incluindo entrevistas e observação
‹#›
Barbosa e Silva 2010
Modelo Mestre-Aprendiz da Investigação Contextual
entrevistador observa o trabalho do usuário, exercendo o papel de aprendiz 
o usuário ensina seu trabalho ao entrevistador enquanto o realiza, exercendo o papel de mestre 
o conhecimento é compartilhado um modo mais simples e natural
na entrevista contextual, o entrevistador tem a oportunidade de entrevistar o usuário, observá-lo e aprender sobre o trabalho do usuário enquanto ele o realiza
‹#›
Barbosa e Silva 2010
Princípios Básicos da Investigação Contextual
contexto – coletar informações concretas e detalhadas sobre o contexto de trabalho dos usuários
parceria – estabelecer uma parceria com os usuários para obter as informações necessárias, através do modelo mestre-aprendiz
interpretação – construir com o usuário um entendimento compartilhado sobre os aspectos relevantes do trabalho
foco – a investigação deve ser guiada pela necessidade de um entendimento claro do trabalho
‹#›
Barbosa e Silva 2010
Atividades extraclasse
Leitura do Capítulo 5
Realização das atividades do Capítulo 5 
‹#›
Barbosa e Silva 2010
cap03.pptx
Abordagens Teóricas de IHC
Capítulo 3
A
Barbosa e Silva 2010
Os slides desse capítulo apenas apresentam uma breve noção básica das abordagens teóricas discutidas no livro.
Se o professor desejar se aprofundar em alguma abordagem específica, recomendamos elaborar mais alguns slides.
O próprio livro fornece mais conteúdo do que foi apresentado nesses slides.
Além disso, as bibliografias citadas podem enriquecer ainda mais uma apresentação que discute alguma abordagem teórica mais profundamente.
1
Barbosa e Silva 2010 • Interação Humano-Computador
Abordagens Teóricas de IHC
fundamentos de base psicológica, etnográfica e semiótica:
leis de Hick-Hyman e de Fitts 
processador humano de informação
princípios da Gestalt
engenharia cognitiva
abordagens etnometodológicas
teoria da atividade
cognição distribuída
engenharia semiótica
‹#›
Barbosa e Silva 2010
Existem várias abordagens teóricas em IHC. Conhecer profundamente todas elas costuma requerer muito tempo.
Então, é importante ter uma visão geral delas, para depois aprofundar o estudo em algumas abordagens escolhidas.
O Capítulo 3 fornece uma introdução a algumas abordagens importantes.
Se o leitor quiser aprofundar seu estudo, deve consultar as referências citadas no livro.
2
Barbosa e Silva 2010 • Interação Humano-Computador
Lei de Hick-Hyman
relaciona o tempo que uma pessoa leva para tomar uma decisão com o número de possíveis escolhas que ela possui
‹#›
Barbosa e Silva 2010
3
Barbosa e Silva 2010 • Interação Humano-Computador
Lei de Hick-Hyman
relaciona o tempo que uma pessoa leva para tomar uma decisão com o número de possíveis escolhas que ela possui
ordem alfabética
ordem por região 
(Norte, Nordeste, ...)
Em qual alternativa é mais rápido localizar um estado que você não conhece? 
Por quê?
‹#›
Barbosa e Silva 2010
Se a pessoa não conhece um estado, ela
pode não saber a que região do país ele pertence ou mesmo nem perceber que a lista está ordenada dessa forma.
A ordem alfabética é mais fácil e rápida de ser percebida e os usuários podem localizar um elemento em uma busca (próxima da) binária.
4
Barbosa e Silva 2010 • Interação Humano-Computador
Lei de Fitts
relaciona o tempo (T) que uma pessoa leva para apontar para algo com o tamanho (S) do objeto-alvo e com a distância (D) entre a mão da pessoa e esse objeto-alvo
‹#›
Barbosa e Silva 2010
5
Barbosa e Silva 2010 • Interação Humano-Computador
Lei de Fitts – exemplos em IHC
Em qual alternativa é mais rápido alcançar o botão salvar? Por quê?
Em qual alternativa é mais rápido alcançar o menu? Por quê?
menu no topo da tela, como no MAC OS
menu no topo da janela, como no Windows
‹#›
Barbosa e Silva 2010
Processador Humano de Informação
‹#›
Barbosa e Silva 2010
7
Barbosa e Silva 2010 • Interação Humano-Computador
Princípios de Gestalt (1/2)
proximidade: as entidades visuais que estão próximas umas das outras são percebidas como um grupo ou unidade;
boa continuidade: traços contínuos são percebidos mais prontamente do que contornos que mudem de direção rapidamente;
simetria: objetos simétricos são mais prontamente percebidos do que objetos assimétricos;
8
‹#›
Barbosa e Silva 2010
Princípios de Gestalt (2/2)
similaridade: objetos semelhantes são percebidos como um grupo;
destino comum: objetos com a mesma direção de movimento são percebidos como um grupo;
fecho: a mente tende a fechar contornos para completar figuras regulares, “completando as falhas” e aumentando a regularidade
9
‹#›
Barbosa e Silva 2010
Engenharia Cognitiva (1/11)
mundo psicológico X mundo físico
‹#›
Barbosa e Silva 2010
Engenharia Cognitiva (2/11)
controle da temperatura e fluxo de água na torneira
problemas de mapeamento (a): Qual é o controle de água quente e qual é o de água fria? De que maneira cada controle deve ser girado para aumentar ou reduzir o fluxo da água? 
dificuldade de controle (b): Para aumentar a temperatura da água mantendo o fluxo constante, é necessário manipular simultaneamente as duas torneiras.
dificuldade de avaliação (c): Quando há dois bicos de torneira, às vezes se torna difícil avaliar se o resultado desejado foi alcançado.
‹#›
Barbosa e Silva 2010
Engenharia Cognitiva (3/11)
controle da temperatura e fluxo de água na torneira
problemas de mapeamento, 
dificuldade de controle, 
dificuldade de avaliação
‹#›
Barbosa e Silva 2010
12
Barbosa e Silva 2010 • Interação Humano-Computador
Engenharia Cognitiva (4/11)
definição de cor via componentes [Red, Green e Blue] ou 
[Hue (matiz), Saturation , Luminance]
problemas de mapeamento das componentes RGB e HSL
dificuldade de controle das componentes HSL
dificuldade de avaliação, 
pois não se vê a cor definida
‹#›
Barbosa e Silva 2010
Engenharia Cognitiva (5/11)
reduz problemas de mapeamento e dificuldade de controle das componentes RGB e HSL
definição de cor via componentes [Red, Green e Blue] e 
[Hue (matiz), Saturation , Luminance]
‹#›
Barbosa e Silva 2010
Engenharia Cognitiva (6/11)
Teoria da Ação - golfos
variáveis psicológicas
variáveis
e controles físicos
distância entre
‹#›
Barbosa e Silva 2010
o golfo de execução distancia variáveis psicológicas das físicas
o golfo de avaliação distancia variáveis físicas das psicológicas
15
Barbosa e Silva 2010 • Interação Humano-Computador
Engenharia Cognitiva (7/11)
Teoria da Ação – travessia dos golfos
‹#›
Barbosa e Silva 2010
Engenharia Cognitiva (8/11)
Teoria da Ação – travessia dos golfos
estabelecimento do objetivo: mudar a cor de fundo do retângulo selecionado
formulação da intenção: definir uma cor verde oliva com os valores R=85, G=107, B=47
especificação das ações: 
acionar o item de menu Formatar > Cor de fundo
informar o valor 85 para a componente R
informar o valor 107 para a componente G
informar o valor 47 para a componente B
confirmar a cor definida pelos valores informados
execução: ação #1 - acionar o item de menu Formatar > Cor de fundo 
percepção: observou que apareceu uma janela de diálogo
interpretação: o título da janela de diálogo é “Selecionar cor” e há controles 
de definição de cada componente de cor individual
avaliação: me aproximei do meu objetivo. 
A especificação de ações parece correta e portanto 
posso prosseguir para o próximo passo.
continua...
‹#›
Barbosa e Silva 2010
Engenharia Cognitiva (9/11)
Teoria da Ação – travessia dos golfos
execução: ação #2 - informar o valor 85 para a componente R, digitando esse valor na caixa de texto correspondente
percepção: o valor na caixa de texto correspondente à componente R mudou, assim como a cor da imagem de pré-visualização
interpretação: o novo valor corresponde ao valor digitado
avaliação: me aproximei do meu objetivo. A especificação de ações parece correta e portanto posso prosseguir para o próximo passo.
execução: ação #3 - informar o valor 107 para a componente G, digitando esse valor na caixa de texto correspondente
percepção: o valor na caixa de texto correspondente à componente G mudou, assim como a cor da imagem de pré-visualização
interpretação: o novo valor corresponde ao valor digitado
avaliação: me aproximei do meu objetivo. 
A especificação de ações parece correta e portanto 
posso prosseguir para o próximo passo.
continua...
‹#›
Barbosa e Silva 2010
Engenharia Cognitiva (10/11)
Teoria da Ação – travessia dos golfos
execução: ação #4 - informar o valor 47 para a componente B, digitando esse valor na caixa de texto correspondente
percepção: o valor na caixa de texto correspondente à componente B mudou, assim como a cor da imagem de pré-visualização
interpretação: o novo valor corresponde ao valor digitado e a cor da imagem de pré-visualização corresponde à cor desejada
avaliação: me aproximei do meu objetivo. A especificação de ações parece correta e portanto posso prosseguir para o próximo passo.
execução: ação #5 (confirmar a cor definida pelos valores informados, clicando em OK)
percepção: a janela de diálogo foi ocultada; a cor do retângulo mudou
interpretação: a nova cor do retângulo é verde oliva
avaliação: alcancei meu objetivo
‹#›
Barbosa e Silva 2010
Engenharia Cognitiva (11/11)
Modelos da engenharia cognitiva
O usuário deve ser capaz de elaborar um modelo conceitual compatível com o modelo de design através da sua interação com a imagem do sistema. Para isso, o designer deverá produzir uma imagem de sistema explícita, inteligível e consistente com seu modelo de design. 
‹#›
Barbosa e Silva 2010
Abordagens Etnometodológicas
enfatizam as influências entre contexto físico e sociocultural e o uso de sistemas computacionais interativos
algumas das principais iniciativas
ações situadas (Suchman) × ações planejadas (Norman)
análise da conversação entre pessoas
estudo da comunicação usuário-sistema
estudos de campo no trabalho, em casa, em movimento etc.
‹#›
Barbosa e Silva 2010
Teoria da Atividade (1/3)
A atividade é realizada através de ações conscientes direcionadas a objetivos do sujeito. As ações são realizadas através de operações inconscientes, disparadas pela estrutura da atividade e as condições do ambiente.
‹#›
Barbosa e Silva 2010
Teoria da Atividade (2/3)
a atividade humana possui três características básicas:
é dirigida a um objeto material ou ideal;
é mediada por artefatos;
é socialmente constituída dentro de uma cultura.
‹#›
Barbosa e Silva 2010
Teoria da Atividade (3/3)
alguns pontos abordados em IHC 
análise
e design de uma prática de trabalho específica, considerando as qualificações, o ambiente de trabalho, a divisão de trabalho e assim por diante;
análise e design com foco no uso real e na complexidade da atividade multiusuário e, em particular, na noção essencial do artefato como mediador da atividade humana;
o desenvolvimento da experiência e do uso em geral;
a participação ativa do usuário no design, e foco no uso como parte do design.
‹#›
Barbosa e Silva 2010
Cognição Distribuída (1/2)
amplia a semântica de cognitivo para abranger as interações entre pessoas, recursos e materiais no ambiente
‹#›
Barbosa e Silva 2010
Cognição Distribuída (2/2)
descreve o contexto da atividade, os objetivos do sistema funcional e seus recursos disponíveis;
identifica as entradas e saídas do sistema funcional;
identifica as representações e processos disponíveis;
identifica as atividades de transformação que ocorrem durante a resolução de problemas para atingir o objetivo do sistema funcional.
‹#›
Barbosa e Silva 2010
Engenharia Semiótica (1/7)
caracteriza a interação humano-computador como um caso particular de comunicação humana mediada por sistemas computacionais 
foco na comunicação entre designers, usuários e sistemas
‹#›
Barbosa e Silva 2010
Engenharia Semiótica (2/7)
investiga processos de comunicação em dois níveis distintos: 
a comunicação direta usuário–sistema e 
a metacomunicação do designer para o usuário mediada pelo sistema, através da sua interface.
‹#›
Barbosa e Silva 2010
Engenharia Semiótica (3/7)
paráfrase da metamensagem:
Este é o meu (designer) entendimento de quem você (usuário) é, do que aprendi que você quer ou precisa fazer, de que maneiras prefere fazer, e por quê. Este, portanto, é o sistema que projetei para você, e esta é a forma como você pode ou deve utilizá-lo para alcançar uma gama de objetivos que se encaixam nesta visão.
‹#›
Barbosa e Silva 2010
Engenharia Semiótica (4/7)
espaço de design de IHC
quem é o emissor (designer)? Que aspectos das limitações, motivações, crenças e preferências do designer devem ser comunicados ao usuário para o benefício da metacomunicação;
quem é o receptor (usuário)? Que aspectos das limitações, motivações, crenças e preferências do usuário, tal como interpretado pelo designer, devem ser comunicados aos usuários reais para que eles assumam seu papel como interlocutores do sistema;
‹#›
Barbosa e Silva 2010
Engenharia Semiótica (5/7)
espaço de design de IHC
qual é o contexto da comunicação? Que elementos do contexto de interação — psicológico, sociocultural, tecnológico, físico etc. — devem ser processados pelo sistema, e como;
qual é o código da comunicação? Que códigos computáveis podem ou devem ser utilizados para apoiar a metacomunicação eficiente, ou seja, qual deve ser a linguagem de interface;
‹#›
Barbosa e Silva 2010
Engenharia Semiótica (6/7)
espaço de design de IHC
qual é o canal? Quais canais de comunicação estão disponíveis para a metacomunicação designer–usuário, e como eles podem ou devem ser utilizados;
qual é a mensagem? O que o designer quer contar aos usuários, e com que efeito, ou seja, qual é a intenção comunicativa do designer.
‹#›
Barbosa e Silva 2010
Engenharia Semiótica (7/7)
objetivo do designer
introduzir
produzir
+
o sistema interativo para os usuários através da interface
‹#›
Barbosa e Silva 2010
Atividades extraclasse
A leitura do Capítulo 3 é fundamental para compreender melhor as abordagens teóricas de IHC. 
Realização das atividades do Capítulo 3 
‹#›
Barbosa e Silva 2010
cap04.pptx
Processos de Design de IHC
Capítulo 4
A
Barbosa e Silva 2010
1
O que é design?
é um processo com três atividades básicas:
análise da situação atual: estudar e interpretar a situação atual;
síntese de uma intervenção: planejar e executar uma intervenção na situação atual;
avaliação da nova situação: verificar o efeito da intervenção, comparando a situação analisada anteriormente com a nova situação, atingida após a intervenção.
‹#›
Barbosa e Silva 2010
2
Perspectivas de design
são formas de interpretar a atividade de design 
racionalismo técnico
reflexão em ação
problemas e soluções conhecidos 
designer enquadra uma situação num tipo geral de problema cuja forma de solução seja conhecida
problemas e soluções únicos
designer busca aprender sobre o problema em questão e a solução sendo concebida
métodos de solução 
bem definidos a priori
métodos e ferramentas para auxiliar o aprendizado do designer sobre o problema e solução únicos
‹#›
Barbosa e Silva 2010
3
Reflexão em ação
esse processo geralmente é estimulado pela conversa com materiais
Conversa com Materiais
interagir com o modelo, obter resultados surpreendentes, tentar interpretá-los, e então inventar novas estratégias de ação com base nas novas interpretações
reflexão em ação é ...
‹#›
Barbosa e Silva 2010
Processos de design de IHC
Ciclo de vida simples
Ciclo de vida em estrela
Engenharia de Usabilidade de Nielsen
Engenharia de Usabilidade de Mayhew
Design Contextual
Design Baseado em Cenários
Design Dirigido por Objetivos
Design Centrado na Comunicação
‹#›
Barbosa e Silva 2010
Cada um desses processos define atividades, a ordem de execução e os artefatos consumidos e produzidos.
6
Ciclo de Vida Simples (Preece et al., 2002)
‹#›
Barbosa e Silva 2010
Ciclo de Vida em Estrela (Hix & Hartson, 1993)
‹#›
Barbosa e Silva 2010
Engenharia de Usabilidade de Nielsen
Conheça seu usuário 
Realize uma análise competitiva 
Defina as metas de usabilidade 
Faça designs paralelos 
Adote o design participativo 
Faça o design coordenado da interface como um todo
Aplique diretrizes e análise heurística 
Faça protótipos 
Realize testes empíricos 
Pratique design iterativo
Atividades propostas:
‹#›
Barbosa e Silva 2010
Engenharia de Usabilidade de Mayhew
‹#›
Barbosa e Silva 2010
Design Contextual
investigação minuciosa do contexto de uso
atividades básicas:
investigação contextual 
quem são os usuários, suas necessidades, objetivos e a forma de trabalho
modelagem do trabalho 
fluxo de trabalho, artefatos utilizados, ambiente físico e cultural de trabalho
consolidação da modelagem do trabalho
reprojeto do trabalho
projeto do ambiente do usuário
prototipação
testes com usuários
‹#›
Barbosa e Silva 2010
Design Baseado em Cenários
Design Dirigido por Objetivos
Design Centrado na Comunicação
Integração de IHC com Engenharia de Software
As principais abordagens de integração são:
definição de características de um processo de desenvolvimento que se preocupa com a qualidade de uso;
definição de processos de IHC paralelos que devem ser incorporados aos processos propostos pela ES;
indicação de pontos em processos propostos pela ES em que atividades e ƒmétodos de IHC podem ser inseridos.
‹#›
Barbosa e Silva 2010
Integração de IHC com Engenharia de Software
IHC e Métodos Ágeis
sugestões de Blomkvist (2005) para integrar IHC em métodos ágeis:
o designer de IHC deve ser responsável pelas decisões relacionadas com a qualidade de uso
equilibrar o tempo necessário para entregar um sistema que funcione com a qualidade de uso oferecida
buscar informações sobre o contexto de uso, e não apenas consultar os usuários e clientes no ambiente de desenvolvimento
realizar uma análise da situação atual mais abrangente e rica em contexto de uso do que as histórias de uso (user stories) e os casos de uso (use cases) amplamente utilizados em métodos ágeis
o designer de IHC deve auxiliar os usuários na priorização das funcionalidades que serão desenvolvidas
realizar avaliações de IHC durante diferentes estágios do ciclo de desenvolvimento 
‹#›
Barbosa e Silva 2010
17
Atividades extraclasse
Leitura do Capítulo 4
Realização das atividades do Capítulo 4 
‹#›
Barbosa e Silva 2010
cap10.pptx
Métodos de 
Avaliação de IHC
Capítulo 10
A
Barbosa e Silva 2010
1
Avaliação de IHC através de Inspeção
não envolvem a participação de usuários
o avaliador tenta se colocar no lugar do usuário enquanto examina (ou inspeciona) uma solução de IHC
permite identificar problemas que os usuários podem vir a ter quando interagirem com o sistema, e quais formas de apoio o sistema oferece para ajudá-los a contornarem esses problemas
alguns métodos de inspeção em IHC são:
avaliação heurística
percurso cognitivo
método de inspeção semiótica
‹#›
Barbosa e Silva 2010
Avaliação Heurística
método de avaliação de IHC criado para encontrar problemas de usabilidade durante um processo de design iterativo
método simples, rápido e de baixo custo para avaliar IHC, quando comparado aos métodos empíricos
tem como base um conjunto de heurísticas de usabilidade, que descrevem características desejáveis da interação e da interface
Nielsen propõem um conjunto de inicial de 10 heurísticas, que pode ser complementado conforme o avaliador julgar necessário
‹#›
Barbosa e Silva 2010
Heurísticas de Nielsen (1/4)
visibilidade do estado do sistema: o sistema deve sempre manter os usuários informados sobre o que está acontecendo através de feedback (resposta às ações do usuário) adequado e no tempo certo
correspondência entre o sistema e o mundo real: o sistema deve utilizar palavras, expressões e conceitos que são familiares aos usuários, em vez de utilizar termos orientados ao sistema ou jargão dos desenvolvedores. O designer deve seguir as convenções do mundo real, fazendo com que a informação apareça em uma ordem natural e lógica, conforme esperado pelos usuários
‹#›
Barbosa e Silva 2010
Heurísticas de Nielsen (2/4)
controle e liberdade do usuário: os usuários frequentemente realizam ações equivocadas no sistema e precisam de uma “saída de emergência” claramente marcada para sair do estado indesejado sem ter de percorrer um diálogo extenso. A interface deve permitir que o usuário desfaça e refaça suas ações
consistência e padronização: os usuários não devem ter de se perguntar se palavras, situações ou ações diferentes significam a mesma coisa. O designer deve seguir as convenções da plataforma ou do ambiente computacional
reconhecimento em vez de memorização: o designer deve tornar os objetos, as ações e opções visíveis. As instruções de uso do sistema devem estar visíveis ou facilmente acessíveis sempre que necessário
‹#›
Barbosa e Silva 2010
Heurísticas de Nielsen (3/4)
flexibilidade e eficiência de uso: aceleradores podem tornar a interação do usuário mais rápida e eficiente, permitindo que o sistema consiga servir igualmente bem os usuários experientes e inexperientes
projeto estético e minimalista: a interface não deve conter informação que seja irrelevante ou raramente necessária. Cada unidade extra de informação em uma interface reduz sua visibilidade relativa, pois compete com as demais unidades de informação pela atenção do usuário
prevenção de erros: melhor do que uma boa mensagem de erro é um projeto cuidadoso que evite que um problema ocorra, caso isso seja possível
‹#›
Barbosa e Silva 2010
Heurísticas de Nielsen (4/4)
ajude os usuários a reconhecerem, diagnosticarem e se recuperarem de erros: as mensagens de erro devem ser expressas em linguagem simples (sem códigos indecifráveis), indicar precisamente o problema e sugerir uma solução de forma construtiva
ajuda e documentação: é necessário oferecer ajuda e documentação de alta qualidade. Tais informações devem ser facilmente encontradas, focadas na tarefa do usuário, enumerar passos concretos a serem realizados e não ser muito extensas
‹#›
Barbosa e Silva 2010
Atividades da Avaliação Heurística
‹#›
Barbosa e Silva 2010
Relato de Problemas na Avaliação Heurística
Para cada problema identificado, o avaliador deve anotar: 
qual diretriz foi violada, 
em que local o problema foi encontrado (em que tela e envolvendo quais elementos de interface), 
qual a gravidade do problema e 
uma justificativa de por que aquilo é um problema
também pode anotar ideias de soluções
‹#›
Barbosa e Silva 2010
Severidade de Problemas na Avaliação Heurística
A severidade de um problema envolve três fatores: 
a frequência com que o problema ocorre: é um problema comum ou raro?
o impacto do problema, se ocorrer: será fácil ou difícil para os usuários superarem o problema?
a persistência do problema: o problema ocorre apenas uma vez e será superado pelos usuários, ou atrapalhará os usuários repetidas vezes?
Nielsen sugere a seguinte escala de severidade:
problema cosmético: não precisa ser consertado a menos que haja tempo no cronograma do projeto
problema pequeno: o conserto deste problema pode receber baixa prioridade
problema grande: importante de ser consertado e deve receber alta prioridade. Esse tipo de problema prejudica fatores de usabilidade tidos como importantes para o projeto 
problema catastrófico: é extremamente importante consertá-lo antes de se lançar o produto, pois provavelmente impedirá que o usuário realize suas tarefas e alcance seus objetivos
‹#›
Barbosa e Silva 2010
Percurso Cognitivo
método de avaliação de IHC cujo principal objetivo é avaliar a facilidade de aprendizado de um sistema interativo, através da exploração da sua interface 
motivado pela preferência de muitas pessoas em “aprenderem fazendo”, em vez de aprenderem através de treinamentos, leitura de manuais, etc.
considera principalmente a correspondência entre o modelo conceitual dos usuários e a imagem do sistema, no que tange à conceitualização da tarefa, ao vocabulário utilizado e à resposta do sistema a cada ação realizada
‹#›
Barbosa e Silva 2010
Percurso Cognitivo
método de avaliação de IHC cujo principal objetivo é avaliar a facilidade de aprendizado de um sistema interativo, através da exploração da sua interface 
motivado pela preferência de muitas pessoas em “aprenderem fazendo”, em vez de aprenderem através de treinamentos, leitura de manuais, etc.
considera principalmente a correspondência entre o modelo conceitual dos usuários e a imagem do sistema, no que tange à conceitualização da tarefa, ao vocabulário utilizado e à resposta do sistema a cada ação realizada
‹#›
Barbosa e Silva 2010
Atividades do Percurso Cognitivo
‹#›
Barbosa e Silva 2010
Tipos de Correção de Problemas no Percurso Cognitivo (1/2)
Se o usuário não tentar fazer a coisa certa (O usuário tentaria alcançar o efeito desejado?), há pelo menos três soluções possíveis:
eliminar a ação, combinando-a com outras ações ou deixar o sistema executá-la sozinho
fornecer uma instrução ou indicação de que a ação precisa ser realizada
modificar alguma parte da tarefa para que o usuário entenda a necessidade dessa ação.
Se o usuário formula a intenção correta mas não sabe que a ação está disponível na interface (O usuário saberá que a ação correta está disponível?), a solução pode ser tornar a ação mais evidente. 
‹#›
Barbosa e Silva 2010
Tipos de Correção de Problemas no Percurso Cognitivo (2/2)
Se o usuário não for capaz de mapear seu objetivo nas ações disponíveis na interface (O usuário conseguirá associar a ação correta com o efeito que está tentando atingir?), pode ser necessário renomear as ações e reescrever as instruções da interface. 
Se o usuário não for capaz de perceber que está caminhando para concluir a tarefa (O usuário perceberá que está progredindo em direção à conclusão da tarefa?), as respostas (feedbacks) do sistema devem ser destacadas ou expressas mais claramente.
‹#›
Barbosa e Silva 2010