PONTIFCIA UNIVERSIDADE CATLICA DE MINAS GERAIS

Especializao em Engenharia de Software

Dorival Lopes Biudes

Matrcula 1046801-3

INTERAO HOMEM MQUINA:

RESUMO

So Paulo
2016
Interao Homem Computador - Mdulo 1 - (2015/2)
Professor Hugo de Paula - BOSS

Unidade 01 - Princpios da Interao Homem-Computador

VIDEO 1 - Usabilidade
Temos que ser flexveis e nos adaptar a necessidade do usurio.
Temos que ser agradveis para a utilizao dos usurios.
Temos que oferecer alta performance para a realizao das atividades.

LIVRO Design e Avaliao de Interfaces Humano-Computador

VIDEO 3 Design de Interao

Interao um processo de comunicao (precisamos de duas entidades) pois no se

comunica sozinho onde temos homem e computador.
Usurio normalmente interage para realizar uma tarefa (meta).
 Look & Feel Aparncia e Comportamento, criando entre o homem e um computador uma
relao com significado, ou seja uma relao com engajamento onde se queira usar o sistema.
VIDEO 4 As 8 Regras de Ouro do Design de Interfaces
A diversidade pode ocorrer por:
Idade: Controle Motor, Memria, Tamanho do dedo, Acuidade Visual, Acuidade Auditiva
Diversidade Tecnolgica: Android, iPhone, etc.
Acessibilidade Universal: Necessidades especiais (Leitor de Tela)
Experincia, onde usurios experientes querem agilidade, menus de teclado, etc, ao passo que
usurios novatos (novos ou espordicos) precisam de telas instrucionais tipo passo a passo.

Contnuo pois deve ocorrer sempre que necessrio e no local para que o usurio perceba o
feedback, acompanhando uma eventual diviso geogrfica da tela.
Feedebak articulatrio tipo um boto ser visualmente pressionado.
Feedback semantico um retorno de informao tipo arquivo salvo, ou no sentido de
evoluo quando uma tarefa de vrias etapas est sendo executada pelo usurio.
Redundncia, como retorno auditivo para que o usurio possa eventualmente sair da frente da
tela enquanto uma atividade demorada est sendo executada.
Tempo de resposta para informar que uma ao est sendo processada, e para atividades mais
demoradas eventualmente uma barra de andamento.
Seguir as 8 regras de ouro no garantia de sucesso, mas no seguir estas regras garantia de fracasso.

Textos
HCI Bibliography : Human-Computer Interaction Resources
Interao e Design Centrado no Usurio
Design de interao
As 8 regras de ouro do design de interfaces
Ergonomia e usabilidade
GABARITO ATIVIDADE 1

1 Questo 1 De acordo com as 8 regras de ouro para o design de interfaces de Bem Shneiderman,
importante se atender usabilidade universal. Isso significa que :

a) se deve manter inrcia na visualizao e eliminar informao desnecessria.

b) se devem impor processos otimizados via sequncias de aes com foco em usurios novatos.
c) se um usurio comete um erro, deve-se detectar o erro e oferecer instrues simples e construtivas
para a recuperao.
d) se devem utilizar guias de estilo para garantir padres de fontes e layouts com foco no aumento da
reteno (ou memorabilidade).

Gabarito Letra: b) - Justificativa: A usabilidade universal est relacionada com a capacidade do sistema
de se adaptar aos diversos perfis de usurio. A letra b) a resposta correta, pois projetar a interface no
modelo assistente, otimizando a sequncia de aes a abordagem correta para usurios novatos. A
letra a) um distrator plausvel, pois ela representa uma ao relacionada s 8 regras, mas se refere
consistncia. A letra c) est relacionada preveno de erros, e no depende da diversidade dos
usurios. A letra d) tambm no depende da diversidade do usurio, uma vez que guia de estilo e
padronizao deve estar presente, independente de quem seja o usurio.

2 Questo - Voc arrasta uma pasta para fazer uma cpia dos seus contedos. Em seguida, uma
animao aparece na tela, mostrando os arquivos se movendo de uma pasta para outra.
Este um exemplo de:

a) visibilidade.
b) mapeamento.
c) serventia.
d) feedback.

Gabarito Letra: d) - Justificativa: Na questo 2 o principal ponto de diferenciao entre visibilidade e

feedback est relacionado com os sete estgios da ao de Norman. O feedback uma reao, ou
resposta direta a uma interao do usurio. Ele pode ser feedback semntico quando ele prov
informaes da tarefa, ou articulatrio quando ele prov informaes da ao, como no caso do
arrastar e soltar. A visibilidade, por outro lado um atributo que no est relacionado com uma reao
interao do usurio. De acordo com o critrio de visibilidade, o usurio deve ser capaz de identificar, a
qualquer momento, qual o estado atual do sistema, e quais as aes possveis sobre esse estado. Se
tentarmos fazer uma analogia com a cpia do arquivo, podemos dizer que a animao feedback, pois
avisa que o arquivo est sendo copiado. A informao de estado, ou visibilidade, estaria relacionada com
os cones dos documentos que esto sendo copiados aparecendo na pasta de destino. Cada vez que um
novo cone aparece na pasta de destino sinaliza que houve uma mudana de estado. Evidentemente
haver, em alguns casos, uma intercesso entre visibilidade e feedback, mas no caso da questo 2, por
ser uma reao direta interao do usurio, a resposta realmente feedback.
3 Questo - Assinale a assertiva verdadeira:
a) Violar o princpio do feedback de Norman interfere com o 4 estgio dos 7 estgios da ao de
Norman.
b) Nielsen acredita que os requisitos de usabilidade podem ser quantificados e definidos como metas
pelos designers de produto.
c) A norma ISO 924111 inclui o conforto como um dos fatores responsveis pelo aumento da eficincia
no uso do sistema.
d) A empatia, como uma das dimenses da usabilidade de Shackel, est relacionada com a satisfao
subjetiva do usurio, segundo Nielsen.
Gabarito Letra: b) - Justificativa: uma questo que deixa claro a importncia da usabilidade como uma
mtrica de software. Como ser abordado em mais detalhes na unidade 04, "se voc no pode medir,
no pode gerenciar", e a nica forma de voc garantir que um sistema est sendo desenvolvido em
direo a uma alta usabilidade se voc souber definir requisitos quantitativos de usabilidade. Veja que
os requisitos podem at ser subjetivos, mas no devem deixar de ser quantitativos. A forma como isso
pode ser feito ser abordado na unidade 04. As demais opes esto erradas.
Na letra a) o feedback pode ser articulatrio ou feedback cognitivo. Dependendo do tipo, ele ocorre em
um estgio diferente.
Na letra c) o conforto no est relacionado com eficincia, apesar de pertencer norma ISO.
Na letra d) a empatia no est relacionada com satisfao. Na verdade ela um atributo externo
usabilidade.

4 Questo - Alguns requisitos, mesmo que no sejam especificamente de usabilidade, influenciam o

projeto da interface com o usurio. Entre os requisitos a seguir, assinale aquele que no tem relao
com o projeto da interface com o usurio:
a) O produto deve ser localizado; ou seja, suportar vrios idiomas.
b) Caso o evento possua um alarme deve enviar uma notificao ao aplicativo mvel de calendrio.
c) As senhas devem conter pelo menos 8 caracteres, incluindo letras maisculas, minsculas e nmeros.
d) Clientes com conhecimento prvio de funcionamento de caixas eletrnicos devem ser capazes de
sacar dinheiro em sua primeira tentativa em um intervalo inferior a 2 minutos.

Gabarito Letra: a) - Justificativa:

A letra a) est relacionada a um requisito arquitetural, que exige que o sistema seja implementado em
diversas lnguas. evidente que um sistema implementado em diversas lnguas exige cuidado para que a
metfora no se perca na traduo, mas a traduo em si no afeta o projeto da interface e nem da
metfora.
A letra b) corresponde a um requisito de usabilidade de uma tarefa automtica que produzida a partir
de uma ao do usurio, provendo o feedback semntico de que o tempo foi decorrido.
A letra c) corresponde formato de dados e envolve o grande problema entre as regras de segurana
para construo de senhas e o esforo cognitivo do usurio para memoriza-lo.
A letra d) est relacionado ao requisito de usabilidade de performance para um perfil de usurio
especfico.
Unidade 02 - Engenharia de Usabilidade

VIDEO 1 Deep Dive IDEO - Carrinho de compras

VIDEO 2 De onde vem boas idias? #Designthinking
VIDEO 3 Usabilidade - Caio Cesar (IEC - PUC-MG) - "Os 10 Punhos Secretos do Monge Pak Mei"
VIDEO 4 Engenharia de Usabilidade
VIDEO 5 Requisitos de Usabilidade
Alguns questionrios de usabilidade que permitem avaliar os requisitos de usurio de formas
gerenciveis, reprodutveis e validadas do ponto de vista estatstica.
SUMI System Usability ....
SUS System Usability Scale (0 a 100%)
PUS Person for User Satisfaction
MINUS Opinion Score
VIDEO 6 Personas e Cenrios
VIDEO 7 Anlise de Tarefas
Objetivo/Meta > Inteno > Aes
VIDEO 8 Modelo conceitual GOMS + KLM

