EAD

Métodos para Avaliação da

Interface

1. OBJETIVOS
• Conhecer os conceitos para avaliar a interface.
• Entender a Avaliação Heurística.
• Compreender os Checklists.
• Conhecer e entender o Percurso Cognitivo.

2. CONTEÚDOS
• Introdução aos Métodos:
• Avaliação Heurística.
• Percurso Cognitivo.
• Checklist.
• Teste de Usabilidade.
• Percurso Pluralístico.
• Modelo GOMS.
• Questionários.
• Explicação dos métodos em detalhes:
• Avaliação Heurística.
• Checklist.
 88 © Interface Humano-Computador

3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE

Antes de iniciar o estudo desta unidade, é importante que você leia as orientações a se-
guir:
1) Leia, atentamente, todos os métodos apresentados nesta unidade e se preocupe em
compreender as características de cada um e a diferença entre eles. Essas informações
lhe ajudarão a escolher o melhor método para avaliar a interface de seu software.
2) Pesquise em livros e/ou na internet mais informações sobre esses métodos descritos
aqui e tantos outros que existem. Ao pesquisar, preocupe-se, inicialmente, em enten-
der o conceito do método e investigue pesquisadores e/ou empresas que o utilizaram,
bem como o resultado obtido. Lembre-se de que você é protagonista do processo
educativo.
3) Fique atento ao site de um pesquisador muito conhecido na área de IHC: Nielsen
<[Link] Frequentemente, há novas postagens sobre novida-
des nessa área, incluindo novos métodos para avaliação de interface e testes para
observar a sua aplicabilidade.
4) Não deixe de comentar com seus colegas de curso e com o tutor o que você aprendeu
nesta unidade e em suas leituras complementares. O ponto de vista de cada um é mui-
to importante para a construção de um conhecimento colaborativo e significativo.

4. INTRODUÇÃO À UNIDADE
Desenvolver sistemas pensando e considerando o usuário em todo o seu processo é uma
característica importante para se construir um aplicativo que seja útil e atenda às suas necessi-
dades, ou seja, que não tenha somente as funcionalidades desejadas, mas que elas sejam visí-
veis e compreensíveis. Como você pôde perceber na unidade anterior, há a possibilidade de unir
a Engenharia de Software (ES) e a Interação Humano Computador (IHC). Dessa forma, podemos
desenvolver sistemas nos preocupando com as suas funcionalidades, hardware etc., bem como,
com as pessoas que os irão utilizar.
Depois dessa etapa, de pensar e considerar a ES e a IHC para planejar e desenvolver sis-
temas, vem outra, que tem como objetivo validar e verificar se, realmente, o que foi planejado
está sendo feito e, especialmente, analisar se o que está pronto é usável (termo relacionado
à facilidade que o sistema proporciona ao usuário para que esse alcance os seus objetivos na
interação), é útil, qual é a facilidade que o sistema proporciona ao usuário para alcançar os seus
objetivos na tarefa (CYBIS et al., 2003), se é acessível e se tem facilidade de acesso e de uso de
sistemas por qualquer pessoa e em diferentes contextos (GODINHO, 2010).
Nessa etapa, também há estratégias para avaliar o sistema sob a ótica da ES e da IHC.
Nesta unidade, serão apresentados alguns métodos para avaliar o sistema, considerando os
conceitos da IHC. A Figura 1, apresentada a seguir, ilustra alguns dos métodos existentes para
essa avaliação.
• Nielsen (1994) dividiu os métodos em três categorias: métodos analíticos ou de inspe-
ção, que não envolvem a participação dos usuários, ou seja, que os próprios projetistas
ou profissionais na área de IHC aplicam; métodos empíricos ou teste com usuários,
que envolvem a participação direta dos usuários em todo o processo de avaliação; e
Outras formas, métodos que envolvem maior rigor de avaliação no que se diz respeito
a dados quantitativos, como o modelo GOMS ou Questionários, que envolve o usuário,
porém não em todo o processo.
 © U5 – Métodos para Avaliação da Interface 89

Figura 1 Métodos para Avaliação.

Avaliação Heurística: esse método tem como objetivo examinar a interface e julgá-la de
acordo com os princípios reconhecidos de usabilidade. Esse método pode ser aplicado por um
pequeno grupo de avaliadores (geralmente cinco), por isso é considerado rápido e barato, logo
no início do ciclo de desenvolvimento, por exemplo, no protótipo em papel.
Alguns métodos, em sua aplicação, já possuem estratégias para identificar os erros e apon-
tar as melhorias, ou seja, explicitam o que poderia ser feito para resolver os erros ou melhorar
a interface. Nesse método, em especial, não está inclusa a proposta de melhorias, embora elas
possam ser feitas como resultado da avaliação ou da discussão entre os avaliadores.
Percurso Cognitivo: esse método também pode ser aplicado no início do desenvolvimen-
to. O profissional precisa simular passo a passo o comportamento de um determinado usuário
em uma tarefa, por isso ele precisa conhecer bem quem é o usuário, as suas características, as
habilidades e as deficiências, pois diante de uma determinada interface, ele tentará executar
uma determinada tarefa como se fosse o usuário. Esse método já possui as propostas de melho-
rias, ou seja, como resultado dessa avaliação, há a necessidade dos problemas identificados e as
possíveis soluções para eles (MANO; CAMPOS, 2004).
Checklist: é um conjunto de itens que devem ser considerados na avaliação da interface
para observar se ela está, ou não, em conformidade com tais itens. Um dos objetivos do Che-
cklist é permitir aos projetistas e/ou profissionais na área da IHC verificarem se o conteúdo e as
opções existentes na interface estão acessíveis aos usuários (CYBIS et al., 2003).
Teste de Usabilidade: tem como finalidade observar o usuário executando alguma(s)
atividade(s) em um determinado sistema. Esse é o principal ponto positivo desse teste, pois
nada melhor do que ver o usuário em ação para perceber quais são as dificuldades, as facili-

Claretiano - Centro Universitário

 90 © Interface Humano-Computador

dades etc. Entretanto, ele tem que ter um objetivo definido, pois, durante o teste, tudo pode
acontecer, e é necessário, desde o início, saber o que se quer observar para poder prestar mais
atenção ao que interessa. Esse teste é realizado durante ou no final do desenvolvimento, pois,
normalmente, é feito com o protótipo de alta-fidelidade ou com o sistema implementado (NIEL-
SEN, 1994).
Percurso Pluralístico: esse método permite avaliar uma sequência de interfaces (percur-
sos de interação) com várias pessoas (pluralístico), dentre elas a equipe de IHC, o projetista e o
usuário. O método funciona da seguinte maneira: existe uma sequência de telas e, ao observá-
as, os usuários, escrevem ou falam quais seriam as ações necessárias para executar uma deter-
minada tarefa, definida por projetista ou por um profissional em IHC. Em seguida, há uma troca
de informações sobre o que o usuário falou e o que o projetista planejou com aquelas telas. Essa
troca de informações é intermediada pelo profissional de IHC, possibilitando, assim, perceber
quais são os erros, se o que o projetista planejou realmente foi realizado pelo usuário etc. Ao
final de cada tarefa é discutida e apresentada a maneira que era esperada para que ela fosse
realizada e somente depois de todos entenderem como é o procedimento correto ou definirem
uma nova maneira de realizá-la poderá prosseguir para a próxima tarefa.
GOMS – Goals (Objetivos), Operators (Operadores), Methods (Métodos) e Selection ru-
les (Regras de seleção): esse método não envolve a participação do usuário. Ele estipula um
tempo possível para que um usuário possa tomar uma decisão, como, por exemplo, pensar em
clicar num botão, encontrar um botão, arrastar o mouse, clicar em um botão etc. É definido um
operador para cada passo que o usuário precisa fazer para realizar uma ação e a cada operador
é atribuído um valor, assim, o tempo de cada ação pode ser calculado por meio da soma dos
valores atribuídos a cada operador necessário para executar a ação. O tempo definido para o
operador encontra-se na literatura (JOHN; KIERAS, 1996). No final, o resultado são as ações, os
operadores e o total de tempo para realizá-las.
Questionários: trata-se de um conjunto de questões apresentados aos usuários (podem
ser de múltipla escolha). Por meio desse método é possível identificar facilmente as preferên-
cias, as satisfações e as ansiedades dos usuários. Há várias maneiras de aplicar os questionários,
algumas delas foram estudadas na Unidade 3 na seção Projeto Centradas no Usuário.
Cybis et al. (2003) descrevem que foram realizados testes com alguns dos métodos de
avaliação, descritos, anteriormente, com intuito de desenvolver um estudo comparativo dos
desempenhos alcançados por diferentes avaliadores, usando métodos distintos para a avaliação
da usabilidade, da utilidade e da acessibilidade. Todos os métodos realizados tiveram sua aplica-
ção e seus resultados registrados.
A taxa custo x benefício (medida em quantidade e severidade de problemas identificados
por hora de avaliação) foi melhor em dois métodos: Avaliação Heurística e Checklist. Devido a
esses resultados positivos e à comprovação da eficiência desses dois métodos, se comparados
aos outros, nesta unidade descreveremos cada um detalhadamente, explicando a maneira de
aplicá-los, os resultados obtidos etc. Vale ressaltar que, apesar desses resultados positivos, todos
os métodos possuem qualidades que devem ser levadas em consideração na hora de escolher o
melhor para se aplicar, pois, dependendo da situação e da necessidade outro, se sobressairá.
Outro método que será discutido nesta unidade é o Percurso Cognitivo, que, além de
ser uma estratégia muito utilizada pelos pesquisadores, possui características importantes para
que, mesmo sem a presença dos usuários, os profissionais de usabilidade possam perceber a
facilidade ou dificuldade que os usuários teriam para interagir com o software.
 © U5 – Métodos para Avaliação da Interface 91

5. AVALIAÇÃO HEURÍSTICA
A Avaliação Heurística é um método de inspeção que visa identificar problemas conforme
um conjunto de heurística. Esse método foi proposto por Jacob Nielsen e Rolf Molich em 19Essa
avaliação pode ser aplicada em especificações em papel, protótipos de baixa, média ou alta-
-fidelidade ou em sistema final. É necessário um pequeno número de avaliadores (geralmente,
entre três e cinco) para examinar e julgar a interface (NIELSEN, 1994).

Curiosidade!–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
O grupo de Nielsen e Norman cobra até 35.000 dólares por uma avaliação heurística em um website. Vale lembrar,
como dito anteriormente, que esse método não inclui a proposta de melhoria, por isso, caso essa proposta ocorra, é
preciso deixar bem claro para o cliente que é algo a mais que se está fazendo, ou seja, o custo para se realizar essa
avaliação pode aumentar ainda mais.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Fases para aplicar a Avaliação Heurística

Geralmente, a Avaliação Heurística ocorre em três fases, contudo, como descrito anterior-
mente, há a possibilidade de aumentar uma fase chamada Melhorias, em que haverá algumas
propostas de melhorias, como você pode observar na Tabela 1.

Tabela 1 Fases para aplicar a Avaliação Heurística (NIELSEN, 1994).

FASES CARACTERÍSTICAS
Uniformização da terminologia.
Sessão de Pré-Avaliação Introdução ao domínio da aplicação.
Apresentação do cenário, protótipo ou aplicação.
Avaliação individual e independente.
Avaliação Navegar pelo sistema no mínimo duas vezes.
Relatar quais heurísticas foram violadas
Características principais da interface.
Problemas de usabilidade identificados.
Discussão dos avaliadores
Severidade dos problemas encontrados.
Elaboração de um relatório contendo: problemas e severidade.
Melhorias Sugestão de modificações

1ª Fase – Sessão de Pré-avaliação: nessa fase, os avaliadores devem reunir-se para conhe-
cer o cenário, o protótipo ou a aplicação. Geralmente, um profissional especialista nesse cenário
ou aplicação é quem fica responsável por mostrá-la aos avaliadores. Essa fase é importante para
que os avaliadores esclareçam todas as suas dúvidas em relação ao que será avaliado, afinal,
com um bom entendimento de todas as características, necessidades etc., será possível uma
boa avaliação.
Os avaliadores também devem discutir cada uma das dez heurísticas, que estudaremos
a seguir e que serão utilizadas para avaliar o sistema. Essa etapa é importante, para que todos
cheguem a um consenso do que é cada heurística e como ela deve ser avaliada, isso evita que
um avaliador pense e avalie uma heurística diferentemente dos demais, pois essa diferença na
forma de avaliar, muitas vezes, não gera resultados satisfatórios.
2ª Fase – Avaliação: a avaliação deve ser feita individualmente, ou seja, cada avaliador
deve avaliar a interface sozinho. Essa avaliação é feita com, pelo menos, duas navegações no

Claretiano - Centro Universitário

 92 © Interface Humano-Computador

sistema, a primeira navegação para conhecer o sistema e a segunda para verificar se alguma das
dez heurísticas está sendo violada. Vale ressaltar que para cada heurística violada o especialista
deve definir uma severidade e a forma de aplicá-la, o que estudaremos adiante. No final, cada
especialista terá uma tabela com as heurísticas violadas e suas respectivas severidades.
3ª Fase – Discussão dos avaliadores: os avaliadores discutem as principais características
da interface as heurísticas violadas encontradas e as suas severidades, ou seja, cada avaliador
apresenta a sua tabela e discute sobre ela com os demais. Nessa discussão, cada avaliador po-
derá dizer se concorda ou não com a heurística e a sua severidade, e, assim, todos juntos criam
uma tabela que possui o consenso de todas as heurísticas e as severidades, ou seja, o resultado
é uma tabela final contendo as heurísticas e severidades que todos concordaram.

Importante:––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
É importante lembrar que isso não significa unir as tabelas de cada avaliador, pois uma heurística encontrada por um
pode não ser pertinente aos demais ou uma severidade definida por um pode não ser a melhor, por isso é importante
a discussão.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
4ª Fase – Melhorias: os avaliadores discutem as heurísticas violadas e as estratégias que
eles pensaram para melhorar a interface e, em um consenso, decidem qual é a melhoria que
pode ser aplicada.

6. AS DEZ HEURÍSTICAS
A seguir, apresentaremos as dez heurísticas refinadas por Nielsen (2002).

1ª Visibilidade do Sistema
Os usuários são informados sobre o progresso do sistema com a resposta apropriada den-
tro de um tempo aceitável?
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
O sistema deve informar aos usuários sobre o que está acontecendo, por meio de mensagens ou de elementos
de interface. Por exemplo, por meio de barra de progressão ou exibindo os passos que se tem para executar uma
tarefa.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
É sempre importante mostrar a quantidade de passos existentes, concomitantemente ao
passo que a pessoa está, por exemplo: Passo 2/Alguns sistemas, como o Contexteller (SILVA,
2009), exibem os passos de uma maneira diferente, como apresentado na Figura 2, pois, além
de exibir a quantidade de passos e em qual a pessoa está, exibem o nome do passo e por meio
dos botões "voltar" e "avançar" é possível saber o nome do passo anterior e do posterior. Assim,
fica fácil o usuário saber em que passo ele está, o que ele fez e o que ele fará.
 © U5 – Métodos para Avaliação da Interface 93

Fonte: ANACLETO, 2010.

Figura 2 Visibilidade do sistema.

Fonte: SILVA, 2009, p. 59.

Figura 3 Tela Cadastrar Jogador do jogo Contexteller.

Claretiano - Centro Universitário

 94 © Interface Humano-Computador

2ª Correspondência entre o sistema e o mundo real

O sistema usa conceitos e linguagens familiares aos usuários ao invés de termos técnicos?
Ele usa convenções do mundo real e apresenta as informações de maneira natural e em ordem
lógica?

Fonte: ANACLETO, 2010.

