Avaliação de Interfaces - Livro Profa. Heloísa

Interação Humano-
Computador
Avaliação de Interfaces
ROCHA, Heloisa Vieira da; BARANAUSKAS, Maria Cecília C. Design e
Avaliação de Interfaces Humano-Computador. Campinas,
SP:NIED/UNICAMP.
Capítulo 4.
Agenda
o Introdução;
o Avaliação Heurística;
o Percurso Cognitivo;
o Teste de Usabilidade.
18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 2

Introdução
Avaliação não deve ser vista como uma fase única dentro do
processo de design e muito menos como uma atividade a ser
feita somente no final do processo e se "der tempo".
Idealmente, avaliação deve ocorrer durante o ciclo de vida do

design e seus resultados utilizados para melhorias gradativas da
interface.
Existe uma forte correlação entre avaliação e as técnicas de

modelagem e construção de protótipos, pois essas técnicas
garantem que o design está constantemente sob avaliação.

Introdução
Na maioria de modelos de desenvolvimento de interfaces
usáveis a avaliação tem um papel central.
Ex: Modelo estrela.

Introdução
Nos estágios bem iniciais onde ideias estão sendo exploradas e
tentadas, muitas vezes testes bastante informais são suficientes.
Por exemplo, depois de uma sessão de discussão (brainstorming)

para explorar diferentes metáforas.
Em estágios um pouco mais avançados do processo, avaliações

mais formais devem ser planejadas.

Introdução
Fatores importantes para elaborar um plano de avaliação:
●
estágio do design (inicio, meio ou fim)
●
quão pioneiro é o projeto (bem definido versus exploratório)
●
número esperado de usuários
●
quão crítica é a interface (por exemplo, um sistema de controle
de tráfego aéreo versus um sistema de orientação de um
shopping)
●
custo do produto e orçamento alocado para o teste
●
tempo disponível
●
experiência dos designers e avaliadores

Introdução
O domínio do plano de avaliação pode estar entre um ambicioso
teste de dois anos, com múltiplas fases, de um novo sistema de
controle de tráfego aéreo até um discreto teste de três dias com
seis usuários de um sistema interno de contabilidade.
Custo pode variar de 10% a 1% do valor total do projeto.
Deve-se ter claro que um certo grau de incerteza sempre

permanece mesmo após exaustivos testes com múltiplos
métodos.
Deve-se ter em vista ao analisar métodos de avaliação que eles

apresentam resultados bastante satisfatórios para grande parte
dos sistemas em condições normais de uso.

Introdução
Três técnicas serão abordadas:
●
Avaliação Heurística;
●
Percurso Cognitivo;
●
Teste com usuários.
Na maioria das situações práticas uma ou mais técnicas são
adotadas e adaptadas para atender as necessidades específicas
da interface sob avaliação.
Geralmente os recursos disponíveis têm um grande impacto no
tipo de avaliação a ser feita.
Selecionar a técnica de avaliação adequada envolve escolher,
misturar e adaptar técnicas a partir do conjunto de técnicas
disponíveis.

Algumas técnicas de
avaliação
Não envolvem os usuários,
podem ser usadas em qual- Avaliação de
quer fase do desenvolvimento
interfaces
Também chamada
de avaliação analítica
Inspeção de Métodos Experimentos Testes de

usabilidade interpretativos controlados usabilidade
Avaliação Percurso Avaliação Avaliação Uso de

heurística Geralmente estes métodos
cognitivo participativa conceitual laboratórios envolvem os usuários, sendo
Revisão de Inspeção de Avaliação necessário algum tipo de
Implementação.
Guidelines Consistência etnográfica
Também chamados de
métodos de avaliação empíricos.

Objetivos
De forma geral, se faz avaliação para conhecer o que os usuários
querem e os problemas que eles experimentam.
Muitas questões poderiam ser objetivo de uma avaliação.
O setor de marketing poderia estar interessado em como o

produto de sua empresa se compara com produtos de outros
competidores do mercado.
Produtos também podem ser avaliados no sentido de verificar se

estão de acordo com padrões específicos, como as normas ISO,
por exemplo.

Objetivos
Resumidamente, podemos dizer que avaliação tem três grandes
objetivos:
(1) Avaliar a funcionalidade do sistema;
(2) Avaliar o efeito da interface junto ao usuário;
(3) Identificar problemas específicos do sistema.

Objetivos
Avaliar a funcionalidade:
Inclui não somente ter a funcionalidade adequada disponível,

mas também torná-la usável, na forma de ações que o usuário
precisa efetuar para executar a tarefa.
Envolve também medir a performance do usuário junto ao

sistema, ou seja, avaliar a eficiência do sistema na execução da
tarefa pelo usuário.

Objetivos
Avaliar o efeito da interface junto ao usuário:
Medir o impacto do design junto ao usuário, ou seja, avaliar sua

usabilidade.
Isso inclui considerar aspectos tais como: avaliar quão fácil é

aprender a usar o sistema; a atitude do usuário com relação ao
sistema; identificar áreas do design as quais sobrecarregam o
usuário de alguma forma, por exemplo, exigindo que uma série
de informações sejam relembradas.

Objetivos
Identificar problemas específicos do sistema:
Identificar aspectos do design os quais quando usados no

contexto alvo, causam resultados inesperados ou confusão entre
os usuários.
Isso é claro está correlacionado tanto com a funcionalidade

quanto com a usabilidade do design.

Inspeção de Usabilidade
Métodos de avaliação baseado em Inspeção de usabilidade
objetiva encontrar problemas no design de uma interface e com
base nesses problemas fazer recomendações no sentido de
eliminar os problemas e melhorar a usabilidade do design.
A maioria dos métodos de inspeção terão um efeito significativo

na interface final somente se forem usados durante o ciclo de
vida do projeto.
Uma inspeção pode demorar de 12hs até 40hs, dependendo da

complexidade da interface e de seus procedimentos
operacionais, além do contexto da tarefa que necessariamente
deverá ser conhecido pelo avaliador.

Avaliação Heurística
Segundo Nielsen:
●
É fácil (pode ser ensinada em 4hs);
●
É rápida (cerca de 1 dia para a maioria das avaliações);
●
É tão barata quanto se deseje.
É possível efetuar a avaliação em interfaces que existam apenas

em papel e que ainda não foram implementadas.