Goals, Operators, Methods, and Selection rules model permite a representao do conhecimento
necessrio para a realizao de uma tarefa por parte de um usurio.

Modelo conceitual de interao GOMS

Goals (METAS/SUBMETAS): o que o usurio deseja fazer.
Operators (OPERADORES): aes que o software permite ao usurio tomar. Diretamente
relacionada com dispositivos de interface.
Methods: sequncias claras de METAS e OPERADORES que permitem um usurio completar uma
tarefa.
Selection rules (REGRAS DE SELEO): regras que um usurio pode seguir para decidir qual
mtodo usar para atingir uma meta.

Modelo conceitual de interao KLM

Keystroke-level model permite prever tempo de execuo de uma tarefa para execuo sem
erros por um usurio experiente
Valores definidos por observao ou por leis cognitivas

Operadores primrios de interao do KLM

K: Tempo para pressionar uma tecla ou boto
T[n]: Tempo de digitao de uma sequncia de teclas.
Datilgrafo profissional (135 ppm) 0.08 segundos
Bom datilgrafo (90 ppm) 0.12 segundos
Datilgrafo mediano (55 ppm) 0.20 segundos
Datilgrafo Amador (40 ppm) 0.28 segundos
Digitar teclas aleatrias 0.50 segundos
Digitar cdigos complexos 0.75 segundos
Pior caso 1.20 segundos
P: Apontar alvo com o mouse 1.10 segundos
Usar lei te Fitts ou de Meyer.
Valores variam de 0,8 a 1,5 segundos,
B: Pressionar/soltar o boto do mouse (B) 0.1 segundos (BB) 0.2 segundos
H posicionar as mos 0.40 segundos
D Desenhar um segmento em linha
D(n, L) desenhar n segmentos de comprimento total L (em polegadas) , onde D(n, L) = 0.9n+0.1L
M Preparao mental para ao 1.35 segundos
R Tempo de resposta do sistema
Leis cognitivas da ao para o Modelo KLM

Lei de Fitts: usada para descrever o tempo gasto para se apontar um objeto na tela com o mouse

T = Tempo p/ mover mo ao alvo

D = distncia entre mo e alvo
S = Tamanho do alvo.
T = k log2 (D/S + 0,5), k ~ 100mseg S

Lei de Meyer: refinamento da Lei de Fitts

T = tempo para mover ao alvo

D = distncia do alvo
W = largura do alvo
A ~ 13 mseg e B ~ 108 mseg

Lei de Hick: estimativa de quanto tempo uma pessoa precisa pra tomar uma deciso de menu,

por exemplo.
H = entropia (Teoria da Informao).
n = nm. de alternativas igualmente provveis.
pi = probabilidade da alternativa i para n alternativas.
O tempo para uma tomada de deciso seria proporcional a H.
T = k H, onde k 150 mseg.

Lei do potencial da prtica: determina aumento da velocidade em funo da prtica.

Tn = tempo para realizar tarefa aps n tentativas.
T1 = Tempo inicial.
n = nmero de tentativas.

Card, Morn, and Newell GOMS (CMN-GOMS)

No CMN-GOMS h uma hierarquia estrita de objetivos, os operadores so executados
estritamente em ordem sequencial, e os mtodos so representados numa notao semelhante
a um pseudocdigo, que inclui submtodos e condicionais.

Estimando tempo de execuo (CMN-GOMS)

Exemplo Resumido de Modelo NGOMSL
GOAL 0: descobrir direo de trfego de uma rua
GOAL 1: encontrar a rua
METHOD 1.A: zoom at o nvel de ruas (SEL. RULE: a regio em que se situa a rua est visvel no
mapa e o usurio conhece o local)
METHOD 1.B: fazer busca pelo nome da rua (SEL.RULE: o usurio no conhece o local ou o mapa
visvel est longe de l)
GOAL 2: identificar a direo do trfego na rua.
Algarismos indicam sequncia, e letras indicam alternativas

Limitaes do GOMS?
(1) No considera o comportamento do usurio. Ex.: fadiga, ambiente social ou fatores
organizacionais; (2) Nenhum dos modelos GOMS permite qualquer tipo de erro; (3) Considera
mais os usurios experientes, e no iniciantes; (4) Personalidades do usurio, hbitos ou
restries fsicas (ex.: deficincia) no so contabilizadas em qualquer um dos modelos GOMS;

Exemplo KLM: Mover texto pelo Menu

Operador KLM Tempo
Preparar-se mentalmente M 1,35
Mover cursor para incio da frase P 1,10
Clicar com o mouse BB 0,20
Mover cursor para fim da frase P 1,10
Pressionar SHIFT e clicar Mouse K+BB 0,28+0,20
Preparao Mental M 1,35
Mover cursor ao menu Editar P 1,10
Pressionar boto B 0,10
Mover Cursor para a opo Recortar P 1,10
Soltar boto B 0,10
Preparar-se mentalmente M 1,35
Mover cursor para ponto de insero P 1,10
Clicar com o mouse BB 0,20
Preparao Mental M 1,35
Mover cursor ao menu Editar P 1,10
Pressionar boto B 0,10
Mover Cursor para a opo Colar P 1,10
Soltar boto B 0,10
Tempo total previsto: 14,38
Textos
Handout: Engenharia de Usabilidade - Ciclo de vida
Anlise de tarefas
Requisitos de Usabilidade
Personas e cenrios
Modelagem conceitual GOMS e KLM
Atividade Objetiva 02

1 Questo - Considerando o processo de anlise de necessidades, assinale a alternativa incorreta:

Alternativas de resposta:
a) Na anlise da concorrncia, devemos estudar a ferramenta que o usurio utiliza para realizar a tarefa
atualmente, mesmo que essa ferramenta no seja computacional.
b) Na construo do perfil do usurio, deve-se levar em considerao, alm de seus aspectos cognitivos e
fatores humanos, quais so as tarefas mais significativas associadas a esse perfil.
c) Na construo dos perfis das tarefas devemos estimar a frequncia de execuo, os requisitos de
usabilidade prioritrios e eventuais restries de usabilidade, como tempo, recursos, etc...
d) Na anlise funcional, deve-se detalhar o funcionamento das tarefas com vistas nos requisitos de
usabilidade, desde que sejam tarefas com interao com o usurio.

Gabarito Letra: d) - Justificativa: Nesta questo estamos nos baseando no Handout: Engenharia de
Usabilidade - Ciclo de vida. O processo de anlise de necessidades envolve o detalhamento do trip:
usurio x ambiente x tarefa. A opo (a) est correta porque a anlise da concorrncia permitir
entendermos como o usurio realiza a tarefa hoje. Alm de fornecer informaes sobre o processo de
realizao da tarefa, permitir a definio de parmetros de benchmarking que orientaro a definio
das metas de usabilidade futuras. A opo (b) est correta pois, devido grande diversidade de perfis de
usurio, fundamental que se identifique quais so as tarefas crticas para cada perfil de usurio de
modo a podermos otimizar os requisitos de usabilidade daquela tarefa para o perfil de usurio que ir
utiliz-la. Por exemplo, enquanto um usurio experiente ir desejar uma interface mais enxuta e focada
em performance, um usurio espordico ir desejar uma interface com foco na facilidade de
aprendizado e reteno, mesmo que para isso seja necessrio reduzir a performance da execuo da
tarefa. E se uma mesma tarefa crtica para os dois perfis de usurio descritos acima, ento o projetista
dever focar na flexibilidade como mecanismo que permitir o ajuste da interface ao perfil do usurio
num determinado momento. Um exemplo que ilustra o descrito acima so os assistentes de instalao,
por exemplo, que possuem um modo de instalao expressa (sem exibir opes ao usurio) e outro
modo avanado, destinado a usurios experientes. A opo (c) est correta, pois requisitos como
durao da tarefa e frequncia com que ser executada iro influenciar diretamente a forma como a
interface dever ser construda. Por exemplo, um sinal sonoro conhecido como um bom recurso de
interface para ser utilizado como alerta ao usurio, de forma redundante com um indicador visual.
Entretanto, se o alerta se tornar muito frequente, alm do sinal perder a sua funo de alertar, pode
causar irritao e frustrao no usurio. Um exemplo concreto o da urna eletrnica. Para o eleitor, que
ir utilizar a urna apenas uma vez, o sinal sonoro um bom indicativo de que seu voto foi apurado com
sucesso. Entretanto, para os mesrios, o sinal se torna extremamente irritante. Finalmente, a opo (d)
est errada, pois, apesar de ser correta a afirmao de que os requisitos de usabilidade devem orientar o
detalhamento das tarefas, est equivocada a afirmao de que os requisitos de usabilidade iro
influenciar apenas as tarefas com interao com o usurio. Existem tarefas que so automticas, ou seja,
no possuem a interao direta do usurio, mas que foram disparadas em funo de uma ao anterior
do usurio e que devero prover feedback adequado e manter o usurio no controle.
2 Questo Assinale a alternativa que melhor complete a frase a seguir:
__________ ocorrem de forma no intencional, enquanto __________ ocorrem a partir da deliberao
consciente do usurio. Alternativas de resposta
a) Slips e mistakes.
b) Errors e slips.
c) Mistakes e Erros.
d) Faults e failures.