Figura 4 Correspondência entre o sistema e o mundo real.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
O sistema deve falar a linguagem do usuário, com palavras, frases e conceitos familiares e não termos orientados
ao sistema.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
A linguagem utilizada em todo o sistema deve ser familiar ao usuário, por exemplo, é co-
mum encontrarmos sistemas web para vender produtos, em que a interface exibe o código do
produto no carrinho de compras. Observe que esse código não é algo familiar ao usuário, seria
mais fácil aparecer o nome do produto e/ou a foto dele. Nesse caso, o código é uma informação
desnecessária e que pode até confundir o usuário.
 © U5 – Métodos para Avaliação da Interface 95

3ª Controle e liberdade do usuário

Os usuários podem fazer o que querem quando desejam?

Fonte: ANACLETO, 2010.

Figura 5 Controle e liberdade do usuário.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Frequentemente, os usuários escolhem funções do sistema por tentativa-erro, então a interface deve deixar as saí-
das claramente marcadas ou dar suporte a desfazer ou refazer.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
O usuário precisa perceber que está no comando e que, a qualquer momento, ele pode
voltar, avançar, parar etc. Algo importante é ter na interface uma opção para voltar à página
principal (inicial), afinal, muitas vezes, essa é a pagina mais conhecida pelo usuário e, se durante
a navegação se sentir perdido ou um pouco confuso, ele pode voltar à página inicial. Essa ati-
tude é comum, pois, geralmente, os usuários voltam para perceber que continuam no mesmo
sistema e, vendo essa interface familiar novamente, eles se sentem seguros para continuar a
navegar.

Claretiano - Centro Universitário

 96 © Interface Humano-Computador

4ª Consistência e padronização
Os elementos de design, como os objetos e as ações, têm o mesmo significado ou efeito
em situações diferentes?

Fonte: ANACLETO, 2010.

Figura 6 Consistência e padronização.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
A interface não deve apresentar palavras, situações ou ações diferentes que possuam um mesmo significado.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Manter a padronização é uma característica fundamental para o sucesso da interface, pois
no momento em que o usuário se familiariza com algo, por exemplo, com um formato de botão,
ele conseguirá navegar no sistema e identificar todos os outros botões. Dessa forma, quando
ele encontrar algo com o formato semelhante terá a certeza de que poderá clicar e ter alguma
ação. Por isso, mantenha o padrão, se você definiu o formato de um botão, siga ele do início
ao fim do sistema. Outra preocupação é manter o padrão nas informações, então, evite ter na
interface botões, links ou palavras diferentes que possuam o mesmo significado ou que vão para
o mesmo lugar.
 © U5 – Métodos para Avaliação da Interface 97

5ª Prevenção de erros
Os usuários cometem erros que não cometeriam em interfaces melhores?

Fonte: ANACLETO, 2010.

Figura 7 Prevenção de erros.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Preocupação com o projeto do sistema para que os erros de interação não ocorram. Exemplo: indicação clara do
formato do dado esperado.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Algo muito útil para evitar erros, especialmente em cadastros, é informar ao usuário como
ele deve inserir os dados. Para tanto, podemos utilizar máscaras, como, por exemplo, "( )",
para ilustrar como deve ser inserido o número de telefone ou ". . –", para inserir o CPF etc. É
comum, também, encontrarmos um exemplo ao lado do campo, (99)9999-9999.

Claretiano - Centro Universitário

 98 © Interface Humano-Computador

6ª Ajuda aos usuários para reconhecerem, diagnosticarem e se recuperarem de erros

As mensagens de erros são expressas em linguagem "plena" (sem códigos)? Elas descre-
vem exatamente o problema e sugerem uma solução?

Fonte: ANACLETO, 2010.

Figura 8 Ajuda aos usuários.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Mensagens de erros devem ser expressas descrevendo o problema, sugerindo soluções e sem linguagem técnica.
As mensagens "Erro 404" ou "Você realizou uma operação ilegal", não são bons exemplos, ou seja, não descrevem
exatamente o problema.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Ao exibir uma mensagem de erro, informe ao usuário qual foi o erro e como ele deve ser
corrigido em uma linguagem natural. Pouco útil será uma mensagem de erro informando que
um determinado cadastrado foi realizado de maneira errada, por isso indique em qual campo foi
o erro e como ele deve ser preenchido corretamente.
 © U5 – Métodos para Avaliação da Interface 99

7ª Reconhecimento em vez de memorização

Os elementos do projeto, como objetos, ações e opções, estão visíveis? O usuário é força-
do a lembrar informações de uma parte para outra do sistema?

Fonte: ANACLETO, 2010.

Figura 9 Reconhecimento em vez de memorização.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
A interface deve ter os seus elementos de interface visíveis. O usuário não tem que se lembrar de informações de
uma parte para outra das interfaces do software.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Não conte com a memória do usuário para visualizar alguma informação em uma tela e
utilizá-la em outra, por exemplo, não é difícil encontrar sistemas que, em uma tela, mostram um
determinado produto (com código, descrição etc.) e seus tamanhos e, em outra tela, existirem
alguns campos para o usuário inserir o código do produto e o tamanho desejado. Observe que
o código não é algo natural para o usuário, ou seja, é difícil de ser memorizado, como também,
para esse caso, há a necessidade de memorizar o tamanho do produto. Evite esse tipo de si-
tuação e permita ao usuário fazer buscas. Assim, apenas com o nome do produto ele poderá
pesquisar e encontrar, automaticamente, o que quer. Após encontrá-lo, será exibido um campo
com todos os seus tamanhos possíveis, para que o usuário somente selecione o desejado.

Claretiano - Centro Universitário

 100 © Interface Humano-Computador

8ª Flexibilidade e eficiência de uso

Os métodos das tarefas são eficientes e os usuários podem customizar ações frequentes
ou atalhos?

Fonte: ANACLETO, 2010.

Figura 10 Flexibilidade e eficiência de uso.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Aceleradores ou atalhos devem estar presentes na interface para aumentar a velocidade de execução da tarefa para um usuário
experiente.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Apresentar o passo a passo é importante para os usuários iniciantes e intermediários, mas
os usuários experientes preferem pressionar "ctrl + n" para deixar um texto em negrito ao invés
de levar o mouse no botão N e clicar. De maneira semelhante, podemos pensar em outros siste-
mas que não processadores de texto. Temos de apresentar caminhos mais rápidos de se realizar
algo, pois os usuários, de acordo com a frequência de uso e a familiaridade com o sistema vão
preferir utilizá-los.
Ajude o usuário a preencher um campo. Por exemplo, se existirem os campos país, cidade
e estado para serem preenchidos, uma maneira de facilitar é permitir que o usuário selecione,
de uma lista, um país e, automaticamente, todos os estados daquele país aparecem como op-
ção para serem selecionados e, uma vez selecionado o estado, aparecem as cidades. Assim fica
muito mais fácil e rápido preencher algo.
 © U5 – Métodos para Avaliação da Interface 101

9ª Design estético e minimalista

Os diálogos contêm informações irrelevantes ou raramente utilizadas?

Fonte: ANACLETO, 2010.

Figura 11 Design estético e minimalista.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
As informações extras irrelevantes diminuem a visibilidade das informações importantes.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Evite informações desnecessárias, pois elas podem poluir a interface e dificultar a intera-
ção com o sistema. Exiba apenas o essencial e necessário. Evite, por exemplo, colocar muita pro-
paganda ou informações irrelevantes na interface, pois isso ajuda o usuário a desviar a atenção
do que ele realmente estava fazendo ou precisa fazer.

Claretiano - Centro Universitário

 102 © Interface Humano-Computador

10ª Ajuda e documentação

Uma ajuda apropriada é fornecida? Essa informação é fácil de ser encontrada e enfocada
na tarefa do usuário?

Fonte: ANACLETO, 2010.

Figura 12 Ajuda e documentação.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
A informação da ajuda deve ser útil e fácil de ser encontrada.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Observe que uma ajuda fácil e útil não é aquela em que há um botão com ponto de inter-
rogação e, ao ser clicado, aparece um texto imenso com as explicações. Afinal, poucos são os
usuários que querem ou que têm tempo de ler algo assim, é preciso uma ajuda sucinta, prática
e clara.

7. ESCALA DE SEVERIDADE
O valor da severidade define a gravidade do problema encontrado. Esse, varia de zero a
quatro, conforme demonstrado na Tabela 2 a seguir:
 © U5 – Métodos para Avaliação da Interface 103

Tabela 2 Graus de Severidade

SEVERIDADE DESCRIÇÃO
0 Não concordo que o problema encontrado seja um problema de usabilidade.
1 Problema cosmético/superficial – precisa ser corrigido somente se um tempo estiver disponível.
2 Problema de usabilidade pequeno – esse problema possui uma baixa severidade para ser solucionado.
3 Problema de usabilidade grande – importante solucionar o problema, alta prioridade.
Catástrofe de usabilidade – imprescindível solucionar esse problema antes que o produto seja liberado
4
para comercialização.

Tabela Para Avaliação Heurística

A Tabela 3, apresentada a seguir, ilustra o formato da tabela que deve ser feita tanto na
avaliação individual quanto na avaliação final, em que todos os avaliadores se reúnem para ge-
rar uma tabela com o consenso de todas as heurísticas e severidades identificadas.

Tabela 3 Formato da Tabela da Avaliação Heurística.

NÚMERO HEURÍSTICA VIOLADA PROBLEMA SEVERIDADE

... ... ... ...

8. EXEMPLO DE APLICAÇÃO DA AVALIAÇÃO HEURÍSTICA

O exemplo ilustrado a seguir foi realizado no LIA – Laboratório de Interação Avançada da
Universidade Federal de São Carlos (UFSCar). A Avaliação Heurística foi realizada em uma ferra-
menta desenvolvida por pesquisadores do próprio laboratório, chamada Cognitor.
O Cognitor é um editor de material de aprendizagem para web, destinado a professores
com pouca experiência em editar conteúdo para Aprendizagem Eletrônica. Ele foi desenvolvido
tendo em mente os princípios pedagógicos para que o material gerado ofereça condições para
uma aprendizagem efetiva (CARLOS, 2007).
De maneira bem simples, é possível dizer que o Cognitor é um editor gráfico para páginas
web, em que o professor não precisa saber programar em HTML durante a elaboração de seu
material, pois o HTML é gerado automaticamente. No entanto, há outros recursos que ajudam
o professor na elaboração do material, pois o Cognitor apoia o professor para fazer um material
considerando alguns recursos cognitivos, a cultura, entre outras características dos alunos.
A seguir, é apresentada a aplicação da Avaliação Heurística na ferramenta Cognitor consi-
derando as três fases para aplicar a Avaliação Heurística, estudadas anteriormente.

1ª Fase – Sessão de Pré-avaliação

Nessa primeira fase, os pesquisadores que desenvolveram o Cognitor apresentaram e expli-
caram o objetivo do sistema. A apresentação foi feita utilizando a própria ferramenta, que, nesse
caso, foi avaliação no sistema final. A Figura 3 apresenta a interface principal do Cognitor.

Claretiano - Centro Universitário

 104 © Interface Humano-Computador

Fonte: CARLOS, 2007, p. 18.

Figura 13 Tela inicial do Cognitor – Criando material.

Para se criar algum material é necessário clicar no botão "Cria/Edita" (representado pela
lâmpada) para iniciar. Após clicar no botão "Cria/Edita", é preciso definir os conceitos que serão
abordados no material de aprendizagem e realizar a sua organização. Para essa atividade, foram
definidos e organizados quatro conceitos, demonstrados na Figura Os botões do lado esquerdo
devem ser utilizados para a organização. À direita, é possível ver sugestões de conceitos cultu-
rais vindas de uma base de conhecimento de senso comum.

Fonte: CARLOS, 2007, p. 21.

Figura 14 Tela para definir e organizar conceitos.
 © U5 – Métodos para Avaliação da Interface 105

Após a explicação do Cognitor, todos os avaliadores conversaram sobre como seria feita
a avaliação, ou seja, quais seriam as telas a serem avaliadas, quais as funcionalidades etc. e,
também, são discutidas cada uma das dez heurísticas e as suas severidades, pois, assim, todos,
durante a avaliação, teriam o mesmo conhecimento sobre elas.
Pode parecer simples, após ler as heurísticas e as suas severidades, pensar que todos os
avaliadores vão avaliar e aplicar as severidades da mesma maneira, mas se isso não for bem con-
versado, as chances de todos aplicarem essa estratégia seguindo um consenso são poucas, uma
vez que o que eu avalio como grave pode não ser tão grave para o outro. Por isso, é importante
que todos conversem sobre o que cada um entendeu das heurísticas e definam como vão aplicar
as severidades, que podem ser aplicadas em termos de:
• Frequência – comum ou raro?
• Impacto – fácil ou difícil para o usuário se recuperar?
• Persistência – ocorre apenas uma vez e os usuários sabem como lidar com ele?
• Impacto no mercado.

2ª Fase – Avaliação
Nessa fase, cada profissional avaliou a ferramenta e elaborou uma tabela, como apresen-
tada na Tabela 4.

Importante:––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
É comum, na primeira vez que alguém faz a avaliação heurística, pensar que deve encontrar em todo o sistema um
problema para cada heurística, ou seja, no final, a tabela contém apenas as dez heurísticas com um problema em
cada. Mas, isso está errado, pois você tem de olhar cada parte da interface e avaliar se essa parte violou alguma(s)
heurística(s), por isso é comum ter um botão violando duas ou três heurísticas, dependendo da forma que ele é
apresentado, o que está escrito nele etc.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Tabela 4 Tabela individual

HEURÍSTICA
NÚMERO PROBLEMA SEVERIDADE
VIOLADA
1 7 Não fica claro que a primeira opção é clicar na lâmpada. 4
O desenho da lâmpada não remete ao seu uso: criar
2 7 2
conceito.
Quando abre a janela "Estruturar Conhecimento", os botões
3 4 Incluir, Buscar e Deletar ficam disponíveis mesmo não tendo 1
nenhuma ação no momento.
Os botões para identar os conceitos, poderia ter alguma
4 7 explicação ao se passar o mouse sobre o desenho, porque 3
nem sempre o usuário vai entender o que eles significam.
Mesmo quando o conceito está em primeiro lugar o botão
de "subir o conceito" fica disponível, permitindo ao usuário
5 5 2
clicar e não ver nenhuma alteração.
(O mesmo ocorre com os outros botões).
Não há nenhum feedback quanto à posição dos elementos.
Por exemplo, quando chega à primeira posição e o usuário
continua clicando para o conceito subir, ele não é informado
6 10 2
que já chegou no "nível máximo" e o botão também não
desabilita.
(O mesmo ocorre com os outros botões).

Claretiano - Centro Universitário

106 © Interface Humano-Computador

HEURÍSTICA
NÚMERO PROBLEMA SEVERIDADE
VIOLADA
Quando se insere um conceito que não tem na base de senso
7 1 comum, como, atividade física, não existe nenhum feedback 2
informando que não há conceitos na base.
O usuário, por não ter o feedback, pode pensar que digitou
8 5 2
o conceito errado e tentar novamente.
No botão "lâmpada", aparece a mensagem "criar mapa de
9 4 conceitos" e, ao clicar nele, aparece uma janela chamada 1
"Estruturar conhecimento".
Ao clicar no botão "buscar conceitos relacionados", o usuário
10 5 precisa esperar um bom tempo para obter o retorno da resposta 3
e, enquanto isso, não há nenhum feedback.
Estruturar conhecimento – Passo 3 de 3 – o botão "remover
11 5 relações selecionadas", fica ativo mesmo não tendo 2
nenhuma relação.
Ao inserir a segunda figura, o Cognitor não reconhece em
12 8 que lugar a primeira estava e isso poderia economizar 1
tempo para encontrar a segunda foto.
Valores de altura e largura, ao inserir a figura, muitas vezes,
13 5 2
são desconhecidos dos usuários.
Não se sabe qual é a medida de altura e largura (centímetro,
14 2 2
metro etc.).
Não fica claro ao usuário que para alterar o tamanho da
15 7 4
figura tem de clicar na opção "objetos da página".
É difícil perceber que ao clicar em alguma opção de "objetos
16 7 da página", a alteração será em cima em "propriedades do 3
objeto".
17 3 Não há a possibilidade de alterar a figura com o mouse. 2
18 3 Não há a possibilidade de alterar a tabela com o mouse. 2
Não há a possibilidade de alterar o tamanho da tabela
19 3 4
depois de criada.
Criar tabela – não apresenta exemplos de largura da
20 7 borda, por isso, o usuário precisa memorizar as espessuras 2
disponíveis.
21 2 Termo desconhecido pelo usuário – Botão popUp. 1
22 2 Termo desconhecido pelo usuário – Botão analogia. 1
Quando selecionamos o texto e fazemos alguma modificação,
23 1 2
ele, aparentemente, perde a seleção.
Se o usuário clicar para mudar de cor, a alteração ainda
24 5 é feita, ele pode se confundir onde vai alterar em algum 2
momento.
Ao clicar na opção de cor a interface altera o idioma para
25 4 2
inglês.
O idioma da opção cor é diferente da conhecida pelo
26 2 1
usuário.
As propriedades de texto não seguem o padrão. N (negrito),
27 4 3
I (itálico) e S (sublinhado), por exemplo.
Só há três opções de fonte e as mais conhecidas (arial, times
28 3 1
new romam etc.) não aparecem.
29 3 Depois que se salva uma figura, não é possível alterá-la. 4
Não há nenhum tipo de ajuda para conhecer as opções do
30 10 3
Cognitor, tais como: Mapa de conceito, analogia etc.
 © U5 – Métodos para Avaliação da Interface 107

