Renato Manuel Faque

Aspecto de criação de interfaces de avaliação

Licenciatura em Informática Aplicada

Universidade Pedagógica

Tete

2019
Índice:
1. Introdução

Em linhas gerais, a área de Interação Humano-Computador (IHC) investiga o “projeto

(design), avaliação e implementação de sistemas computacionais interativos para uso humano,
juntamente com os fenômenos associados a este uso” (Hewett et al., online). Os estudos
relacionados ao projeto de IHC se referem a como construir interfaces com alta qualidade.
Para isto, são definidos métodos, modelos e diretrizes. Os estudos relacionados à avaliação de
IHC, por sua vez, buscam avaliar a qualidade de um projeto de interface, tanto ao longo do
processo de desenvolvimento como quando o software está pronto.
2. Objectivos
2.1. Objectivos gerais
- Avaliar a funcionalidade do sistema.
 Estar adequado aos requisitos da tarefa do usuário;
 Efectuar a tarefa pretendida e de modo mais fácil e eficiente.
- Avaliar o efeito da interface junto ao usuário.
 Avaliar quão fácil é aprender a usar o sistema, a atitude do usuário com relação ao
sistema, identificar áreas do design sa quais sobrecarregam o usuário de alguma
forma, por exemplo, exigindo que uma série de informações seja relembradas.
- Identificar problemas específiccos do sistema.
 Identificar aspectos do design os quais quando usamos no contexto alvo, causam
resultados inesperados ou confusão entre usuário.

2.1.1. Objectivos específicos

- Identificar os modos de interação e os modelos de interface;
- Conhecer os modelos para desenvolvimento de interfaces;
- Avaliar o grau de usabilidade de interfaces;
- Construir interfaces Web acessiveis.

3. Interface x Interação
Interação é o processo de comunicação entre pessoas e sistemas interativos (Preece etal.,
1994). Neste processo, usuário e sistema trocam turnos em que um “fala” e o outro
“ouve”,interpreta e realiza uma ação. Esta ação pode ser tão simples quanto dar uma resposta
imediata à fala do outro, ou consistir de operações complexas que alteram o estado do mundo.
A área de IHC estuda este processo, principalmente do ponto de vista do usuário: as ações que
ele realiza usando a interface de um sistema, e suas interpretações das respostas transmitidas
pelo sistema através da interface.

Figura 1: O processo de interação humano-computador

Interface é o nome dado a toda a porção de um sistema com a qual um usuário mantém
contato ao utilizá-lo, tanto ativa quanto passivamente. A interface engloba tanto software
quanto hardware (dispositivos de entrada e saída, tais como: teclados, mouse, tablets,
monitores, impressoras e etc.). Considerando a interação como um processo de comunicação,
a interface pode ser vista como o sistema de comunicação utilizado neste processo. Uma
definição de interface utilizada com freqüência foi proposta por Moran:

“a interface de usuário deve ser entendida como sendo a parte de um

sistema computacional com a qual uma pessoa entra em contato —
física, perceptiva ou conceitualmente” (Moran, 1981).

A dimensão física inclui os elementos de interface que o usuário pode manipular, enquanto a
dimensão perceptiva engloba aqueles que o usuário pode perceber. A dimensão conceitual
resulta de processos de interpretação e raciocínio do usuário desencadeados pela sua interação
com o sistema, com base em suas características físicas e cognitivas, seus objetivos e seu
ambiente de trabalho. Atualmente, as interfaces mais comuns envolvem elementos visuais e
sonoros, com entrada de dados via teclado e mouse. Outros tipos de interfaces, como interface
via voz e entrada de dados através de canetas estão se tornando freqüentes, devido à
disseminação de dispositivos móveis.
3.1. Objetivos e Importância da Avaliação de Interação
Antes de declarar um software pronto para uso, é importante saber se ele apóia
adequadamente os usuários, nas suas tarefas e no ambiente em que será utilizado. Assim
como testes de funcionalidade são necessários para se verificar a robustez da implementação,
a avaliação de interface é necessária para se analisar a qualidade de uso de um software.
Quanto mais cedo forem encontrados os problemas de interação ou de interface, menor o
custo de se consertá-los.

Alguns dos principais objetivos de se realizar avaliação de sistemas interativos

são:
 Identificar as necessidades de usuários ou verificar o entendimento dos
projetistas sobre estas necessidades
 Identificar problemas de interação ou de interface
 Investigar como uma interface afeta a forma de trabalhar dos usuários
 Comparar alternativas de projeto de interface
 Alcançar objetivos quantificáveis em métricas de usabilidade
 Verificar conformidade com um padrão ou conjunto de heurísticas

3.1.1. Conceitos de qualidades de uso

O conceito geral de qualidade de uso está estreitamente relacionado com a capacidade e a
facilidade de os usuários atingirem suas metas com eficiência e satisfação. Quando os
usuários têm vias alternativas para realizarem suas tarefas, com ou sem apoio computacional,
o fato de escolherem espontaneamente utilizar um determinado sistema, e com certa
freqüência, dependerá em grande parte da qualidade de uso daquele sistema.

O conceito de qualidade de uso mais amplamente utilizado é o de usabilidade, relacionado à

facilidade e eficiência de aprendizado e de uso, bem como satisfação do usuário. Mais
recentemente, foi elaborado o conceito de comunicabilidade, que busca avaliar o processo
implícito de comunicação designer–usuário, que se dá através da interface (Prates et al.
2000b,). Já o conceito de aplicabilidade está relacionado à flexibilidade de um sistema, em
particular com relação à sua utilidade em uma variedade de situações.

Usabilidade
O conceito de usabilidade permite avaliar a qualidade de um sistema com relação a fatores
que os projetistas definem como sendo prioritários ao sistema. Alguns fatores típicos
envolvidos no conceito de usabilidade são (Preece et al., 2002):
 Facilidade de aprendizado;
 Facilidade de uso;
 Eficiência de uso e produtividade;
 Satisfação do usuário;
 Flexibilidade;
 Utilidade;
 Segurança no uso.