Como é realizada
Envolve um pequeno conjunto de avaliadores (de 3 a 5)
examinando a interface e julgando suas características em face
de reconhecidos princípios de usabilidade, denominados
heurísticas (Nielsen Propõe 10 – veremos adiante).
Primeiro momento: Cada avaliador percorre a interface

diversas vezes (no mínimo 2 vezes) inspecionando os diferentes
componentes do diálogo e ao detectar problemas os relata
associando-os claramente com as heurísticas de usabilidade que
foram violadas (costuma durar em torno de 2 horas).
Segundo momento: As listas de problemas dos avaliadores são

consolidadas em uma só.

Heurísticas
1. Visibilidade do status do sistema
O sistema precisa manter os usuários informados sobre o que está acontecendo, fornecendo
um feedback adequado dentro de um tempo razoável.
2. Compatibilidade do sistema com o mundo real

O sistema precisa falar a linguagem do usuário, com palavras, frases e conceitos familiares
ao usuário, ao invés de termos orientados ao sistema. Seguir convenções do mundo real, fazendo
com que a informação apareça numa ordem natural e lógica.
3. Controle do usuário e liberdade

Usuários frequentemente escolhem por engano funções do sistema e precisam ter claras
saídas de emergência para sair do estado indesejado sem ter que percorrer um extenso diálogo.
Prover funções undo e redo.

Heurísticas
4. Consistência e padrões
Usuários não precisam adivinhar que diferentes palavras, situações ou ações significam a
mesma coisa. Seguir convenções de plataforma computacional
5. Prevenção de erros
Melhor que uma boa mensagem de erro é um design cuidadoso o qual previne o erro antes
dele acontecer.
6. Reconhecimento ao invés de relembrança

Tornar objetos, ações e opções visíveis. O usuário não deve ter que lembrar informação de
uma para outra parte do diálogo. Instruções para uso do sistema devem estar visíveis e
facilmente recuperáveis quando necessário.
7. Flexibilidade e eficiência de uso

Usuários novatos se tornam peritos com o uso. Prover aceleradores de formar a aumentar a
velocidade da interação. Permitir a usuários experientes "cortar caminho" em ações freqüentes.

Heurísticas
8. Estética e design minimalista
Diálogos não devem conter informação irrelevante ou raramente necessária. Qualquer
unidade de informação extra no diálogo irá competir com unidades relevantes de informação e
diminuir sua visibilidade relativa.
9. Ajudar os usuários a reconhecer, diagnosticar e corrigir erros

Mensagens de erro devem ser expressas em linguagem clara (sem códigos) indicando
precisamente o problema e construtivamente sugerindo uma solução.
10. Help e documentação

Embora seja melhor um sistema que possa ser usado sem documentação, é necessário
prover help e documentação. Essas informações devem ser fáceis de encontrar, focalizadas na
tarefa do usuário e não muito extensas.

Heurísticas específicas
O avaliador pode adicionalmente considerar heurísticas
específicas da categoria do produto sendo analisado, por
exemplo, heurísticas derivadas da análise de produtos similares
e seus resultados de uso.
Exemplos de heurística para sistema com muitas entradas de

dados usando formulário:
1. Opções de menu significativas e agrupadas logicamente
O agrupamento e os nomes das opções do menu são pistas para o usuário encontrar a
opção requerida.
2. Agrupamento lógico e sequencial dos campos
O sistema deve dispor os campos de forma lógica e sequencial nos formulários. O
agrupamento lógico facilita a entrada de dados tanto para usuários iniciantes quanto experientes.
3. Agilidade na movimentação do cursor
O sistema deve facilitar a mudança de um campo para outro nos formulários através de
teclas de atalho além do mouse, como o TAB ou ENTER.

Resultado da avaliação
O resultado de uma avaliação heurística é uma lista de
problemas de usabilidade da interface com referências aos
princípios de usabilidade que foram violados.
O avaliador não pode simplesmente dizer que não gosta de um

determinado aspecto, tem que justificar com base nas
heurísticas e tem também que ser o mais específico possível e
listar cada problema encontrado separadamente.
Vejamos alguns exemplos:

Exemplo (avaliação heurística)
Em um sistema para oferecimento de cursos a distância denominado
TelEduc, a ferramenta de correio eletrônico não permite o envio de
mensagens sem o preenchimento do campo assunto (subject). Essa
característica é uma fonte de erros constante, pois a maioria dos
sistemas de correio permite isso, emitindo apenas um aviso. A heurística
violada é a de prevenção de erros.
Também deve ser observada a mensagem de erro inadequada - Você não

informou o assunto da correspondência – usando o termo
correspondência que não é natural no contexto de mensagens. Heurística
violada - consistência e padrões.
A recuperação do erro também é difícil, pois ao retornar à tela de

composição da mensagem ela tem que ser completamente refeita.
Portanto, mais uma heurística violada - ajudar os usuários a reconhecer,
diagnosticar e corrigir erros.

No sistema Windows quando se quer instalar um
novo componente de hardware é inciado um
processo de busca e o indicador de detecção
pode ficar parado por muito tempo, como
indicado na janela de diálogo. O usuário fica
perdido na maioria das vezes por não saber o
que significa esse muito tempo e não sabe se
deve ou não reiniciar o computador, mesmo
porque usuários de sistemas semelhantes sabem
quão pouco confiável é a relação da barra de
detecção com o real andamento da operação
(Heurísticas violadas: visibilidade e status do
sistema; ajudar os usuários a reconhecer,
diagnosticar e corrigir erros).

No Dia das Crianças um provedor fez uma página especial que dava
entrada para uma página de jogos (Figura 4.5). Nessa página uma coleção
de termos técnicos é encontrada e as crianças, potencialmente usuários
novatos, não conseguem entender o que tem que fazer para atingir seu
objetivo, que é jogar (Heurística violada: compatibilidade do sistema com o
mundo real).

O software Winzip em uma mesma versão gratuita (não registrada)

tem uma tela de abertura onde os botões aparecem em ordem
aleatória a cada execução. Arbitrariamente os botões Accept e
Quit aparecem em ordem trocada levando o usuário a errar sem
saber porque (Heurísticas violadas: consistência e padrões;
prevenção de erros).

Visibilidade e status do sistema;

Consistência e padrões.

Software para download.

Qual problema podemos identificar?

Software para download. Visibilidade e status do sistema;

Qual problema podemos identificar? Compatibilidade com o mundo real.

Quais problemas
podem ser observados?