A Tabela 4, demonstrada anteriormente, representa somente a tabela de um avaliador,

mas cada um tem que criar a sua tabela, ou seja, no final dessa fase, obtiveram cinco tabelas
com diversas heurísticas e severidades.

3ª Fase – Avaliação
Nessa fase, os avaliadores já conversaram e elaboraram, juntos, uma tabela que represen-
tasse a tabela de todos. É comum encontrarmos uma heurística que um avaliador considerou
como severidade 3 e, depois de uma conversa, chegaram à conclusão de que, na verdade, seria
severidade 1, ou ao contrário, por isso todos devem se entender e criar a tabela final.
É nesse momento, que se percebe melhor o uso da severidade "0", pois quando a ava-
liação é individual não tem sentido escrever um problema se o significado de sua severidade é
"Não concordo que o problema encontrado seja um problema de usabilidade". No entanto, na
tabela final, é comum essa severidade, caso todos entrem em um consenso de que uma heurís-
tica apontada por um avaliador não é de fato um problema de usabilidade.

9. CHECKLIST
Dentre os checklists existentes, citados por Nielsen (2000), Tahir (2002), Shneiderman
(1998), Cybis (2010) etc., esta unidade apresenta um conjunto feito pelo LabIUtil – Laborató-
rio de Utilizabilidade, localizado na Universidade Federal de Santa Catarina. Por meio destes
checklists é possível avaliar, inspecionar a interface e descobrir os seus defeitos, melhorando a
facilidade de uso e a utilidade dos sistemas computacionais.
Os checklists foram inseridos em uma lista chamada ErgoList. Nessa lista, há 18 grupos de reco-
mendações, que são descritos a seguir:
01 Presteza
Projete um sistema que informe e conduza o usuário na interação.
02 Agrupamento por localização
Certifique-se de que a distribuição espacial dos itens nas telas conduz os usuários na interação.
03 Agrupamento/distinção por formato
Use os formatos dos itens como meio de transmitir associações e diferenças.
04 Feedback
Forneça feedback imediato e de qualidade às ações do usuário.
05 Legibilidade
Garanta a legibilidade das informações apresentadas nas telas do sistema.
06 Concisão
Dimensione adequadamente os códigos e termos apresentados e introduzidos no sistema.
07 Ações Mínimas
Dimensione adequadamente os diálogos propostos para a realização dos objetivos do usuário.
08 Densidade Informacional
Garanta uma adequada densidade informacional das telas apresentadas pelo sistema.
09 Ações Explícitas
Certifique-se que é o usuário quem comanda explicitamente as ações do sistema.
10 Controle do Usuário
Forneça possibilidades para o usuário controlar o encadeamento e a realização das ações.

Claretiano - Centro Universitário

108 © Interface Humano-Computador

11 Flexibilidade
Permita que o usuário possa personalizar as apresentações e os diálogos.
12 Experiência do Usuário
Projete para usuários com diferentes níveis de experiência.
13 Proteção contra erros
Ofereça as oportunidades para o usuário prevenir eventuais erros.
14 Mensagens de erro
Garanta a qualidade das mensagens de erro enviadas aos usuários em dificuldades.
15 Correção de erros
Ofereça facilidades para que o usuário possa corrigir os erros cometidos.
16 Consistência
Garanta a coerência do projeto de códigos, telas e diálogos com o usuário.
17 Significados
Certifique-se que os códigos e denominações são claros e significativos para os usuários do sistema
18 Compatibilidade
Garanta a compatibilidade do sistema com as expectativas e necessidades do usuário em sua tarefa.
(Disponível em: <[Link] Acesso em: 19 mar. 2010).

Além dos checklists, o LabIUtil teve o cuidado de criar mais dois módulos para auxiliar os
projetistas a entenderem cada item da lista e saberem a melhor maneira de avaliar a interfa-
ce. O primeiro módulo tem como objetivo apresentar de modo informal, as justificativas e as
questões que compõem o checklist. Esse módulo é chamado de Questões, o segundo módulo,
chamado de Recomendações, apresenta exemplos para auxiliar os projetistas nas decisões de
projeto de interfaces com o usuário.
A seguir, são apresentados cada um dos 18 itens da lista, citados anteriormente, junta-
mente com o módulo de Questões e Recomendações (CYBIS, 2010). Ao ler cada item, preste
atenção não apenas em suas características, para depois avaliar uma interface verificando se ela
atende ou não os checklists, mas, também, procure entender todos os itens, pois eles represen-
tam fundamentos básicos que todos os projetistas devem considerar para desenvolver sistemas
usáveis e úteis. Por isso considere esses itens não apenas para a avaliação, mas, especialmente,
quando você for desenvolver um sistema.
01 Presteza
Justificativa(s):
Uma boa presteza guia o usuário e lhe poupa, por exemplo, o aprendizado de uma série de comandos.
Ela permite, também, que o usuário saiba em que modo ou em que estado ele está, onde ele se encon-
tra no diálogo e o que ele fez para se encontrar nessa situação. Uma boa presteza facilita a navegação
no aplicativo e diminui a ocorrência de erros.

Exemplos de Recomendações:
• Dirigir a entrada de dados indicando o formato adequado e os valores aceitáveis (ex.:__/__/__).
• Exibir as unidades de medidas dos dados a digitar (cm , mm, m)
• Indicar todas as informações sobre o estado da interação.
• Para cada campo de dados, fornecer um rótulo.
• Indicar o tamanho do campo, quando ele é limitado.
• Quando necessário, fornecer no rótulo informações suplementares.
• Dar um título a cada janela.
• Fornecer ajuda on-line e orientação.
 © U5 – Métodos para Avaliação da Interface 109
02 Agrupamento por localização
Justificativa(s):
A compreensão de uma tela pelo usuário depende, entre outras coisas, da ordenação dos objetos (ima-
gens, textos, comandos, etc.) que são apresentados. Os usuários irão detectar os diferentes itens mais
facilmente se eles forem apresentados de uma forma organizada (em ordem alfabética, frequência de
uso, etc). Além disso, a aprendizagem e a recuperação de itens serão melhoradas. O Agrupamento/
distinção por localização leva a uma melhor Condução.

Exemplos de Recomendações:
• Organizar os itens em listas hierárquicas
• Organizar as opções de um diálogo por menus, em função dos objetos aos quais elas se aplicam.
• Quando várias opções são apresentadas, sua organização deve ser lógica, isto é, a organização deve
representar uma organização funcional, relevante ou significativa (ordem alfabética, frequência de
uso, etc.).

03 Agrupamento/distinção por formato

Justificativa(s):
Será mais fácil para o usuário perceber relacionamento(s) entre itens ou classes de itens, se diferentes
formatos ou diferentes códigos ilustrarem suas similaridades ou diferenças. Tais relacionamentos serão
mais fáceis de aprender e de lembrar. Um bom agrupamento/distinção leva a uma boa condução.

Exemplos de Recomendações:
• Fazer uma distinção visual clara de áreas que têm diferentes funções (área de comandos, área de
mensagens, etc.).
• Fazer uma distinção visual clara dos campos de dados e seus rótulos.

04 Feedback
Justificativa(s):
A qualidade e a rapidez do feedback são dois fatores importantes para o estabelecimento de satisfação
e confiança do usuário, assim como, para o entendimento do diálogo. Esses fatores possibilitam que
o usuário tenha um melhor entendimento do funcionamento do sistema. A ausência de feedback ou
sua demora podem ser desconcertantes para o usuário. Os usuários podem suspeitar de uma falha no
sistema e podem realizar ações prejudiciais para os processos em andamento.

Exemplos de Recomendações:
• Todas as entradas dos usuários devem ser mostradas, com exceção de dados sigilosos. Mesmo neste
caso, cada entrada deve produzir um feedback perceptível (por exemplo, símbolos como *).
• Seguindo a interrupção pelo usuário de um processamento de dados, mostrar uma mensagem garan-
tindo ao usuário que o sistema voltou ao seu estado prévio.
• Quando o processamento é longo, informações sobre o estado do processamento devem ser forneci-
das.

05 Legibilidade
Justificativa(s):
A performance melhora quando a apresentação da informação leva em conta as características cogni-
tivas e perceptivas dos usuários. Uma boa legibilidade facilita a leitura da informação apresentada. Por
exemplo, letras escuras em um fundo claro são mais fáceis de ler que letras claras em um fundo escuro;
texto apresentado com letras maiúsculas e minúsculas é lido mais rapidamente que texto escrito so-
mente com maiúsculas.

Exemplos de Recomendações:
• Títulos devem ser centralizados.
• Rótulos devem estar em letras maiúsculas.

Claretiano - Centro Universitário

110 © Interface Humano-Computador

• Cursores devem se apresentar distintos dos outros itens.

• Quando o espaço para o texto for limitado, mostrar poucas linhas longas ao invés de muitas linhas curtas.
• Exibir texto contínuo em colunas largas de, ao menos, 50 caracteres por linha.
• A justificação à direita deve ser empregada se puder ser obtida por espaçamento, desde que sejam
mantidos espaçamentos proporcionais constantes entre e nas palavras, e espaçamento consistente
entre palavras de uma mesma linha.
• Ao exibir um texto, mantenha as palavras intactas, com o mínimo de hífens.

06 Concisão
Justificativa(s):
A capacidade da memória de curto termo é limitada. Consequentemente, quanto menos entradas,
menor a probabilidade de cometer erros. Além disso, quanto mais sucintos forem os itens, menor será
o tempo de leitura.

Exemplos de Recomendações:
• Para dados numéricos, a entrada de zeros à esquerda não deve ser necessária.
• Se os códigos forem mais longos que 4 ou 5 caracteres, use mnemônicos ou abreviaturas.
• Permitir ao usuário entradas de dados sucintas.
• Quando uma unidade de medida está associada a um campo, inclua a unidade como parte do campo
de dados, em vez de fazer o usuário digitá-la.

07 Ações Mínimas
Justificativa(s):
Quanto mais numerosas e complexas forem as ações necessárias para se chegar a uma meta, a carga de
trabalho aumentará e, com ela, a probabilidade de ocorrência de erros.

Exemplos de Recomendações:
• Minimize o número de passos necessários para se fazer uma seleção em menu.
• Não faça o usuário entrar com dados que poderiam ser gerados pelo computador.
• Evite entrada de comandos que exijam pontuação
• Para entrada de dados, exiba os valores default atuais nos campos apropriados.
• Quando várias páginas estiverem envolvidas, torne possível ir diretamente para uma página sem ter
que passar pelas intermediárias.

08 Densidade Informacional
Justificativa(s):
Na maioria das tarefas, a performance dos usuários piora quando a densidade de informação é muito
alta ou muito baixa. Nesses casos, é mais provável a ocorrência de erros. Itens que não estão relaciona-
dos à tarefa devem ser removidos.
A carga de memorização dos usuários deve ser minimizada. Eles não devem ter que memorizar listas
de dados ou procedimentos complicados. Eles não devem, também, ter que executar tarefas cognitivas
complexas quando estas não estão relacionadas com a tarefa em questão.

Exemplos de Recomendações:
• Em qualquer transação, fornecer somente dados que sejam necessários e diretamente utilizáveis.
• Os dados não devem necessitar de tradução entre unidades.
• A linguagem de consulta deve usar o mínimo de quantificadores na formulação das consultas.
• Não fazer com que os usuários precisem lembrar de dados exatos de uma tela para outra.
• Prover computação automática de dados derivados, para que o usuário não tenha que calcular e
entrar com dados que possam ser derivados de dados já acessíveis ao computador.
 © U5 – Métodos para Avaliação da Interface 111
09 Ações Explícitas
Justificativa(s):
Quando o processamento pelo computador resulta de ações explícitas dos usuários, estes aprendem e
entendem melhor o funcionamento da aplicação e menos erros são observados.

Exemplos de Recomendações:
• Sempre faça necessário que o usuário tecle um ENTER explícito para iniciar o processamento de da-
dos digitados; não inicie um processamento (por exemplo, atualizar um arquivo) como efeito colate-
ral de uma outra ação (por exemplo, imprimir um arquivo).
• Se a seleção do menu é feita através de dispositivo de apontamento, faça a ativação em dois passos:
a primeira ação (posicionar o cursor) deve designar a opção selecionada e uma segunda ação distinta
faz uma entrada de controle explícita.
• Entradas de comandos do usuário devem ser seguidas de um ENTER depois de editadas.

10 Controle do Usuário
Justificativa(s):
O controle sobre as interações favorece a aprendizagem e, assim, diminui a probabilidade de erros.
Como consequência, o computador se torna mais previsível.

Exemplos de Recomendações:
• Deixar ao usuário o controle do ritmo de suas entradas de dados e não pelo computador ou por even-
tos externos.
• O cursor não deve ser automaticamente movido sem o controle do usuário (com exceção de procedi-
mentos estáveis e bem conhecidos como o preenchimento de formulários).
• Possibilitar aos usuários interromper ou cancelar a transação ou processo atual.
• Fornecer uma opção CANCELAR com o efeito de apagar qualquer mudança que acabou de ser feita e
trazer a tela para seu estado anterior.

11 Flexibilidade
Justificativa:
Quanto mais formas de efetuar uma tarefa existirem, maiores serão as chances de que o usuário possa
escolher e dominar uma delas no curso de sua aprendizagem.

Exemplos de recomendações:
• Quando as exigências para o usuário forem imprecisas, fornecer meios para que ele controle a confi-
guração das telas.
• Quando, em algum contexto, a validade de certas apresentações não pode ser determinada, fornecer
ao usuário a possibilidade de desativá-las temporariamente.
• Quando os valores por default não são previamente conhecidos, o sistema deve permitir que o usuário defi-
na, mude ou suprima valores.
• A sequencia de entrada de dados deve poder ser modificada para se adaptar à ordem preferida pelo
usuário.
• Quando o formato de um texto não puder ser previsto com antecedência, deve-se proporcionar ao
usuário os meios para definir e salvar os formatos de que ele venha a precisar.
• O usuário deve poder definir os nomes dos campos de dados que ele(a) venha a criar.
12 Experiência do Usuário
Justificativa:
O grau de experiência dos usuários pode variar. Eles tanto podem se tornar especialistas, devido à uti-
lização continuada, como menos hábeis, depois de longos períodos de não utilização. A interface deve
também ser concebida para lidar com as variações de nível de experiência. Usuários experientes não
têm as mesmas necessidades informacionais que os novatos. Todos os comandos ou opções não preci-
sam ser visíveis o tempo todo. Diálogos de iniciativa exclusiva do computador podem entediar e dimi-
nuir o rendimento do usuário experiente. Os atalhos, ao contrário, podem lhes permitir rápido acesso
às funções do sistema. Pode-se fornecer aos usuários inexperientes diálogos fortemente conduzidos,