Facilidade de aprendizado se refere ao tempo e esforço necessários para que os usuários
aprendam a utilizar uma determinada porção do sistema com determinado nível de
competência e desempenho. Geralmente, um sistema pode ser analisado sob uma perspectiva
de uso simples, considerando um nível intermediário ou avançado, por exemplo, cada qual
requerendo tipos e graus de aprendizado distintos. Neste caso, o fator de facilidade de
aprendizado pode ser analisado em diversos pontos, considerando cada passagem de um nível
de capacitação ao próximo.

Comunicabilidade
O conceito de comunicabilidade (de Souza et al. 1999, Prates et al., 2000b) se refere à
capacidade de os usuários entenderem o design tal como concebido pelos projetistas. A
hipótese subjacente ao conceito de comunicabilidade é que, se um usuário entende as decisões
que o projetista tomou ao construir a interface, aumentam suas chances de fazer um bom uso
daquele sistema. Em sistemas com alta comunicabilidade, os usuários são capazes de
responder:
 Para que o sistema serve;
 Qual é a vantagem de utilizá-lo;
 Como funciona;
 Quais são os princípios gerais de interação com o sistema.

Uma interface com boa comunicabilidade permite que o usuário formule um modelo mental
compatível com o do projetista. O uso de analogias com artefatos familiares ao usuário pode
contribuir para isto, pois o usuário já possui um modelo mental sobre o comportamento desses
artefatos. No entanto, é importante deixar claro qual é o escopo da analogia, ou seja, quais são
as porções do modelo mental sobre o artefato conhecido que podem ser transportadas para a
construção do modelo mental sobre a interface em questão. Um exemplo de interface com boa
comunicabilidade é a tela inicial do programa CD Player, do Windows 95 (Figura 2). Ela tira
proveito da familiaridade do usuário com os aparelhos comuns de CD, fornecendo elementos
de interface análogos, tais como os botões de comando para acionamento das funções e o
visor de trilhas e duração como elemento de feedback.

Figura 2: Exemplo de boa comunicabilidade: interface de um software para tocar CD’s.

Um exemplo de baixa comunicabilidade pode ser encontrado na ferramenta de busca de

arquivos no Windows 2000 (Figura 3). O usuário aciona a ferramenta de busca, mas a janela
aparece reduzida e deslocada, de modo que as opções de busca não estão visíveis. O usuário
move a janela para o centro da tela, mas ainda assim as opções não aparecem. Fazendo uso do
conhecimento adquirido de que o menu dá acesso a todas as funções de um sistema, ele
resolve procurar estas opções sob o menu Edit. Este menu não apresenta as opções de busca,
como esperado, mas surpreendentemente, possui um item chamado Undo Move. Tentando
entender o que significa este comando, o usuário imagina que sirva para restaurar a posição da
janela ao local anterior ao deslocamento, e resolve experimentar, mas “nada acontece”. (Na
verdade, o comando Undo Move desfez a última transferência de arquivo que o usuário fez
antes de acionar a ferramenta de busca. Existe uma mensagem na barra de status indicando o
que consiste o comando Undo Move, mas esta mensagem não atenua o fato de que
transferência de arquivos não é uma tarefa que deva estar contida em uma ferramenta de

busca de arquivos.)
Figura 3: Exemplo de baixa comunicabilidade. Observe o item de menu Undo Move dentro da
ferramenta de busca.
Aplicabilidade
A aplicabilidade de um sistema também determina sua qualidade de uso. Este conceito está
relacionado com a utilidade deste sistema em uma variedade de situações e problemas
(Fischer, 1998). Este conceito permite determinar:
 O quanto o sistema é útil para o contexto em que foi projetado;
 Em que outros contextos o sistema pode ser útil.

Fischer acredita que as pessoas, por serem hábeis e especialistas no seu domínio, querem agir
como designers, no sentido de participar ativamente dos processos de solução de problemas e
de construção ou transformação dos seus próprios artefatos e espaços de trabalho. Ele coloca
como desafios essenciais de IHC a melhoria das formas como as pessoas podem usar
computadores para trabalharem, pensarem, se comunicarem, aprenderem, criticarem,
explicarem, argumentarem, discutirem, observarem, decidirem, calcularem, simularem e
projetarem.
Interfaces muito rígidas, nas quais os usuários têm apenas um caminho a seguir, com pouca
possibilidade de cometer erros, são freqüentemente chamadas de “a prova de idiotas” (do
inglês, idiot-proof). Na realidade, este tipo de interface trata todos os usuários como pessoas
incapazes de tomar decisões apropriadas. Os usuários destes sistemas têm reações negativas
de diversos tipos, conforme suas características e o contexto em que estão inseridos: eles
fazem um mau uso do sistema, deixam de usá-lo, ou até mesmo se limitam a crer que o
sistema tem sempre razão e que eles, usuários, não deveriam mesmo tomar decisões
importantes.

Por que incluir, em um processo de desenvolvimento de sistemas interativos, procedimentos

de avaliação de sistemas com relação à sua qualidade de uso? Do ponto de vista do usuário, a
qualidade da interface e da interação determina a qualidade do sistema, e não seus algoritmos,
arquitetura ou modelos de dados. Para ele, o sistema é a interface. O grau de qualidade de uso
de um sistema pode causar aumento (ou queda) de produtividade dos usuários, e reduzir (ou
aumentar) os custos com suporte técnico para atendimento aos usuários. Além disto, as
iniciativas voltadas para a qualidade de uso de sistemas computacionais estão geralmente
associadas a melhorias em processos de negócio, que ajudam a promover ainda mais um
aumento de qualidade do produto final.
Interfaces com baixa qualidade de uso trazem diversos problemas, dentre os quais:
 Requerem treinamento excessivo;
 Desmotivam a exploração;
 Confundem os usuários;
 Induzem os usuários ao erro;
 Geram insatisfação;
 Diminuem a produtividade;
 Não trazem o retorno de investimento previsto.

3.2. Características dos métodos de avaliação