Exemplo
(avaliação heurística)
1. O nome do sistema está muito proeminente. Tornando-o menor, poderia ser
aproveitado o espaço para outros componentes alternativos do diálogo, ou a tela
poderia ficar menos carregada (estética e design minimalista).
2. O mapa poderia apresentar os nomes de pelo menos algumas cidades grandes
ou outras informações que pudessem auxiliar o usuário a se localizar. Cuidado
deve ser tomado para não sobrecarregar demais o mapa (compatibilidade do
sistema com o mundo real, visibilidade do status do sistema).
3. Mesmo que tempo não respeite limites políticos, é muito difícil ler um mapa que
não apresenta limites de estados ou países (compatibilidade do sistema com o
mundo real, visibilidade do status do sistema).
4. O formato da data (dia/mês/ano) pode ser mal interpretado por usuários
estrangeiros. Um meio de evitar isso é representar o mês por seu nome ao invés
de seu número (prevenção de erros).

Exemplo
5. Os zeros na data estão cortados, o que é um modo computacional de escrever

zeros. Usar um tipo regular de zeros (compatibilidade do sistema com o mundo
real).
6. O termo “Precipitação” pode ser de difícil entendimento para usuários

estrangeiros (que são usuários alvo do sistema). Poderia ser considerada a
possibilidade de usar palavras simples como Chuva/Neve. Usabilidade
internacional poderia ser aumentada adicionando ícones como um termômetro
para temperatura e gotas de chuva para precipitações (compatibilidade do
sistema com o mundo real).

Exemplo
7. O display das temperaturas em Farenheit e Celsius são mutuamente

exclusivos, com um dos dois ativos em um dado momento. Portanto, a escolha da
escala da temperatura deveria ser feita via radio buttons e não com check boxes,
que geralmente são utilizados para opções não mutuamente exclusivas
(consistência e padrões).
8. A seleção da escala da temperatura não é uma informação adicional do mesmo

tipo que Temperature/Precipitation/Visibility/Wind. A escolha da escala da
temperatura deveria ser agrupada com a seleção da temperatura e deveria ser
desativada (gray out) quando temperatura não é escolhida (estética e design
minimalista; compatibilidade do sistema com o mundo real)

Exemplo
9. Não está aparente na tela o modo de sair do sistema. Adicionar uma caixa
close ou um botão quit (controle do usuário e liberdade).
10. O sistema não tem nenhuma característica de ajuda. Espera-se que a

interface seja redesenhada e que os usuários não necessitem de ajuda, mas o
sistema certamente continuará complexo o suficiente para prover uma tela de
help. Por exemplo, a tela de help poderia explicar como o dado de visibilidade
deve ser interpretado (Ajuda e documentação).

Graus de Severidade
Adicionalmente à lista de problemas de usabilidade detetados, a
avaliação heurística pode ser usada para avaliar a gravidade de
cada problema. Esta informação é importante no momento em
que forem alocados recursos para corrigir os problemas mais
sérios e se necessário deixar os menos graves para uma nova
versão.
Combinação de três fatores:

●
a frequência com que ele ocorre: se é comum ou raro.
●
impacto do problema quando ele ocorre: se é fácil ou difícil para o
usuário superá-lo.
●
a persistência do problema: problema que ocorre uma única vez e que
o usuário pode superar desde que saiba que ele existe, ou se os
usuários serão repetidamente incomodados por ele

Graus de Severidade
Usualmente se faz uma tabela onde os avaliadores indicam, de
modo bastante, subjetivo a severidade dos problemas.
1. eu não concordo que isso é um problema de usabilidade;

2. é um problema cosmético somente - precisa ser corrigido
somente se sobrar algum tempo no projeto;
3. problema de usabilidade menor - corrigi-lo deve ter prioridade
baixa;
4. problema de usabilidade grave - importante corrigi-lo, deve
ser dada alta prioridade;
5. catástrofe de usabilidade - a sua correção é imperativa antes
do produto ser liberado

Considerações (avaliação heurística)
Avaliação heurística não objetiva prover meios de corrigir os

problemas em um redesign e não levanta os aspectos positivos do
design. Porém, seus resultados podem ser usados como uma forma
a prover efetivas soluções de redesign a partir de uma reunião
final envolvendo a equipe de avaliadores e representantes da
equipe de desenvolvimento.
Na reunião podem ser levantados os aspectos positivos do design,

evitando que estes sejam alterados ou eliminados em um
redesign.

Avaliação heurística tem se mostrado um bom método para

determinar tanto problemas graves como problemas menores de
usabilidade.
Problemas de usabilidade em um diálogo podem ser localizados

de quatro maneiras diferentes:
●
Em um único local da interface;
●
Em dois ou mais locais que devem ser comparados para se
detectar o problema;
●
Um problema da estrutura geral da interface;
●
Algo que precisa ser incluído na interface.

Não existem diferenças significativas na quantidade de

problemas localizados de alguma das maneiras, o que indica que
avaliadores têm igual facilidade de localizar qualquer um dos
tipos de problemas.
A diferença que existe é no estágio de implementação da

interface e o tipo de problema que pode ser detectado. Por
exemplo, componentes de diálogo que precisariam ser incluídas
(que faltam) são difíceis de serem detectadas em interfaces em
estágio muito primário de desenvolvimento (em papel, por
exemplo).

Segundo Nielsen os principais componentes de uma avaliação

heurística podem ser resumidos como:
●
Avaliadores devem percorrer a interface pelo menos duas
vezes. Na primeira vez devem se concentrar no fluxo e na
segunda nas componentes individuais do diálogo.
●
A interface deve ser inspecionada com base em uma lista de
princípios de usabilidade, as denominadas heurísticas, e todos
os problemas devem ser justificados e detalhados o máximo
possível.
●
Combinar os problemas encontrados por 3 a 5 avaliadores e
fazer com que trabalhem individualmente (sem que um
influencie o outro).

Proposta de Atividade 1
1) Selecionar para avaliação um protótipo construído em sala (no
mínimo três avaliadores para um único protótipo - o autor do protótipo não deve avaliar o seu
próprio protótipo).
2) Realizar a avaliação do protótipo selecionado, produzindo uma

lista com os problemas de usabilidade encontrados (cada avaliador
deve fazer seu trabalho de forma individual).
3) Reunião entre os membros avaliadores para consolidar a lista

de problemas em uma única lista.
4) Realizar a definição do grau de severidade para a lista