Claretiano - Centro Universitário

112 © Interface Humano-Computador

ou mesmo passo a passo. Em suma, meios diferenciados devem ser previstos para lidar com diferenças
de experiência, permitindo que o usuário delegue ou se aproprie da iniciativa do diálogo.

Exemplo de recomendações:
• Prever atalhos. Permitir que usuários experientes contornem uma série de seleções por menu através
da especificação de comandos ou atalhos de teclado.
• Prever a escolha de entradas simples ou múltiplas conforme a experiência do usuário.
• Autorizar diferentes modos de diálogo correspondentes aos diferentes grupos de usuários (ex. prever
uma presteza adaptada ao nível de experiência do usuário).
• Permitir a digitação de vários comandos antes de uma confirmação do usuário experiente.
• Fornecer um tutorial passo a passo para os usuários novatos.
• Quando as técnicas de condução atrasam o usuário experiente, fornecer meios de contornar esta
condução.
• O usuário deve poder escolher o nível de detalhe das mensagens de erro em função de seu nível de
conhecimento.

13 Proteção contra erros

Justificativa:
É preferível detectar os erros no momento da digitação, do que no momento da validação. Isto pode
evitar perturbações na planificação da tarefa.

Exemplos de recomendações:
• Quando o usuário termina uma seção e existe o risco de perda de dados, deve haver uma mensagem
avisando desse fato e pedindo confirmação do final da seção.
• Os rótulos dos campos devem estar protegidos (não devem ser acessíveis ao usuário).
• As apresentações que acompanham as entrada de dados devem estar protegidas. Os usuários não
podem modificar as informações contidas nesses campos.
• Depois de um erro de digitação de um comando ou de dados, dar ao usuário a possibilidade de corri-
gir somente a parte dos dados ou do comando que está errada.
• Todas as ações possíveis sobre uma interface devem ser consideradas e, mais particularmente, as
digitações acidentais, a fim de que entradas não esperadas sejam detectadas.
• Agrupar os atalhos de teclado por funções perigosas e/ou rotineiras.

14 Mensagens de erro
Justificativa:
A qualidade das mensagens favorece o aprendizado do sistema, indicando ao usuário a razão ou a natu-
reza do erro cometido, o que ele fez de errado, o que ele deveria ter feito e o que ele deve fazer.

Exemplos de recomendações:
• Se o usuário pressiona uma tecla de função inválida, nenhuma ação deve ocorrer, a não ser uma
mensagem indicando as funções apropriadas a essa etapa da transação.
• Fornecer mensagens de erro orientadas a tarefas.
• Utilizar termos tão específicos quanto possível para as mensagens de erros.
• Utilizar mensagens de erro tão breves quanto possível.
• Adotar um vocabulário neutro, não personalizado, não repreensivo nas mensagens de erro; evitar o
humor.

15 Correção de erros
Justificativa:
Os erros são bem menos perturbadores quando eles são fáceis de corrigir.
 © U5 – Métodos para Avaliação da Interface 113
Exemplos de recomendações:
• Fornecer a possibilidade de modificar os comandos no momento de sua digitação.
• Quando se verifica erro na digitação de um ou mais comandos, proporcionar ao usuário a possibilida-
de de refazer a digitação apenas da parte equivocada do(s) comando(s), evitando rejeitar um bloco
todo já digitado.
• Se o usuário não percebe que cometeu um erro de digitação, dar-lhe a possibilidade de efetuar, no
momento da detecção do erro, as correções apropriadas.

16 Consistência
Justificativa(s):
Os procedimentos, rótulos, comandos etc., são melhor reconhecidos, localizados e utilizados, quando
seu formato, localização ou sintaxe são estáveis de uma tela para outra, de uma seção para outra. Nes-
sas condições, o sistema é mais previsível e a aprendizagem mais generalizável; os erros são diminuí-
dos. É necessário escolher opções similares de códigos, procedimentos, denominações para contextos
idênticos, e utilizar os mesmos meios para obter os mesmos resultados. É conveniente padronizar tanto
quanto possível todos os objetos quanto a seu formato e a sua denominação, e padronizar a sintaxe dos
procedimentos. A falta de homogeneidade nos menus, por exemplo, pode aumentar consideravelmen-
te os tempos de procura.
A falta de homogeneidade é também uma razão importante da recusa de utilização.

Exemplos de recomendações:
• Localização similar dos títulos das janelas.
• Formatos de telas semelhantes.
• Procedimentos similares de acesso às opções dos menus.
• Na condução, sempre utilizar as mesmas pontuações e as mesmas construções de frases.
• Apresentar, na mesma posição, os convites (prompts) para as entrada de dados ou de comandos.
• Os formatos dos campos de entrada de dados devem sempre ser os mesmos.

17 Significados
Justificativa (s):
Quando a codificação é significativa, a recordação e o reconhecimento são melhores. Códigos e deno-
minações não significativos para os usuários podem sugerir operações inadequadas para o contexto,
levando a cometer erros.

Exemplos de recomendações:
• O título deve transmitir o que ele representa e ser distinto de outros títulos;
• Explicitar as regras de contração ou de abreviação;
• Utilizar códigos e denominações significativas e familiares em vez de códigos e denominações arbitrá-
rias (ex.: utilizar M para masculino e F para feminino, em vez de 1 e 2).

18 Compatibilidade
Justificativas:
A transferência de informações de um contexto a outro é tanto mais rápida e eficaz quanto menor é o
volume de informação que deve ser recodificada. A eficiência é aumentada quando os procedimentos
necessários ao cumprimento da tarefa são compatíveis com as características psicológicas do usuário;
os procedimentos e as tarefas são organizadas de maneira a respeitar as expectativas ou costumes do
usuário; quando as traduções, as transposições, as interpretações, ou referências a documentação são
minimizadas.
O desempenho é melhor quando a informação é apresentada de uma forma diretamente utilizável (te-
las compatíveis com o suporte tipográfico, denominações de comandos compatíveis com o vocabulário
do usuário etc).

Claretiano - Centro Universitário

114 © Interface Humano-Computador

Exemplos de recomendações:
• A organização das informações apresentadas deve ser conforme à organização dos dados a entrar.
• O formato das telas deve ser compatível com os documentos em papel.
• Os procedimentos de diálogo devem ser compatíveis com a ordem, assim como o usuário a imagina
ou conforme o seu costume.
• O formato da data deve respeitar o formato do país em que a aplicação será utilizada (ex.: na França,
o formato da data é dia/mês/ano e, na Inglaterra, é mês/dia/ano).
• Os termos empregados devem ser familiares aos usuários, conforme a tarefa a realizar.
• As unidades de medida devem ser as que são normalmente utilizadas.
• A apresentação de texto na tela deve ser conforme às convenções utilizadas para a apresentação
de texto em papel. (Disponível em: <[Link] Acesso em: 19
mar. 2010).

10. PERCURSO COGNITIVO

Percurso Cognitivo é um método de usabilidade que tem como enfoque principal inspe-
cionar o software pela facilidade de aprendizagem, particularmente por exploração (LEWIS et
al., 1992; WHARTON et al., 1994; SALGADO et al., 2006).
Nesse contexto, a palavra "exploração" está relacionada ao fato de observar se a interface
é intuitiva e fácil de ser compreendida e manuseada sem ter de ensinar a um determinado usu-
ário como utilizá-la, ou seja, a interface naturalmente tem de permitir ao usuário saber como
realizar as tarefas a que ela se propõe por meio de suas funcionalidades. Devido a essas carac-
terísticas, esse método também pode ser entendido como um método analítico que avalia uma
proposta de projeto de Interface Humano-Computador (IHC) no contexto de tarefas específicas
do usuário ( SALGADO et al., 2006).
Para que seja possível identificar a facilidade com que o usuário conseguirá entender e
utilizar um determinado software, esse método está alinhado com a teoria da Engenharia Cog-
nitiva (NORMAN, 1986). Como pode ser observado no próprio nome, a Engenharia Cognitiva
investiga a área cognitiva dos seres vivos, especialmente a dos seres humanos, com o intuito de
explorar e conhecer a forma com que o ser vivo aprende, percebe algo quando lhe é apresenta-
do, explora um determinado objeto etc.
Em nosso contexto atual, a ideia principal é saber como nós, seres humanos, percebemos,
aprendemos e utilizamos um determinado software naturalmente, afinal, quando se conhece
todos esses fatores, é possível desenvolver algo, pois o cérebro naturalmente identificará seu
objetivo e a forma de sua utilização. Em um sonho, ainda longe, seria a interface ideal. Já pensou
em olhar um sistema computacional e, em segundos, saber a sua proposta e como utilizá-lo?
O destaque positivo que esse método possui entre os profissionais de IHC está relaciona-
do, de modo especial, ao fato anteriormente citado, pois dificilmente o usuário lê manuais ou
realiza qualquer tipo de treinamento para utilizar um software; na maioria das vezes, o aprendi-
zado e o uso do software são realizados pela exploração, ou seja, o usuário aprende a manipular
a interface por meio de uma série de tentativas e erros até a chegada do momento em que
consegue entender como se faz e, assim, realiza a tarefa.
Esta é, justamente, a proposta do método: inspecionar a interface de tal forma a avaliar o
quanto ela facilita a exploração e o aprendizado do software por parte do usuário, uma vez que ele
deve poder descobrir, aprender e memorizar sozinho como o software funciona (SALGADO et al.,
2006). Segundo Lewis (et al. 1997), esse método de inspeção analisa os processos mentais que os
 © U5 – Métodos para Avaliação da Interface 115

usuários formam para executar determinadas tarefas, a fim de avaliar a interface e detectar se ela
é fácil de aprender e memorizar.
Wharton (et al., 1992) relata que esse método investiga, especialmente:
• A correspondência entre o conceito de uma tarefa por parte dos usuários e dos desig-
ners;
• A escolha adequada ou inadequada de termos, como, por exemplo, se o vocabulário
está adequado ao público-alvo;
• O feedback adequado ou inadequado como consequência de uma ação.
A avaliação do Percurso Cognitivo pode ser aplicada pelos próprios desenvolvedores, es-
pecialistas, grupos de designers e representantes de outras áreas, como marketing e treinamen-
to, por exemplo (SALGADO et al., 2006).
O interessante de os próprios desenvolvedores aplicarem o método é que eles podem
fazer isto mesmo durante a especificação do sistema, a fim de que a interface esteja próxima
do ideal antes mesmo de os especialistas ou outros profissionais avaliarem. A possibilidade de
realizar esse método mesmo durante a especificação permite ao Percurso Cognitivo ter uma fle-
xibilidade pertinente, pois ele pode ser utilizado desde as fases iniciais do desenvolvimento do
software, por meio de protótipos em papel, até o software completo. Alguns profissionais em
IHC experientes conseguem aplicá-lo, somente, com o documento de requisitos, já que a expe-
riência os permite imaginar algumas características da interface apenas lendo sobre a descrição
do sistema.
O método consiste em três fases básicas, como pode ser vista na Tabela Cada fase será
descrita, de maneira detalhada, a seguir.

Tabela 5 Fases para realizar o Percurso Cognitivo.

Número da Fase Nome da Fase
1 Preparação
2 Avaliação
3 Interpretação

1 – Fase de Preparação
Preparar todo o material e todas as informações que serão utilizadas na próxima fase. Nes-
ta fase, é definido quem são os usuários-alvo com o intuito de documentar e esclarecer quais
são suas características, seus comportamentos, suas habilidades, entre outras particularidades
que podem influenciar a interação com o software.
Vale ressaltar que essa atividade – definir usuários-alvo – é de extrema importância, pois
os profissionais que irão aplicar o método terão de levar em consideração essas informações,
uma vez que cada perfil de usuário possui características que influenciam, diretamente, na utili-
zação do software. Por exemplo, se o público-alvo for idosos, então, durante a avaliação, terá de
considerar o tamanho das letras, a quantidade de informações apresentadas para não confundi-
-los, entre outras coisas que ajudam esse público; outro exemplo, se o público-alvo for crian-
ças, é preciso se preocupar com a forma com que as informações serão apresentadas e com o
vocabulário para permitir uma melhor compreensão por elas, já que não são completamente
alfabetizadas etc. Enfim, o profissional, antes de realizar o método, tem de saber quem são os
usuários, seus objetivos, suas características e todas as outras informações que os influenciarão
a "advinhar" como manejar o software corretamente (SALGADO et al., 2006).
Claretiano - Centro Universitário
 116 © Interface Humano-Computador

É fundamental também definir as tarefas que serão inspecionadas e a sequência das ações
corretas para cada tarefa. A escolha das tarefas não é algo simples; por isso, ela pode ser feita
com base em estudos de mercado, análise das necessidades e análise dos requisitos. Não há a
quantidade de tarefas que devem ser analisadas, essa quantidade tem de ir ao encontro das
prioridades, do tempo e das necessidades dos profissionais, bem como da disponibilidade fi-
nanceira.
Para cada tarefa, é preciso definir, minuciosamente, as ações que o usuário terá de fazer
por meio da interface para conseguir realizá-la. Por exemplo, se a tarefa fosse efetuar uma pes-
quisa em um campo de busca, então, as possíveis ações seriam encontrar o campo de busca,
digitar uma palavra ou frase que representa a pesquisa, pressionar o <enter> (tecla existente no
teclado do computador) ou clicar em "Pesquisar" (botão existente na interface).
Como último passo dessa fase, está a definição da(s) interface(s) que será(ão) objeto(s) de
análise. No exemplo anterior, apenas uma interface foi escolhida. Nessa interface, que é a prin-
cipal do software, já contém o campo de busca; assim, não há necessidade do usuário clicar em
algo para mudar para a página que contém esse campo. Caso isto fosse preciso, agregaria mais
algumas ações e interfaces à tarefa.
De maneira geral, podemos resumir essa fase em quatro perguntas, ilustradas na Tabela 6.

Tabela 6 Perguntas da Fase de Preparação (Wharton et al., 1992)

Quem são os usuários do software?
Quais tarefas serão analisadas?
Qual é a sequência correta de ações para cada tarefa?
Qual é a interface definida?
Fonte: WHARTON et al., 1992

2 – Fase de Avaliação
Nesta segunda fase, o avaliador é responsável por descrever em detalhes o que o usuário
faria para realizar uma tarefa. Encontramos a primeira grande dificuldade do método, pois o
profissional terá de conhecer muito bem o usuário-alvo e se comportar como ele ao utilizar o
software para ter a ideia exata do que o usuário faria e, assim, para descobrir os pontos negati-
vos e positivos.
Quando as ações e atitudes do pesquisador vão ao encontro do esperado, o software é
tido por usável; quando este vai de encontro, identifica-se não apenas um problema de usabi-
lidade, mas também a sua causa, ou seja, a razão de não se poder "advinhar" o que fazer (SAL-
GADO et al., 2006).
Durante a avaliação, é preciso registrar todas as informações. Uma forma de registrar é
responder algumas perguntas, que devem ser sistematicamente levantadas e respondidas pelos
avaliadores no decorrer do processo. Não há perguntas obrigatórias, uma vez que elas depen-
dem do contexto, público-alvo, objetivo etc. Entretanto, como estudo e aprendizado do método,
quatro perguntas básicas descritas por Wharton (et al., 1992) são abordadas, como pode ser
observado na Tabela Essas perguntas, além de serem básicas, ou seja, podem ser utilizadas para
avaliar vários tipos de softwares, remetem ao pensamento natural do ser humano e à forma
com que ele tenta atingir uma determinada meta no contexto computacional.
 © U5 – Métodos para Avaliação da Interface 117

Tabela 7 Perguntas da Fase de Avaliação.

1 O usuário tentará atingir a meta correta?
2 O usuário perceberá que a ação correta está disponível?
3 O usuário associará o elemento correto à meta a ser atingida?
4 Se a ação correta é tomada, o usuário perceberá que progrediu em direção à solução da tarefa?