Os métodos de avaliação de interface diferem entre si em vários aspectos. É preciso entender
as diferentes características de cada método, para se definir qual deles é o mais apropriado
para se avaliar a interface de um software em um determinado contexto. As principais
diferenças entre os métodos são a etapa do ciclo de design do software em que devem ou
podem ser aplicados (durante o ciclo de desenvolvimento ou após ter o produto pronto), a
técnica utilizada para coletar os dados (desde entrevistas até experimentos em laboratórios),
os tipos de dados coletados (quantitativos ou qualitativos), e ainda o tipo de análise feito (o
avaliador pode prever potenciais problemas ou interpretar os dados obtidos) (Preece et al.,
1994). Nesta seção apresentaremos cada uma destas dimensões.

3.2.1. Etapa do ciclo de design

A avaliação de uma interface pode ser feita durante diferentes etapas do ciclo de
desenvolvimento do software. As avaliações formativas (Preece et al., 1994; Hartson, 1998)
são aquelas que são feitas durante o processo de design, antes de o sistema estar terminado, e
muitas vezes antes de uma linha de código sequer ser escrita. A avaliação pode ser feita
utilizando-se desde cenários, storyboards, ou a modelagem conceitual da interação até
protótipos do sistema. A vantagem de se fazer avaliação formativa é que problemas de
interação são identificados e consertados antes de a aplicação ser terminada e liberada para
uso. Quanto mais cedo no ciclo de design um problema é descoberto e reparado, menor o
custo das alterações necessárias no software (Karat, 1993). Além disto, o software resultante a
ser oferecido para o usuário é de melhor qualidade.
As avaliações de interface feitas em produtos já terminados são chamadas de avaliações
somativas. Normalmente, enquanto as avaliações formativas têm por objetivo melhorar a
qualidade do sistema, tornando-o mais usável para o usuário, as avaliações somativas buscam
verificar a existência de determinados aspectos no sistema desenvolvido, como por exemplo a
sua conformidade com um padrão estabelecido.

3.2.2. Técnicas de Coleta de Dados

Existem várias técnicas disponíveis para se coletar dados sobre a interface de um software e
se fazer a análise da sua qualidade de uso. A decisão sobre que técnica utilizar depende
principalmente da disponibilidade dos recursos que se tem e objetivos da avaliação a ser feita.
A seguir apresentamos as principais características de cada uma das técnicas.

Coleta da opinião de usuários

A coleta da opinião de usuários tem por objetivo se obter uma apreciação dos usuários em
relação ao sistema interativo. Normalmente, se deseja identificar o nível de satisfação dos
usuários com o sistema, o que inclui aspectos como: se eles gostam do sistema, se a aparência
estética do sistema é satisfatória, se o sistema faz aquilo que eles desejam, se tiveram algum
problema ao usá-lo, e/ou se eles gostariam de (ou pretendem) usá-lo novamente. As principais
técnicas utilizadas para se coletar a opinião de usuários são questionários e entrevistas. Os
tipos de questionários e entrevistas a serem utilizados variam em diversos aspectos (Nicolaci-
da Costa, 2001; Preece et al., 2002). Eles podem ser feitos pessoalmente ou por telefone,
email ou web, com um pequeno grupo de pessoas ou com centenas de pessoas, com cada
usuário individualmente ou com grupos de usuários, e utilizando perguntas bem estruturadas
ou livres.

Observação de usuários
Nem sempre usuários percebem ou conseguem expressar a sua experiência de uso com o
sistema. A observação do uso do sistema pelo usuário permite ao avaliador ter uma visão dos
problemas sendo vivenciados pelos usuários e muitas vezes dos aspectos positivos
experimentados durante o uso. A observação pode ser registrada usando-se anotações do
observador, gravação de vídeo, áudio ou da interação, ou uma combinação destas.
O usuário pode ser observado no seu contexto de uso, ou seja utilizando o software no seu
trabalho, ou até mesmo em sua casa. Nestas situações se consegue observar o usuário
utilizando o software para realizar as tarefas que ele considerar relevantes e para as quais
acredita que o software seja apropriado, e ainda da maneira que considera adequada ou
desejável. Em tais situações, alguns dos desafios para os avaliadores são conseguir observar
sem interferir no contexto ou inibir o usuário, e como fazer a análise dos dados coletados,
principalmente quando se obtém várias horas de vídeo gravadas, ou quando diferentes tipos
de registro feitos durante o uso devem ser integrados.

O avaliador pode desejar observar o uso feito pelo usuário em ambientes mais controlados,
como laboratórios. Nestes ambientes o avaliador tem um controle maior sobre as variáveis
que influenciam a avaliação, como o tempo de duração, a concentração do usuário e as tarefas
a serem executadas. Assim, é possível coletar dados mais precisos sobre a utilização de
diferentes usuários de forma a compará-los. Nestes casos, o avaliador normalmente determina
as tarefas a serem executadas pelo usuário e pode coletar dados qualitativos ou quantitativos
sobre o uso, como por exemplo, o tipo e freqüência das dificuldades enfrentadas pelos
usuários, caminhos preferenciais, o tempo gasto para executar a tarefa, ou o número de erros
cometidos.

Registro de uso
Observar o usuário requer que o usuário e o observador estejam presentes em uma mesma
hora e local por um determinado período de tempo. No entanto, isto nem sempre é possível,
ou se gostaria de ter informações sobre o uso em um período de tempo mais longo. Uma outra
forma de coletar informações sobre como os usuários usam o sistema é através de registros
feitos durante o uso. Isto pode ser feito através de logs, que armazenam em um arquivo as
ações executadas em um sistema, através da gravação da interação do usuário com o sistema,
ou da gravação em vídeo da experiência do usuário. As diferentes formas de registro
armazenam aspectos distintos do uso feito. Normalmente, registros de uso geram uma grande
quantidade de informação e a análise destes dados pode ser bastante custosa para avaliadores.

Coleta da opinião de especialistas