unificada de problemas realizada no passo anterior (cada avaliador
deve fazer seu trabalho de forma individual).
5) Construção do documento sintetizado contendo a lista de

problemas e o grau de severidade aplicado por cada avaliador.

Projeto Oré (avaliação heurística)
O Projeto Oré (Oré, 2001) tem por objetivo desenvolver um ambiente de groupware para apoiar o
trabalho da comunidade de uma organização não-governamental, a Associação Saúde-Criança
Renascer (ASCR). A primeira etapa no desenvolvimento deste ambiente foi o projeto de um quadro
de avisos, onde funcionários e voluntários da ASCR poderiam colocar e ler avisos sobre as atividades
e notícias relevantes. Durante a etapa de design identificou-se que grande parte dos membros da
comunidade da ASCR tinham uma grande resistência ao uso de computadores (Barbosa et al., 2001).
Assim, um dos objetivos do design do Quadro de Avisos era que este fosse simples o suficiente para
que as pessoas o aprendessem rapidamente e facilmente, ajudando-as, em alguns casos, a superar
seus sentimentos negativos relativos ao computador.
O conjunto de funcionalidades do Quadro de Avisos era pequeno e continha funções para criar,
alterar, remover ou ler um aviso. Além disso, ele possuía dois espaços, um público e outro privativo
da comunidade. O espaço público estaria aberto ao público em geral, e no qual só se podia ler os
avisos classificados como públicos. No espaço privativo o membro tinha acesso a todos os avisos
públicos e mais aqueles privativos relacionados com o trabalho em que estava envolvido na ASCR.
Além disso, para facilitar o uso da aplicação decidiu-se oferecer mecanismos de explicação e ajuda
ostensivos aos usuários. Quando acionados, estes mecanismos apresentavam uma ajuda em função
do contexto em que o usuário se encontrava, de forma simples e direta. Caso desejasse, o usuário
poderia se aprofundar mais nas explicações. Como avaliação do projeto foi feita uma inspeção
informal e um teste em laboratório utilizando o protótipo proposto do quadro de avisos. A partir dos
problemas identificados nesta avaliação foi projetada uma nova interface para o Quadro de Avisos.


Problemas encontrados
Problema: O usuário não conseguirá entender que o texto “privativo da comunidade” lhe dá acesso
a um espaço com mais funcionalidades do que aquele em que ele se encontra.
Heurística violada: correspondência entre o sistema e o mundo real.
Explicação: Embora na sede da ASCR tenha alguns espaços que normalmente só são acessíveis por
membros da comunidade, o usuário não utiliza a palavra “privativo” no seu cotidiano e não saberá a
que ela se refere.
Gravidade: 4 – catastrófico. O usuário não conseguirá acessar as funcionalidades que estão
disponíveis apenas para membros, como por exemplo ler avisos específicos ao trabalho em que está
envolvido, ou criar um novo aviso.
Problema: O texto “Quadro geral” não transmite a idéia do que está sendo visualizado
Heurística violada: reconhecimento.
Explicação: O que está sendo mostrado na seção denominada Quadro Geral são os avisos do
Quadro de Avisos que foram colocados em destaque.
Gravidade: 3 – grave. Como os usuários na sua maioria têm pouca experiência com informática,
pode não ficar claro para eles que os avisos no Quadro geral são aqueles selecionados para estarem
em destaque e podem aparecer também em outras seções. Isto pode comprometer o entendimento
do usuário sobre como utilizar o Quadro de Avisos.

Problemas encontrados
Problema: A representação das diversas seções do Quadro de Avisos não está clara.
Heurística violada: correspondência entre o sistema e o mundo real.
Explicação: O Quadro de Avisos foi dividido em vários setores, possibilitando diferentes
visualizações deste. No entanto, no mundo real um quadro de avisos não tem visualizações distintas,
e além disso na ASCR não existem quadro de avisos específicos aos setores com acesso restrito às
pessoas envolvidas naquele setor.
Gravidade: 4 – catastrófico. O usuário pode não conseguir entender que conceitos, do que ele
conhece sobre quadro de avisos, podem ser transportados para o sistema, e o que é diferente. Ele
poderá ter grande dificuldade em entender e utilizar o sistema.

Percurso Cognitivo
Percurso cognitivo é um método de inspeção de usabilidade que
tem como foco principal avaliar o design quanto à sua facilidade
de aprendizagem, particularmente por exploração.
O foco na aprendizagem foi motivado por resultados de estudos

que apontavam que usuários preferem aprender a usar um
software por exploração. Ao invés de investir tempo em
treinamento formal ou leitura de extensivo material de apoio,
usuários preferem aprender sobre um software enquanto
trabalham em suas tarefas usuais, adquirindo conhecimento
sobre as características do software à medida que delas
necessitem.

Percurso Cognitivo
Os revisores avaliam a interface proposta no contexto de uma ou
mais tarefas do usuário.
A entrada para uma sessão de percurso inclui:

●
Uma descrição detalhada da interface (na forma de um
protótipo executável ou uma maquete em papel),
●
O cenário da tarefa;
●
Suposições explícitas sobre a população de usuários e o
contexto de uso;
●
A sequência de ações que o usuário terá que fazer para
executar corretamente a tarefa.

Percurso Cognitivo
O processo de percurso pode ser dividido em duas fases básicas
(Preparatória e Análise):
Fase Preparatória:
Analistas definem tarefas, sequências de ações para cada tarefa,

população de usuários e a interface a ser analisada.
1)Quem serão os usuários do sistema?

2)Qual tarefa (ou tarefas) devem ser analisadas?
3)Qual é a correta sequência de ações para cada tarefa e como
pode ser descrita?
4)Como é definida a interface?

Fase Preparatória
(percurso cognitivo)
Quem são os usuário do sistema?
Pode ser uma descrição simples e geral tal como, "pessoas que
usam LINUX". Mas o processo de percurso é mais revelador se a
descrição inclui mais especificamente a experiência e
conhecimento técnico que podem influenciar os usuários na
interação com uma nova interface. Por exemplo, usuários podem
ser "Usuários de Windows que trabalham com o Microsoft Word".
No processo de percurso são considerados o conhecimento do

usuário com relação à tarefa e com relação à interface.

Fase Preparatória
Qual tarefa (ou tarefas) será analisada?
O percurso envolve a detalhada análise de uma ou várias tarefas. É