Gabarito Letra: a) - Justificativa: Basicamente, em IHC costuma-se dizer que os erros intencionais
(mistakes) acontecem devido a dois problemas: falta de conhecimento semntico do sistema e falta de
conhecimento sinttico. O conhecimento semntico est relacionado com a tarefa... o que o usurio
deve fazer para alcanar seu objetivo. O Tutorial a ajuda adequada a ensinar a semntica do sistema.
Ele est focado em tarefas, e ele ensina passo a passo a realizao de uma tarefa. O conhecimento
sinttico est relacionado a como fazer. Ele est mais voltado aos componentes da interface, e no
tarefa em si. Um assistente de navegao ir ajudar na construo do conhecimento da organizao do
sistema, sem se focar em uma tarefa especfica. Evidentemente que, ao se ensinar a navegar no sistema,
est se utilizando da arquitetura do sistema, que inerentemente semntica, mas a navegao tambm
afetada por elementos da interface, pelo layout (onde as coisas esto), etc.

3 Questo Considere a persona a seguir.

Adaptada de http://chocoladesign.com/criando-personas-no-design-de-produto
Ela foi construda aps uma anlise de usurios feita na empresa proprietria do site
http://bolsademulher.com.br A empresa est interessada em comprar uma nova plataforma para
potencializar seus anncios na Web e acompanhar a performance das campanhas de publicidade do site.
A persona Carla uma usuria que sempre anseia extrair a mxima performance do sistema interativo,
mas o requisito de usabilidade mais importante para a tarefa de visualizar relatrios relativos ao
desempenho de campanhas deve ser facilidade de aprendizado.
PORQUE
meta final da usuria ser capaz de utilizar o sistema para avaliar campanhas com facilidade, a partir de
relatrios de desempenho, e a eficcia na exibio dos resultados sobrepe em importncia a eficincia
na execuo da tarefa.
Alternativas de resposta
a) As duas asseres so proposies verdadeiras, e a segunda uma justificativa correta da primeira.
b) As duas asseres so proposies verdadeiras, mas a segunda no uma justificativa correta da
primeira.
c) A primeira assero uma proposio verdadeira, e a segunda uma proposio falsa. d) A primeira
assero uma proposio falsa, e a segunda uma proposio verdadeira

Gabarito Letra: a) - Justificativa: Essa uma questo de assero-razo que exige capacidade de anlise
por parte do aluno. Tanto a frase destaque da persona quanto a sua frustrao sugerem que a usuria
preocupada com performance e possui um perfil ansioso. O seu hbito no uso de informtica em
diversos aspectos sugere que ela uma usuria frequente do ponto de vista do uso da informtica.
Entretanto, a meta de negcio sugere que um objetivo ainda no alcanado pela usuria a capacidade
de interpretar com facilidade relatrios de desempenho. Ela tambm manifesta baixo conhecimento do
sistema, ao afirmar o desejo de aprender a usa a interface assistente, que tipicamente implementada
para usurios que precisam de facilidade de aprendizado.

4 Questo No mbito da IHC, uma boa representao do ciclo de vida de um software

Alternativas de resposta
a) anlise, projeto, desenvolvimento, produo, teste, redesign, ps-produo e aposentadoria.
b) definio do conceito, anlise de requisitos, anlise de tarefas, avaliao de um prottipo, produo,
implementao, operao e aposentadoria.
c) fase conceitual, fase de definio, fase de design, fase de teste, fase de implementao, fase de
operao e fase de manuteno, fase de desativao.
d) anlise de front-end, design conceitual, design e teste iterativos, design do material de suporte,
produo, avaliao, operao e manuteno.

Gabarito Letra: d) - Justificativa: Independente do processo de desenvolvimento centrado no usurio

que o designer escolha, a Engenharia de Usabilidade e o design centrado no usurio afirmam que se
deve envolver o usurio ao longo de todo o processo, e que o processo baseado em avaliao com o
usurio e redesign de forma iterativa. A nica alternativa que deixa claro um processo iterativo a letra
d). As demais letras so distratores, que utilizam palavras e fases da engenharia de usabilidade, mas
possuem como falha comum no serem iterativas
Unidade 03 - Prototipao

VIDEO 1 Projeto Interativo Personal Chef (Prototipao em papel)

VIDEO 2 Prototipao

Prottipos em design de interao

Esboos de telas
Storyboard (como uma sria de cenas)
Apresentao de slides (powerpoint)
Simulao em vdeo
Maquete de papel, madeira ou 3d
Software com funcionalidade limitada

Prottipo fundamento? Sim, mas por que?

Avaliao, permite observar precocemente a natureza final do produto, pois sem um prottipo
possvel avaliar antecipadamente
o Poupa tempo e custo de desenvolvimento (exigncia e vantagem do prottipo)
o Resolve problemas antes de escrever cdigo
o Mantm o projeto centrado no usurio
Feedback do solicitante (usurio) inclusive para identificar necessidades no informadas na fase
de levantamento de requistos
Apresentar aos stakeholders (partes interessadas) mostrando dre uma forma palpvel que o
produto vivel de forma a obter apoio, financiamento,
Comunicao facilitada, entre as equipes de desenvolvimento de software, entre usurio e
analista de software, entre reas de design e rea tcnica,
Testar idias, identificando qual idia melhor entre as vrias alternativas imaginadas para
saber qual possibilidade a melhor para atender a demanda do cliente
Incentivo refleco, para validar se a forma que a idia foi implementada est adequada as
necessidade do solicitante ou pblico alvo que utilizar,
Responder questes sobre conceito ou usabilidade pois agora que a idia se tornou algo
palpvel possvel escolher entre alternativas ou mesmo modificar complementamente o
conceito original da idia para construir algo que esteja mais adequado a necessidade do cliente
Ciclo de vida do prottipo

Atravs do processo de prototipao podemos observar precocemente a natureza final do produto,

atravs de um ciclo onde se faa um projeto, um prottipo, avaliao do prottipo e retorna para
redesenhar seu projeto. Com isto vemos que um prottipo a concretizao de um projeto especfico e
serve para ser avaliado. Ou seja, um prottipo que no for avaliado no est cumprindo o seu dever. Um
prottipo tem que ter um objetivo claro, eu vou avaliar o que? Arquitetura da informao, vou usar uma
tcnica de prototipao especfica para apresentar a arquitetura da informao e uma metodologia de
avaliao especfica para verificar se a arquitetura da informao atende a necessidade do cliente. Se eu
preciso avaliar a performance eu preciso de outro tipo de prottipo e outra metodologia de avaliao.

DIMENSES DA PROTOTIPAO
Fidelidade: Classifica as diferentes abordagens e define o nvel de detalhe do prottipo. Dividido
entre BAIXA E ALTA (recentemente alguns definiram MDIA). O mais utilizado o de baixa
fidelidade que trata de apenas uma caracterstica do produto, sendo geralmente feito em papel
(paper prototype) de forma rpida, barata e extremamente eficiente, permitindo validar e obter
aprovao de como os requisitos sero implementados logo na fase inicial do projeto.=
Representao: como o desenho da interao representado no prottipo? Ser toda a
interao ou s parte dela? S a tela inicial e menus?
Executabilidade: o prottipo pode ser executado a qualquer tempo? Neste caso o prottipo
construdo com uma soluo de tecnologia alternativa como Flash ou mesmo Powerpoint.
Escopo: o prottipo inclui todo o sistema ou somente a interface? Quando representa-se
somente a interface chamado de fachada, modelo (mock-up) podendo fazer as principais para
avaliar a visibilidade e comunicabilidade, de forma que o usurio avalie campos e a disposio
destes tela alm de menus e a navegabilidade para garantir que o usurio se sente no controle
Amadurecimento: Como o prottipo evolui para o produto?
o Evolucionrio O prottipo evolutivo evolui para o produto final.
o Revolucionrio Voc testa um aspecto da interface e joga o prottipo fora.
Prototipao Horizontal Imaginando que num eixo X tenhamos horizontalmente todas as
tarefas do nosso sistema e a profundidade (funcionamento) seria o eixo Y numa dimenso
vertical. Um prottipo horizontal teria maior abrangncia das tarefas do sistema, mas com uma
profundidade baixa, no se aprofundando em como operaes do sistema iro se comportar.
extremamente til nas fases iniciais do projeto, pois apesar de menos realista, consegue
oferecer aos envolvidos uma viso geral do produto.
Prototipao Vertical um prottipo mais estreito que abrange apenas algumas das tarefas
crticas do sistema, mas muito abrangente e profundo no sentido de detalhamento na
operao do sistema. O prottipo pode permitir entrada e validao de dados, conjunto de
dados do domnio, simular o tempo de operao de algumas atividades no sistema de forma a
dar uma viso realista de como o sistema deve ser utilizado aps sua implantao.
PROTTIPO GLOBAL X LOCAL
o Prottipo Global: visa representar o sistema inteiro, trabalhando tanto em alto nvel, como em
detalhes e tende a ser um prottipo evolutivo. Depois de ter sido investido bastante tempo no
prottipo ele tende a evoluir para o produto final.
o Prottipo Local: descreve um detalhe especfico, mas importante o suficiente para potencializar
a usabilidade de todo o sistema. Utilizando-se o princpio de Pareto poderamos avaliar os 20%
das tarefas no escopo a ser desenvolvido onde os usurios investiro 80% do tempo durante a
operao no sistema e para com isto definir quais tarefas devem receber mais ateno para
serem potencializadas atravs da construo e validao de prottipos.