Em algumas situações os usuários não estão disponíveis para participar da avaliação, ou o seu
envolvimento implica um custo elevado. Nestas situações, a avaliação pode ser feita sem a
participação dos usuários. Neste caso, pode se considerar a coleta da opinião de especialistas
em IHC e/ou no domínio da aplicação. Os especialistas examinam a interface e identificam
possíveis dificuldades que os usuários podem vir a ter ao utilizar o software. A seção 6.3
apresenta métodos de avaliação baseados na inspeção da interface por especialistas.

3.2.3. Tipo de Dados Coletados

Os dados coletados a partir de uma avaliação de interface podem ser quantitativos ou
qualitativos. Dados quantitativos são aqueles que podem ser representados numericamente.
Normalmente dados quantitativos são utilizados para se avaliar a eficiência e produtividade de
um sistema, para se comparar alternativas de design ou ainda se determinar se o sistema
atingiu algum objetivo de qualidade de uso prédefinido. A análise destes dados
freqüentemente é feita utilizando-se cálculos estatísticos simples, como desvio padrão ou
médias. Alguns exemplos de dados quantitativos são o número de erros ocorridos ou o tempo
gasto para completar uma tarefa.

Dados qualitativos são resultados não numéricos, tais como uma lista de problemas que os
usuários tiveram ao utilizar a aplicação, ou suas sugestões sobre como melhorar o projeto de
interação. Normalmente estes dados permitem identificar quais são as características de
interação ou interface relacionadas com os problemas medidos e observados. Em alguns
casos, dados qualitativos podem ser categorizados e então quantificados.

3.2.4 Tipo de Análise

Os avaliadores podem analisar os dados coletados de forma preditiva, intepretativa ou
experimental. A análise preditiva é realizada quando os avaliadores, ao analisarem os dados
coletados de especialistas, tentam prever que tipo de problemas os usuários enfrentarão. Esta
análise pode ser feita através de uma inspeção da interface ou em função de técnicas de
modelagem.
A análise interpretativa é realizada quando, ao analisarem os dados coletados a partir da
interação do usuário com o sistema, os avaliadores procuram explicar os fenômenos que
ocorreram durante esta interação. Normalmente se considera a análise como sendo
interpretativa quando ela é feita sobre dados coletados em ambientes naturais sem
interferência dos observadores nas atividades dos usuários.
3.2.5. Guia para o planejamento de uma avaliação

IHC, propõe-se utilizar o esquema DECIDE (Preece et al., 2002), para ajudar avaliadores
inexperientes no planejamento e realização de uma avaliação. Os pontos relevantes a serem
considerados são os seguintes:
 Determinar os objetivos gerais que a avaliação deverá tratar. Trata-se de
responder as perguntas gerais: Quais são os objetivos gerais da avaliação? Quem quer
realizá-la e por quê?
 Explorar perguntas específicas a serem respondidas. Trata-se de decompor as
perguntas gerais em perguntas específicas ao sistema a ser avaliado, considerando-se
os usuários-alvo e suas atividades. Estas perguntas são necessárias para permitir
efetivamente que os objetivos da avaliação sejam atingidos.
 Escolher (Choose) o paradigma e as técnicas de avaliação que responderão as
perguntas. Dentre os pontos a serem considerados, destacam-se o prazo, o custo, os
equipamentos e o grau de conhecimento e experiência dos avaliadores exigidos por
cada técnica.
 Identificar questões práticas que devem ser tratadas. Consideram-se aqui fatores
como: perfil e número de usuários que participarão da avaliação; ambiente em que a
avaliação será realizada; seleção das tarefas; planejamento e preparação do material
de avaliação; alocação de pessoal, recursos e equipamentos para a realização da
avaliação.
 Decidir como lidar com questões éticas. Quando uma avaliação envolve pessoas
como participantes de testes, os avaliadores devem se certificar que os direitos destas
pessoas estão sendo respeitados. Na seção 6.4 apontamos formas de lidar com as
questões éticas envolvidas neste tipo de avaliação.
 Avaliar (Evaluate), interpretar e apresentar os dados. Como apontado nesta seção,
os dados coletados durante uma avaliação podem variar bastante. Sendo assim, é
importante considerar aspectos como a confiabilidade dos dados (se a técnica produz
os mesmos resultados nas mesmas circunstâncias), sua validade (se mede o que
deveria medir); potenciais distorções; escopo (o quanto as descobertas podem ser
generalizadas); e validade ecológica (o quanto o ambiente em que a avaliação é feita
influencia ou distorce os resultados).

3.3. Métodos de Avaliação Analíticos

Métodos de avaliação analíticos são aqueles nos quais avaliadores inspecionam ou examinam
aspectos de uma interface de usuário relacionados a usabilidade. Normalmente, os avaliadores
são especialistas em usabilidade, mas também podem ser consultores de desenvolvimento de
software especializados em um determinado estilo de interface, ou ainda usuários finais
conhecedores do domínio e da tarefa, entre outros.

A avaliação analítica ou por inspeção é utilizada geralmente para buscar problemas de

usabilidade em um projeto de interface existente, e analisar estes problemas com vistas a fazer
recomendações para consertá-los e assim melhorar a usabilidade do projeto. Mack e Nielsen
(1994) identificam como principais objetivos deste tipo de avaliação:
 Identificação de problemas de usabilidade: identificar, classificar e contar o
número de problemas de usabilidade encontrados durante a inspeção;
 Seleção dos problemas que devem ser corrigidos: após identificar os problemas, a
equipe de projeto deve reprojetar a interface para corrigir o maior número possível de
problemas. Os problemas a serem corrigidos são priorizados de acordo com a
gravidade do problema e o custo associado à correção.

3.3.1. Avaliação Heurística

O método de avaliação heurística é um método analítico que visa identificar problemas de

usabilidade conforme um conjunto de heurísticas ou diretrizes (guidelines) (Nielsen, 1994).
Ele se baseia em melhores práticas definidas por profissionais experientes e especialistas em
IHC, ao longo de diversos anos de trabalho nesta área. Este método não envolve usuários, e
deve ser realizado por avaliadores especialistas. Em geral, recomenda-se que 3 a 5
especialistas realizem uma avaliação heurística. Este método é bastante rápido, e de menor
custo que a maior parte dos métodos de avaliação amplamente difundidos.