possível fazer a análise de todas as tarefas associadas a um sistema com
funcionalidade simples, como um sistema de compactação de arquivos,
por exemplo.
Em geral, para sistemas com alguma complexidade, a análise deverá ser

limitada a uma razoável, mas representativa, coleção de tarefas.
Tarefas devem ser escolhidas a partir da funcionalidade central da

aplicação, isto é, operações básicas que se pretende que o sistema deva
suportar. Adicionalmente, outras tarefas que requeiram uma combinação
dessas funções básicas podem ser consideradas.

Fase Preparatória
Qual a correta sequência de ações para cada tarefa e

como é descrita?
Para cada tarefa, deve haver uma descrição de como se espera que o
usuário veja a tarefa antes de aprender sobre a interface. Também deve
haver uma descrição da sequência de ações para resolver a tarefa na
atual definição da interface. Essas ações podem incluir movimentos
simples como "pressionar a tecla ENTER" ou "mover o cursor para o
menu File", ou, podem ser sequências de diversas ações simples que o
usuário típico pode executar como um bloco, tais como "Logar no
sistema" para usuários experientes em UNIX, ou selecionar o "Salvar
como do menu File" para usuários experientes em Windows. A decisão
sobre a granularidade da descrição depende muito da expertise do
usuário alvo. A grosso modo, pode-se definir que a descrição deve ser
equivalente a descrição que seria colocada em um tutorial eficiente.

Fase Preparatória
Como a interface é definida?
A definição da interface precisa descrever as entradas que precedem

cada ação requerida para completar as tarefas que estão sendo
analisadas como também a reação da interface para cada uma de suas
ações. Se a interface já está implementada, toda informação estará
disponível na implementação.
Para uma interface descrita em papel, o detalhamento da definição da

interface irá depender da experiência pretendida dos usuários alvo com
sistemas que já existem. Por exemplo, a preparação para analisar uma
aplicação Windows dirigida para usuários experientes em Windows, não
precisa prover uma descrição detalhada da aparência padrão de menus
Windows; uma descrição simples de seus conteúdos é suficiente.

Percurso Cognitivo
Fase de análise:
Objetiva contar uma estória verossímil que informe sobre o

conhecimento do usuário e objetivos, e sobre o entendimento do
processo de solução de problemas que leva o usuário a
"adivinhar" a correta solução. Analistas respondem 4 questões:
1) Os usuários farão a ação correta para atingir o resultado desejado?
2) Os usuários perceberão que a ação correta está disponível?
3) Os usuários irão associar a ação correta com o efeito desejado?
4) Se a ação correta for executada os usuários perceberão que foi feito um

progresso em relação a tarefa desejada?
Uma estória verossímil de fracasso será contada se algumas das

questões acima tiver resposta negativa.

Fase de Análise
Os usuários farão a ação correta para atingir o resultado

desejado?
Se a interface falha nesse ponto, existem pelo menos três opções para
tentar corrigir:
1) A ação precisa ser eliminada, ou o sistema a efetua ou deve ser
combinada com outra ação mais adequada;
2) Um prompt deve ser dado ao usuário informando-o sobre qual ação
deve ser feita;
3) Alguma outra parte da tarefa precisa ser mudada de forma que o
usuário entenda a necessidade da ação, talvez porque passe a ser
consistente com alguma outra parte da sequência de ações.

Fase de Análise
Os usuários perceberão que a ação correta está

disponível?
Se o usuário tem os objetivos corretos mas não sabe que a ação está
disponível na interface, a solução é associar a ação a um controle mais
óbvio. Isso tipicamente envolve o uso de um menu ou prompt, ao invés
de uma tecla de controle; ou pode envolver associar a ação a um controle
mais escondido mas que pode ser facilmente descoberto por estar
significativamente agrupado.

Fase de Análise
Os usuários irão associar a ação correta com o efeito

desejado?
Para corrigir essa falha os designers precisam conhecer seus usuários e a

forma como descrevem a tarefa. Com essa informação o designer pode
prover rótulos e descrições para ações que incluam palavras que os
usuários frequentemente usam para descrever suas tarefas. Pode ser
necessário redefinir rótulos ou outros controles que os usuários
selecionam em preferência aos corretos. Também pode envolver um
reagrupamento de funções em menus de forma mais significativa com
relação à visão que o usuário tem da tarefa.

Fase de Análise
Se a ação correta for executada os usuários perceberão

que foi feito um progresso em relação à tarefa desejada?
Claramente, na maioria das situações qualquer feedback é melhor que

nenhum feedback. E feedback que indica o que aconteceu é sempre
melhor que um feedback que indica que alguma coisa aconteceu.
Respostas são sempre mais efetivas quando usam termos (ou gráficos)
relacionados à descrição do usuário para a tarefa.

Considerações (percurso cognitivo)
Percurso cognitivo avalia cada passo necessário para a

realização de uma tarefa com o objetivo de descobrir erros de
design que podem dificultar a aprendizagem por exploração.
Usar como único método para avaliar uma interface conduzir à

uma avaliação negativa de características que objetivem o
aumento de produtividade se essas características tornarem
mais difícil decidir como efetuar uma determinada tarefa.
Por ser uma avaliação muito detalhada ela quase sempre é

realizada durante o processo de design avaliando sempre
pequenos cenários de interação que se apresentem críticos com
relação a característica de aprendizagem.

Considerações (percurso cognitivo)
Todos os métodos têm suas características fortes e fracas.
O forte compromisso do percurso cognitivo com a facilidade de

aprendizagem sacrifica a obtenção de informação válida sobre
outros importantes atributos de usabilidade como, por exemplo,
consistência global da interface.
Isso reforça a necessidade de se usar diversos métodos

complementares de forma a garantir uma ampla cobertura da
interface em todas as suas características relevantes.
Todo método de avaliação não pode ser considerado completo e

sim complementar suas características com outros métodos.

1) Elaborar a fase preparatória para avaliação do protótipo
criado em sala usando percurso cognitivo (cada aluno deve fazer a fase
preparatória de seu protótipo contendo pelo menos 4 tarefas para avaliação).
2) Selecionar trabalhos para realizar a fase de análise (criar grupos de

avaliadores – no mínimo dois alunos por grupo – e selecionar dois protótipos de seus colegas de
sala para avaliar. Não é permitido avaliar o próprio protótipo).
3) Realizar a avaliação e elaborar um relatório indicando os

resultados da avaliação.