Prottipo de baixa fidelidade (meio no o final)

Storyboards
Guia que ilustra os detalhes importantes (diagramas de fluxo)
Usado com cenrios
Esboo (Sketching)
Forma de Brainstorming, exerccio de design, possibilidade de testes a baixo custo. Costumam
ser independentes de plataforma
Permitem melhoria rpida, baseadas em usurios reais, sem programar uma nica linha de
cdigo.
Avaliao Rpida e Suja, so testes rpidos baseados em esboo, como apresentado no vdeo
Deep Dive.
Precisam ter um usurio real para avaliar o esboo, criticar e propor alternativas.

Prottipos baseados em cartes

Utilizando cartes (exemplo cartes de fichrios tamanho 8x12 cm)
til em sistemas tipo quiosque (de shopping) onde o sistema opera em uma tela cheia
Cada carto representa uma tela ou parte dela

Prottipo Mgico de Oz
Usurio pensa que est interagindo com o computador, mas um desenvolvedor est respondendo
pelas sadas apresentadas na tela, til em sistema instrucionais (pergunta vs resposta).
Wireframe
Define a arquitetura de informao e o layout
Disposio bsica dos macroblocos na tela
Ferramentas profissionais de site, tipo Dreamweaver, possuem o modelo wireframe onde a
ferramenta preenche as caixas com um gerador de texto automtico. Dessa forma o foco no
est no contedo, mas no layout como cores, disposio das imagens.

Prottipos de Alta Fidelidade

Usa o material esperado no produto final (plstico, madeira, etc)
Tecnologia de desenvolvimento no precisa ser a final (ex: utilizar Adoble Flex para simular a
interface)
Conhecido tambm como Prottipo Funcional (Functional Prototype)