Ao ler a primeira pergunta com atenção, você deve ter pensado: mas "o usuário tentará
atingir a meta correta?". Com certeza, pois é este o objetivo dele ao utilizar o sistema; então,
essa pergunta será sempre positiva, independentemente do software e da dificuldade que ele
tiver ao utilizá-lo. No entanto, essa pergunta é bem mais complexa do que aparenta; por meio
dela, é preciso observar se a interface permite ao usuário saber por onde começar. Uma coisa
é ele querer atingir a meta, outra coisa é saber se a interface o possibilita a fazer isto de uma
maneira fácil.
É sempre importante manter o enfoque na interface, pois, assim, fica mais claro saber o
que você irá avaliar. No caso, com base na primeira pergunta, terá de observar, considerando as
características de seu público-alvo, se a opção necessária está disponível ou não na interface;
se o local que a opção está é adequado para o usuário encontrar, clicar ou realizar alguma ação;
se o vocabulário utilizado para apresentá-la é viável e fácil de ser compreendido; se o tamanho
da opção está bom; se as cores estão sendo utilizadas de forma satisfatória; se o contraste das
cores do fundo e da opção o permitem estar visível adequadamente etc.
Essas considerações influenciam, diretamente, a identificação de uma opção pelo usuá-
rio; portanto, elas terão de ser analisadas. É válido mencionar que você terá de escrever qual
é a ação que o usuário tentará fazer nesse momento. Observe que você, ao avaliar, tem a ação
correta, mas a opção para executar essa ação está visível a ponto de o usuário a escolher ou, por
exemplo, ter outra opção que remeta à mesma funcionalidade e que possa confundi-lo.
Ao observar isto, você terá condições de descrever a resposta da primeira pergunta, mas é
preciso descrevê-la com detalhes, como, por exemplo, explicar o porquê de o usuário clicar em
outra opção ao invés de o fazer na correta, quais são as características da outra opção que fazem
que o usuário a visualize primeiro ou clique nela etc. Esses detalhes são de extrema importância
para o momento da correção, afinal, se você sabe quais são as características que possivelmente
farão o usuário clicar na opção errada, às vezes, pode ser uma estratégia utilizar tais caracterís-
ticas para destacar a opção certa.
A primeira pergunta também está relacionada a observar se o usuário saberá qual será
o próximo passo, ou seja, se o usuário, ao ver a primeira opção em que ele terá de clicar, vai
perceber qual é a próxima ação, de modo a não ficar perdido quando essa segunda ação for
necessária. Esta é uma estratégia para permitir ao usuário ter controle e compreender todas as
opções de maneira mais fácil, uma vez que ele estará preparado para a próxima ação desde a
ação anterior.
Na segunda pergunta, "o usuário perceberá que a ação correta está disponível?", há a pre-
ocupação em observar o formato do elemento que a interface disponibiliza a ação. Por exemplo,
se a opção é clicar, o usuário perceberá por meio do formato que é isto que terá de fazer? Se a
opção é visualizar um determinado resultado, o elemento escolhido para ficar na interface ilus-
tra que ali será exibido um resultado? Ao olhar, o usuário saberá, de imediato, o local correto?
Enfim, quais são as opções e seus formatos que a interface possui para o usuário executar a
ação?

Claretiano - Centro Universitário

118 © Interface Humano-Computador

Outra questão que deve ser investigada nessa segunda pergunta é o local em que está o
elemento para o próximo passo. Observe que, na pergunta anterior, houve a preocupação em
saber se o elemento está ou não disponível. Nessa pergunta, também é preciso saber o local em
que ela está, bem como investigar se o local escolhido é de fácil visualização e se é intuitivo para
o usuário chegar até ela.
Para a pergunta "o usuário associará o elemento correto a meta a ser atingida?", é preciso
perceber a relação entre a ação e o elemento disponível na interface para o usuário executar a
ação. Por exemplo, pelas perguntas anteriores, é possível saber que a ação é clicar, pois o forma-
to do elemento da interface indica isto, mas é preciso realizar uma comparação para se saber se
todas essas informações ajudarão o usuário. Nesse caso, para permitir ao usuário saber que a
opção tem de ser clicada, o elemento, que poderia ser um botão ou link, com um nome intuitivo
em um local, bem como cor e tamanho adequados.
Observe a particularidade dessa pergunta ao compará-la às anteriores, pois até à segunda
pergunta, é preciso identificar as características, os formatos e outros detalhes, e, por meio da
terceira pergunta, terá de ser feita uma análise detalhada sobre se tudo o que foi apresentado
é viável e/ou útil para o usuário saber o que fazer, uma vez que é preciso saber se o elemento
da interface revela seu propósito e comportamento. Uma dica é você se colocar no lugar do
público-alvo e olhar o elemento para realizar a ação, para pensar no que você faria ao vê-lo.
Seria clicar? Arrastar? Ficar aguardando para ver algo acontecer? etc.
É interessante perceber se o elemento permite ao usuário saber o que ele pode fazer –
observe que, nesse caso, é importante conhecer o significado do elemento. Há um estudo muito
interessante sobre semiótica, um assunto que influencia, diretamente, como o usuário percebe
o que está na interface e o seu significado (SOUZA et al., 2008). De maneira bem simples, é
possível dizer que a preocupação central é permitir que a interface tenha elementos que sejam
intuitivos e fáceis para o usuário saber o que fazer com eles. Enfim, como citado anteriormente,
se o elemento revela o seu propósito e comportamento.
Por exemplo, se o elemento possui o formato de um botão, então, tem de ser possível cli-
car sobre ele, pois qualquer ação possível diferente disto poderá deixar o usuário perdido. Outro
exemplo é ter um elemento que pareça uma lista de opções, mas que sempre e somente apa-
rece uma opção nesse campo, que possui tamanho suficiente para mais. Isto faz que o usuário
fique aguardando para saber se mais informações vão ou não aparecer, afinal o elemento sugere
isto. Esses dois exemplos foram apenas para você perceber a influência e a importância que os
detalhes fazem na interação humano-computador; por isso, tudo tem de ser bem pensado. Há
a necessidade de ter um planejamento, um cuidado e uma estratégia para cada item disponível
por meio da interface.
Sobre a última pergunta, "se a ação correta é tomada, o usuário perceberá que progrediu
em direção à solução da tarefa?", é preciso analisar se a interface apresenta ou não o resulta-
do da ação e a forma com que ela faz isto. A mensagem ou qualquer outra informação que for
apresentada ao usuário uma como forma de mostrar se está certo ou não o que ele fez tem de
ser clara e fácil de ser compreendida. Não adianta exagerar no visual, colocando cores, formas e
letras diferentes, se o principal, que é passar a mensagem para o usuário, não for atingido.
O resultado apresentado tem de ter correspondência com o objetivo do usuário. Por
exemplo, se o objetivo for visualizar uma informação, tem de estar claro o local e a forma do
elemento responsável por exibi-la para que o usuário encontre e visualize a informação deseja-
da facilmente. Se o objetivo foi enviar um e-mail, o usuário tem de perceber, no final, se o este
 © U5 – Métodos para Avaliação da Interface 119

foi enviado com sucesso ou não. Enfim, são formas para o usuário compreender que aquilo que
ele pretendia foi realizado com sucesso.
Observe que esse passo é importante para cada ação, e não apenas para a tarefa final,
uma vez que, se a tarefa for enviar um e-mail, mas, dentre as ações, tiver "clicar em Escrever
e-mail", então, assim que clicar, o usuário tem de perceber que está no caminho correto e na in-
terface adequada para escrever um e-mail, ou seja, o resultado tem de ser adequado para cada
ação. Nesse caso, não há necessidade de mostrar uma mensagem que represente a conclusão
do objetivo da tarefa "seu e-mail foi enviado com sucesso", pois o usuário está apenas em uma
das ações para executar essa tarefa, e o importante é deixar claro que a ação foi realizada com
sucesso.
Como forma de facilitar a compreensão das quatro perguntas e permitir ao profissional
realizar uma inspeção mais detalhada, Prates (2003) elaborou algumas subperguntas para cada
pergunta descrita por Wharton (et. al., 1992). Por meio dessas novas perguntas, é possível res-
ponder com mais detalhes cada uma das quatro perguntas anteriores. Você pode verificar as
perguntas juntamente com as subperguntas, apresentadas na Tabela 8.

Tabela 8 Perguntas e subperguntas da Fase de Avaliação

1 O usuário tentará atingir a meta correta?
1a. Dada a decomposição de uma tarefa em subtarefas, o usuário saberá por onde começar? Saberá qual é o próximo
passo?
1b. O que o usuário vai tentar fazer a cada momento?
2 O usuário perceberá que a ação correta está disponível?
2a. Onde está o elemento de interface correspondente ao próximo passo?
2b. Que ações a interface torna disponível?
3 O usuário associará o elemento correto à meta a ser atingida?
3a. O elemento da interface revela seu propósito e comportamento?
3b. O usuário consegue identificar os elementos da interface?
4 Se a ação correta é tomada, o usuário perceberá que progrediu em direção a solução da tarefa?
4a. Como a interface apresenta o resultado de cada ação?
4b. O resultado apresentado tem correspondência com o objetivo do usuário?
Fonte: Prates, 2003.

Se você prestar atenção em cada das perguntas, possivelmente perceberá que elas estão
diretamente relacionadas com o nome do método, Percurso Cognitivo, pois, de alguma forma,
elas se assemelham com a forma com que nós, seres humanos, intuitivamente pensamos ao re-
alizar algo, ou seja, com nossa forma cognitiva (natural) de realizar uma determinada atividade
no computador. Por exemplo, se você quiser "clicar no botão enviar", geralmente, seguirá essa
sequência: encontrar uma opção na interface que lhe remeta à ação enviar, depois perceber o
formato em que está essa opção para saber se ela lhe permite clicar e, ao realizar a ação "clicar
no botão enviar", vai querer saber se o que você fez foi realizado com sucesso ou não.
Apesar de, após a história apresentada, tudo isto parecer um pouco mais simples, é preci-
so ficar claro que realizar essa inspeção com o rigor que ela deve ter não é trivial, pois ela é uma
inspeção subjetiva, o que faz que a avaliação tenha de ser bem descrita, com detalhes suficien-
tes para permitir o rigor necessário para que você ou outro profissional possa ler, entender e
realizar as modificações necessárias na interface.
Finalmente, é importante reforçar que, para cada ação que compõe a tarefa, é preciso
responder às quatro perguntas.
Claretiano - Centro Universitário
120 © Interface Humano-Computador

Por meio de todas as perguntas da primeira e da segunda fase, será possível registrar as
seguintes informações, de acordo com Wharton (et al., 1992) e Salgado (et al., 2006): quem é o
público-alvo e qual é o conhecimento esperado desse público, bem como sua experiência, a cla-
reza da disponibilidade da ação no momento apropriado; a facilidade de identificação da ação
disponível; as recomendações para mudanças de design e uma descrição coerente com detalhes
suficientes que explicam e justificam o julgamento do profissional.
Essa descrição deve ser imparcial e deve contar o que é possível visualizar por meio da
interface, relatando os pontos positivos e negativos para avaliar a facilidade de aprendizagem e
memorização da interface.
Agora, veremos a terceira fase.

3 – Fase de Interpretação
Nesta terceira fase, toda a descrição e todas as outras informações discutidas até o momen-
to serão analisadas. Segundo Salgado (et al., 2006), um dos resultados esperados é a descoberta
dos conflitos entre o que o profissional pensou que seria viável para exibir na interface e o que o
usuário realmente enxergará e, de fato, precisará para realizar uma determinada atividade.
No final, é realizado um relatório com o mesmo detalhe e rigor que foi feito até essa fase.
Nesse relatório, tem de conter a interpretação dos resultados e os problemas encontrados, bem
como as soluções observadas que podem sanar o problema. Resumidamente, é possível des-
crever que essa fase conterá todos os problemas identificados na fase de avaliação e a forma de
solucioná-los; por isso, geralmente, esse relatório possui problemas nas escolhas das palavras,
dos menus, da informação exibida pelo botão e respostas inadequadas sobre as consequências
de ações, entre outras informações que influenciaram o julgamento do projetista para dizer que
a ação pode não ser feita de maneira adequada pelo usuário.
Para auxiliar a escrita desse relatório, há uma tabela que permite ao projetista saber quais
são os detalhes que devem ser inseridos e o local adequado para cada informação, de modo que
seja possível manter uma organização. A Tabela 9 possui um exemplo da estrutura desse relató-
rio; no entanto, ressalta-se que o relatório pode conter mais informações e detalhes. O objetivo
dessa tabela é apenas apresentar as informações básicas que devem constar no relatório.

Tabela 9 Interpretação dos resultados e sugestões de melhorias.

Nrº Problema encontrado Local O que ocasionou o problema? Soluções sugeridas
1
2
3

Como pode ser observado na Tabela 9, há cinco informações básicas para um relatório de
Percurso Cognitivo. O primeiro campo representa o "Número" sequencial que deve ser atribuí-
do. Esse número é utilizado, apenas, para facilitar a interpretação de quantos problemas foram
encontrados. No "Problema encontrado", é necessário descrever em detalhes qual foi o proble-
ma, por que ele foi considerado um problema, quais são as características do elemento ou da
interface que influenciaram para isto acontecer; enfim, é necessário ser bem minucioso nessa
descrição, pois o outro avaliador, ao ler esse campo, tem de identificar, de imediato, o problema
que ocorreu e o que aconteceu para ser considerado um problema. Isto o ajudará a refletir sobre
o problema e pensar sobre qual foi a falha e quais são as possíveis soluções para resolvê-lo.
 © U5 – Métodos para Avaliação da Interface 121

Vale ressaltar que você também pode descrever alguma solução, mas é viável permitir a
outro profissional refletir sobre as soluções que ele poderia propor – isto ajudará em uma solu-
ção ainda mais completa, pois o que você pensar poderá ser um complemento e, dessa forma,
enriquecer a solução, ou será uma forma de discutir qual é a melhor solução a ser aplicada e,
com isso, possivelmente escolher a forma mais adequada.
É necessário também descrever o "Local" em que o problema ocorreu. O nível de detalhe
para esse campo depende da quantidade de interfaces e da complexidade do software. O obje-
tivo é que, ao ler o local, o profissional saiba, de imediato, em que interface e em que elemento
ocorreu o problema, bem como onde encontrar esse elemento. É preciso deixar bem claro esse
local, pois o profissional não pode perder tempo para procurar o problema – o tempo deve ser
utilizado para solucioná-lo.
A quantidade de interfaces e a sua complexidade influenciam o nível de detalhe, porque,
dependendo desses fatores, será necessário descrevê-los, de forma que seja fácil identificar
uma interface dentre as várias, e, se a tarefa for complexa e requerer a utilização de vários ele-
mentos, é preciso relatar em qual desses elementos há um problema.
Para uma melhor organização do conteúdo da tabela e compreensão por outros profissio-
nais, é importante que cada linha da tabela contenha um problema apenas. Não agrupe vários
problemas em um mesmo local, pois, assim, você evita que o nível de atenção de quem for ler a
tabela tenha de ser ainda maior para entender todos os detalhes descritos em um mesmo local,
o que é desnecessário. Esse cuidado também ajudará no preenchimento da tabela, uma vez que
é mais fácil escrever algo por partes ao invés de tentar escrever tudo sem uma ordem.
No campo "o que ocasionou o problema?", é possível escrever quais foram as atitudes
realizadas para se chegar ao erro. Lembre-se de que, além de saber onde está o problema, é
importante que o outro profissional saiba como simular o software, com o intuito de conseguir
ver o mesmo erro. Assim, ficará mais fácil perceber, além do problema e o local, como isto acon-
teceu e entender se houve alguma outra coisa que pode ter ocasionado o problema.
Ao descrever as "soluções sugeridas", é preciso ter certo cuidado, pois, além de expor a sua
opinião sobre algo, você terá a responsabilidade de explicar em detalhes qual foi o seu raciocínio
para chegar a essa solução, por que ela é viável e como aplicá-la. Todas essas informações têm de
estar claras para que o outro profissional, além de entender, possa se interessar por sua solução.
Ao concluir esse relatório, o método Percurso Cognitivo é finalizado, e tudo o que foi re-
gistrado deve ser entregue para as pessoas que são responsáveis pelo desenvolvimento do sof-
tware ou para a pessoa contratante para esse serviço se realizar.
Segundo Salgado (et al., 2006), ao aplicar o método com sucesso, é possível ter como
resultado como será a interação entre o usuário e o software, e as perguntas e a forma de se
avaliar servem como base para um conflito entre algum modelo mental (do usuário) e uma pro-
priedade física ou funcional do sistema. Outra informação pertinente é que, por meio da teoria
cognitiva, o profissional pode trabalhar com dados da cognição do usuário mesmo sem observá-
los diretamente.
Dessa forma, podemos dizer que é possível prever as atitudes do usuário ao ver uma de-
terminada interface mesmo sem ver o usuário utilizando o sistema. Entretanto, é importante
ressaltar que a qualidade dos resultados está relacionada com o profissional e sua experiência.
Por não precisar do usuário para realizar essa avaliação, esse método tende a adquirir uma van-
tagem de todos os métodos de inspeção, que é o custo, pois envolve menor número de pessoas,
já que tudo pode ser feito com os profissionais que já estão envolvidos no desenvolvimento.