Como em todo método de avaliação, a avaliação heurística envolve uma fase de

preparação, na qual se definem:
 Proposta de design (papel ou protótipo)
 Hipóteses sobre os usuários (opcional)
 Cenário de tarefas (opcional)
A avaliação deve ser realizada de acordo com o seguinte procedimento:
1. sessões curtas (1 a 2 horas) de avaliação individual, onde cada especialista...
  Julga a conformidade da interface com um determinado conjunto de princípios
(“heurísticas”) de usabilidade
 Anota os problemas encontrados e sua localização
 Julga a gravidade destes problemas
 Gera um relatório individual com o resultado de sua avaliação e comentários
adicionais

É importante que estas sessões sejam individuais, para que um avaliador não seja influenciado
pela opinião de outros. Durante cada sessão de avaliação, o avaliador percorre a interface
diversas vezes, inspecionando os diversos elementos de interface e comparando-os com a lista
de heurísticas de usabilidade.

2. consolidação da avaliação dos especialistas

 Novo julgamento sobre o conjunto global dos problemas encontrados
 Relatório unificado de problemas de usabilidade
Nesta etapa, cada avaliador tem acesso aos relatórios individuais de todos os avaliadores, e
pode expressar seu julgamento sobre os problemas apontados pelos outros avaliadores. Ao
final desta etapa, deve-se gerar um relatório unificado e consolidado sobre todos os problemas
encontrados.

3. seleção dos problemas que devem ser corrigidos

Esta etapa deve ser realizada junto ao cliente ou ao gerente de projeto. Trata-se de uma análise
de custo/benefício das correções aos problemas encontrados na etapa anterior. Esta análise
deve levar em conta não apenas a gravidade dos problemas, mas também os prazos e o
orçamento do projeto, bem como a capacitação da equipe de desenvolvimento.

Nielsen propôs um conjunto básico1 de heurísticas. Cada elemento de interface (ou conjunto
de elementos) deve ser analisado para verificar sua conformidade com cada uma das seguintes
heurísticas:
 Visibilidade do estado do sistema: mantenha os usuários informados sobre o que
está acontecendo, através de feedback adequado e no tempo certo.
 Correspondência entre o sistema e o mundo real: utilize conceitos, vocabulário e
processos familiares aos usuários.
  Controle e liberdade do usuário: forneça alternativas e “saídas de emergência”;
possibilidades de undo e redo
 Consistência e padronização: palavras, situações e ações semelhantes devem
significar conceitos ou operações semelhantes; caso haja convenções para o ambiente
ou plataforma escolhidos, estas devem ser obedecidas
 Prevenção de erro: tente evitar que o erro aconteça, informando o usuário sobre as
conseqüências de suas ações ou, se possível, impedindo ações que levariam a uma
situação de erro
 Ajuda aos usuários para reconhecerem, diagnosticarem e se recuperarem de
erros: mensagens de erro em linguagem simples, sem códigos, indicando
precisamente o problema e sugerindo de forma construtiva um caminho remediador
 Reconhecimento em vez de memorização: torne objetos, ações e opções visíveis e
compreensíveis
 Flexibilidade e eficiência de uso: ofereça aceleradores e caminhos alternativos para
uma mesma tarefa; permita que os usuários customizem ações freqüentes
 Design estético e minimalista: evite porções de informação irrelevantes. Cada
unidade extra de informação em um diálogo compete com as unidades de informação
relevantes e reduz sua visibilidade relativa.
 Ajuda e documentação devem ser fáceis de buscar, focadas no domínio e na tarefa
do usuário, e devem listar passos concretos a serem efetuados para atingir seus
objetivos

Para cada problema encontrado, ou seja, para cada heurística violada, deve-se definir ainda a
localização do problema, ou seja, onde ele ocorre na interface, e sua gravidade.

Com relação à localização, o problema pode estar:

 Em um único local na interface;
 Em dois ou mais locais na interface, casualmente;
 Na estrutura geral da interface, de forma sistemática; ou
 Pode ser algo que “não está lá”, ou seja, precisa ser incluído na interface.

Já a gravidade (severidade) do problema é calculada, por cada especialista, como uma

combinação dos fatores:
 Freqüência com que o problema ocorre: É um problema comum ou raro?
  Impacto do problema: Será fácil ou difícil para os usuários superarem o problema?
 Persistência do problema: É um problema que ocorre apenas uma vez e que os
usuários conseguem superar facilmente, ou os usuários serão incomodados pelo
problema repetidas vezes?
A gravidade do problema é definida por um valor da seguinte escala:
 0 – Não concordo que isto seja um problema (este valor pode resultar da avaliação de
um especialista sobre um problema apontado por outro especialista)
 1 – Problema cosmético: não precisa ser consertado a menos que haja tempo extra no
projeto
 2 – Problema pequeno: o conserto deste problema é desejável, mas deve receber baixa
prioridade
 3 – Problema grande: importante de ser consertado; deve receber alta prioridade
 4 – Catastrófico: é imperativo consertar este problema antes do lançamento do
produto
Como produto da avaliação heurística, os especialistas redigem um relatório
consolidado. Este relatório pode conter, por exemplo, os seguintes itens:
 Problemas esperados (e possíveis consertos)
 O quão bem o sistema apóia as tarefas dos usuários
 Caminhos de interação primários (importantes e/ou freqüentes)
 Caminhos de interação alternativos ou pouco utilizados
 Consistência
 Elementos de estilo
 Recomendações de projeto
É possível realizar uma avaliação heurística nas etapas iniciais do ciclo de projeto e
desenvolvimento. Esta avaliação pode ser feita sobre interfaces que ainda não tenham
sido implementadas, representadas em papel.

3.3.2. Percurso Cognitivo

O percurso cognitivo é um método analítico que avalia uma proposta de projeto de IHC no
contexto de tarefas específicas do usuário. Ele visa avaliar principalmente a facilidade de
aprendizado do sistema, em particular pela exploração dos usuários. A motivação para este
tipo de avaliação advém do fato de que muitas pessoas preferem aprender sobre a
funcionalidade de um sistema computacional enquanto trabalham em suas tarefas típicas,
adquirindo conhecimento sobre novas características ou funções apenas quando seu trabalho
as requerer.