Projeto Oré (percurso cognitivo)
Fase Preparatória
Usuários típicos: Membros da comunidade ASCR com pouca familiaridade no uso de
computadores, e muitas vezes com uma resistência ao seu uso.
Tarefa: Incluir um aviso no quadro de avisos
Cenário: O usuário deseja criar um aviso no quadro de avisos para os voluntários da

recreação.
Sequência correta de ações:

1. Entrar no espaço privativo do Quadro de Avisos
2. Entrar login e senha
3. Selecionar a opção Criar Avisos
4. Preencher campos (pelo menos os obrigatórios)
5. Confirmar criação do aviso

Campos para preenchimento na tela de criar avisos

Resultado da fase de análise

Ação 1. Entrar no espaço privativo do Quadro de Avisos
− Usuários saberão que devem entrar no espaço privativo?

Não, os usuários não entenderão que estão em um espaço público em que têm
disponíveis algumas funcionalidades e podem passar para um privativo onde terão
acesso a mais opções. Logo, eles vão procurar uma opção para criar aviso no espaço
público.
− Usuários saberão que devem selecionar a opção privativo da comunidade?

Não, os usuários não estão familiarizados com o termo privativo da comunidade.
No ambiente físico o que é privativo a um grupo, fica localizado na sala onde aquele
grupo exerce suas funções, mas o termo “privativo” não é utilizado.


Ação 2. Entrar login e senha
− Usuário vai entender o que entrar quando aparecerem os campos login e senha?
Sim, apesar de login ser um termo computacional, ele vem sendo bem difundido
e pessoas em outros contextos utilizam o termo. Embora os usuários utilizem pouco o
computador, vários deles tem acesso à Internet, onde se utiliza os conceitos de login
e senha.
− Ao se logar o usuário vai perceber que está no espaço privativo?

Não. O feedback de entrada no espaço privativo é muito sutil, apenas mudanças
nos setores de avisos disponíveis e novas opções de ações. O aspecto visual é o
mesmo do espaço público, dificultando a percepção da mudança de espaço.


Ação 3. Selecionar a opção Criar Avisos
− O usuário vai entender que a opção desejada é “Criar aviso”?

Sim. O conjunto de opções é pequeno, a opção “Criar aviso” está bem visível e o
texto da opção está claro.
Ação 4. Preencher campos (pelo menos os obrigatórios)
− O usuário saberá preencher os campos necessários para criar um aviso?

Não. O usuário pode não entender o campo “chamada” no qual deverá entrar o
equivalente a um resumo ou indicador do assunto ao qual se refere o aviso, e como é
um campo opcional vários usuários podem deixá-lo em branco. A opção “incluir no
quadro geral”, não deixa claro que isto significa colocar o aviso também como
destaque no espaço público e o usuário pode não entender quem terá acesso ao aviso
sendo criado. O campo “prazo de validade” também não deixa claro que se refere a
data no qual o aviso será retirado do quadro de avisos.


Ação 5. Confirmar criação do aviso
− O usuário saberá que deve confirmar a ação de criação para que o aviso seja
criado?
Sim. Mesmo um usuário com pouca experiência em uso de computadores está
acostumado a confirmar suas ações em ambientes como caixas eletrônicos.
− O usuário reconhecerá o botão incluir aviso para que o aviso seja criado?
Sim. O texto deixa claro que o botão inlcuirá o aviso no Quadro de Avisos.

Teste de Usabilidade
Esse tipo de teste é realizado com os usuários do software (ou
possíveis usuários).
Tem por objetivo avaliar os fatores que caracterizam a

usabilidade de um software: facilidade de aprendizado,
facilidade de uso, eficiência de uso e produtividade,
satisfação do usuário, flexibilidade, utilidade e segurança
no uso.
Quais destes fatores devem ser priorizados deve ser definido no

projeto de design.
O movimento em direção aos testes de usabilidade estimulou a

construção de laboratórios de usabilidade.

Teste de Usabilidade
Um laboratório de usabilidade geralmente abriga uma pequena
equipe de pessoas com experiência em teste e design de
interface de usuário.
De acordo com Nielsen, a disponibilidade de um laboratório não

deve ser considerada condição para a realização de um teste de
usabilidade e sim como uma grande facilitação. Quase todas as
formas de teste podem ser feitas nos mais diversos locais, desde
que devidamente preparados. Também não deve ser considerada
uma condição a existência de avaliadores experientes para se
efetuar um teste. Bons resultados têm sido obtidos com
experimentadores novatos que aprendem o método de teste.

Objetivo e plano de teste
(Teste de Usabilidade)
Antes de qualquer teste ter inicio é preciso estabelecer seus

objetivos pois isso tem um impacto significativo no tipo de teste
a ser feito.
A principal distinção é se o teste tem como objetivo: (1) obter

uma ajuda no desenvolvimento ou (2) é um teste que visa
avaliar a qualidade global de uma interface.
(1) Interessa saber em detalhe quais aspectos da interface estão bons ou

ruins, e como o design pode ser melhorado. Geralmente utiliza uma
técnica de pensar em voz alta (thinking- aloud test).
(2) Como se quer uma visão mais global de uma interface em fase final
de definição geralmente se utiliza testes que deem medidas de
performance.

Em qualquer uma das situações deve ser desenvolvido um plano

detalhado de teste onde, dentre outras mais específicas, as seguintes
questões devem ser respondidas:
O objetivo do teste: o que se deseja obter?

Quando e onde o teste irá acontecer?
Qual a duração prevista de cada sessão de teste?
Qual o suporte computacional necessário?
Qual software precisa estar a disposição?
Qual deverá ser o estado do sistema no inicio do teste?
Quem serão os experimentadores?
Quem serão os usuários e como serão conseguidos?
Quantos usuários são necessários?
Quais as tarefas que serão solicitadas aos usuários?
Qual critério define que os usuários terminaram cada tarefa corretamente?
Quanto o experimentador poderá ajudar o usuário durante o teste?
Quais dados serão coletados e como serão analisados uma vez que tenham sido coletados?
Qual critério determina o sucesso da interface?
(p. ex: nenhum problema de usabilidade novo com severidade maior ou igual a 3).

Deve-se sempre estar atento a dois problemas vinculados a um teste de

usabilidade: a confiabilidade e a validade.
Confiabilidade: grau de certeza de que o mesmo resultado será obtido

se o teste for repetido.
Por exemplo, cuidar do grau de confiança que se dá a afirmações do