Claretiano - Centro Universitário

 122 © Interface Humano-Computador

11. EXEMPLO DE APLICAÇÃO – PERCURSO COGNITIVO

A inspeção descrita a seguir foi realizada em um webmail que tem conquistado muitos usu-
ários atualmente, especialmente pela quantidade de funcionalidades de adaptação da interface.
Esse webmail permite mudar o tema ou a imagem de fundo de tela, aumentar ou diminuir a quan-
tidade de funcionalidades na interface, bem como mudá-las de posição, entre outros recursos que
facilitam ao usuário ter uma interface adequada e divertida, uma vez que tem a possibilidade de
inserir desenhos, cores, jogos etc.
Esse webmail é chamado Gmail. A empresa responsável por esse webmail é a mesma que
possui, atualmente, um site de busca que é considerado o melhor por muitas pessoas – o Goo-
gle. Por isso, outra vantagem desse e-mail é unir os recursos dos webmails tradicionais com uma
das melhores tecnologias de pesquisa do mundo, o que torna o ato de localizar as mensagens
recebidas, enviadas etc. algo muito fácil.
A ideia de realizar o Percurso Cognitivo no Gmail é para identificar se todos esses recursos
e essas vantagens que a Google diz que oferece não atrapalha os usuários em realizar uma ta-
refa simples e básica para um webmail, que é "Enviar um e-mail". A intenção é saber se o Gmail
não está se parecendo com um celular de última geração, que possui tantas funcionalidades
e botões que se torna difícil saber como realizar uma tarefa que deveria ser trivial, como, por
exemplo, fazer uma ligação.
Para a inspeção, foram selecionadas duas interfaces. A primeira, que pode ser observada
na Figura 15, é a principal do Gmail. Por meio dessa interface, o usuário tem acesso a todas
as funcionalidades. Se você olhar da esquerda para a direita de cima para baixo, vai visualizar
alguns links para os aplicativos da empresa Google, como Orkut, Agenda etc., o e-mail do usu-
ário que realizou o acesso e, ao lado, algumas opções para realizar as adaptações na interface
(símbolo verde) e alterar as configurações, bem como ajuda e o link de sair. Depois há o símbolo
do Gmail, seguido por um campo que permite realizar buscas no e-mail ou em toda a web. Do
lado esquerdo, você pode observar alguns links que funcionam como menus para acessar as
funcionalidades básicas comuns a qualquer webmail. No centro, você verá uns botões utilizados
para realizar algumas ações nos e-mails, que se encontram na parte central, finalmente, do lado
direito, existe o Gtalk, o bate-papo do Google.

Figura 15 Tela principal do Gmail.

 © U5 – Métodos para Avaliação da Interface 123

A segunda interface, ilustrada na Figura 16, é a que permite ao usuário escrever um e-mail
e enviá-lo. No início da interface, há três botões: "Enviar", "Salvar agora" e "Descartar". Em se-
guida, há alguns campos para ser preenchidos, para criar o e-mail a ser enviado.

Figura 16 Tela do Gmail para enviar e-mails.

Tabela de Avaliação
Antes de ler as perguntas que devem ser respondidas na Fase de Preparação, vale a pena
saber um pouco mais sobre uma pergunta que, apesar de parecer simples, é bem complexa, e
a sua resposta influenciará toda a inspeção. Essa pergunta, inclusive, é a primeira: "quem são
os usuários do sistema?". Observe que o principal objetivo da inspeção é perceber as possíveis
dificuldades que os usuários podem ter; assim, saber quem são os usuários e entender a forma
com que eles pensam, agem, entre tantas outras características descritas em unidades anterio-
res, é essencial.
Devido à importância desses fatores, é imprescindível bem pensar e discutir com todos os
agentes envolvidos no desenvolvimento do software sobre quem serão os usuários. Essa discus-
são deve acontecer desde o levantamento de requisitos, ou seja, tem de ser uma das primeiras
coisas a se pensar.
Apenas para facilitar o entendimento das características que foram inseridas na primeira
pergunta, é válido discutir que, na área da IHC, de maneira geral, o usuário é classificado em três
tipos: iniciante, intermediário e avançado no uso de um determinado software.
Na maioria das vezes, a opção escolhida é a de intermediário. Isto ocorre porque, geral-
mente, o usuário é classificado como iniciante por pouco tempo, e poucos são os usuários que
alcançam o nível avançado. Um usuário é considerado iniciante nas primeiras vezes em que
utiliza o software, pois ele ainda não conhece bem quais são as opões e qual é o objetivo do
software e ainda possui dificuldades muito básicas que, após três ou quatro vezes de uso, se es-
pera que sejam sanadas. Por fim, para o usuário ser considerado avançado, ele tem de conhecer

Claretiano - Centro Universitário

 124 © Interface Humano-Computador

todas as funcionalidades do software, ou seja, os caminhos necessários para realizar qualquer

tipo de tarefa que o software possa executar. O usuário intermediário é aquele que conhece o
software e sabe utilizar as funcionalidades que realmente precisa e que, eventualmente, memo-
riza outras funcionalidades que utiliza esporadicamente.
Se o usuário precisa e gosta do software, possivelmente passará da classificação de ini-
ciante para a de intermediário muito rápido, ou seja, em apenas alguns dias de uso. Entretanto,
dificilmente um usuário passa a ser classificado como avançado, porque, a maioria dos usuários,
não se interessa em conhecer todas as funcionalidades que o software possui e, na maioria das
vezes, preocupa-se em memorizar, apenas, as funcionalidades de que realmente precisa.
Vale lembrar que, dependendo do software, existe a possibilidade de se pensar em outro
tipo de usuário. Por exemplo, se você for desenvolver um software para ser utilizado por pesso-
as idosas, então, provavelmente, você terá de pensar em usuários iniciantes, devido à capacida-
de cognitiva e de memorização dessas pessoas.
No caso do exemplo citado a seguir, foi considerada a classificação de intermediário para
a experiência com o computador, no uso de webmails etc.

Tabela 10 Tabela Preparação.

Quem são os usuários do sistema?

Algumas características comuns do público-alvo são citadas a seguir:
- entendem textos curtos e são capazes de interpretá-los;
- estão acostumados a utilizar o computador;
- geralmente navegam na internet.
- conhecem outros webmails.
Observação: uma pesquisa de mercado foi realizada para identificar os tipos de usuários que acessam a web.
Dentre os identificados, foi escolhido um tipo que representa a maioria dos usuários, com as características citadas
anteriormente. Foi identifica que, hoje em dia, existe uma grande diversidade de usuários acessando a web, mas
a maioria ainda não está totalmente escolarizada, e a capacidade de esses usuários lerem um texto complexo e
interpretá-los é pouca; por isso, é necessário avaliar a interface considerando textos simples, curtos e fáceis de
serem compreendidos.
Esse tipo de usuário já tem contato com o computador a mais de três anos e conhece as suas funcionalidades bá-
sicas. No entanto, quando é solicitado para fazer alguma tarefa diferente do habitual, ele fica com receio, mas se
arrisca a realizá-la por tentativa e erro. Se a tarefa for muito complexa e ele não conseguir realizar em quatro tenta-
tivas, há uma desistência.
Tem contato com a internet a mais de dois anos geralmente para acessar:
- e-mails;
- notícias;
- rede de relacionamentos, como Orkut;
- sites de buscas, como Google;
- comunicadores instantâneos, como MSN Messenger.
Como o contexto é a inspeção em um webmail, houve o interesse em identificar quais seriam os webmails mais
utilizados pelo público-alvo escolhido. Partindo dessa informação, seria feita uma análise na interface com o intuito
de conhecer quais seriam as funcionalidades, as opções, os símbolos, a linguagem, entre outras características que
os usuários estão acostumados a encontrar no webmail que eles possivelmente gostam, pois acessam com mais
frequência.
Na pesquisa, identificou-se que o webmail mais utilizado é o Hotmail, um produto da Microsoft©. Um fato interessante
abordado é que o uso desse webmail não tem como fatores principais a satisfação e a facilidade de uso. O fator
principal é a ligação entre o Hotmail e o programa MSN Messenger. A maioria dos usuários utiliza o Hotmail porque
se interessaram, inicialmente, pelo MSN, para conversar com as pessoas da família e com os amigos ou para con-
tatos profissionais. E, como era preciso ter um e-mail no Hotmail para entrar no MSN, os usuários faziam a "conta"
e utilizavam-na por comodidade.
 © U5 – Métodos para Avaliação da Interface 125
Por meio da pesquisa de mercado, foi possível perceber que muitos usuários, mas não a maioria deles, estão insa-
tisfeitos com a forma com que as opções e funcionalidades são apresentadas; por isso, durante a inspeção, é viável
realizar a comparação para saber o que os usuários estão acostumados, mas, se tiver algo diferente, vale a pena
pensar se o "novo" ou "diferente" não é melhor.
O objetivo de descrever essa pesquisa é, apenas, para ilustrar a forma com que se deve pensar. Não é apenas definir
os usuários; é preciso saber o que eles usam, o porquê de usarem, se gostam ou não, entre outros fatores que in-
fluenciam, diretamente, a forma com que eles interagem com o computador. Também há a necessidade de se pensar
na concorrência existente no mercado. Se você deseja desenvolver algo, que ele seja o melhor.
*Pesquisa de mercado hipotética – meramente ilustrativa
ssss

Quais tarefas serão analisadas?

A tarefa é enviar um e-mail com um anexo.
Algumas informações pertinentes para realizar a tarefa são:
1 – O e-mail deve ser enviado para o endereço professor@[Link]
2 – O assunto deve ser "Trabalho – Percurso Cognitivo" (sem as aspas)
3 – A mensagem deve conter o seguinte texto:
"Prezado professor,
Segue anexo um arquivo .doc com a inspeção realizada no e-mail Gmail utilizando o método Percurso Cognitivo.
Os nomes completos dos alunos e outras informações pertinentes se encontram no arquivo.
Atenciosamente, " (sem as aspas)
4 – Anexar um arquivo .doc que se encontre na área de trabalho do computador. (o local definido tem de estar de
acordo com o computador em que o profissional irá realizar a inspeção).

Qual é a sequência correta de ações para cada tarefa e como ela é descrita?
A sequência para realizar a tarefa definida é:
1 – Clicar em "Escrever e-mail"
2 – Definir "Para"
3 – Digitar o "Assunto"
4 – Escrever a mensagem
5 – Anexar arquivo
6 – Clicar no botão "Enviar"

Qual é a interface definida?

Duas interfaces foram escolhidas para ser avaliadas:
1 – Interface principal em que o usuário tem acesso aos e-mails na caixa de entrada e outras funcionalidades do
sistema.
2 – Interface que permite ao usuário digitar todas as informações definidas na tarefa e enviar a mensagem com
anexo.
Observação: a interface principal tem de ser avaliada, pois há a necessidade de saber se o usuário encontrará a
opção para enviar uma mensagem, bem como o feedback de mensagem enviada, exibida somente na interface prin-
cipal (essa observação foi feita porque, para a tarefa, é realmente necessário também avaliar a interface principal;
dependendo da tarefa, seria preciso apenas avaliar uma interface se tudo pudesse ser feito e visualizado nela).

Tabela 11 Tabela Avaliação.

AÇÃO CLICAR EM "ESCREVER E-MAIL"
Sim. Embora haja muitas opções na interface, a opção
O usuário tentará atingir a meta correta?
"Escrever e-mail" está em um local de destaque.

Claretiano - Centro Universitário

126 © Interface Humano-Computador

AÇÃO CLICAR EM "ESCREVER E-MAIL"

Mesmo tendo alguma dificuldade na primeira vez, devido
à quantidade de opções e por estar em local diferente
de outros e-mail, como o Hotmail, o usuário encontrará e
aprenderá onde está a opção.
Essa afirmação é porque os usuários geralmente leem
1a. Dada a decomposição de uma tarefa em subtarefas,
da esquerda para direita e de cima para baixo, e a op-
o usuário saberá por onde começar? Saberá qual é o
ção "Escrever e-mail" encontra-se nessa posição de
próximo passo?
destaque, logo abaixo de um dos símbolos mais visíveis
– o logotipo do Gmail.
Entretanto, ele não saberá qual é a próxima ação, pois
ela está visível, apenas, na próxima tela, que será exibi-
da após um clique do usuário na opção correta.
Nesse momento, o usuário tentará encontrar uma opção
que indique uma maneira de escrever um novo e-mail.
1b. O que o usuário vai tentar fazer a cada momento? Então, ele encontrará uma opção com uma linguagem
comum – "Escrever e-mail". Por isso, pressupõe-se que
o usuário clicará em "Escrever e-mail".
Sim, pois a opção correta está em um formato que apa-
renta ser um link por ser azul e sublinhado, o que pode
O usuário perceberá que a ação correta está disponí- indicar ao usuário que ali é uma opção que está disponí-
vel? vel para ser clicada, especialmente porque o público-alvo
considerado nessa inspeção tem conhecimento de alguns
símbolos existentes na internet, e o link é um destes.
Não há possibilidade de ver a próxima ação; por isso,
2a. Onde está o elemento de interface correspondente
não há indícios de que a próxima opção correta está
ao próximo passo?
disponível.
Para essa ação, existe a opção "Escrever e-mail" para
2b. Quais ações a interface torna disponível?
ser clicada.
Sim, pois o que está escrito na opção a ser clicada vai
O usuário associará o elemento correto à meta a ser
ao encontro da ação desejada pelo usuário, que é en-
atingida?
viar um e-mail.
Sim, pois o elemento é um link com aparência de um link,
3a. O elemento da interface revela seu propósito e com-
e, quando clicado, executa uma atividade normal de um
portamento?
link – no caso, vai para uma próxima página.
3b. O usuário consegue identificar os elementos da in- Sim. Para essa ação, é possível identificar o link "Es-
terface? crever e-mal".
Se a ação correta é tomada, o usuário perceberá que Sim, a interface é alterada logo que o usuário clica sobre
progrediu em direção à solução da tarefa? o link, mostrando que algo aconteceu.
4a. Como a interface apresenta o resultado de cada Destaca o "Escrever o e-mail" em azul e abre a página/
ação? conteúdo de envio de e-mail.
Sim, pois a próxima página possui alguns campos que
4b. O resultado apresentado tem correspondência com
são para enviar um e-mail. Devido à experiência do usu-
o objetivo do usuário?
ário em mandar e-mail, ele reconhecerá os campos.

AÇÃO DEFINIR "PARA"