Neste método, o custo de aprendizado deve ser determinado pelo benefício imediato aos seus
usuários. Este método investiga principalmente:
 A correspondência entre a conceitualização de uma tarefa por parte dos usuários e dos
designers;
 Escolha adequada (ou inadequada) de termos, ou seja, o vocabulário utilizado;
 feedback adequado (ou inadequado) para as conseqüências de uma ação.

Antes de realizar a avaliação, deve-se passar por uma fase de preparação, na

qual se definem:
 Hipóteses sobre os usuários e sobre o conhecimento que eles têm sobre a tarefa e
sobre a interface proposta;
 Cenários de tarefas, construídos a partir de uma seleção de tarefas importantes e de
tarefas freqüentes;
 Seqüência “correta” de ações para completar cada tarefa, tal como definida pelo
Projetista;
 Proposta de design em papel ou protótipo, ilustrando cada passo e indicando o estado
da interface antes/depois de cada um.
O procedimento de execução da avaliação compreende os seguintes passos:
1. O projetista apresenta uma proposta de design
2. Os avaliadores constroem histórias plausíveis sobre a interação de um usuário típico
com a interface, com base nos cenários de tarefas selecionados
3. Os avaliadores simulam a execução da tarefa, efetuando uma série de perguntas sobre
cada passo
4. Os avaliadores anotam pontos-chave, como:
 O que o usuário precisa saber antes de realizar a tarefa
 O que o usuário deve aprender ao realizar a tarefa.
A cada passo da tarefa, os avaliadores devem se fazer uma série de perguntas, buscando
descobrir problemas em potencial, ou seja, que poderiam ocorrer durante a interação de
usuários reais com o produto final implementado conforme aquela proposta de design.
A lista a seguir apresenta as perguntas básicas, assim como perguntas adicionais mais
específicas associadas a cada uma delas:
 O usuário tentará atingir a meta correta?
 Dada a decomposição de uma tarefa em subtarefas, o usuário saberá poronde
começar? Saberá qual é o próximo passo?
 O que o usuário vai tentar fazer a cada momento?
 O usuário perceberá que a ação correta está disponível?
 Onde está o elemento de interface correspondente ao próximo passo?
 Que ações a interface torna disponíveis?
 O usuário associará o elemento de interface correto à meta a ser atingida?
 O elemento de interface revela seu propósito e comportamento?
 O usuário consegue identificar os elementos de interface?
 Se a ação correta é tomada, o usuário perceberá que progrediu em direção àsolução da
tarefa?
 Como a interface apresenta o resultado de cada ação?
 O resultado apresentado tem correspondência com o objetivo do usuário?

Considerando-se cada um destes critérios, há algumas soluções típicas para as falhas mais
comuns:
 “O usuário tentará atingir a meta correta?” Se a interface falhar neste ponto, hápelo
menos três soluções possíveis:
 Eliminar a ação, combinando-a com outra ou deixando o sistema assumi-la;
 Fornecer uma instrução ou indicação de que a ação precisa ser realizada; • alguma
parte da tarefa pode ser modificada para que o usuário entenda a necessidade desta
ação.
 “O usuário perceberá que a ação correta está disponível?” Se o usuário possui os
objetivos certos mas não sabe que a ação está disponível na interface, a solução pode
ser:
 atribuir um operador mais óbvio para a ação. Isto geralmente requer um item
de menu ou instrução, em vez de combinação de teclas;
  atribuir à ação um controle menos visível mas como parte de uma estrutura em
que possa ser facilmente encontrado, como um submenu.
 “O usuário associará o elemento de interface correto à meta a ser atingida?”

Para corrigir este tipo de falha, o designer precisa conhecer os usuários e ter uma idéia sobre
como eles descreverão suas tarefas. Com esta informação, o designer poderá fornecer rótulos
e descrições de ações que incluam palavras que os usuários utilizariam para descrever estas
tarefas. Também pode ser necessário modificar os rótulos de outros controles, para que os
usuários possam decidir sobre qual é o correto.
 “Se a ação correta é tomada, o usuário perceberá que progrediu em direção à solução
da tarefa?”
Algum feedback é melhor do que nenhum. O feedback que indica o que ocorreu é melhor do
que aquele que indica que algo ocorreu. Além disto, o feedback será mais útil quando for
composto de termos ou símbolos relacionados à descrição do usuário para aquela tarefa.
Observe que, em situações simples, a interface pode prescindir de feedback e chamar logo a
próxima ação lógica.

3.4. Métodos de Avaliação Empíricos

Nesta seção serão apresentados alguns dos principais métodos de avaliação empíricos, ou
seja, aqueles nos quais se envolve usuários para a coleta de dados, que são posteriormente
analisados pelo especialista para identificar os problemas da interface. Em particular serão
enfatizados os métodos de avaliação de interfaces feitos em ambientes controlados.

Em testes com usuários em laboratório o avaliador tem um maior controle sobre o ambiente e
sobre as atividades do usuário. Assim, o avaliador consegue identificar problemas da interface
que dificultam a interação, sem se preocupar com fatores externos, tais como o usuário sendo
interrompido durante o uso do sistema. A principal desvantagem de testes em laboratórios é
justamente fazer a avaliação fora do contexto em que a aplicação será utilizada de fato. Desta
forma não se consegue identificar através de testes em laboratório fatores do ambiente que
podem impactar uso do sistema.

3.4.1. Preparação de Testes em Laboratório

Testes em laboratório requerem um planejamento minuncioso para que o avaliador tenha de
fato controle sobre as condições de teste. Isto envolve se certificar de que as condições de
teste são as mesmas para todos os participantes, e de que o teste sendo executado permite a
avaliação dos critérios desejados. Assim durante a etapa de preparação de teste o avaliador
deve determinar o objetivo da avaliação e, em função deste, os critérios relevantes e pontos
críticos, selecionar as tarefas, selecionar usuários participantes, gerar o material para o teste e
executar o teste-piloto.