Prottipo Adequado
A prototipao tem que ser utilizada durante todo o processo de desenvolvimento
Mesmo na fase inicial do projeto, podemos utilizar um prottipo para ajudar na avaliao de
requisitos de usabilidade
Se temos cenrios de utilizao, podemos utilizar um Storyboard que permite avaliar cenrio de
interao incluindo a performance, o fluxo adequado, eficincia, satisfao do usrio com
nmero de cliques ou taxas de erros.
Se temos casos de uso especficos, podemos utilizar um Prottipo de Carto para avaliar o caso
de uso.
Retorno sobre o Investimento (ROI) - Por que prototipar se o prottipo gera custo?
Em 1984 foram feitos dois estudos com empresas na rea de software criando produtos
baseados na experincia centrada no usurio com prototipao intensiva e produtos que no
eram prototipados ou que no tinham envolvimento com os usurios. Aps uma anlise feita de
forma sistemtica nos dois produtos foi confirmado que:
o Sistemas desenvolvidos com uso de prottipos so (Boehm et al, 1984):
Mais fceis de aprender e utilizar (a metfora criada pelo sistema estava bem
mais prxima do modelo mental esperado no software pelos usurios)
Grupos menos sujeitos a presses de prazo (pois o usurio via o produto
evoluindo e atrasos eram melhor compreendidos pelos usurios)
o cdigo dos sistemas 40% menores (que reflete menor custo de manuteno)
Sistemas desenvolvidos com 45% menos esforo (economizando tempo nas
fases de desenvolvimento e correo e erros logo aps a entrega do software)
o Sistemas prototipados (Alavi, 1984):
Usurios demonstraram maior nvel de satisfao
Melhoria da comunicao sobre o sistema
Prottipos geraram uma referncia comum para discusses
Maior entusiasmo dos usurios
Maior aceitao dos usurios (fundamental, pois tem casos onde um sistema
excelente entregue mas no se consegue o engajamento dos usurios por
questes de aceitabilidade social que melhor trabalhado com prottipos.
Usurios eram bons e produzir crticas, mas no eram bons em antecipar ou
articular necessidades
Prototipao facilita uma resposta mais rpida dos desenvolvedores (servindo
para apresentar um feedback ao cliente sobre a evoluo do software enquanto
o trabalho de desenvolvimento continua sendo realizado)
Podem fazer coisas que no podiam anteriormente (testar modelos, fazer benchmarking, etc)
economizando muito dinheiro com questes de recall devido a defeitos ou mesmo verificar se
seu produto melhor que seu concorrente ou identificar pontos fracos a serem melhorados
Melhora o processo de design atravs de provas de conceito e verificao de modelo do desenho
(entretanto retorno varia muito do perfil do usurio, pois os usurios do tipo Lead User avaliam
o produto e apresentam crticas ou sugestes de melhoria importantes)
Apresentaes visuais atraem novos clientes e dlares (investimento)

Reduo de custo em prototipao rpida

Aprenda a prototipar com grfico ruim, evitando por exemplo colocar efeitos 3D em botes
Prototipe em marcos significativos do processo, e no apenas no incio e fim
No prototipe globalmente, mas escolha um caminho completo (tarefa ou processo)
No se apegue ao seu cdigo, aprenda a jogar fora seu prottipo
No adicione detalhes visuais
No tente fazer mais do que o perodo planejado permite
Tente seguir a mdia final, considere as capacidades de sua arquitetura final
Perigos da prototipao
Pode haver reduo da disciplina da equipe que tende a enxergar prototipao como um
treino que no para valer ao invs de considerar o prottipo como parte integral do processo
de desenvolvimento centrado no usurio
Equipe de desenvolvedores e usurios podem perder entusiasmo aps a apresentao de vrias
verses de prottipos, caso sejam feitas verses finais do prottipo
Prototipao pode ser em si um processo caro e trabalhoso
Podem ser confundidos pelos usurios com o sistema verdadeiro criando falsas expectativas com
relao a prazos
preciso cuidado para no criar-se faltas expectativas de provimento de mais funcionalidades do
que o real
Armadilha de superdesenhar (overdesign): tendncia a sofisticar demais o prottipo
Apresenta dificuldades para o desenvolvedor acostumado com a abordagem top-down de
projeto

Contedo de um prottipo
Prottipos inicias
o Objetivo: testar globalmente a metfora de interao
o Fidelidade pode ser um pouco menor
o Deve incluir de forma detalhada as funes representativas do sistema, como as
sequencias de subtarefas que no forem includas na prototipao
Prottipos finais
o Objetivo: testar partes importantes ou ainda no bem resolvidas
o Prottipo deve apresentar de forma detalhada todos os detalhes de interao
o Permitir a avaliao da performance e esforo fsico, como nmero de cliques, tempo
gasto na realizao de cada tarefa, possvel disperso do usurio, etc, de forma que
fundamento que ele j funcione da forma final
Ferramentas de prototipao rpida
o Permitem ganho em produtividade
o Facilitam a gesto da evoluo de desenhos de projetos, muito importante dada a
natureza iterativa do ciclo desenho/avaliao
Design de Interfaces VIDEO 3 Design de Interfaces

Diretrizes e Princpios
Instrues vagas e genricas sobre atitudes a serem tomadas no processo de criao, encontradas em
livros e artigos que orientam sobre fatores humanos envolvidos no projeto da interao com o usurio,
que necessitam de uma traduo para o contexto de uso pessoal antes de sua aplicao

Ex. 1: Heurstica de Nielsen - Jakob Nielsen, 10 Usability Heuristics for User Interface, January 1995.

1. Visibilidade de Status do Sistema - Isso significa que voc precisa se certificar de que a interface
sempre informe ao usurio o que est acontecendo, ou seja, todas as aes precisam de feedback
instantneo para orient-lo.
2. Relacionamento entre a interface do sistema e o mundo real - Ou no usar palavras de sistema, que
no fazem sentido pro usurio. Toda a comunicao do sistema precisa ser contextualizada ao usurio, e
ser coerente com o chamado modelo mental do usurio.
3. Liberdade e controle do usurio - Facilite as sadas de emergncia para o usurio, permitindo
desfazer ou refazer a ao no sistema e retornar ao ponto anterior, quando estiver perdido ou em
situaes inesperadas.
4. Consistncia - Fale a mesma lngua o tempo todo, e nunca identifique uma mesma ao com cones
ou palavras diferentes. Trate coisas similares, da mesma maneira, facilitando a identificao do usurio.
5. Preveno de erros - Na traduo livre das palavras do prprio Nielsen Ainda melhor que uma boa
mensagem de erro um design cuidadoso que possa prevenir esses erros. Por exemplo, aes
definitivas, como delees ou solicitaes podem vir acompanhadas de um checkbox ou uma mensagem
de confirmao.
6. Reconhecimento ao invs de lembrana - Evite acionar a memria do usurio o tempo inteiro,
fazendo com que cada ao precise ser revista mentalmente antes de ser executada. Permita que a
interface oferea ajuda contextual, e informaes capazes de orientar as aes do usurio ou seja
que o sistema dialogue com o usurio.
7. Flexibilidade e eficincia de uso - O sistema precisa ser fcil para usurios leigos, mas flexvel o
bastante para se tornar gil usurios avanados. Essa flexibilidade pode ser conseguida com a
permisso de teclas de atalhos, por exemplo. No caso de websites, uso de mscaras e navegao com
tab em formulrios so outros exemplos.
8. Esttica e design minimalista - Evite que os textos e o design fale mais do que o usurio necessita
saber. Os dilogos do sistema precisam ser simples, diretos e naturais, presentes nos momentos em
que so necessrios.
9. Ajude os usurios a reconhecer, diagnosticar e sanar erros - As mensagens de erro do sistema devem
possuir uma redao simples e clara que ao invs de intimidar o usurio com o erro, indique uma sada
construtiva ou possvel soluo.
10. Ajuda e documentao - Um bom design deveria evitar ao mximo necessidade de ajuda na
utilizao do sistema. Ainda assim, um bom conjunto de documentao e ajuda deve ser utilizado para
orientar o usurio em caso de dvida. Deve ser visvel, facilmente acessada, e com oferecer uma
ferramenta de busca na ajuda.
Ex. 2: Universal Principles of Design: 100 Ways to Enhance Usability, Influence Perception, Increase
Appeal, Make Better Design Decidions, and Tech Through Design.
Wlliam Lidwell, Kritina Holden, Jill Butler. Rockport, 2003.
Diretrizes Gerais de Design de Interface
Design para Idosos
Design para Software Educaional
Design para Jogos

SITE OS X Human Interface Guidelines

SITE Guidelines for Universal Windows Platform (UWP) apps

SITE Windows User Experience Interaction Guidelines for Windows Desktop apps (UX Guide) for
Windows 7 and Windows Vista
Metforas VIDEO 3 Metforas

Metforas
proveem muitas informaes
permitem a transferncia de habilidades
boas metforas produzem mapeamentos naturais metforas no devem ser literais
metforas podem ser violadas
podem ser combinadas (ex., windows e desktops)
podem ser enganosas (ex. colocar disco no lixo)
algumas aes no possuem metfora bvia (ex: UNDO)
uma metfora melhor se leva a previses mais corretas acerca do funcionamento do sistema

Tipos de Metforas

baixo nvel: cones e mapeamentos. Pastas, calculadora, janela, programa, etc.

nvel operacional: arrastar e soltar, jogar fora um arquivo, duplo click.
alto nvel: organiza a rea de trabalho na tela

Exemplos de Metforas

edio de texto como uma mquina de escrever

dados como arquivos (em pastas ou diretrios)
apagar arquivo jogando na lixeira
aplicaes como ferramentas
aplicaes como prestadores de servios

Desktops e Rooms (Mesas e Quartos?)

A metfora do desktop conhecida: enxergamos a tela do computador como uma mesa.

A metfora do quarto diferente. A tela dividida em quartos, cada quarto apropriado para um
conjunto de tarefas.

Metfora do Quarto

todas as tarefas de um determinado contexto so executadas sem sair do quarto.

cada quarto um espao de trabalho projetado otimamente para as tarefas contidas nele.
especialmente til para se ter acesso a tarefas de suporte de forma rpida.
Metfora do Quarto Exemplo

Exemplo de um sistema de e-Health com dois quartos, um para leitura de pronturios de

pacientes e outra para agendamento de consultas

Estilos de Interao VIDEO 4 Estilos de Interao

Estilos de Interao

Colees de objetos de interface e tcnicas associadas que so utilizadas para desenhar os

componentes de interao de uma interface.

Estilos de Interao Discretos (Operao Feedback)

Linguagens de comando
Menus
Desktop
Manipulao direta
Estilos de Interao Contnuos

Fala (entrada e sada)

Viso computacional (gestos)
udio
Ttil e force-feedback
Sinais biofsicos (scanner de retina)

Estilos de Interao diferentes levam a metforas diferentes

Comandos: digitar comandos atravs do teclado, teclas de funo e teclas de atalho

Menus: selecionar a partir de uma lista predeterminada de alternativas
Manipulao direta: interage com objetos virtuais
Sistemas conversacionais: interagir com o sistema como se estivesse em uma conversa.
Explorar, buscar e ciscar por informao: encontrar e aprender coisas.

Perguntas sobre a criao de metforas

A metfora fcil de representar? concreta?

O usurios iro capt-la?
Pode ser estendida?
Pode ser enganosa ou irritante?
Ela casa com o estilo de interao?

Problemas com metforas

Podem romper regras culturais (ex. Lixeira na mesa)

Podem limitar o designer
Podem conflitar com princpios de bom design
Fora usurios a entender o sistema em termos da metfora.
Wireframes VIDEO 3 Wireframes 23min

O que so Wireframes

So como a planta do seu sistema ou site.

Documentam caractersticas do produto
Definem a funcionalidade por trs dos controles
Ilustram a aparncia (visual)

Exemplo de um Sketching
Contedo do Wireframe

Contedo - texto, vdeo, cones, animaes

Funcionalidade - controles, botes, alavancas, sliders, dials, campos de entrada
Navegao - Como controles acessam contedo

Anotaes do Wireframe

Descrevem caractersticas que no podem ser inferidas pela estrutura do wireframe

Permitem o entendimento do wireframe na ausncia do designer
Exemplos
o Controles
o Itens condicionais (ex. objetos que escurecidos ou realados)
o Restries (ex. tamanho mximo de um campo)

Metadados do Wireframe (pode ser um XML)

Nome do designer : Hugo de Paula

ltima modificao : Hoje
Verso : 3
ChangeLog : Adicionados novos itens de menu
Documentao relacionada : Rel. de prototipao, Seo 7.2
Questes pendentes : Usurio deve validar menu
Outros : Cliente deseja discutir cores

Observaes sobre o wireframe

Lembre-se que ele definir o layout de disposio dos componentes na interface.

No uma pr-visualizao
No se preocupe com fine art.

Construindo um Wireframe

Mantenha simples no incio (no incremente sem validar o bsico com seu usurio)
Siga um layout bsico, e a partir disto v evoluindo o seu layout
Identifique os links (use cor)
Identifique o local dos elementos grficos (foto do usurio, foto de notcias, etc)
Identifique o tipo de contedo (foto, video, texto, etc)
Papel e Lapis, pois est sempre disponvel
Ferramentas de diagramao, como Word ou Visio que podem ser utilizados
Ferramentas de Mockup (online e off-line) como Balsamiq, Wirefy ou Pencil Project
Exemplos de Ferramentas de Mockup

Pencil Project (Open Source)

Wirefy, faz engenharia reversa para sites

(Sites da Nokia e Samsung)

VIDEO DE APOIO Prottipo Rpido do Google Glass - Tom Chi 8 min

Textos
Introduo teoria e prtica da interao humano computador fundamentada na engenharia
semitica
Why You Should Talk Less and Do More
Guia Sobre Wireframing para Iniciantes
Metforas e Estilos de Interao
Wireframes
Unidade 04 - Avaliao e Teste de Usabilidade

VIDEO APOIO 1 Teste de usabilidade de sites 4 min

VIDEO APOIO 2 ISA11 Por que monitorar a experincia do usurio? 52 min

Palestra: Monitorando a experincia do usurio por meio da web analtica

VIDEO 3 Avaliao e Testes de Usabilidade 52 min

Avaliao e Testes

Inovao Six Sigma

O que a gente define como meta de usabilidade?

A meta est relacionada com os requisitos do sistema e estes requisitos so por conseguinte as
necessidades dos usurios. Requisito aquilo que o sistema precisa atender. Vimos que alm dos
requisitos funcionais tambm existem requisitos de usabilidade que precisam ser alcanados.
Kano Customer Need Model (Modelo de Necessidade do Cliente)

Mas basta a gente alcanas estes requisitos?

O que faz um cliente adorar um produto? Alm dos requisitos funcionais, suas tarefas bsicas, isto vai
gerar frustrao para o usurio. A frustrao a pior coisa que um produto gerar pois o cliente vai
associar o produto ruim com o fato da empresa ser ruim

Quanto pensamos na regra de Pareto (80/20) corremos o risco de pensar se o usurio somente vai usar
muito apenas algumas funcionalidades, que as outras podem ser efetuadas de qualquer jeito. Porm
Kano diz em seu modelo que se todas as funcionalidades bsicas funcionarem OK isso apenas garante
que o usurio no ir ficar frustrado. Ou seja, somente quando entregamos funcionalidades que o
usurio sequer imaginaria que seriam encontradas que conseguimos a satisfao (extase) do usurio.
As 8 dimenses da qualidade de produto de Garvin

Mitos sobre avaliao de usabilidade

Tempo
Acontece quando processo de teste atrasado.
Testes devem acontecer durante o desenvolvimento. Tempo
Testes devem ser alocados pela necessidade da sua informao.
Custo
Testes pilotos auxiliam na determinao da eficincia do teste.
Mudanas feitas ao produto em resposta a avaliao de usabilidade devem ser testados.
Testes produzem informaes que podem ser utilizadas transversalmente.
Contedo
Metas de avaliao devem ser bem definidas.
Testes especficos servem a etapas especficas.
Testes encontram defeitos, no solues.
Ferramentas de anlise adequadas devem ser empregadas.

por que devemos avaliar a usabilidade?

O design iterativo, com seu ciclo repetitivo de design e teste, a nica metodologia validada existente
que produzir resultados bem-sucedidos com consistncia. Se voc no dispuser de teste com o usurio
como uma parte integrante do seu processo de design, voc estar jogando muito dinheiro fora
Bruce Tognazzini (www.asktog.com)
Quando avaliar produtos interativos

Produtos que no existem

o Foco: desenvolvimento
Produtos que j existem
o Foco: melhoria
Pesquisa de mercado
Anlise do uso
Avaliando durante o processo de desenvolvimento
o Avaliaes formativas
Avaliando um produto desenvolvido
o Avaliaes somativas

Tcnicas de avaliao ergonmica (Cybis, 2003)

Tcnicas prospectivas
o Buscam a opinio do usurio sobre a interao com o sistema.
o Relacionada aplicao de questionrios / entrevistas
Tcnicas preditivas ou diagnsticas:
o Previso de erros de projetos de interface sem a participao do usurio
o Verificao de verses intermedirias
o Avaliaes Heursticas e Inspees por Checklist
Tcnicas objetivas ou empricas:
o Constatar os problemas a partir da participao direta de usurios
o Ensaios de interao e sesses com sistemas espies

Metodologias empricas e analticas

Testes de usabilidade servem para identificar e corrigir deficincias, assegurando a criao de

dispositivos fceis e satisfatrios de usar e que sejam valorizados por quem os usar
Rubin (1994)
Os quatro tipos de teste de usabilidade, de acordo com Rubin (1994)
o Testes exploratrios
o Testes de medio
o Testes de validao
o Testes de comparao
Metodologias empricas e analticas

Testes podem seguir diferentes tipos de tcnicas: observao, aplicao de questionrios e

entrevistas, testes com usurios Preece, Rogers e Sharp (2005)

Metodologias empricas (envolvem testes com usurios)

o Tcnicas prospectivas e empricas (CYBIS, 2003)
o Testes exploratrios, de validao e de medio (RUBIN, 1994)
o Questionrios, entrevistas e testes com usurios (PREECE, ROGERS e SHARP, 2005)
o
Metodologias analticas (envolvem avaliao de especialistas)
o Tcnicas preditivas (CYBIS, 2003)
o Testes de validao e comparao (RUBIN, 1994)
o Observao (PREECE, ROGERS e SHARP, 2005)

Avaliao de usabilidade

Avaliao
o testar usabilidade e funcionalidade do sistema.
o pode ocorrer em laboratrio, em campo, ou em colaborao com o usurio.
o avaliar projeto e implementao
Objetivos
o avaliar a extenso da funcionalidade do sistema.
o avaliar o efeito da interface no usurio.
o identificar problemas especficos.

Metodologias de teste

Combinar abordagens / Avaliaes oportunistas

Metodologias de teste e procedimentos de avaliao

Quando parar?

avaliaes no devem atrasar cronograma

avaliaes no devem estourar oramento
avaliaes devem ter objetivos claros
avaliaes devem prover informaes teis

Avaliao Heurstica VIDEO 4 Avaliao Heurstica

Avaliao Heurstica

mtodo simples, rpido e de baixo custo para avaliar IHC, quando comparado aos mtodos
empricos
tem como base um conjunto de heursticas de usabilidade, que descrevem caractersticas
desejveis da interao e da interface
Nielsen prope um conjunto de inicial de 10 heursticas, que pode ser complementado conforme
julgar necessrio
Heursticas de Nielsen

1 - visibilidade do estado do sistema - sempre manter os usurios informados sobre o que est
acontecendo atravs de feedback (resposta s aes do usurio) adequado e no tempo certo
2 - correspondncia entre o sistema e o mundo real - usar palavras, expresses e conceitos
familiares aos usurios, ao invs de utilizar termos orientados ao sistema seguir convenes do
mundo real; informao apresentada em uma ordem natural e lgica H
3 - controle e liberdade do usurio - os usurios frequentemente realizam aes equivocadas no
sistema e precisam de uma sada de emergncia claramente marcada para sair do estado
indesejado sem ter de percorrer um dilogo extenso. A interface deve permitir que o usurio
desfaa e refaa suas aes
4 - consistncia e padronizao - os usurios no devem ter de se perguntar se palavras,
situaes ou aes diferentes significam a mesma coisa designer deve seguir as convenes da
plataforma ou do ambiente computacional
5 - reconhecimento em vez de memorizao - designer deve tornar os objetos e as aes e
opes visveis instrues de uso do sistema devem estar visveis ou facilmente acessveis
sempre que necessrio
6 - flexibilidade e eficincia de uso - aceleradores podem tornar a interao do usurio mais
rpida e eficiente, permitindo que o sistema consiga servir igualmente bem os usurios
experientes e inexperientes
7 - projeto esttico e minimalista - a interface no deve conter informao que seja irrelevante
ou raramente necessria cada unidade extra de informao em uma interface reduz sua
visibilidade relativa, pois compete com as demais unidades de informao pela ateno do
usurio
8 - preveno de erros - melhor do que uma boa mensagem de erro um projeto cuidadoso que
evite que um problema ocorra, caso isso seja possvel
9 - ajude os usurios a reconhecerem, diagnosticarem e se recuperarem de erros - as
mensagens de erro devem ser expressas em linguagem simples (sem cdigos indecifrveis),
indicar precisamente o problema e sugerir uma soluo de forma construtiva
10 - ajuda e documentao - necessrio oferecer ajuda e documentao de alta qualidade.
Tais informaes devem ser facilmente encontradas, focadas na tarefa do usurio, enumerar
passos concretos a serem realizados e no ser muito extensas

Atividades da Avaliao Heurstica

preparao (todos os avaliadores)

o aprendem sobre a situao atual
o selecionam partes da interface que devem ser avaliadas
coleta de dados (cada avaliador, individualmente)
o inspeciona a interface
o documenta problemas que violam heursticas com local, justificativa, severidade e
proposta de soluo
 consolidao e relato dos resultados (todos os avaliadores)
o revisam os problemas encontrado
o julgam relevncia, gravidade e soluo
o geram relatrio

Fatores para severidade de problemas

frequncia com que o problema ocorre; um problema comum ou raro?

impacto ser fcil ou difcil para os usurios superarem o problema?
persistncia o problema ocorre apenas uma vez e ser superado pelos usurios, ou
atrapalhar os usurios repetidas vezes?

Escala de severidade de Nielsen

1- cosmtico: no precisa ser consertado

2- problema pequeno: baixa prioridade
3- problema grande: importante ser consertado
4- problema catastrfico: provavelmente impedir que o usurio realize suas tarefas e alcance seus
objetivos

Documentao dos problemas

Resultados da Avaliao Heurstica

Resultados da Avaliao Heurstica

Preo: relao custo/benefcio de 1: 48 [Nielsen94]

o custo de $10500 para benefcio de $500000
o Valor-problema ~$15K (Nielsen e Landauer)
Companhia: produtividade
mercado - vendas

Card Sorting VIDEO 5 Card Sorting 27 min

Projeto da arquitetura da informao (MAURER, 2008)

Projeto da Arquitetura da Informao
o Organizar contedo de modo que as pessoas descubram o que eles precisam.
(visibilidade)
Abordagem TopDow
o Focada no comportamento e necessidades dos usurios
o Refinamentos sucessivos
Abordagem BottomUp
o Baseada na informao em si.
o Classificao da informao pela sua unidade.
o Construo do modelo mental a partir da informao final.

Esquemas de classificao: por data

Esquemas de classificao: alfabtica

Esquemas de classificao: geogrfica

Esquemas de classificao: por tarefa

Esquemas de classificao: por pblico

Esquemas de classificao: por tpico

Boa Arquitetura da Informao
Combina objetivos do negcio com objetivos do usurio (utilidade e usabilidade)
Balanceia largura e profundidade. Permite alta visibilidade/encontrabilidade
Permite caminhos redundantes ao contedo.
Possui um modelo mental coerente.

Card-Sorting e Cluster Analysis para o projeto da arquitetura da informao

estrutura informao;
prov sugestes de navegao;
apoia elaborao de menus;
orienta construo de taxonomias.
Pode no prover a estrutura final, mas permite eliminar dvidas, identificar tendncias, etc.

Card Sorting Aberto

Participantes recebem conjuntos de cartas mostrando o contedo do sistema.
No h agrupamento prvio.
Usurios agrupam as cartas como acharem apropriado.
Usurios devem rotular/descrever cada grupo criado.

Card Sorting Fechado

Participantes recebem conjuntos de cartas mostrando o contedo do sistema.
Um conjunto de grupos iniciais fornecido.
Usurios alocam as cartas nos grupos predeterminados como acharem apropriado.

Vantagens do Card Sorting

Simples e barato (o nico custo preparao).
Rpido de ser aplicado (trabalho em grupo, sesses curtas)
Estabelecido (mais de 10 anos).
Envolve o usurio (tendncia maior facilidade de uso).

Perigos do Card Sorting (ZILSE, 2007)

Card Sorting uma abordagem Bottom-Up
Difcil manter unidade da informao
Importante garantir extensibilidade
No garante implementabilidade
No define a organizao da informao
No lida com a complexidade
Perigos do Card Sorting (ZILSE, 2007)

Card Sorting bidimensional por natureza

o Estrutura hierrquica no leva em considerao caractersticas hipertextuais do ser
humano.
o No leva em conta a construo de redes semnticas.
o No leva em considerao funcionalidades de busca.
Procedimento de aplicao rpido, mas anlise complicada e demorada.

Aplicao do Card Sorting (ROBERTSON, 2001)

Selecionar contedo
o Contedo existente (documentao e manuais)
o Descrio de grupos e processos.
o Contedo potencial futuro.
o Manter mesma granularidade.
o Amostragem significativa.
o Contedo pode ser revisado entre as sesses.
o Comprimento da lista gerencivel.
o No refletir estrutura atual.
o Refletir contedo e no formato.
o Evitar utilizar termos agrupadores.
o Terminologia adequada ao perfil do usurio.
o Lista feita por muitas pessoas evita processo cognitivo induzido.

Selecionar os participantes
o Individual ou em grupos em um nico teste.
o Testes repetidos diversas vezes.
o Grupos conseguem ordenar maior quantidade de cartas.
o Grupos so mais difceis de agendar.
o Grupos discutem em voz alta: deixa claro o processo cognitivo.

Preparar as cartas
o Rtulos curtos: fcil leitura.
o Detalhes: garantir clareza/entendimento.
o Indexados: facilitam anlise.
o Papel rgido mais durvel e mais fcil de manusear.
o Nmero de cartes entre 30 e 100.
Modos de execuo

A execuo do Card Sorting (ROBERTSON, 2001)

Se modo aberto:
o Dividir a pilha em subpilhas.
o Nomear cada uma das pilhas resultantes.
Se modo fechado:
o Alocar cada carto a uma das categorias preexistentes.
Funo do aplicador:
o Orientar os usurios e evitar divagaes.
o Permitir e encorajar a criao de um grupo A ser determinado, para garantir o trmino
da sesso (apenas no final).
o Descartar cartas que estejam causando confuso.
o Anotar/gravar consideraes dos usurios.

Anlise dos resultados do Card Sorting

Comparao simples por similaridades/diferenas

o Mesma estrutura est presente nos diversos testes.
o Diferenas entre testes podem representar:
particularidades de perfis de usurios;
contedo que os usurios no entenderam corretamente;
contedos que podem pertencer a mais de uma rea.
Tcnicas de agrupamento (clustering)
No garante a estrutura final, mas define:
o Forma de agrupamento.
 o Itens mais importantes.
o Profundidade e Largura da estrutura.
o Homogeneidade/Heterogeneidade do seu perfil de usurios.
o Associado ao questionrio identifica pontos crticos.

VIDEO 6 Framework DECIDE

Framework DECIDE (Preece et al., 2002)

Determine the goals the evaluation addresses Determinar as metas do teste

Explore the specific questions to be answered Explorar as questes a serem respondidas
Choose the evaluation paradigm and techniques to answer the questions Escolher o paradigma
(orientao) e tcnicas para o teste
Identify the practical issues Identificar as questes prticas
Decide how to deal with the ethical issues Decidir como lidar com questes ticas
Evaluate, interpret and present the data Avaliar, analisar e apresentar os dados
Decidindo objetivos do teste

aprenda sobre a situao atual: domnio do problema, papis e perfis dos usurios, seus
objetivos e atividades, e o contexto em que o sistema ou ser utilizado
conhea interfaces dos sistemas complementares ou semelhantes com os quais os usurios
estejam acostumados a utilizar, alm de, claro, a interface do prprio sistema ou prottipo a
ser avaliado
sempre que possvel, busque saber quais so os comportamentos e as dificuldades tpicos dos
usurios durante o uso de sistemas interativos semelhantes.
esse conhecimento necessrio para planejar a avaliao adequadamente e facilita a coleta e
anlise dos dados

Planejamento de uma avaliao de IHC deve definir

os objetivos e questes especficas de investigao

escopo da avaliao: quais partes da interface, caminhos de interao, tarefas devem fazer parte
da avaliao
os mtodos a serem utilizados
os perfis e o nmero de participantes

Escolher o paradigma e tcnicas para o teste

Metodologias de teste e procedimentos de avaliao

Questes prticas da avaliao

alocar pessoal, recursos e equipamentos preparar e imprimir o material de apoio:

o termo de consentimento
o questionrio (ou roteiro de entrevista) pr e ps-teste
o instrues e cenrios para orientar os participantes sobre as tarefas a serem realizadas;
o roteiro de acompanhamento da observao, de modo a facilitar a captura de dados e
anotaes
preparar todo ambiente, hardware e software
realizar um teste-piloto
recrutar participantes

Identificando e selecionando usurios

Definindo grupos de usurios (Noyes and Baber, 1999)

o Definir as caractersticas da populao de usurios.
o Trabalhar com uma amostra representativa do grupo identificado.
Complementando (Hackos and Redish, 1998):
o Lista preliminar de usurios (Brainstorm)
o Descrever caractersticas principais (incluindo tamanho do mercado)
o Descrever o principais grupos de usurios e atribuir prioridades.
o Selecionar usurios tpicos e representativos de cada grupo.
o Coletar informaes destes usurios e redefinir as descries de grupos.

Orientaes gerais observao em laboratrio

d oportunidade e tempo para o participante se acostumar com o ambiente e reduzir sua

ansiedade:
seja cordial e deixe o participante vontade
estabelea um conversa quebra-gelo
apresente o laboratrio, incluindo a sala de observao
oferea gua, caf, oportunidade para ir ao toalete
apresente a avaliao ao participante:
explique os objetivos do estudo, o sistema de interesse, o procedimento da
avaliao
informe os cuidados ticos sendo tomados
esclarea qualquer dvida do participante
entregue o termo de consentimento
caso o participante aceite, inicie a sesso de observao:
entregue o formulrio 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 instrues e os cenrios das tarefas
esclarea as eventuais dvidas
o participante passa a realizar as tarefas solicitadas
observe o participante:
um avaliador na sala de uso e outro na sala de observao
anote qualquer acontecimento relevante
no interfira, questione ou interrompa os participantes enquanto realizam as tarefas
depois de concludas as tarefas:
realize a entrevista ps-teste para esclarecer as dvida

Questes ticas

Questes centrais:
o privacidade,
o propriedade,
o prestao de contas.
Aspectos importantes (Diniz e Guillem, 2005):
o defesa dos direitos humanos;
o termo de consentimento livre e esclarecido; no caso de crianas e adolescentes,
opta-se pelo termo de assentimento;
o riscos da pesquisa;
Aspectos importantes (Diniz e Guillem, 2005):
o formas de recrutamento dos sujeitos;
o ressarcimento de gastos pessoais e a indenizao por danos;
o quebra de sigilo;
o confiabilidade sobre a origem das informaes.

Interpretao

anlise do material registrado para atribuir significado aos dados coletados

deve ser orientada pelo mtodo de avaliao utilizado e pelo planejamento da avaliao
os mtodos de avaliao costuma apontar:
os focos de anlise (i.e., quais dados devem ser analisados sob quais perspectivas de
anlise) e
os tipos de interpretaes mais frequentes
por exemplo
o mtodo de avaliao heurstica enfatiza a anlise de um conjunto de heursticas
o mtodo de avaliao de comunicabilidade investiga problemas na recepo da
metamensagem
Consolidao dos resultados

os resultados individuais so consolidados e analisados em conjunto, em uma anlise

denominada de intersujeito ou interparticipante.
busca recorrncias nos resultados de todos os participantes acordo com o mtodo selecionado.
Resultados comuns a participantes de um grupo permitem distinguir entre caractersticas do
grupo e especficas de cada participante.
Busca responder ou justificar por que alguma resposta no foi encontrada para as questes de
investigao.
A generalizao dos resultados exige muito cuidado, pois sempre so fortemente influenciados
pelo ambiente de avaliao e pelas caractersticas, preferncias, interesses e necessidades dos
participantes individuais.

Relato dos resultados

o relato dos resultados costuma incluir:

o os objetivos e escopo da avaliao;
o a forma como a avaliao foi realizada (mtodo de avaliao empregado);
o o nmero e o perfil de usurios e avaliadores que participaram da avaliao;
o relato dos resultados costuma incluir:
o um sumrio dos dados coletados, incluindo tabelas e grficos;
o um relato da interpretao e anlise dos dados;
o uma lista dos problemas encontrados;
o um planejamento para o reprojeto do sistema.

Textos

Avaliao e Testes de Usabilidade

Card Sorting

Framework DECIDE

Avaliao Heurstica
GABARITO ATIVIDADE OBJETIVA 04

1 Questo Assinale a assertiva verdadeira.

Alternativas de resposta
a) No h forma tica de se coletar dados de usurios sem o seu consentimento livre e esclarecido.
b) Entrevistas estruturadas so mais suscetveis a perder detalhes importantes que as entrevistas no
estruturadas.
c) A satisfao do usurio uma dimenso inerentemente subjetiva, e por isso no deve ser avaliada
com o uso de questionrios, devendo-se utilizar as entrevistas.
d) Heursticas de usabilidade so princpios gerais que orientam o projeto de uma interface e podem ser
utilizados em avaliaes por especialistas.