Sim, pois a nova página deixa em destaque as opções
O usuário tentará atingir a meta correta? necessárias para enviar um e-mail, incluindo a opção
"Para".
Sim, pois de modo semelhante à escrita de uma carta,
existe a preocupação em definir o remetente e o destina-
tário, e a interface exibe, automaticamente, o remetente,
1a. Dada a decomposição de uma tarefa em subtarefas, que pode ser visualizado no campo "De", fazendo com
o usuário saberá por onde começar? Saberá qual é o que o usuário perceba que falta informar o destinatário,
próximo passo? que se encontra em um campo logo abaixo.

Sim. É possível visualizar a opção "Assunto", que repre-

senta o próximo passo.
 © U5 – Métodos para Avaliação da Interface 127

AÇÃO DEFINIR "PARA"

O usuário tentará digitar o endereço de um e-mail no
1b. O que o usuário vai tentar fazer a cada momento?
campo "Para".
Sim, pois há um campo em branco logo a direita de
O usuário perceberá que a ação correta está disponí-
"Para", que pode representar ao usuário que ali é o local
vel?
para digitar o e-mail.
O elemento "Assunto" está abaixo da opção "Para", per-
2a. Onde está o elemento de interface correspondente mitindo que o usuário o visualize sem dificuldade, espe-
ao próximo passo? cialmente porque não há muitas informações entre os
dois elementos.
Uma caixa de texto com um cursor intermitente indican-
2b. Que ações a interface torna disponível?
do a primeira opção "Para".
Sim, pois a opção "Para" remete que, nesse campo,
O usuário associará o elemento correto à meta a ser
deve ser digitada alguma informação sobre o destinatá-
atingida?
rio – no caso, o e-mail.
Sim. Com o propósito igual a qualquer caixa de texto,
o campo ao lado de "Para" permite ao usuário digitar
algum texto. Nesse caso, foi observado que o usuário
intuitivamente digitará um e-mail por dois motivos:
3a. O elemento da interface revela seu propósito e com-
1 – Por se tratar de um e-mail, leva a pessoa a digitar um
portamento?
endereço eletrônico.

2 – Porque, no campo logo acima, "De", aparece o e-

-mail do usuário, mostrando a ele até um exemplo de
como deve ser a informação a ser digitada.
Sim. É possível identificar que o e-mail deve ser digitado
3b. O usuário consegue identificar os elementos da in- dentro da caixa de texto, especialmente porque o cursor
terface? está piscando dentro dela, o que pode levar o usuário a
pensar que ali está a primeira opção a ser preenchida.
Se a ação correta é tomada, o usuário perceberá que Sim, pois o usuário consegue perceber uma diferença
progrediu em direção à solução da tarefa? na interface.
4a. Como a interface apresenta o resultado de cada Mantendo visível o e-mail digitado na caixa de texto ao
ação? lado de "Para"
Sim, pois o resultado confirma a ação pretendida pelo
usuário, que foi digitar um e-mail. Quando o usuário vê
o que ele digitou, e essa informação se mantém durante
todos os próximos passos, o usuário tem a certeza de
4b. O resultado apresentado tem correspondência com
que realizou algo com sucesso, especialmente quando
o objetivo do usuário?
essa informação vai ao encontro de seu objetivo. Enfim,
o usuário pode visualizar o e-mail digitado até o fim da
tarefa. Um ponto positivo é que ele tem a liberdade de
alterar o e-mail no campo a qualquer momento.

AÇÃO DIGITAR O "ASSUNTO"

Sim, pois o próximo campo a ser preenchido está re-
lacionado com a ação pretendida. Essa característica
O usuário tentará atingir a meta correta? evita que o usuário fique perdido, pois, se tivesse mui-
tas opções sem sequência, ele poderia não saber o que
fazer.
Sim. A próxima caixa de texto é sobre o assunto.
1a. Dada a decomposição de uma tarefa em subtare-
fas, o usuário saberá por onde começar? Saberá qual Sim. Há outra caixa de texto maior, logo abaixo, que
é o próximo passo? pode permitir ao usuário pensar que ali pode ser digita-
do um texto longo, ou seja, uma mensagem.
Digitar o assunto na caixa de texto localizada ao lado
1b. O que o usuário vai tentar fazer a cada momento?
da opção "Assunto".
O usuário perceberá que a ação correta está disponí- Sim. Existe a caixa de texto em branco indicando que
vel? ali deve ser digitado algo.

Claretiano - Centro Universitário

128 © Interface Humano-Computador

AÇÃO DIGITAR O "ASSUNTO"

Em uma caixa de texto com tamanho grande após o
assunto. O tamanho da caixa de texto permite que o
2a. Onde está o elemento de interface correspondente
usuário a visualize sem problemas e sem dificuldades,
ao próximo passo?
mesmo tendo algumas opções entre o campo "Assun-
to" e a caixa de texto para digitar a mensagem.
2b. Que ações a interface torna disponível? A caixa de texto para escrever o assunto.
O usuário associará o elemento correto à meta a ser Sim, pois a opção "Assunto" remete que, ali, deve ser
atingida? digitado o título ou o assunto do e-mail.
Sim. É visível que o campo ao lado de "Assunto" é uma
3a. O elemento da interface revela seu propósito e
caixa de texto; por isso, o usuário intuitivamente saberá
comportamento?
que é possível digitar algo.
3b. O usuário consegue identificar os elementos da in- Sim. Para essa ação, é possível identificar a caixa de
terface? texto e a sua finalidade.
Se a ação correta é tomada, o usuário perceberá que Sim, pois o usuário percebe algo diferente na interfa-
progrediu em direção à solução da tarefa? ce.
Mantendo visível o assunto digitado pelo usuário na
4a. Como a interface apresenta o resultado de cada
caixa de texto, permitindo que ele tenha a certeza de
ação?
que executou a ação de maneira satisfatória.
Sim. O objetivo a ser alcançado era digitar o assunto,
4b. O resultado apresentado tem correspondência com
e, no final da ação, o usuário visualizará o assunto di-
o objetivo do usuário?
gitado.

AÇÃO ESCREVER A MENSAGEM

Sim. Há uma caixa de texto com tamanho grande após
O usuário tentará atingir a meta correta?
a caixa de texto referente ao "Assunto".
Sim, pois há a caixa de texto com uma aparência que
também é padrão nos editores de texto de outros e-
-mails. É válido mencionar que, diferentemente das ou-
tras caixas de texto apresentadas até o momento, esta
não possui uma opção clara, por exemplo, em que está
escrito "Mensagem", mas é possível perceber que se
trata de um local para digitar mensagens por dois mo-
tivos:
1 – o tamanho da caixa de texto remete a um lugar em
1a. Dada a decomposição de uma tarefa em subtarefas, que pode ser digitado um texto longo – no caso, a men-
o usuário saberá por onde começar? Saberá qual é o sagem;
próximo passo?
2 – há algumas opções acima dessa caixa de texto se-
melhantes às de outros editores de texto para realizar
alterações no formato do texto. E, geralmente, essas
opções ficam localizadas logo acima da caixa de texto
para digitar a mensagem.
Sim. Há uma grande possibilidade de os olhos do usu-
ário passarem pela opção "Anexar um arquivo" quando
ele estiver vendo a caixa de texto "Assunto" e indo para
a caixa de texto em que se deve digitar a mensagem.
Nessa ação, ele digitará a mensagem desejada na cai-
1b. O que o usuário vai tentar fazer a cada momento?
xa de texto.
O usuário perceberá que a ação correta está disponí- Sim. Há a caixa de texto em branco que remete ao local
vel? em que deve ser digitada a mensagem.
2a. Onde está o elemento de interface correspondente Na mesma interface, um pouco acima da caixa de texto
ao próximo passo? em que o usuário está.

Disponibiliza uma caixa de texto em um tamanho dife-

2b. Que ações a interface torna disponível? rente das demais, o que sugere que deve ser digitado
um texto maior.
 © U5 – Métodos para Avaliação da Interface 129

AÇÃO ESCREVER A MENSAGEM

Sim. É possível identificar o campo correto para digitar
a mensagem, especialmente porque a caixa de texto é
a última opção para a inserção de um texto. As outras
O usuário associará o elemento correto à meta a ser opções aparentemente já estão preenchidas, o que re-
atingida? mete ao usuário que ali seja o único campo viável para
digitar uma mensagem. Isto já não aconteceria se hou-
vesse vários campos em branco sem uma descrição ao
lado.

3a. O elemento da interface revela seu propósito e com- Sim. É possível identificar o que se pode fazer em uma
portamento? caixa de texto.

3b. O usuário consegue identificar os elementos da in- Sim. Dentre as caixas de texto existentes, é possível
terface? saber qual é a correta para digitar a mensagem.
Se a ação correta é tomada, o usuário perceberá que Sim. O usuário visualizará que o conteúdo da interface
progrediu em direção à solução da tarefa? vai se alterando conforme é digitada a mensagem.
Mostra o texto digitado enquanto o usuário está digi-
4a. Como a interface apresenta o resultado de cada
tando. Esse feedback imediato permite ao usuário ter a
ação?
certeza de que está fazendo a ação correta.
Sim, a ação pretendida era digitar uma mensagem.
4b. O resultado apresentado tem correspondência com Após essa ação, o usuário consegue visualizar toda a
o objetivo do usuário? mensagem digitada, podendo inclusive realizar altera-
ções nela.

AÇÃO ANEXAR ARQUIVO

O usuário tentará atingir a meta correta? Sim, há uma opção visível para "Anexar um arquivo".
Sim, pois, além da opção correta estar com um nome
intuitivo para a ação desejada, "Anexar um arquivo", ela
está localizada entre duas caixas de texto que o usuário
já utilizou. Assim, houve a possibilidade de o usuário ver
1a. Dada a decomposição de uma tarefa em subtarefas, essa opção. Destaque para o clipe localizado ao lado
o usuário saberá por onde começar? Saberá qual é o esquerdo do nome da ação. Esse símbolo é padrão nos
próximo passo? webmails; assim, o usuário poderá identificar o campo
tanto pelo que está escrito quanto pelo símbolo.
Sim. O usuário perceberá que a próxima ação é enviar o
e-mail que ele criou.
1b. O que o usuário vai tentar fazer a cada momento? Clicar sobre a opção "Anexar um arquivo"
Sim, porque a opção está com a aparência de um link,
O usuário perceberá que a ação correta está disponí-
de cor azul e sublinhado, o que permitirá ao usuário pen-
vel?
sar que a opção deve ser clicada.
2a. Onde está o elemento de interface correspondente A opção está localizada em dois locais distintos da inter-
ao próximo passo? face: acima e abaixo.
2b. Que ações a interface torna disponível? Um link com o nome "Anexar um arquivo".
Sim, pois a opção está em um formato (link) e em uma
O usuário associará o elemento correto à meta a ser linguagem adequada e, também, há um símbolo (clipe)
atingida? que permite ao usuário identificar o propósito do ele-
mento.
3a. O elemento da interface revela seu propósito e com- Sim, pois a opção possui todas as características e fun-
portamento? cionalidades de um link.
3b. O usuário consegue identificar os elementos da in- Sim. É possível perceber o link para realizar a ação e
terface? saber como utilizá-lo.
Se a ação correta é tomada, o usuário perceberá que Sim. Por meio da interface, é perceptível que algo esteja
progrediu em direção à solução da tarefa? acontecendo.

Claretiano - Centro Universitário

130 © Interface Humano-Computador

AÇÃO ANEXAR ARQUIVO

A interface exibe de duas formas o progresso da ação
do usuário. Essas formas se diferem quando o usuário
possui ou não o plugin flash. Observe quais são elas a
seguir:
1 – O nome do arquivo aparecerá, com barra de pro-
gressão, caso o usuário tenha instalado o plugin flash.
4a. Como a interface apresenta o resultado de cada
Por meio da barra de progressão, ele conseguirá per-
ação?
ceber o quanto de tempo ainda falta para o arquivo ser
anexado.
2 – Exibirá uma caixa de texto com o caminho do arqui-
vo. No entanto, nesse caso, não há indicação para o
usuário sobre o tempo que falta para o anexo ser con-
cluído.
4b. O resultado apresentado tem correspondência com Sim. No final da ação, o usuário consegue visualizar os
o objetivo do usuário? anexos inseridos por ele.

AÇÃO CLICAR NO BOTÃO "ENVIAR"

O usuário tentará atingir a meta correta? Sim, pois está visível a opção para realizar essa ação.
1a. Dada a decomposição de uma tarefa em subtarefas, Sim, pois há dois botões com o nome "Enviar", o que re-
o usuário saberá por onde começar? Saberá qual é o mete o usuário ao objetivo desse elemento na interface.
próximo passo? O próximo passo não há, pois este é o último passo.
1b. O que o usuário vai tentar fazer a cada momento? Clicar em um dos botões "Enviar"
Sim, o usuário perceberá que há dois botões para reali-
zar a ação pretendida. É possível afirmar que o usuário
verá, pelo menos, um dos botões, pela forma que eles
se encontram na interface.
O primeiro botão está localizado em um lugar de des-
taque; é a primeira opção a aparecer na nova página
O usuário perceberá que a ação correta está disponí-
(após o usuário clicar em "Escrever e-mail") do lado es-
vel?
querdo superior.
O segundo botão está localizado logo após a caixa de texto
utilizada para digitar a mensagem, e, como o usuário ficou
visualizando algum tempo a caixa de texto para digitar toda
a mensagem, é bem provável que ele tenha percebido que
também há um botão de enviar logo abaixo.
2a. Onde está o elemento de interface correspondente
Não há próximo passo.
ao próximo passo?
2b. Que ações a interface torna disponível? Dois botões com o nome "Enviar".
O usuário associará o elemento correto à meta a ser Sim, pois o nome do botão remete à ação do usuário
atingida? com uma linguagem adequada e compreensível.
Sim, pois possui um formato que aparenta ser um botão.
Quando clicado, o feedback é adequado para o seu for-
3a. O elemento da interface revela seu propósito e com- mato. Especialmente quando o usuário clica sobre ele, a
portamento? animação do botão faz que o usuário tenha a impressão
de que ele realmente está sendo pressionado, uma vez
que a imagem parece "afundar".
Sim É possível perceber que existe, pelo menos, um bo-
tão para realizar a ação pretendida.
Nesse caso, em especial, a opção "Enviar" também po-
deria estar como link, pois o usuário já se acostumou;
ele sabe que, ao ver algo azul e sublinhado, é possível
clicar sobre, ou seja, tem a mesma funcionalidade que
3b. O usuário consegue identificar os elementos da in- o botão. Entretanto, foi considerado o formato de botão
terface? adequado por três motivos:
1 – formato e nome remetem à funcionalidade proposta;
2 – diferenciou essa opção das demais, sem poluir a
interface;
3 – seguiu o padrão dos outros editores de e-mail; por
isso, o usuário não ficará perdido ao ver esse formato.
Se a ação correta é tomada, o usuário perceberá que Sim, pois será exibida uma mensagem de confirmação
progrediu em direção a solução da tarefa? de envio ao usuário.
 © U5 – Métodos para Avaliação da Interface 131

Caso o e-mail tenha sido enviado corretamente, apare-

4a. Como a interface apresenta o resultado de cada cerá a mensagem "sua mensagem foi enviada". Caso
ação? contrário, outra mensagem aparecerá, ou seja, de qual-
quer forma, o usuário possui um feedback do Gmail.
Sim, pois como o objetivo da tarefa é o envio de um
e-mail, a última mensagem da última ação teria de ir ao
encontro do objetivo para o usuário ter certeza de que
realizou com sucesso todas as ações necessárias para
executar a tarefa desejada.
4b. O resultado apresentado tem correspondência com
o objetivo do usuário? Embora a mensagem final seja "sua mensagem foi en-
viada" e esta não seja exatamente a tarefa, no caso "seu
e-mail foi enviado", é possível perceber a relação entre
a mensagem e o e-mail, que são sinônimos para esse
caso. Assim, ambas levariam a compreensão de sua fi-
nalidade ao usuário.

A seguir, apresentaremos a interpretação dos resultados e as sugestões de melhorias.

Tabela 12 Interpretação dos resultados e das sugestões de melhorias.