3.4.1. Execução dos Testes em Laboratório

A execução dos testes exige a escolha de um ambiente adequado para os testes, a atenção a
questões éticas envolvidas no processo de teste com participação de outros seres humanos, e
ainda deixar os usuários o mais à vontade possível para que possam agir tão naturalmente
quanto consigam neste ambiente controlado e artificial.

Ambientes de teste
Os testes normalmente são executados em laboratórios de testes com usuários como por
exemplo o mostrado na Figura 7. Os laboratórios costumam possuir 2 salas, uma para a
execução do teste (Figura 7a) e outra para observação do teste (Figura 7b). As salas são
separadas por um vidro espelhado, de forma que o participante não enxergue quem se
encontra do outro lado do vidro, mas os observadores possam ver o participante e suas ações.
A sala de teste costuma ser equipada com um computador e espaço para o participante e um
avaliador. A sala de observação costuma ter um monitor que replica o que está sendo visto no
monitor do usuário, um outro computador para anotações. Além disso, câmeras de vídeo e
gravadores podem estar presentes em uma sala ou na outra, ou em ambas dependendo do teste
a ser executado.
 (a) Sala de teste: participantee um (b) Sala de observação: avaliador
Avaliador na sala. Observando por trás do vidro espelho.
Figura 7 – Laboratório de comunicabilidade do Grupo de Pesquisa em
Engenharia Semiótica (SERG), na PUC-Rio.

3.4.2. Testes de Usabilidade

O teste de usabilidade é executado em laboratório e tem por objetivo permitir que se apreciem
os fatores que caracterizam a usabilidade de um software, ou seja, facilidade de aprendizado,
facilidade de uso, eficiência de uso e produtividade, satisfação do usuário, flexibilidade,
utilidade e segurança no uso (Nielsen, 1993; Preece et al., 2002). Quais destes fatores devem
ser priorizados deve ser definido no projeto de design. Através do teste procura-se quantificar
o desempenho do usuário. Para isso durante a preparação de testes em laboratório descrita
anteriormente, para cada medida a ser observada, deve-se definir quais são os limites mínimos
aceitáveis, os máximos possíveis (em outras palavras, o melhor e pior caso) e também o valor
almejado para a medida no projeto. A quantificação do desempenho normalmente envolve a
medição do tempo e de ações de usuários. Apenas a satisfação do usuário se distingue e
normalmente é medida através da coleta de opinião do usuário e cujos limites mínimos,
máximos e almejados costumam ser definidos em função da porcentagem de usuários que se
dizem ou não satisfeitos com o software e o seu nível de satisfação. Alguns exemplos de
medidas comumente utilizadas no teste de usabilidade são tempo gasto para se executar uma
tarefa, número de erros executados, porcentagem de usuários a conseguirem se recuperar de
um erro, ou porcentagem de usuários a se dizerem satisfeitos com a aplicação, ou a preferirem
a aplicação a um outro sistema sendo utilizado.

Na análise dos dados coletados durante o teste de usabilidade o avaliador primeiramente

classifica os problemas pela sua gravidade (Nielsen, 1998):
 Problema catastrófico: impede que o usuário termine sua tarefa
 Problema sério: atrapalha a execução da sua tarefa
 Problema cosmético: atrasa a execução e/ou irrita usuários

3.4.3. Testes de Comunicabilidade

Testes de comunicabilidade, como os de usabilidade, devem ser executados em laboratório.

No entanto o seu objetivo é avaliar a interface com relação à qualidade da comunicação do
designer para os usuários. Para isto, este método simula a comunicação do usuário para o
designer sobre a interface. Isto é feito através de um pequeno conjunto de expressões que o
usuário potencialmente pode usar para se exprimir em uma situação onde acontece uma
ruptura na sua comunicação com o sistema (de Souza et al., 1999; Prates et al., 2000b).

A análise dos dados é dividida em 3 passos:

1. Uma etiquetagem, que consiste em assistir às gravações da interação eatribuir a
expressão apropriada nos momentos de ruptura da interação;
2. Uma interpretação, que consiste em tabular e consolidar a informaçãoobtida, ou seja,
as expressões obtidas, associando-as a classificações deproblemas de interação ou
diretrizes de design; e
3. Um perfil semiótico, que consiste em interpretar a tabela resultante dopasso anterior,
dentro do quadro teórico da Engenharia Semiótica (de Souza,1993; de Souza et al.
2001), em uma tentativa de se reconstruir a metamensagemsendo transmitida pelo
designer ao usuário através da interface.
3.4.4. Testes de Usabilidade x Testes de Comunicabilidade
A maior diferença entre os testes de usabilidade e comunicabilidade está no conceito de
qualidade de uso que eles pretendem apreciar, conforme seus próprios nomes indicam. Assim,
testes de usabilidade pretendem avaliar a solução do designer, enquanto os de
comunicabilidade buscam avaliar a comunicação sendo feita sobre esta solução. Para isso, os
testes de usabilidade normalmente coletam dados quantitativos e buscam informar designers
durante o ciclo de desenvolvimento quais critérios não correspondem ao objetivo almejado
para o software. Testes de comunicabilidade, por sua vez, coletam dados qualitativos e têm
por objetivo informar designers sobre pontos da sua solução que não estão sendo transmitidos
com sucesso aos usuários.

3.4.5. Protocolos Verbais

Os métodos que envolvem protocolos verbais normalmente são testes executados em