Gabarito Letra: d) - Justificativa: A questo aborda mecanismos de coleta de dados para avaliao de
interface. A resposta correta, letra (d) bem direta e objetiva, e afirma, corretamente, que as heursticas
so norteadores utilizados por especialistas para avaliao diagnstica.
A letra (a) afirma que o termo de consentimento livre e esclarecido obrigatrio para a coleta de dados
de usurios. Na verdade, o termo de consentimento livre e esclarecido deve ser assinado atestando que
o usurio tem cincia da coleta de dados, que ele conhece e compreende a extenso dessa coleta e a
destinao dos dados. Isso necessrio em avaliaes empricas, quando a interao do usurio est
sendo realizada. Em questionrios e entrevistas, no necessria a assinatura de um termo de
consentimento livre e esclarecido, apesar de ser desejvel que exista uma carta de apresentao
descrevendo os objetivos da avaliao e os possveis usos dos dados obtidos.
A letra (b) apresenta a diferena entre entrevista e questionrio, mas afirma que essa uma diferena
entre entrevista estruturada e no estruturada. Realmente, quando levamos em considerao a
aplicao de questionrios com questes fechadas, muitos detalhes so perdidos, em favor da facilidade
para a anlise desses dados. No caso de entrevistas, como o usurio tem a liberdade de falar
abertamente sobre o assunto, os detalhes podero ser captados pelo entrevistador. A diferena entre
entrevista estruturada e a no estruturada muito pequena e reside no fato da entrevista estruturada
possuir uma lista prvia dos assuntos que devem ser abordados, facilitando a conduo da entrevista. As
entrevistas no estruturadas permitem maior divagao por parte do usurio, e so especialmente teis
em fazes mais iniciais do projeto.
A letra (c) toca num ponto que fundamental em qualquer processo de avaliao e controle. Apesar da
satisfao do usurio ser subjetiva, ela pode e deve ser medida de forma quantitativa. Existem diversos
questionrios e metodologias que permitem avaliar quantitativamente se o projeto est caminhando na
direo da satisfao do usurio ou no.
2 Questo Em uma avaliao heurstica:

Alternativas de resposta
a) Um grupo de especialistas em usabilidade avaliam a interface com um extenso questionrio de
diretrizes.
b) Um grupo de usurios que so testados em um experimento formal.
c) Um grupo de especialistas em usabilidade que revisam a interface de acordo com um pequeno
nmero de princpios gerais.
d) Um grupo de psiclogos aplicando um questionrio.

Gabarito Letra: c) - Justificativa: Essa questo apresenta a definio direta de avaliao heurstica. A letra
(b) e a letra (d) podem ser diretamente eliminadas, por envolverem a participao do usurio. A grande
polmica foca entre a letra (a) e a letra (c). Em ambos os casos estamos tratando de avaliaes
diagnsticas, mas com uma pequena diferena, na letra (a), utiliza-se uma extensa lista de diretrizes de
design de interface, enquanto na letra (c) utiliza-se uma pequena lista de princpios gerais. A letra (a)
est descrevendo a inspeo por checklist, onde uma extensa lista de requisitos de interface checada
para analisar a conformidade do projeto. No caso da avaliao heurstica, letra (c), utiliza-se princpios
gerais para se identificar erros na interface.

3 Questo Explorar como duas crianas conversam entre si, com a finalidade de se desenvolver um
produto de groupware inovador, que iria ajudar as crianas a serem mais engajadas poderia buscar
informaes atravs de:

Alternativas de resposta
a) Avaliao preditiva.
b) Testes de usabilidade.
c) Estudos de campo
d) Framework DECIDE.

Gabarito Letra: c) - Justificativa: A questo aborda tcnicas de avaliao que envolvem o usurio.
Tcnicas de observao de usurio realizando tarefas no relacionadas diretamente ao sistema (como no
caso do enunciado) constituem estudos de campo, letra (c). Avaliaes preditivas, letra (a), no
envolvem o usurio; os testes de usabilidade, letra (b), observam o usurio interagindo com o sistema
em ambiente controlado, e o framework DECIDE no est relacionado diretamente com nenhuma
tcnica de coleta de informao, mas a penas uma metodologia de definio de processo de avaliao.
4 Questo A seleo correta dos usurios decisiva para o sucesso de uma avaliao de usabilidade.
Sobre a seleo de usurios, assinale a alternativa incorreta:

Alternativas de resposta
a) A armadilha do usurio gerente faz com que seja selecionado um usurio que, apesar de ser o
comprador do sistema, no ser ele que efetivamente ir us-lo.
b) Lead user, ou power user, excelente para se obter ideias inovadores e se problemas mais
consistentes, mas no detecta pequenas imperfeies na interface.
c) Estatisticamente, quanto mais usurios, melhor, mas com grupos de 20 usurios podemos identificar
80% dos problemas de usabilidade.
d) Para potencializar a coleta de dados, deve-se selecionar usurios especficos, representativos de todos
os perfis de usurio que iro utilizar o sistema.

Gabarito Letra: c) - Justificativa: A questo aborda os critrios de seleo de usurios. A resposta

incorreta a letra (c), que apresenta uma informao que no tem nenhum fundamento. Realmente, a
estatstica amostral indica que uma amostra maior produzir resultados com maior grau de confiana
estatstica, mas no existe nenhum estudo que garante que 20 usurios iro identificar 80% dos erros de
usabilidade. Existe um estudo de Nielsen, focado em especialistas que afirma que 5 especialistas so o
suficiente para levantar 80% dos erros de usabilidade em uma avaliao heurstica. Vamos analisar as
outras questes. A questo aborda os critrios de seleo de usurios.
A resposta incorreta a letra (c), que apresenta uma informao que no tem nenhum fundamento.
Realmente, a estatstica amostral indica que uma amostra maior produzir resultados com maior grau de
confiana estatstica, mas no existe nenhum estudo que garante que 20 usurios iro identificar 80%
dos erros de usabilidade. Existe um estudo de Nielsen, focado em especialistas que afirma que 5
especialistas so o suficiente para levantar 80% dos erros de usabilidade em uma avaliao heurstica.
Vamos analisar as outras questes.
A letra (a) aborda o problema do usurio gerente. O usurio gerente o cliente que contrata o
desenvolvimento do software, mas no quem vai efetivamente utilizar o sistema. Essa armadilha
realmente existe e deve ser evitada.
A letra (b) descreve o papel do lead user, ou power user. O lead user, ou usurio lder um usurio que
est sempre buscando solues e, por isso, pode auxiliar a identificar novos recursos potenciais para o
sistema. Por ser um usurio experiente e proativo, ele no se incomoda nem percebe como obstculo,
pequenos problemas de interface que no impactam na realizao da tarefa.
Finalmente, a letra (d) aborda um assunto que sempre reforado quando se trata de selecionar
usurios. Apesar da estatstica sugerir que, para se realizar uma pesquisa de opinio, deve-se realizar
uma amostragem aleatria do seu universo de pesquisa, na rea de usabilidade no se est buscando a
opinio mdia de uma populao. No caso de testes de usabilidade, se um erro foi detectado por
apenas uma pessoa ele no deixa de ser erro apenas porque, na mdia, as pessoas no o detectaram.
Em avaliao de interface, deve-se buscar a maior diversidade de perfis possvel, de modo a manter um
nmero reduzido de usurios capazes de identificar uma mxima diversidade de erros de usabilidade.