O que ocasionou o proble-
Nrº Problema encontrado Local Soluções sugeridas
ma?
01 A falta de feedback ao ane- Na página para escre- Após clicar na opção "Anexar Há duas sugestões:
xar o arquivo caso não haja ver um e-mail. um arquivo", não foi visualizada 1 – Algum elemento que
plugin flash. Não há ele- nenhuma indicação de progres- mostre a progressão, como,
mento para indicar ao usu- são de envio do arquivo. por exemplo, a barra de
ário o tempo restante para progressão. Dessa forma,
que um determinado arqui- espera-se que o usuário
vo seja anexado. fique ciente de um tempo
aproximado de demora
para que um determinado
arquivo seja enviado com-
pletamente.
2 – Caso a opção anterior
não seja possível devido à
falta de plugin, recomenda-
se, ao menos, exibir uma
mensagem ao usuário, in-
formando que há um arqui-
vo sendo anexado.
02 Há uma opção utilizada Na página para escre- Existe uma opção na interface Há duas sugestões:
para criar uma janela dis- ver o e-mail. , do lado direito superior.1 – Colocar um texto infor-
tinta para visualizar toda a mando sobre a funcionali-
Dois problemas foram encon-
interface existente na janela dade da opção mesmo que
trados nessa opção:
"Escrever um e-mail". Des- seja preciso passar o mou-
sa forma, é possível ver os 1 – Ao clicar nessa opção, é
se sobre ela.
e-mails da caixa de entrada criada, automaticamente, outra
em uma janela e digitar o página. No entanto, a partir do 2 – Melhorar o símbolo exis-
e-mail em outra. Contudo, momento em que essa janela é tente na opção. No lugar da
após criar essa página, não criada, não há possibilidade de flecha, poderia ser uma mi-
há a possibilidade de voltar voltar ao normal, ou seja, unir niatura da página.
ao normal. as duas páginas novamente.
Isto faz que o usuário perca sua
liberdade de retroceder a uma
ação.

2 - Essa informação precisa ser

melhor ilustrada, pois este sím-
bolo , bem como essa fun-
cionalidade, não são comuns
nos outros e-mails. Por isso, é
importante se preocupar se o
usuário conseguirá entender e
utilizar essa novidade de forma
satisfatória.

Claretiano - Centro Universitário

132 © Interface Humano-Computador

Está descrito na tabela anterior os dois problemas identificados durante o Percurso Cogni-
tivo da tarefa especificada, seguindo as ações definidas na Fase de Preparação.
Você pôde observar que, para cada problema, existem algumas sugestões que deverão ser
discutidas com os outros profissionais envolvidos no desenvolvimento do software, de modo a
escolher qual é a melhor forma para solucionar os problemas encontrados.
É válido mencionar que, para a ação "Anexar arquivo", não foi inspecionada a janela que
aparece ao clicar na opção "Anexar um arquivo" para encontrar e escolher o arquivo a ser anexa-
do. A inspeção não foi realizada porque essa janela faz parte do sistema operacional, e, por isso,
cada usuário pode ter um tipo de janela distinto. Espera-se, também, que, como é algo presente
no sistema operacional e padrão para realizar esse tipo de ação em vários outros softwares, o
usuário já tenha alguma familiaridade que permita a ele utilizá-la sem dificuldades.
Durante a aplicação desse método na tarefa especificada, alguns outros problemas foram
identificados. Todavia, apesar de fazerem parte da tarefa, elas não faziam parte das ações defini-
das; então, observa-se que não seria adequado unir problemas de outras ações em uma mesma
tabela, pois isto poderia confundir os outros profissionais, uma vez que eles estão preparados
para saber apenas dos problemas encontrados, seguindo as ações descritas anteriormente.
Entretanto, como objeto de estudo, percebeu-se que seria interessante descrever alguns
dos outros problemas existentes na interface, como uma forma de ilustrar o quão complexo e
detalhado é o método. A próxima tabela possui o relatório de avaliação de dois desses proble-
mas encontrados.
O primeiro problema está relacionado com a área que permite realizar a formatação da
mensagem digitada pelo usuário na caixa de texto. Apesar de a ação "formatar a mensagem"
fazer parte da tarefa "enviar e-mail", uma vez que o usuário pode querer alterar a cor da fonte,
aumentar o tamanho da letra, colocar alguma palavra em negrito, entre tantas outras opções
para destacar ou deixar a mensagem mais bonita para ser enviada, essa ação não foi definida
para ser avaliada.
O segundo problema encontra-se próximo ao botão "Enviar" que foi avaliado – é o outro
botão, com o nome "Descartar". Esse problema, além de ser outra ação, poderia fazer parte de
outra tarefa ao invés de "enviar e-mail", poderia ser "descartar e-mail", mas, mesmo tendo es-
sas diferenças, optou-se por abordar o problema.
É válido lembrar que a não definição dessas ações não foi uma falha, apenas foi reduzido o
número de ações para que o Percurso Cognitivo das ações definidas pudesse ter mais detalhes.
Esta é uma estratégia adotada por muitos profissionais e por muitas empresas que fazem essa
inspeção, pois, devido ao número de detalhes e o tempo para que essa inspeção seja realizada,
na maioria das vezes, são escolhidas as ações principais para realizar uma tarefa. Em nosso caso,
que era para enviar um e-mail, percebeu-se que as ações básicas e realmente necessárias para
concluir a tarefa são as seis descritas na Fase de Preparação.
Ressalta-se que este é um ponto negativo do método, pois ele permite escolher as ações
que se deseja avaliar isto reforça a importância da "Fase de Preparação", pois, ao escolher ações
desnecessárias ou não escolher as ações que serão importantes para o usuário realizar a tarefa,
isto pode prejudicar o resultado da inspeção. No primeiro caso, haverá desperdício de tempo
e dinheiro, uma vez que haverá um ou mais profissionais alocados para realizar a inspeção de
ações que não são importantes e, no segundo caso, não haverá uma inspeção adequada de
todas as ações que influenciam, diretamente, a realização da tarefa, o que pode prejudicar a
afirmação de que a interface está usável.
 © U5 – Métodos para Avaliação da Interface 133

Tabela 13 Relatório de avaliação de dois problemas encontrados.

Nrº Problema encontrado Local O que ocasionou o problema? Soluções sugeridas
01 Linguagem não co- Na página para escre- Logo acima da caixa de texto Alterar símbolos dos botões. Ao
mum na edição de ver o e-mail. para digitar mensagem, existem invés de "B" e "U", inserir op-
texto. algumas opções com a possi- ções em português, como "N" e
bilidade de formatar o texto. No "S", respectivamente. Informa-
entanto, há opções que podem ções essas comumente encon-
não ser conhecidas pelo usuário, tradas em softwares brasileiros.
e isto pode dificultar a compre- As opções para alterar a fonte
ensão das opções e a sua utili- e o tamanho poderiam ser al-
zação. teradas para símbolos comuns
Por exemplo, as opões " " " nos softwares brasileiros, como
" estão em outra língua, ou para
seja, não estão em português. alterar a fonte e
No caso, o "B" significa bold, em para alterar o seu tamanho.
inglês, que, em português, seria Esses símbolos, além de serem
negrito; e o "U" é de Underline, mais comuns, expressam as
em inglês, e, em português, se- suas funcionalidades.
ria sublinhado. Há outras opções
Sugere-se que os outros sím-
que, embora estejam em outra
bolos sejam comparados aos
língua, se assemelham com a
softwares utilizados no Brasil,
forma com que os brasileiros fa-
como o Microsoft Word©, pois,
lam, no caso " " para alterar
seguindo o padrão, haverá uma
a fonte e a opção e " " para
garantia maior das opções a
alterar o tamanho do texto.
serem compreendidas pelo usu-
Apesar de terem semelhanças ário.
com o português, esses símbo-
los não são intuitivos o que pos-
sibilita que suas funcionalidades
sejam percebidas de imediato.
02 O nome do botão "Des- Na página para escre- O botão "Descartar", que está Substituir a opção "Descartar"
cartar" não é tão co- ver o e-mail. tanto no lado superior direito por "Excluir", pois, além desse
mum em e-mails. quanto inferior direito, possui nome ser mais utilizado em e-
uma linguagem diferente dos -mails, ele também é utilizado
outros e-mails. O que pode "ra- em um sistema operacional
ramente" causar uma falta de utilizado pela maioria dos bra-
compreensão. sileiros.
O "raramente" é porque, apesar
de o botão estar escrito com
nome distinto, é possível identi-
ficar a sua utilização. No entanto,
espera-se que, com nome mais
comum e utilizado com mais
frequência pelo usuário, existe
a possibilidade de ser compre-
endido melhor e de maneira ime-
diata pelo usuário.

12. QUESTÕES AUTOAVALIATIVAS

Sugerimos que você procure responder, discutir e comentar as questões a seguir, que tra-
tam da temática desenvolvida nesta unidade.
A autoavaliação pode ser uma ferramenta importante para você testar o seu desempenho.
Se você encontrar dificuldades em responder a essas questões, procure revisar os conteúdos
estudados para sanar as suas dúvidas. Esse é o momento ideal para que você faça uma revisão
desta unidade. Lembre-se de que, na Educação a Distância, a construção do conhecimento ocor-
re de forma cooperativa e colaborativa; compartilhe, portanto, as suas descobertas com os seus
colegas.
Confira, a seguir, as questões propostas para verificar o seu desempenho no estudo desta
unidade:

Claretiano - Centro Universitário

 134 © Interface Humano-Computador

1) Imagine a seguinte situação: uma empresa contratou você para inspecionar uma interface e ela deseja saber se
o público-alvo definido para o software desenvolvido vai conseguir entender e utilizar as opções na interface.
No entanto, a empresa relata que não haverá usuários para a inspeção devido aos custos que isto agregaria.
Qual dos métodos a seguir você escolheria para realizar a inspeção?
a) Checklists.
b) Avaliação Heurística.
c) Percurso Pluralístico.
d) Percurso Cognitivo.
e) Teste de Usabilidade.
2) O Percurso Cognitivo é divido em três fases: Preparação, Avaliação e Interpretação. Em cada fase, existem algu-
mas questões que devem ser respondidas ou, no caso da interpretação, algumas opções que devem ser preen-
chidas em uma tabela. Esta é uma forma de organizar melhor os dados para depois serem compreendidos mais
facilmente por outros profissionais. Na fase de Preparação, existem algumas perguntas que são importantes
para se pensar em como será a inspeção; no total, são quatro perguntas básicas. Das perguntas a seguir, qual
delas não faz parte dessas quatro questões?
a) Qual é a sequência correta de ações para cada tarefa?
b) Quais são as tarefas que serão analisadas?
c) Qual é a linguagem de programação utilizada no desenvolvimento?
d) Qual é a interface definida?
e) Quem são os usuários do software?

Gabarito
Depois de responder às questões autoavaliativas, é importante que você confira o seu
desempenho, a fim de que possa saber se é preciso retomar o estudo desta unidade. Assim, con-
fira, a seguir, as respostas corretas para as questões autoavaliativas propostas anteriormente:
As respostas corretas para cada questão são:
1) d.

2) c.

13. CONSIDERAÇÕES
Avaliar o sistema utilizando e as estratégias descritas nesta unidade é uma forma de ga-
rantir que aquilo que foi feito realmente considerou as características dos usuários, e que todas
as opções e informações, enfim, tudo o que há no sistema, de alguma maneira está acessível,
usável e é útil. No entanto, considere todos os conceitos aprendidos nessa unidade, não somen-
te no momento de avaliação, mas também no momento do planejamento e desenvolvimento
do seu sistema.
Pense que, ao considerar todos esses conceitos, você estará se prevenindo e evitando
muito retrabalho no final. Retrabalho esse que, em muitos casos, seria desnecessário se, duran-
te o planejamento, na conversa com o usuário e em outras etapas anteriores, todo esse cuidado
fosse tomado.

14. E-REFERÊNCIAS
ANACLETO, J. C. Tópicos em Engenharia de Software. O Projeto de Interação – Questões de Usabilidade – Um Estudo de Caso.
Disponível em: <[Link] Acesso em: 8 jul. 2010.
CYBIS, W. A. ErgoList. Disponível em: <[Link] Acesso em: 10 fev. 2010.
GODINHO, F. Noções de acessibilidade a web. Disponível em: <[Link] Acesso em: 1 fev. 2010.
NIELSEN, J. Heuristic Evaluation. Disponível em: <[Link] Acesso em: 21 mar. 2010.
 © U5 – Métodos para Avaliação da Interface 135

15. REFERÊNCIAS BIBLIOGRÁFICAS

CARLOS, A. J. F. Aplicando senso comum na edição de objetos de aprendizagem. Dissertação de Mestrado. Programa de Pós-
graduação em Ciência da Computação: UFSCar, 2007.
CYBIS, W. A. et al. Abordagem para o desenvolvimento de listas de verificação de usabilidade sistemáticas e produtivas. Tradução
de Latin American Congress on Human-Computer Interaction. Rio de Janeiro, 2003.
JOHN, B. E.; KIERAS, D. E. The GOMS family of user interface analysis techniques: comparison and contrast. ACM Transactions on
Computer-Human Interaction, v. 8, n. 3, p. 320-351, 1996.
LEWIS, C.; RIEMAN, J.; WHARTON, C. Cognitive walkthroughs: a method for theory-based.
LEWIS, C.; WHARTON, C. Cognitive walkthroughs. In: HELANDER, M.; LANDAUER, T. K.; PRABHU, P. (Eds.) Handbook of human-
computer interaction. Elsevier Science, 1997, p. 717-7
MANO, A.; CAMPOS, J. C. Aplicação de um cognitive walkthrough: estudo de caso. Interacção 2004 – Conferência Nacional em
Interacção Pessoa-Máquina, Lisboa, 2004.
NIELSEN, J. Heuristic Evaluation. In: NIELSEN, J; MACK, R. Usability Inspection Methods. John Wiley & Sons, 19p. 25-62.
______. Projetando websites. Rio de Janeiro: Campus, 2000.
NIELSEN, J.; TAHIR, M. Homepage usabilidade: 50 websites descontruídos. Rio de Janeiro: Campus, 2002.
NORMAN, D. A. Cognitive Engineering. In: NORMAN, D. A.; DRAPER, S. W. (Eds.) User Centered System Design. Hillsdale, 19p.
31-61.
PRATES, R. O.; BARBOSA, S. D. J. Avaliação de interfaces de usuário: – conceitos e métodos. Campinas – Brasil. In: XXII Jornada
de atualização em informática em anais do XXIII congresso da sociedade brasileiro de computação, 2003.
SALGADO, L. C. C.; BIM, S. A.; SOUZA, C. S. Comparação entre os métodos de avaliação de base cognitiva e semiótica. Natal –
Brasil In: Simpósio Sobre Fatores Humanos em Sistemas Computacionais (IHC), 2006.
SHNEIDERMAN, B. Designing the user interface: strategies for effective human-computer interaction. Estados Unidos: Addison-
Wesley, 1998.
SILVA, M. A. R. O uso de senso comum no apoio a jogos narrativos para crianças em idade escolar. Dissertação de Mestrado.
Programa de Pós-graduação em Ciência da Computação, Universidade Federal de São Carlos, 2009.
SOUZA, C. S.; LEITÃO, C. F. Contribuições da engenharia semiótica para os métodos científicos de pesquisa em IHC. Porto Alegre
– Brasil In: Simpósio Sobre Fatores Humanos em Sistemas Computacionais (IHC), 2008.
WHARTON, C. et al. Applying Cognitive Walkthroughs to More Complex User Interfaces: experiences, issues, and recommendations.
In: ACM CHI Conference Proceedings. Monterey – USA, 1992.
WHARTON, C.; RIEMAN, J.; LEWIS, C. The cognitive walkthrough method: a practitioner´s guide. In: NIELSEN, J; MACK, R. Usability
Inspection Methods. John Wiley & Sons, 19p. 105-140.

Claretiano - Centro Universitário

Claretiano - Centro Universitário