tipo: “usuário A usando a interface X executa uma tarefa 40% mais
rápido que o usuário B usando a interface Y”.
Não necessariamente significam que a interface X tem melhor

qualidade, pois não é incomum ter-se um grupo de usuários onde o
melhor usuário é 10 vezes mais rápido que o mais lento e que os 25%
melhores são 2 vezes mais rápidos que os 25% piores.

Validade: o fato dos resultados de teste refletirem os aspectos de

usabilidade que se deseja testar.
O que se gostaria de assegurar é que o resultado obtido tenha

realmente significado considerando-se o produto real em uso e fora da
situação de laboratório.
Deve-se então nesse ponto estar atento à escolha dos usuários, à

escolha das tarefas e à diferença entre equipamentos (situação de teste
e situação real).

Escolha dos usuários
Os usuários devem ser tão representativos quanto possível com relação

aos usuários reais do sistema.
O ideal seria envolver usuários reais do sistema, mas isso nem sempre
é possível.
Se o grupo de sujeitos não é composto de usuários reais, ele deve ter

idade e nível educacional similar ao grupo de usuários alvo. Também
similar deve ser sua experiência com computadores, com o tipo de
sistema que está sendo testado e o conhecimento do domínio da tarefa.
O usuário deve ser informado de que é a interface e não ele que está
sendo testado.

Os experimentadores
Os experimentadores devem ser preparados no sentido de terem

conhecimento extenso sobre a aplicação e a respectiva interface de
usuário. Não precisam saber como o sistema foi implementado, mas
devem estar prontos a lidar com problemas que afetem o teste, por
exemplo, problemas que levem o sistema a cair.
Nada impede que sejam os próprios designers desde que esses estejam
preparados no sentido de manter uma certa isenção no sentido de não
mascarar os resultados do teste. Geralmente eles tendem a ajudar
muito os usuários e a antecipar situações de erro, dado seu extenso
conhecimento da interface.

As tarefas
As tarefas a serem feitas durante um teste devem ser as mais

representativas possíveis e devem dar uma cobertura razoável das
partes mais significativas da interface. Devem poder ser completadas
no tempo definido para uma sessão de teste (de 1 a 3 horas). Devem
ter grau de dificuldade gradativa para dar mais confiança ao usuário e
devem ser planejadas para que possam ser interrompidas a qualquer
tempo, caso o usuário assim o deseje.
A descrição de cada tarefa a ser efetuada deve ser feita por escrito e
deve ser tão realista quanto possível e inserida em um cenário de uso.
Geralmente, um teste piloto é efetuado com um pequeno grupo (de 1 a

3) de usuários, para refinar todos os procedimentos definidos.

Etapas de um teste
●
Preparação;
●
Introdução;
●
Teste;
●
Sessão final.

Preparação
Nessa etapa se garante que tudo estará

pronto antes do usuário chegar.
Muito cuidado deve ser tomado com relação
aos equipamentos que serão utilizados,
devem estar "limpos" (de resultados de outros
teste, alarmes sonoros, etc).

Introdução
Os usuários são apresentados à situação de teste e de alguma forma

colocados a vontade. Sugestão de pontos que devem ser falados aos
usuários:
●
O propósito do teste é avaliar o sistema e não o usuário;
●
Não devem se preocupar em ferir sentimentos dos experimentadores (designers) com suas
observações;
●
Os resultados do teste servirão para melhorar a interface do usuário;
●
Relembrar que o sistema é confidencial e não deve ser comentado com outros (que inclusive
podem vir a ser futuros usuários em outros testes);
●
A participação no teste é voluntária e podem parar a qualquer tempo;
●
Os resultados do teste não serão colocados publicamente e o anonimato do participante estará
garantido;
●
Explicar sobre o uso de gravações de vídeo ou áudio que estarão sendo feitas (o ideal é não
gravar a face do usuário);
●
Explicar que podem fazer qualquer pergunta durante o teste, mas que nem sempre o
experimentador irá ajudá-los ou responder suas questões;
●
Instruções específicas sobre a forma do teste (p. ex.: falar em voz alta, ou fazer as atividades o
mais rápido que puder, etc.).

Teste
Durante o teste deve ser escolhido somente um experimentador

para falar com o usuário, para evitar confusão, e é importante
que:
●
Evite qualquer tipo de comentário ou expressões sobre a
performance ou observações do usuário;
●
evite ajudar o usuário, a não ser que ele esteja realmente em
dificuldades muito graves.

Sessão final
Depois do tempo definido para completar as tarefas -

usualmente de 1 a 3 horas - os participantes são convidados a
fazerem comentários ou sugestões gerais, ou a responderem um
questionário específico.
Gravar em vídeo os participantes efetuando as tarefas é sempre
um recurso valioso para uma posterior revisão.
A reação de designers vendo esses vídeos de usuários
cometendo erros é muito poderosa e motivadora. Quando
designers veem usuários repetidamente acessando o menu
errado, eles se convencem que rótulos e posições devem ser
mudadas.

Pensando em voz alta
Uma técnica efetiva durante um teste de usabilidade é solicitar que os

usuários pensem em voz alta sobre o que estão fazendo. A atmosfera
informal de uma sessão que usa essa técnica é extremamente
agradável, e frequentemente leva à muitas sugestões espontâneas de
melhorias.
Certamente é uma técnica não adequada quando se deseja medidas de

performance. Geralmente os usuários ficam mais lentos e cometem
menos erros quando pensam em voz alta.

O experimentador tem que ser bem preparado no sentido de levar o

usuário a falar sempre e nunca interferir no uso do sistema pelo
usuário. Formas de questionamento usuais podem ser relacionadas:
●
O que você está pensando agora?
●
O que você acha que essa mensagem significa (depois do usuário
notar a mensagem)?
●
Se o usuário pergunta se pode fazer alguma coisa: O que você acha
que vai acontecer se fizer isso?
●
Se o usuário se mostra surpreso: Era isso que você esperava que iria
acontecer? O que esperava?

Os comentários dos usuários devem ser criteriosamente analisados e

nunca aceitos indiscriminadamente.
A principal força dessa técnica é mostrar o que os usuários estão

fazendo e porque estão fazendo enquanto estão fazendo, evitando as
racionalizações posteriores.
No sentido de incentivar o pensar em voz alta muitas vezes se coloca

usuários trabalhando aos pares de forma a produzirem mais conversas.
Outra alternativa ao pensar em voz alta é fazer com que o usuário