laboratório, nos quais os participantes explicitam aquilo que estão pensando, à medida que
executam as tarefas propostas. A principal vantagem destes métodos sobre outros métodos de
teste em laboratório é permitir que o avaliador tenha acesso aos processos mentais dos
participantes descritos por eles mesmos no decorrer da execução da tarefa. Desta forma
avaliadores podem compreender melhor os comportamentos, sentimentos e atitudes dos
usuários em relação à atividade sendo observada.
Um dos principais métodos de protocolo verbal utilizado é o de pensar alto (think aloud) ().
Neste método o participante executa os testes individualmente no laboratório e narra o que
está pensando à medida que o faz. Se o participante fica em silêncio por um longo período de
tempo, o avaliador pode lembrar o participante de continuar dizendo o que está pensando,
com perguntas como: “O que você está pensando?” ou “O que você acabou de fazer?”. No
entanto, esta interrupção pode atrapalhar a atividade do participante. A maior desvantagem
deste método é que o participante faz duas coisas ao mesmo tempo: executa a tarefa, e narra
suas ações e
pensamentos. Uma forma de amenizar as desvantagens do método de pensar alto é colocar
dois participantes juntos para executar a tarefa. Desta forma, os participantes trocam idéias
entre si sobre o que fazer, o que significa o que estão vivenciando e seus sentimentos e
atitudes relativos à atividade e à aplicação. Ao fazerem isso eles explicitam seus pensamentos
e os avaliadores passam a ter acesso ao que estão pensando. Este método normalmente é
conhecido por método de co-descoberta.

3.4.6. Avaliação no Ambiente do Usuário7

Uma outra forma de se fazer avaliações é ao invés de fazê-las em um ambiente controlado e
artificial, fazê-las no ambiente natural dos usuários onde a aplicação será utilizada de fato.
Enquanto testes no laboratório permitem a identificação de problemas de interface e interação,
avaliações no contexto do usuário normalmente são utilizadas principalmente para se facilitar
a introdução de tecnologia ou avaliar o uso sendo feito desta no contexto do usuário (Bly,
1997).

Em avaliações no ambiente do usuário, normalmente a coleta de dados é feita através da

observação do uso sendo feito da aplicação e conversas com os usuários. Os dados podem ser
armazenados como anotações, gravações de áudio ou vídeo, ou uma combinação de formas.
Podem ser armazenados também artefatos ou quaisquer indicadores que auxiliem no
entendimento de como as pessoas trabalham no seu próprio ambiente. Normalmente o dado
coletado é qualitativo e a análise feita sobre ele interpretativa.

Independente da abordagem de atuação do avaliador utilizada, com freqüência o avaliador

utiliza-se de esquemas de apoio à sua observação. O objetivo destes esquemas é guiar a
observação, e organizar os dados sendo coletados. Um exemplo de esquema é o proposto por
Robson (1993):
 Espaço: Como é a disposição física do ambiente e como ele está organizado?
 Atores: Quais são os nomes e detalhes relevantes das pessoas envolvidas?
 Atividades: O que os atores estão fazendo e por quê?
 Objetos: Que objetos físicos, como por exemplo móveis, estão presentes?
 Atos: O que cada um dos atores está fazendo?
 Eventos: O que está sendo observado é parte de algum evento?
 Objetivos: Que objetivos os atores estão tentando atingir?
 Sentimentos: Qual o humor do grupo e dos indivíduos?

3.4. Conclusão

Neste capítulo foram apresentados alguns dos principais métodos analíticos e empíricos de
avaliação da qualidade de uso de usabilidade e comunicabilidade de interfaces. Estes métodos
foram desenvolvidos para avaliações de interfaces de sistemas mono-usuário de propósito
geral. Todos os métodos propõem que o domínio da aplicação e o seu contexto de uso sejam
considerados durante a execução da avaliação, seja pelos especialistas que inspecionam a
interface, seja pelas tarefas a serem propostas aos usuários. No entanto, nenhum dos métodos
se propõe a apreciar aspectos específicos relacionados ao domínio da aplicação.
3.5. Referências Bibliográficas
Adler, P. & Winograd, T. (1992) Usability: Turning Technologies into Tools. Oxford
University Press. New York, NY, 1992.
Asdi, K. and Daniels, H., (2000) “ 'Learnability' Testing in Learner-Centered Design”. In CHI
2000 Extended Abstracts.
Baker, K., Greenberg, S. and Gutwin, C. (2001) “Heuristic Evaluation of Groupware Based
on the Mechanics of Collaboration”. In M.R. Little and L. Nigay (Eds) Engineering for
Human Computer Interaction (8th IFIP International Conference, EHCI 2001, Toronto,
Canada, May), Lecture Notes in Computer Science Vol 2254, p123-139, Springer-Verlag.
Barbosa, C. M. O., de Souza, C. S., Nicolaci-da-Costa, A. M., and Prates, R. O. P. (2002),
“Using the Underlying Discourse Unveiling Method to Understand Organizations of Social
Volunteers”, Anais do V Simpósio sobre Fatores Humanos em Sistemas Computacionais
(IHC 2002), Fortaleza, 15-26.
Blackmon, M.H.; Polson, P.G.; Kitajima, M.; Lewis, C. (2002) “Cognitive Walkthrough for
the Web”. ACM Proceedings of CHI 2002. pp.463–469. Bly, S. (1997) “Field Work: Is it
product work?” Interactions, Jan/Fev, 25-30.
de Souza, C.S. (1993) “The Semiotic Engineering of User Interface Languages”.
International Journal of Man-Machine Studies, Vol.39, 1993, pp.753-773.
de Souza, C.S.; Prates, R.O.; and Barbosa, S. D. J. (1999) “A Method for Evaluating Software
Communicability”. Anais do II Workshop sobre Fatores Humanos em Sistemas
Computacionais (IHC’1999). Campinas, Artigo 28.
de Souza, C. S., Barbosa, S. D. J., Prates, R. O. (2001) “A Semiotic Engineering
Approach to User Interface Design”. Journal of Knowledge-Based Systems, Vol.14, Issue 8,
2001, pp 461-465.
Dumas, J. S e Redish, J. C. (1999) A Practical Guide to Usability Testing (Revised Edition).
Exeter, UK: Intellect, 1999.
Ericsson, K. A. and Simon, H. A. (1985) Protocol Analysis: Verbal Reports as Data.
Cambridge, MA: MIT Press.
Fischer, G. (1998) “Beyond ‘Couch Potatoes’: From Consumers to Designers” In
Proceedings of the 5th Asia Pacific Computer-Human Interaction Conference. IEEE Computer
Society, 2-9, 1998.
Güell, N.; Schwabe, D.; Barbosa, S.D