comente depois suas ações gravadas em vídeo. Isso auxilia quando se
está também interessado em obter dados qualitativos de performance,
mas deve ser levado em conta que todo o teste demora pelo menos o
dobro do tempo.

Medida de Performance
Útil para avaliar se os objetivos de usabilidade foram efetivamente

atingidos e também para comparar produtos competitivos.
Em usabilidade tem-se o critério de eficiência de uso como uma das

guidelines de usabilidade. Dentro desse, são fundamentais algumas
medidas de performance na forma de tomadas de tempo, por exemplo.
Como e quando marcar tempos deve ser decidido a priori de acordo

com os dados necessários na coleta.
Se deseja saber quanto o usuário demora fazendo uma determinada

tarefa é preciso primeiro definir quando começa e quando termina a
tarefa e depois se o tempo será cronometrado pelo próprio usuário, pelo
computador, pelo experimentados, etc.

Medida de Performance
Medidas típicas de usabilidade que são quantificáveis incluem:

●
O tempo que o usuário gasta para fazer uma determinada tarefa
●
O número de tarefas de diferentes tipos que são completadas em determinado limite de tempo
●
A razão entre interações de sucesso e de erro
●
O número de erros do usuário
●
O número de ações errôneas imediatamente subsequentes
●
O número de comandos (ou diferentes comandos) ou outras características que foram utilizados pelo
usuário
●
O número de comandos ou outras características nunca utilizados pelo usuário
●
O número de características do sistema que o usuário consegue se lembrar na sessão subsequente ao
teste
●
A frequência de uso de manuais ou do sistema de help e o tempo gasto usando esses elementos do
sistema
●
Quão frequentemente o manual/sistema de help resolveu o problema do usuário
●
A proporção entre comentários do usuário favoráveis e críticos com relação ao sistema
●
O número de vezes que o usuário expressou frustração (ou alegria)
●
A proporção de usuários que disse preferir o sistema a outro sistema competidor
●
A proporção de usuários utilizando estratégias eficientes e ineficientes
●
A quantidade de “tempo morto” - quando o usuário não está interagindo com o sistema (ou esperando
resposta ou pensando)
●
O número de vezes que o usuário desviou do objetivo da tarefa

Considerações
Certamente somente um pequeno subconjunto de medidas pode ser

coletado em uma particular situação de teste.
Testes de usabilidade geralmente são feitos em laboratórios onde os

usuários são observados diretamente pelos avaliadores. Porém algumas
dificuldades são encontradas como: recrutamento de usuários
representativos; software de aplicação distribuída; reprodução do
contexto de trabalho do usuário em laboratório; dentre outros.
Essas barreiras para o teste de usabilidade têm levado à uma extensão

do teste para além dos limites dos laboratórios e começam a surgir
métodos de teste de usabilidade remotos, tipicamente usando a rede
como uma ponte de acesso aos usuários em seu ambiente natural de
trabalho (opcionalmente usando software construídos para coletar
dados de uso).

Considerações
Temos também como modalidade de teste de usabilidade os

denominados testes de campo que objetivam colocar novas interfaces
em ambientes reais de uso por um determinado período de tempo.
Testes de campo dão melhor resultado quando se pode dispor de

software que geram arquivos de log que capturam erros, comandos
usados, frequência de acesso a helps e mais algumas medidas de
produtividade.
Quando se conta somente com a resposta do usuário os resultados não

são muito satisfatórios. A maioria dos usuários estão mais interessados
em obter uma primeira versão do produto.

Elaborar um teste de usabilidade contendo as 4 etapas
(Preparação, Introdução, Teste e Sessão Final) (Durante a etapa de Teste
não há a necessidade de usar de fato um grupo de usuários representativos, a sugestão e que os
próprios alunos da disciplina participem do teste).

Avaliação de Interfaces - Livro Profa. Heloísa

Enviado por

Direitos autorais:

Formatos disponíveis

Avaliação de Interfaces - Livro Profa. Heloísa

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Avaliação de Interfaces - Livro Profa. Heloísa

Enviado por

Direitos autorais:

Formatos disponíveis

Interação Humano-

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 2

Idealmente, avaliação deve ocorrer durante o ciclo de vida do

Existe uma forte correlação entre avaliação e as técnicas de

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 3

Ex: Modelo estrela.

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 4

Por exemplo, depois de uma sessão de discussão (brainstorming)

Em estágios um pouco mais avançados do processo, avaliações

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 5

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 6

Custo pode variar de 10% a 1% do valor total do projeto.

Deve-se ter claro que um certo grau de incerteza sempre

Deve-se ter em vista ao analisar métodos de avaliação que eles

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 7

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 8

Inspeção de Métodos Experimentos Testes de

Avaliação Percurso Avaliação Avaliação Uso de

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 9

Muitas questões poderiam ser objetivo de uma avaliação.

O setor de marketing poderia estar interessado em como o

Produtos também podem ser avaliados no sentido de verificar se

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 10

(1) Avaliar a funcionalidade do sistema;

(2) Avaliar o efeito da interface junto ao usuário;

(3) Identificar problemas específicos do sistema.

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 11

Inclui não somente ter a funcionalidade adequada disponível,

Envolve também medir a performance do usuário junto ao

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 12

Medir o impacto do design junto ao usuário, ou seja, avaliar sua

Isso inclui considerar aspectos tais como: avaliar quão fácil é

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 13

Identificar aspectos do design os quais quando usados no

Isso é claro está correlacionado tanto com a funcionalidade

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 14

A maioria dos métodos de inspeção terão um efeito significativo

Uma inspeção pode demorar de 12hs até 40hs, dependendo da

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 15

É possível efetuar a avaliação em interfaces que existam apenas

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 16

Primeiro momento: Cada avaliador percorre a interface

Segundo momento: As listas de problemas dos avaliadores são

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 17

2. Compatibilidade do sistema com o mundo real

3. Controle do usuário e liberdade

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 18

6. Reconhecimento ao invés de relembrança

7. Flexibilidade e eficiência de uso

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 19

9. Ajudar os usuários a reconhecer, diagnosticar e corrigir erros

10. Help e documentação

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 20

Exemplos de heurística para sistema com muitas entradas de

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 21

O avaliador não pode simplesmente dizer que não gosta de um

Vejamos alguns exemplos:

18/05/19 INTERAÇÃO HUMANO-COMPUTADOR 22

Também deve ser observada a mensagem de erro inadequada - Você não