Captulo

6
Avaliao de Interfaces de Usurio Conceitos e
Mtodos
Raquel Oliveira Prates, Simone Diniz Junqueira Barbosa
Abstract
As personal computers become more and more popular, they are being used
not only to perform work, but also as means to communicate, provide social
insertion and household planning. The quality of the interface is mister, if
interactive systems are to be successful. To design high quality interfaces, it is
essential that they are evaluated during the design process, in order to
indentify and adjust interaction problems. This chapter presents concepts of
quality of use in interfaces and the main evaluation methods used to assess
them.
Resumo
Atualmente, com a popularizao de computadores pessoais, cada vez mais
computadores so incorporados ao cotidiano das pessoas, sendo utilizados
no apenas como ferramenta de trabalho, mas tambm como meio de
comunicao, de insero social e de planejamento familiar. A qualidade da
interface fundamental para que sistemas interativos possam ser utilizados
com sucesso. Para se obter interfaces de alta qualidade essencial que estas
sejam avaliadas durante o processo de design, permitindo assim a
identificao e ajustes de problemas de interao. Neste captulo sero
apresentados conceitos de qualidade de uso de interfaces e os principais
mtodos de avaliao utilizados para sua apreciao
6.1. Introduo
Em linhas gerais, a rea de Interao Humano-Computador (IHC) investiga o projeto
(design), avaliao e implementao de sistemas computacionais interativos para uso
humano, juntamente com os fenmenos 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, so definidos mtodos, modelos e diretrizes. Os estudos
relacionados avaliao 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.
6.1.1 Interface x Interao
Interao o processo de comunicao entre pessoas e sistemas interativos (Preece et
al., 1994). Neste processo, usurio e sistema trocam turnos em que um fala e o outro
ouve, interpreta e realiza uma ao. Esta ao pode ser to simples quanto dar uma
resposta imediata fala do outro, ou consistir de operaes complexas que alteram o
estado do mundo. A rea de IHC estuda este processo, principalmente do ponto de vista
do usurio: as aes que ele realiza usando a interface de um sistema, e suas
interpretaes das respostas transmitidas pelo sistema atravs da interface (Figura 1).
ao
interpretao
usurio
sistema
interface aplicao
ao
interpretao
usurio
sistema
interface aplicao
Figura 1: O processo de interao humano-computador.
Interface o nome dado a toda a poro de um sistema com a qual um usurio
mantm contato ao utiliz-lo, tanto ativa quanto passivamente. A interface engloba
tanto software quanto hardware (dispositivos de entrada e sada, tais como: teclados,
mouse, tablets, monitores, impressoras e etc.). Considerando a interao como um
processo de comunicao, a interface pode ser vista como o sistema de comunicao
utilizado neste processo. Uma definio de interface utilizada com freqncia foi
proposta por Moran:
a interface de usurio deve ser entendida como sendo a parte de um
sistema computacional com a qual uma pessoa entra em contato
fsica, perceptiva ou conceitualmente (Moran, 1981).
A dimenso fsica inclui os elementos de interface que o usurio pode manipular,
enquanto a dimenso perceptiva engloba aqueles que o usurio pode perceber. A
dimenso conceitual resulta de processos de interpretao e raciocnio do usurio
desencadeados pela sua interao com o sistema, com base em suas caractersticas
fsicas 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 atravs de canetas esto se tornando freqentes, devido
disseminao de dispositivos mveis.
6.1.2 Objetivos e Importncia da Avaliao de Interao
Antes de declarar um software pronto para uso, importante saber se ele apia
adequadamente os usurios, nas suas tarefas e no ambiente em que ser utilizado. Assim
como testes de funcionalidade so necessrios para se verificar a robustez da
implementao, a avaliao de interface necessria para se analisar a qualidade de uso
de um software. Quanto mais cedo forem encontrados os problemas de interao ou de
interface, menor o custo de se consert-los (Karat, 1993).
Um projetista no deve supor que basta seguir mtodos e princpios de projeto
de interfaces para garantir uma alta qualidade de uso de seu software. Alm disto,
tambm no deve presumir que os usurios so como ele prprio, e que portanto
bastaria sua avaliao individual para atestar esta qualidade (Preece et al., 2002). Deve-
se ter em mente que algum vai avaliar a qualidade de uso do seu sistema, nem que seja
apenas o usurio final...
Alguns dos principais objetivos de se realizar avaliao de sistemas interativos
so (Hartson, 1998; Preece et al., 2002):
identificar as necessidades de usurios ou verificar o entendimento dos
projetistas sobre estas necessidades
identificar problemas de interao ou de interface
investigar como uma interface afeta a forma de trabalhar dos usurios
comparar alternativas de projeto de interface
alcanar objetivos quantificveis em mtricas de usabilidade
verificar conformidade com um padro ou conjunto de heursticas
Infelizmente, freqente encontrarmos gerentes de projeto que pensam apenas nos
custos envolvidos na realizao de avaliaes de seus sistemas. Isto se deve geralmente
pelo desconhecimento dos benefcios associados a estas avaliaes. Dependendo do
momento em que for realizada a avaliao, estes benefcios podem ter efeito imediato,
em consertos importantes no incio do desenvolvimento; a mdio prazo, no
planejamento da estratgia de treinamento e marketing; ou at mesmo a longo prazo,
apoiando o planejamento de verses futuras do software.
6.1.3 Conceitos de qualidades de uso
O conceito geral de qualidade de uso est estreitamente relacionado com a capacidade
e a facilidade de os usurios atingirem suas metas com eficincia e satisfao. Quando
os usurios tm vias alternativas para realizarem suas tarefas, com ou sem apoio
computacional, o fato de escolherem espontaneamente utilizar um determinado sistema,
e com certa freqncia, 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 eficincia de aprendizado e de uso, bem como satisfao do
usurio (Nielsen, 1993). Mais recentemente, foi elaborado o conceito de
comunicabilidade, que busca avaliar o processo implcito de comunicao designer
usurio, que se d atravs da interface (Prates et al. 2000b,Prates et al., 2000a). J o
conceito de aplicabilidade est relacionado flexibilidade de um sistema, em particular
com relao sua utilidade em uma variedade de situaes (Fischer, 1998).
Usabilidade
O conceito de usabilidade permite avaliar a qualidade de um sistema com relao a
fatores que os projetistas definem como sendo prioritrios ao sistema. Alguns fatores
tpicos envolvidos no conceito de usabilidade so (Nielsen, 1993; Preece et al., 2002):
facilidade de aprendizado
facilidade de uso
eficincia de uso e produtividade
satisfao do usurio
flexibilidade
utilidade
segurana no uso
Facilidade de aprendizado se refere ao tempo e esforo necessrios para que os
usurios aprendam a utilizar uma determinada poro do sistema com determinado nvel
de competncia e desempenho. Geralmente, um sistema pode ser analisado sob uma
perspectiva de uso simples, considerando um nvel intermedirio ou avanado, 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 nvel de capacitao ao prximo.
O fator facilidade de uso do sistema est relacionado no apenas com o esforo
cognitivo para interagir com o sistema, mas tambm com o nmero de erros cometidos
durante esta interao. importante observar que um sistema fcil de aprender no
necessariamente fcil de utilizar ou vice-versa.
Sistemas fceis de utilizar podem ser ineficientes de duas formas: com relao a
o que permite o usurio fazer (eficincia de uso), e a como o usurio deve faz-lo
(produtividade). O fator eficincia de uso serve para analisar se o sistema faz bem
aquilo a que se destina. J o fator produtividade serve para avaliar se o usurio
consegue fazer o que precisa de forma rpida e eficaz. Este fator geralmente avaliado
pelo tempo decorrido desde o incio at a concluso de uma tarefa e pelo nmero de
passos que o usurio precisou realizar.
Como a aceitao de um sistema interativo determinante do sucesso do
sistema, o fator satisfao do usurio enfatiza a avaliao subjetiva do sistema feita
por seus usurios, incluindo emoes que possam surgir durante a interao, sejam elas
positivas, como prazer e diverso, ou negativas, como tdio ou frustrao.
Pessoas diferentes podem seguir caminhos distintos para atingir um mesmo
objetivo. Estas idiossincrasias vo desde operaes primitivas como o uso de mouse ou
teclas de atalho para acionar uma funo do sistema, at mesmo estratgias de soluo
de problemas completamente distintas, como o uso criativo de um editor de textos
como software de apresentao de slides, por exemplo. O fator flexibilidade considera
o quanto um sistema capaz de acomodar estas idiossincrasias.
O fator utilidade de um sistema se refere ao quanto um sistema oferece o
conjunto de funcionalidades necessrias para os usurios realizarem suas tarefas. Esta
dimenso est intimamente relacionada ao conceito de aplicabilidade proposto por
Fischer (1998), que ser visto adiante.
A dimenso de segurana no uso se refere ao grau de proteo de um sistema
contra condies desfavorveis ou at mesmo perigosas para os usurios. Trata-se
principalmente de como evitar e permitir que o usurio se recupere de condies de erro
com conseqncias srias para seu trabalho ou para sua sade.
Comunicabilidade
O conceito de comunicabilidade (de Souza et al. 1999, Prates et al., 2000b) se refere
capacidade de os usurios entenderem o design tal como concebido pelos projetistas. A
hiptese subjacente ao conceito de comunicabilidade que, se um usurio entende as
decises que o projetista tomou ao construir a interface, aumentam suas chances de
fazer um bom uso daquele sistema. Em sistemas com alta comunicabilidade, os usurios
so capazes de responder:
para que o sistema serve
qual a vantagem de utiliz-lo
como funciona
quais so os princpios gerais de interao com o sistema
Durante o processo de design, o projetista elabora as respostas para estas perguntas, mas
nem sempre se preocupa em transmiti-las adequadamente atravs da interface. Como
resultado, o usurio pode ser incapaz de criar um modelo mental do sistema que seja
compatvel com o do projetista, o que freqentemente torna a interao um tedioso
exerccio de tentativa e erro.
Uma interface com boa comunicabilidade permite que o usurio formule um
modelo mental compatvel com o do projetista. O uso de analogias com artefatos
familiares ao usurio pode contribuir para isto, pois o usurio j possui um modelo
mental sobre o comportamento desses artefatos. No entanto, importante deixar claro
qual o escopo da analogia, ou seja, quais so as pores do modelo mental sobre o
artefato conhecido que podem ser transportadas para a construo do modelo mental
sobre a interface em questo.
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 usurio
com os aparelhos comuns de CD, fornecendo elementos de interface anlogos, tais
como os botes de comando para acionamento das funes e o visor de trilhas e durao
como elemento de feedback.
Figura 2: Exemplo de boa comunicabilidade: interface de um software para
tocar CDs.
Um exemplo de baixa comunicabilidade pode ser encontrado na ferramenta de
busca de arquivos no Windows 2000 (Figura 3). O usurio aciona a ferramenta de
busca, mas a janela aparece reduzida e deslocada, de modo que as opes de busca no
esto visveis. O usurio move a janela para o centro da tela, mas ainda assim as opes
no aparecem. Fazendo uso do conhecimento adquirido de que o menu d acesso a
todas as funes de um sistema, ele resolve procurar estas opes sob o menu Edit.
Este menu no apresenta as opes de busca, como esperado, mas surpreendentemente,
possui um item chamado Undo Move. Tentando entender o que significa este comando,
o usurio imagina que sirva para restaurar a posio da janela ao local anterior ao
deslocamento, e resolve experimentar, mas nada acontece. (Na verdade, o comando
Undo Move desfez a ltima transferncia de arquivo que o usurio 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 no atenua o fato de que transferncia de
arquivos no 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 tambm determina sua qualidade de uso. Este conceito
est relacionado com a utilidade deste sistema em uma variedade de situaes 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 hbeis e especialistas no seu domnio,
querem agir como designers, no sentido de participar ativamente dos processos de
soluo de problemas e de construo ou transformao dos seus prprios artefatos e
espaos 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 rgidas, nas quais os usurios tm apenas um caminho a seguir,
com pouca possibilidade de cometer erros, so freqentemente chamadas de a prova de
idiotas (do ingls, idiot-proof). Na realidade, este tipo de interface trata todos os
usurios como pessoas incapazes de tomar decises apropriadas. Os usurios destes
sistemas tm reaes negativas de diversos tipos, conforme suas caractersticas e o
contexto em que esto inseridos: eles fazem um mau uso do sistema, deixam de us-lo,
ou at mesmo se limitam a crer que o sistema tem sempre razo e que eles, usurios,
no deveriam mesmo tomar decises importantes.
Diversos pesquisadores tm chamado ateno para a necessidade de se
desenvolver sistemas que ampliem as capacidades dos usurios, em vez de tentarem
substitu-las, possibilitando que eles ajam de forma mais inteligente e eficiente (Adler &
Winograd, 1992). O usurio pode ser considerado um especialista na sua tarefa: seu
conhecimento, competncia e forma de atuao devem ser respeitados.
Por que incluir, em um processo de desenvolvimento de sistemas interativos,
procedimentos de avaliao de sistemas com relao sua qualidade de uso? Do ponto
de vista do usurio, a qualidade da interface e da interao determina a qualidade do
sistema, e no 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 usurios, e reduzir (ou aumentar) os custos com suporte tcnico
para atendimento aos usurios. Alm disto, as iniciativas voltadas para a qualidade de
uso de sistemas computacionais esto geralmente associadas a melhorias em processos
de negcio, 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 explorao
confundem os usurios
induzem os usurios ao erro
geram insatisfao
diminuem a produtividade
no trazem o retorno de investimento previsto
Estes problemas podem ser detectados atravs de mtodos de avaliao diversos,
realizados ao longo do processo de desenvolvimento. Como ser visto adiante, os
mtodos de avaliao mais utilizados se concentram em avaliar a usabilidade e a
comunicabilidade de um sistema. Como no h um mtodo de avaliao especfico para
o conceito de aplicabilidade, deve-se optar por um dos mtodos qualitativos de
avaliao, que provem insumos preciosos para esta avaliao.
6.2. Caractersticas dos mtodos de avaliao
Os mtodos de avaliao de interface diferem entre si em vrios aspectos. preciso
entender as diferentes caractersticas de cada mtodo, para se definir qual deles o
mais apropriado para se avaliar a interface de um software em um determinado
contexto. As principais diferenas entre os mtodos so a etapa do ciclo de design do
software em que devem ou podem ser aplicados (durante o ciclo de desenvolvimento ou
aps ter o produto pronto), a tcnica utilizada para coletar os dados (desde entrevistas
at experimentos em laboratrios), os tipos de dados coletados (quantitativos ou
qualitativos), e ainda o tipo de anlise feito (o avaliador pode prever potenciais
problemas ou interpretar os dados obtidos) (Preece et al., 1994). Nesta seo
apresentaremos cada uma destas dimenses.
6.2.1 Etapa do ciclo de design
A avaliao de uma interface pode ser feita durante diferentes etapas do ciclo de
desenvolvimento do software. As avaliaes formativas (Preece et al., 1994; Hartson,
1998) so aquelas que so feitas durante o processo de design, antes de o sistema estar
terminado, e muitas vezes antes de uma linha de cdigo sequer ser escrita. A avaliao
pode ser feita utilizando-se desde cenrios, storyboards, ou a modelagem conceitual da
interao at prottipos do sistema. A vantagem de se fazer avaliao formativa que
problemas de interao so identificados e consertados antes de a aplicao ser
terminada e liberada para uso. Quanto mais cedo no ciclo de design um problema
descoberto e reparado, menor o custo das alteraes necessrias no software (Karat,
1993). Alm disto, o software resultante a ser oferecido para o usurio de melhor
qualidade.
As avaliaes de interface feitas em produtos j terminados so chamadas de
avaliaes somativas. Normalmente, enquanto as avaliaes formativas tm por
objetivo melhorar a qualidade do sistema, tornando-o mais usvel para o usurio, as
avaliaes somativas buscam verificar a existncia de determinados aspectos no sistema
desenvolvido, como por exemplo a sua conformidade com um padro estabelecido.
6.2.2 Tcnicas de Coleta de Dados
Existem vrias tcnicas disponveis para se coletar dados sobre a interface de um
software e se fazer a anlise da sua qualidade de uso. A deciso sobre que tcnica
utilizar depende principalmente da disponibilidade dos recursos que se tem e objetivos
da avaliao a ser feita. A seguir apresentamos as principais caractersticas de cada uma
das tcnicas.
Coleta da opinio de usurios
A coleta da opinio de usurios tem por objetivo se obter uma apreciao dos usurios
em relao ao sistema interativo. Normalmente, se deseja identificar o nvel de
satisfao dos usurios com o sistema, o que inclui aspectos como: se eles gostam do
sistema, se a aparncia esttica do sistema satisfatria, 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 tcnicas utilizadas para se coletar a opinio
de usurios so questionrios e entrevistas. Os tipos de questionrios 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 usurio
individualmente ou com grupos de usurios, e utilizando perguntas bem estruturadas ou
livres.
Observao de usurios
Nem sempre usurios percebem ou conseguem expressar a sua experincia de uso com
o sistema. A observao do uso do sistema pelo usurio permite ao avaliador ter uma
viso dos problemas sendo vivenciados pelos usurios e muitas vezes dos aspectos
positivos experimentados durante o uso. A observao pode ser registrada usando-se
anotaes do observador, gravao de vdeo, udio ou da interao, ou uma combinao
destas.
O usurio pode ser observado no seu contexto de uso, ou seja utilizando o
software no seu trabalho, ou at mesmo em sua casa. Nestas situaes se consegue
observar o usurio 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 desejvel. Em tais situaes, alguns dos desafios para os
avaliadores so conseguir observar sem interferir no contexto ou inibir o usurio, e
como fazer a anlise dos dados coletados, principalmente quando se obtm vrias horas
de vdeo gravadas, ou quando diferentes tipos de registro feitos durante o uso devem ser
integrados.
O avaliador pode desejar observar o uso feito pelo usurio em ambientes mais
controlados, como laboratrios. Nestes ambientes o avaliador tem um controle maior
sobre as variveis que influenciam a avaliao, como o tempo de durao, a
concentrao do usurio e as tarefas a serem executadas. Assim, possvel coletar
dados mais precisos sobre a utilizao de diferentes usurios de forma a compar-los.
Nestes casos, o avaliador normalmente determina as tarefas a serem executadas pelo
usurio e pode coletar dados qualitativos ou quantitativos sobre o uso, como por
exemplo, o tipo e freqncia das dificuldades enfrentadas pelos usurios, caminhos
preferenciais, o tempo gasto para executar a tarefa, ou o nmero de erros cometidos.
Registro de uso
Observar o usurio requer que o usurio e o observador estejam presentes em uma
mesma hora e local por um determinado perodo de tempo. No entanto, isto nem sempre
possvel, ou se gostaria de ter informaes sobre o uso em um perodo de tempo mais
longo. Uma outra forma de coletar informaes sobre como os usurios usam o sistema
atravs de registros feitos durante o uso. Isto pode ser feito atravs de logs, que
armazenam em um arquivo as aes executadas em um sistema, atravs da gravao da
interao do usurio com o sistema, ou da gravao em vdeo da experincia do usurio.
As diferentes formas de registro armazenam aspectos distintos do uso feito.
Normalmente, registros de uso geram uma grande quantidade de informao e a anlise
destes dados pode ser bastante custosa para avaliadores.
Coleta da opinio de especialistas
Em algumas situaes os usurios no esto disponveis para participar da avaliao, ou
o seu envolvimento implica um custo elevado. Nestas situaes, a avaliao pode ser
feita sem a participao dos usurios. Neste caso, pode se considerar a coleta da opinio
de especialistas em IHC e/ou no domnio da aplicao. Os especialistas examinam a
interface e identificam possveis dificuldades que os usurios podem vir a ter ao utilizar
o software. A seo 6.3 apresenta mtodos de avaliao baseados na inspeo da
interface por especialistas.
6.2.3 Tipo de Dados Coletados
Os dados coletados a partir de uma avaliao de interface podem ser quantitativos ou
qualitativos. Dados quantitativos so aqueles que podem ser representados
numericamente. Normalmente dados quantitativos so utilizados para se avaliar a
eficincia 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 anlise destes dados freqentemente feita utilizando-se clculos
estatsticos simples, como desvio padro ou mdias. Alguns exemplos de dados
quantitativos so o nmero de erros ocorridos ou o tempo gasto para completar uma
tarefa.
Dados qualitativos so resultados no numricos, tais como uma lista de
problemas que os usurios tiveram ao utilizar a aplicao, ou suas sugestes sobre como
melhorar o projeto de interao. Normalmente estes dados permitem identificar quais
so as caractersticas de interao ou interface relacionadas com os problemas medidos
e observados. Em alguns casos, dados qualitativos podem ser categorizados e ento
quantificados.
6.2.4 Tipo de Anlise
Os avaliadores podem analisar os dados coletados de forma preditiva, intepretativa ou
experimental. A anlise preditiva realizada quando os avaliadores, ao analisarem os
dados coletados de especialistas, tentam prever que tipo de problemas os usurios
enfrentaro. Esta anlise pode ser feita atravs de uma inspeo da interface ou em
funo de tcnicas de modelagem.
A anlise interpretativa realizada quando, ao analisarem os dados coletados a
partir da interao do usurio com o sistema, os avaliadores procuram explicar os
fenmenos que ocorreram durante esta interao. Normalmente se considera a anlise
como sendo interpretativa quando ela feita sobre dados coletados em ambientes
naturais sem interferncia dos observadores nas atividades dos usurios.
Os dados coletados em ambientes controlados, como laboratrios, precisam ser
analisados em funo das variveis sendo observadas. Embora esta anlise tambm
dependa da interpretao do avaliador, diferenciamo-na da anterior, pelo fato de as
variveis sendo manipuladas serem conhecidas. Assim, denominamos este tipo de
anlise de experimental.
6.2.5 Guia para o planejamento de uma avaliao
Para organizar as decises que devem ser tomadas com respeito a uma avaliao de
IHC, prope-se utilizar o esquema DECIDE (Preece et al., 2002), para ajudar
avaliadores inexperientes no planejamento e realizao de uma avaliao. Os pontos
relevantes a serem considerados so os seguintes:
Determinar os objetivos gerais que a avaliao dever tratar. Trata-se de
responder as perguntas gerais: Quais so os objetivos gerais da avaliao? Quem
quer realiz-la e por qu?
Explorar perguntas especficas a serem respondidas. Trata-se de decompor
as perguntas gerais em perguntas especficas ao sistema a ser avaliado,
considerando-se os usurios-alvo e suas atividades. Estas perguntas so
necessrias para permitir efetivamente que os objetivos da avaliao sejam
atingidos.
Escolher (Choose) o paradigma e as tcnicas de avaliao que respondero
as perguntas. Dentre os pontos a serem considerados, destacam-se o prazo, o
custo, os equipamentos e o grau de conhecimento e experincia dos avaliadores
exigidos por cada tcnica.
Identificar questes prticas que devem ser tratadas. Consideram-se aqui
fatores como: perfil e nmero de usurios que participaro da avaliao;
ambiente em que a avaliao ser realizada; seleo das tarefas; planejamento e
preparao do material de avaliao; alocao de pessoal, recursos e
equipamentos para a realizao da avaliao.
Decidir como lidar com questes ticas. Quando uma avaliao envolve
pessoas como participantes de testes, os avaliadores devem se certificar que os
direitos destas pessoas esto sendo respeitados. Na seo 6.4 apontamos formas
de lidar com as questes ticas envolvidas neste tipo de avaliao.
Avaliar (Evaluate), interpretar e apresentar os dados. Como apontado nesta
seo, os dados coletados durante uma avaliao podem variar bastante. Sendo
assim, importante considerar aspectos como a confiabilidade dos dados (se a
tcnica produz os mesmos resultados nas mesmas circunstncias), sua validade
(se mede o que deveria medir); potenciais distores; escopo (o quanto as
descobertas podem ser generalizadas); e validade ecolgica (o quanto o
ambiente em que a avaliao feita influencia ou distorce os resultados).
6.3. Mtodos de Avaliao Analticos
Mtodos de avaliao analticos so aqueles nos quais avaliadores inspecionam ou
examinam aspectos de uma interface de usurio relacionados a usabilidade (Mack &
Nielsen, 1994). Normalmente, os avaliadores so especialistas em usabilidade, mas
tambm podem ser consultores de desenvolvimento de software especializados em um
determinado estilo de interface, ou ainda usurios finais conhecedores do domnio e da
tarefa, entre outros.
A avaliao analtica ou por inspeo utilizada geralmente para buscar
problemas de usabilidade em um projeto de interface existente, e analisar estes
problemas com vistas a fazer recomendaes para consert-los e assim melhorar a
usabilidade do projeto. Mack e Nielsen (1994) identificam como principais objetivos
deste tipo de avaliao:
identificao de problemas de usabilidade: identificar, classificar e contar o
nmero de problemas de usabilidade encontrados durante a inspeo;
seleo dos problemas que devem ser corrigidos: aps identificar os
problemas, a equipe de projeto deve reprojetar a interface para corrigir o maior
nmero possvel de problemas. Os problemas a serem corrigidos so priorizados
de acordo com a gravidade do problema e o custo associado correo.
Alm disto, ressaltam que este tipo de avaliao promove a formao e capacitao da
equipe com relao a projetos de interface centrados no usurio.
Existem trs tipos de conhecimento envolvidos em uma avaliao analtica:
conhecimento sobre o domnio, conhecimento e experincia no projeto e avaliao de
interfaces de usurio, e experincia em se realizar um tipo especfico de avaliao
(Lynch & Palmiter, 2002).
O conhecimento sobre o domnio necessrio para determinar o que os
usurios querem, do que eles precisam, quais so as tarefas mais freqentes e quais as
mais importantes.
O conhecimento e a experincia de projeto de interfaces de usurio so
necessrios para que o avaliador seja capaz de analisar os aspectos mais importantes de
um projeto de interfaces (navegao, terminologia, estruturas de controle, etc.) e para
que ele conhea os princpios e diretrizes disponveis na literatura. Alm disto, como os
princpios e diretrizes costumam ser bastante genricos, esta experincia fundamental
para que o avaliador saiba distinguir quando aplicar e quando ignorar um princpio ou
diretriz.
J a experincia em realizar um tipo de avaliao especfico d ao avaliador a
capacidade de representar um cliente, bem como o conhecimento sobre o que procurar e
o que relatar como resultado da avaliao.
Com base nestes tipos de conhecimento, pode-se avaliar os perfis de possveis
avaliadores conforme a seguinte escala, em ordem de preferncia:
ideal: especialista duplo. Possui experincia tanto nos processos e princpios
de usabilidade quanto nos processos e aspectos relevantes do domnio.
desejvel: especialista em IHC. Conhece o processo de avaliao, bem como os
princpios e diretrizes relevantes. Pode aprender o suficiente do domnio para
selecionar as tarefas que devero ser realizadas.
menos desejvel: especialista no domnio. Tem conhecimento do domnio e
estuda princpios de interface e o processo de avaliao para realizar a avaliao.
menos desejvel ainda: membro da equipe de desenvolvimento. Tem
dificuldade em deixar de lado seu papel de desenvolvedor e assumir um ponto
de vista semelhante ao de um usurio.
Caso o domnio do problema seja desconhecido dos avaliadores, pode ser necessrio
incluir no planejamento da avaliao um especialista no domnio, para esclarecer
eventuais dvidas dos avaliadores. Esta ajuda pode tomar a forma de criao de
cenrios de uso tpicos, que listem vrios passos que um usurio com determinado perfil
deve seguir para realizar uma amostra realista de tarefas. Tais cenrios devem ser
construdos com base em uma anlise das tarefas dos futuros usurios do sistema.
Existem diversos tipos de avaliao analtica: avaliao heurstica, percurso cognitivo,
percurso pluralista, conformidade com diretrizes e padres, e inspees de consistncia,
de caractersticas ou formais (Mack & Nielsen, 1994). Nesta seo, descrevemos os
mtodos de avaliao heurstica e percurso cognitivo. Como ilustrao dos mtodos de
avaliao descritos nesta seo e na prxima ser apresentado a avaliao feita na
primeira verso do Projeto Or (Or, 2001). Nem todos os mtodos apresentados foram
utilizados no Projeto Or, mas para aqueles que no foram, apresentaremos um exemplo
de como poderia ter sido a aplicao do mtodo. O Quadro 1 contm uma breve
descrio do Projeto.
Quadro 1- Descrio do Projeto Or
O Projeto Or (Or, 2001) tem por objetivo desenvolver um ambiente de groupware para apoiar o
trabalho da comunidade de uma organizao no-governamental, a Associao Sade-Criana
Renascer (ASCR). A primeira etapa no desenvolvimento deste ambiente foi o projeto de um quadro
de avisos, onde funcionrios e voluntrios da ASCR poderiam colocar e ler avisos sobre as
atividades e notcias relevantes. Durante a etapa de design identificou-se que grande parte dos
membros da comunidade da ASCR tinham uma grande resistncia ao uso de computadores
(Barbosa et al., 2001). Assim, um dos objetivos do design do Quadro de Avisos era que este fosse
simples o suficiente para que as pessoas o aprendessem rapidamente e facilmente, ajudando-as, em
alguns casos, a superar seus sentimentos negativos relativos ao computador.
O conjunto de funcionalidades do Quadro de Avisos era pequeno e continha funes para criar,
alterar, remover ou ler um aviso. Alm disso, ele possua dois espaos, um pblico e outro privativo
da comunidade. O espao pblico estaria aberto ao pblico em geral, e no qual s se podia ler os
avisos classificados como pblicos. No espao privativo o membro tinha acesso a todos os avisos
pblicos e mais aqueles privativos relacionados com o trabalho em que estava envolvido na ASCR.
Alm disso, para facilitar o uso da aplicao decidiu-se oferecer mecanismos de explicao e ajuda
ostensivos aos usurios. Quando acionados, estes mecanismos apresentavam uma ajuda em funo
do contexto em que o usurio se encontrava, de forma simples e direta. Caso desejasse, o usurio
poderia se aprofundar mais nas explicaes. Como avaliao do projeto foi feita uma inspeo
informal e um teste em laboratrio utilizando o prottipo proposto do quadro de avisos. A partir dos
problemas identificados nesta avaliao foi projetada uma nova interface para o Quadro de Avisos.
6.3.1 Avaliao Heurstica
O mtodo de avaliao heurstica um mtodo analtico que visa identificar problemas
de usabilidade conforme um conjunto de heursticas ou diretrizes (guidelines) (Nielsen,
1994). Ele se baseia em melhores prticas definidas por profissionais experientes e
especialistas em IHC, ao longo de diversos anos de trabalho nesta rea.
Este mtodo no envolve usurios, e deve ser realizado por avaliadores
especialistas. Em geral, recomenda-se que 3 a 5 especialistas realizem uma avaliao
heurstica. Este mtodo bastante rpido, e de menor custo que a maior parte dos
mtodos de avaliao amplamente difundidos.
Como em todo mtodo de avaliao, a avaliao heurstica envolve uma fase de
preparao, na qual se definem:
proposta de design (papel ou prottipo)
hipteses sobre os usurios (opcional)
cenrio de tarefas (opcional)
A avaliao deve ser realizada de acordo com o seguinte procedimento:
1. sesses curtas (1 a 2 horas) de avaliao individual, onde cada especialista...
julga a conformidade da interface com um determinado conjunto de
princpios (heursticas) de usabilidade
anota os problemas encontrados e sua localizao
julga a gravidade destes problemas
gera um relatrio individual com o resultado de sua avaliao e comentrios
adicionais
importante que estas sesses sejam individuais, para que um avaliador no
seja influenciado pela opinio de outros. Durante cada sesso de avaliao, o
avaliador percorre a interface diversas vezes, inspecionando os diversos
elementos de interface e comparando-os com a lista de heursticas de
usabilidade.
2. consolidao da avaliao dos especialistas
novo julgamento sobre o conjunto global dos problemas encontrados
relatrio unificado de problemas de usabilidade
Nesta etapa, cada avaliador tem acesso aos relatrios 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 relatrio
unificado e consolidado sobre todos os problemas encontrados.
3. seleo dos problemas que devem ser corrigidos
Esta etapa deve ser realizada junto ao cliente ou ao gerente de projeto. Trata-se
de uma anlise de custo/benefcio das correes aos problemas encontrados na
etapa anterior. Esta anlise deve levar em conta no apenas a gravidade dos
problemas, mas tambm os prazos e o oramento do projeto, bem como a
capacitao da equipe de desenvolvimento.
Nielsen props um conjunto bsico
1
de heursticas (Nielsen, 1993). Cada elemento de
interface (ou conjunto de elementos) deve ser analisado para verificar sua conformidade
com cada uma das seguintes heursticas:
visibilidade do estado do sistema: mantenha os usurios informados sobre o
que est acontecendo, atravs de feedback adequado e no tempo certo.
correspondncia entre o sistema e o mundo real: utilize conceitos,
vocabulrio e processos familiares aos usurios.
controle e liberdade do usurio: fornea alternativas e sadas de emergncia;
possibilidades de undo e redo
consistncia e padronizao: palavras, situaes e aes semelhantes devem
significar conceitos ou operaes semelhantes; caso haja convenes para o
ambiente ou plataforma escolhidos, estas devem ser obedecidas
preveno de erro: tente evitar que o erro acontea, informando o usurio sobre
as conseqncias de suas aes ou, se possvel, impedindo aes que levariam a
uma situao de erro
ajuda aos usurios para reconhecerem, diagnosticarem e se recuperarem de
erros: mensagens de erro em linguagem simples, sem cdigos, indicando
precisamente o problema e sugerindo de forma construtiva um caminho
remediador
reconhecimento em vez de memorizao: torne objetos, aes e opes visveis
e compreensveis
flexibilidade e eficincia de uso: oferea aceleradores e caminhos alternativos
para uma mesma tarefa; permita que os usurios customizem aes freqentes
design esttico e minimalista: evite pores de informao irrelevantes. Cada
unidade extra de informao em um dilogo compete com as unidades de
informao relevantes e reduz sua visibilidade relativa.
ajuda e documentao devem ser fceis de buscar, focadas no domnio e na
tarefa do usurio, e devem listar passos concretos a serem efetuados para atingir
seus objetivos
Para cada problema encontrado, ou seja, para cada heurstica violada, deve-se definir
ainda a localizao do problema, ou seja, onde ele ocorre na interface, e sua gravidade.
Com relao localizao, 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 sistemtica; ou
pode ser algo que no est l, ou seja, precisa ser includo na interface

1
Nielsen afirma que este conjunto pode ser estendido de acordo com caractersticas especficas a um
domnio ou ambiente computacional.
J a gravidade (severidade) do problema calculada, por cada especialista, como uma
combinao dos fatores:
freqncia com que o problema ocorre: um problema comum ou raro?
impacto do problema: Ser fcil ou difcil para os usurios superarem o
problema?
persistncia do problema: um problema que ocorre apenas uma vez e que os
usurios conseguem superar facilmente, ou os usurios sero incomodados pelo
problema repetidas vezes?
A gravidade do problema definida por um valor da seguinte escala:
0 No concordo que isto seja um problema (este valor pode resultar da
avaliao de um especialista sobre um problema apontado por outro especialista)
1 Problema cosmtico: no precisa ser consertado a menos que haja tempo
extra no projeto
2 Problema pequeno: o conserto deste problema desejvel, mas deve receber
baixa prioridade
3 Problema grande: importante de ser consertado; deve receber alta prioridade
4 Catastrfico: imperativo consertar este problema antes do lanamento do
produto
Como produto da avaliao heurstica, os especialistas redigem um relatrio
consolidado. Este relatrio pode conter, por exemplo, os seguintes itens:
problemas esperados (e possveis consertos)
o quo bem o sistema apia as tarefas dos usurios
caminhos de interao primrios (importantes e/ou freqentes)
caminhos de interao alternativos ou pouco utilizados
consistncia
elementos de estilo
recomendaes de projeto
possvel realizar uma avaliao heurstica nas etapas iniciais do ciclo de projeto e
desenvolvimento. Esta avaliao pode ser feita sobre interfaces que ainda no tenham
sido implementadas, representadas em papel.
Quadro 2- Avaliao Heurstica no Projeto Or.
Para avaliao do Quadro de Avisos foi feita a avaliao do mtodo de comunicabilidade (seo
6.4.4). Alm disso, o mtodo de avaliao heurstica foi aplicado informalmente (seo 6.5.3) por
especialistas em IHC que conheciam o projeto, mas no participaram do desenvolvimento do seu
projeto de interao. A Figura 4 apresenta a tela principal do Quadro de Avisos e a seguir o Quadro
3 apresenta alguns dos problemas identificados durante a avaliao heurstica.
Figura 4 Tela principal do Quadro de Avisos do primeiro prottipo do Projeto
Or
Quadro 3 - Problemas identificados na Avaliao Heurstica
Problema: O usurio no conseguir entender que o texto privativo da comunidade lhe d acesso
a um espao com mais funcionalidades do que aquele em que ele se encontra.
Heurstica violada: correspondncia entre o sistema e o mundo real
Explicao: Embora na sede da ASCR tenha alguns espaos que normalmente s so acessveis por
membros da comunidade, o usurio no utiliza a palavra privativo no seu cotidiano e no saber a
que ela se refere.
Gravidade: 4 catastrfico. O usurio no conseguir acessar as funcionalidades que esto
disponveis apenas para membros, como por exemplo ler avisos especficos ao trabalho em que est
envolvido, ou criar um novo aviso.
Problema: O texto Quadro geral no transmite a idia do que est sendo visualizado
Heurstica violada: reconhecimento
Explicao: O que est sendo mostrado na seo denominada Quadro Geral so os avisos do
Quadro de Avisos que foram colocados em destaque
Gravidade: 3 grave. Como os usurios na sua maioria tm pouca experincia com informtica,
pode no ficar claro para eles que os avisos no Quadro geral so aqueles selecionados para estarem
em destaque e podem aparecer tambm em outras sees. Isto pode comprometer o entendimento do
usurio sobre como utilizar o Quadro de Avisos.
Problema: A representao das diversas sees do Quadro de Avisos no est clara
Heurstica violada: correspondncia entre o sistema e o mundo real
Explicao: O Quadro de Avisos foi dividido em vrios setores, possibilitando diferentes
visualizaes deste. No entanto, no mundo real um quadro de avisos no tem visualizaes distintas,
e alm disso na ASCR no existem quadro de avisos especficos aos setores com acesso restrito s
pessoas envolvidas naquele setor.
Gravidade: 4 catastrfico. O usurio pode no conseguir entender que conceitos do que ele
conhece de quadro de avisos podem ser transportados para o sistema, e o que diferente. Ele poder
ter grande dificuldade em entender e utilizar o sistema.
6.3.2 Percurso Cognitivo
O percurso cognitivo um mtodo analtico que avalia uma proposta de projeto de IHC
no contexto de tarefas especficas do usurio (Wharton et al., 1994). Ele visa avaliar
principalmente a facilidade de aprendizado do sistema, em particular pela explorao
dos usurios. A motivao para este tipo de avaliao advm do fato de que muitas
pessoas preferem aprender sobre a funcionalidade de um sistema computacional
enquanto trabalham em suas tarefas tpicas, adquirindo conhecimento sobre novas
caractersticas ou funes apenas quando seu trabalho as requerer.
Neste mtodo, o custo de aprendizado deve ser determinado pelo benefcio
imediato aos seus usurios. Este mtodo investiga principalmente:
a correspondncia entre a conceitualizao de uma tarefa por parte dos usurios
e dos designers
escolha adequada (ou inadequada) de termos, ou seja, o vocabulrio utilizado
feedback adequado (ou inadequado) para as conseqncias de uma ao
A hiptese subjacente a este mtodo que, num bom projeto de interface, as intenes
dos usurios causam a seleo da ao adequada. Caso isto no acontea, so levantadas
hipteses sobre as possveis causas dos problemas, para que sejam estudadas e
propostas solues alternativas.
O percurso cognitivo tambm no envolve usurios. Ele pode ser realizado
individualmente, pelo prprio projetista que est propondo a soluo, ou em grupo. Este
grupo pode incluir: o projetista, a equipe de projeto, pessoal de marketing e de
documentao, alm de especialistas em avaliao de interfaces.
Antes de realizar a avaliao, deve-se passar por uma fase de preparao, na
qual se definem:
hipteses sobre os usurios e sobre o conhecimento que eles tm sobre a tarefa e
sobre a interface proposta
cenrios de tarefas, construdos a partir de uma seleo de tarefas importantes e
de tarefas freqentes
seqncia correta de aes para completar cada tarefa, tal como definida pelo
projetista
proposta de design em papel ou prottipo, ilustrando cada passo e indicando o
estado da interface antes/depois de cada um
O procedimento de execuo da avaliao compreende os seguintes passos:
1. o projetista apresenta uma proposta de design
2. os avaliadores constroem histrias plausveis sobre a interao de um usurio tpico
com a interface, com base nos cenrios de tarefas selecionados
3. os avaliadores simulam a execuo da tarefa, efetuando uma srie de perguntas
sobre cada passo
4. os avaliadores anotam pontos-chave, como:
o que o usurio precisa saber antes de realizar a tarefa
o que o usurio deve aprender ao realizar a tarefa
A cada passo da tarefa, os avaliadores devem se fazer uma srie de perguntas, buscando
descobrir problemas em potencial, ou seja, que poderiam ocorrer durante a interao de
usurios reais com o produto final implementado conforme aquela proposta de design.
A lista a seguir apresenta as perguntas bsicas, assim como perguntas adicionais mais
especficas associadas a cada uma delas:
O usurio tentar atingir a meta correta?
Dada a decomposio de uma tarefa em subtarefas, o usurio saber por
onde comear? Saber qual o prximo passo?
O que o usurio vai tentar fazer a cada momento?
O usurio perceber que a ao correta est disponvel?
Onde est o elemento de interface correspondente ao prximo passo?
Que aes a interface torna disponveis?
O usurio associar o elemento de interface correto meta a ser atingida?
O elemento de interface revela seu propsito e comportamento?
O usurio consegue identificar os elementos de interface?
Se a ao correta tomada, o usurio perceber que progrediu em direo
soluo da tarefa?
Como a interface apresenta o resultado de cada ao?
O resultado apresentado tem correspondncia com o objetivo do usurio?
Considerando-se cada um destes critrios, h algumas solues tpicas para as falhas
mais comuns:
O usurio tentar atingir a meta correta? Se a interface falhar neste ponto, h
pelo menos trs solues possveis:
eliminar a ao, combinando-a com outra ou deixando o sistema assumi-la;
fornecer uma instruo ou indicao de que a ao precisa ser realizada;
alguma parte da tarefa pode ser modificada para que o usurio entenda a
necessidade desta ao.
O usurio perceber que a ao correta est disponvel? Se o usurio possui os
objetivos certos mas no sabe que a ao est disponvel na interface, a soluo
pode ser:
atribuir um operador mais bvio para a ao. Isto geralmente requer um item
de menu ou instruo, em vez de combinao de teclas;
atribuir ao um controle menos visvel mas como parte de uma estrutura
em que possa ser facilmente encontrado, como um submenu.
O usurio associar o elemento de interface correto meta a ser atingida?
Para corrigir este tipo de falha, o designer precisa conhecer os usurios e ter uma
idia sobre como eles descrevero suas tarefas. Com esta informao, o designer
poder fornecer rtulos e descries de aes que incluam palavras que os usurios
utilizariam para descrever estas tarefas. Tambm pode ser necessrio modificar os
rtulos de outros controles, para que os usurios possam decidir sobre qual o
correto.
Se a ao correta tomada, o usurio perceber que progrediu em direo
soluo da tarefa?
Algum feedback melhor do que nenhum. O feedback que indica o que ocorreu
melhor do que aquele que indica que algo ocorreu. Alm disto, o feedback ser mais
til quando for composto de termos ou smbolos relacionados descrio do usurio
para aquela tarefa. Observe que, em situaes simples, a interface pode prescindir
de feedback e chamar logo a prxima ao lgica
Quadro 4 - Percurso Cognitivo no Projeto Or.
O mtodo de Percurso Cognitivo no foi utilizado na avaliao do Quadro de Avisos do Projeto
Or. No entanto, abaixo ilustramos como uma tarefa tpica, como criar aviso, poderia ter sido
avaliada atravs deste mtodo. A seguir mostramos o exemplo do material que seria gerado na etapa
de preparao para a avaliao:
Usurios tpicos: Membros da comunidade ASCR com pouca familiaridade no uso de
computadores, e muitas vezes com uma resistncia ao seu uso
Tarefa: Incluir um aviso no quadro de avisos
Cenrio: O usurio deseja criar um aviso no quadro de avisos para os voluntrios da recreao.
Seqncia correta de aes:
1. Entrar no espao privativo do Quadro de Avisos
2. Entrar login e senha
3. Selecionar a opo Criar Avisos
4. Preencher campos (pelo menos os obrigatrios)
5. Confirmar criao do aviso
A Figura 5 mostra os campos a serem preenchidos na tela de criar aviso e o Quadro 5 mostra
algumas das perguntas e respostas plausveis que poderiam ter sido geradas pelo especialista.
Figura 5 - Campos a serem preenchidos na tela de criar aviso do Projeto Or
Quadro 5 - Exemplos de possveis perguntas e respostas para uma avaliao
do Quadro de Avisos utilizando o Percurso Cognitivo
1. Entrar no espao privativo do Quadro de Avisos
Usurios sabero que devem entrar no espao privativo?
No, os usurios no entendero que esto em um espao pblico em que tm disponveis
algumas funcionalidades e podem passar para um privativo onde tero acesso a mais
opes. Logo, eles vo procurar uma opo para criar aviso no espao pblico.
Usurios sabero que devem selecionar a opo privativo da comunidade?
No, os usurios no esto familiarizados com o termo privativo da comunidade. No
ambiente fsico o que privativo a um grupo, fica localizado na sala onde aquele grupo
exerce suas funes, mas o termo privativo no utilizado.
2. Entrar login e senha
Usurio vai entender o que entrar quando aparecerem os campos login e senha?
Sim, apesar de login ser um termo computacional, ele vem sendo bem difundido e pessoas
em outros contextos utlizam o termo. Embora os usurios utilizem pouco o computador,
vrios deles tem acesso Internet, onde se utiliza os conceitos de login e senha.
Ao se logar o usurio vai perceber que est no espao privativo?
No. O feedback de entrada no espao privativo muito sutil, apenas mudanas nos
setores de avisos disponveis e novas opes de aes. O aspecto visual o mesmo do
espao pblico, dificultando a percepo da mudana de espao.
3. Selecionar a opo Criar Avisos
O usurio vai entender que a opo desejada Criar aviso?
Sim. O conjunto de opes pequeno, a opo Criar aviso est bem visvel e o texto
da opo est claro.
4. Preencher campos (pelo menos os obrigatrios)
O usurio saber preencher os campos necessrios para criar um aviso?
No. O usurio pode no entender o campo chamada no qual dever entrar o equivalente
a um resumo ou indicador do assunto ao qual se refere o aviso, e como um campo
opcional vrios usurios podem deix-lo em branco. A opo incluir no quadro
geral, no deixa claro que isto significa colocar o aviso tambm como destaque no
espao pblico e o usurio pode no entender quem ter acesso ao aviso sendo criado. O
campo prazo de validade tambm no deixa claro que se refere a data no qual o
aviso ser retirado do quadro de avisos.
5. Confirmar criao do aviso
O usurio saber que deve confirmar a ao de criao para que o aviso seja criado?
Sim. Mesmo um usurio com pouca experincia em uso de computadores est acostumado
a confirmar suas aes em ambientes como caixas eletrnicos.
O usurio reconhecer o boto incluir aviso para que o aviso seja criado?
Sim. O texto deixa claro que o boto inlcuir o aviso no Quadro de Avisos.
6.4. Mtodos de Avaliao Empricos
Nesta seo sero apresentados alguns dos principais mtodos de avaliao empricos,
ou seja, aqueles nos quais se envolve usurios para a coleta de dados, que so
posteriormente analisados pelo especialista para identificar os problemas da interface.
Em particular sero enfatizados os mtodos de avaliao de interfaces feitos em
ambientes controlados.
Em testes com usurios em laboratrio o avaliador tem um maior controle sobre
o ambiente e sobre as atividades do usurio. Assim, o avaliador consegue identificar
problemas da interface que dificultam a interao, sem se preocupar com fatores
externos, tais como o usurio sendo interrompido durante o uso do sistema. A principal
desvantagem de testes em laboratrios justamente fazer a avaliao fora do contexto
em que a aplicao ser utilizada de fato. Desta forma no se consegue identificar
atravs de testes em laboratrio fatores do ambiente que podem impactar uso do
sistema.
Existem vrios mtodos que permitem se fazer avaliao de um sistema com
usurio no laboratrio. Enquanto eles tm vrias caractersticas em comum, como parte
da preparao e execuo dos testes, eles variam no tipo de dado a ser coletado ou na
anlise a ser feita deste. Os testes de usabilidade, buscam avaliar a qualidade de
usabilidade presente em um software, avaliando principalmente o desempenho do
usurio com o software. Os testes de comunicabilidade apreciam a qualidade de
comunicabilidade, e buscam identificar os pontos do sistema que no foram bem
comunicados pelo designer ao usurio. Os testes que fazem uso de protocolos verbais
buscam apreciar a usabilidade de um software, mas se diferenciam do teste de
usabilidade por tentarem explicitar o processo mental sendo vivenciado pelo usurio. A
seguir, sero apresentadas as etapas de preparao de testes, e cada um destes mtodos
de teste em laboratrio. Na ltima seo discutimos brevemente avaliao emprica feita
no ambiente do usurio. Para cada etapa do processo de avaliao descrito ser
apresentado a avaliao feita na primeira verso do Projeto Or (Quadro 1).
6.4.1 Preparao de Testes em Laboratrio
Testes em laboratrio requerem um planejamento minuncioso para que o avaliador
tenha de fato controle sobre as condies de teste. Isto envolve se certificar de que as
condies de teste so as mesmas para todos os participantes, e de que o teste sendo
executado permite a avaliao dos critrios desejados. Assim durante a etapa de
preparao de teste o avaliador deve determinar o objetivo da avaliao e, em funo
deste, os critrios relevantes e pontos crticos, selecionar as tarefas, selecionar usurios
participantes, gerar o material para o teste e executar o teste-piloto.
Determinao do objetivo da avaliao
O objetivo da avaliao pode ser to geral quanto verificar se o software usvel ou
bem compreendido. No entanto, para se preparar o teste o avaliador deve definir os
critrios relevantes ou prioritrios para que se verifique o objetivo desejado e pontos
crticos da aplicao a serem testados. Os critrios prioritrios normalmente so
definidos durante a etapa de design, como sendo aspectos da qualidade de uso que se
pretende que o sistema possua. Por exemplo, pode-se priorizar o desempenho e se
desejar que o usurio execute a tarefa em um determinado perodo de tempo, ou que os
usurios estejam satisfeitos com o sistema. Os pontos crticos do design normalmente
esto relacionados com decises de design, com tarefas que sejam estratgicas para o
uso da aplicao, ou ainda com tarefas de uso muito freqente. Decises de design a
serem testadas podem incluir estruturas de acesso, hierarquia e caminhos de navegao
definidos na interface. Tarefas a serem consideradas estratgicas normalmente so
aquelas essenciais para o sucesso da empresa ou do prprio usurio. Finalmente, as
tarefas de uso freqente so aquelas que se prev que sero utilizadas comumente pelo
usurio durante sua interao com o software.
Quadro 6 - Objetivo da avaliao do Projeto Or
Como um dos objetivos do design era que o quadro de avisos fosse simples para pessoas leigas que
usam o computador eventualmente fossem capazes de us-lo bem, o principal objetivo da avaliao
era observar se os usurios conseguiam compreender o que podiam fazer e como usar o Quadro de
Avisos. Em funo do objetivo da avaliao, definiu-se que a qualidade de uso a ser avaliada seria a
comunicabilidade, e logo o planejamento para um teste de comunicabilidade foi feito.
Assim, os pontos crticos a serem avaliados foram identificados como:
O usurio consegue entender e executar as tarefas bsicas de achar e ler um aviso?
O usurio consegue utilizar o sistema de ajuda oferecido? Este til para ele?
O usurio consegue entender a diferena entre os espaos pblico e privativo? Consegue passar do
pblico para o privativo?
Seleo de tarefas
Uma vez definidos os objetivos da avaliao, o avaliador deve determinar as tarefas a
serem executadas durante o teste, que podero fornecer indicadores sobre estes
objetivos. As tarefas devem ser tpicas, no sentido de serem tarefas to realistas quanto
se possa prever sobre o uso a ser feito do sistema. No caso de testes de usabilidade, o
avaliador deve definir tambm as medidas a serem observadas para cada aspecto que se
deseja apreciar. Por exemplo, para se avaliar o critrio de produtividade, possivelmente
ser desejvel medir o tempo gasto no desempenho de cada tarefa, e o nmero de erros
cometidos por tarefa.
Na definio das tarefas, o avaliador deve tomar cuidado com o tempo previsto
para cada tarefa e para o teste. Normalmente o tempo de execuo de uma tarefa deveria
ser de no mximo 20 minutos, e deveria se manter o tempo de teste inferior a uma hora
para no ser muito cansativo para o participante (Preece et al., 2002). Alm disso, deve-
se pensar no tempo necessrio para a anlise do material coletado durante o teste.
Quadro 7 - Seleo das tarefas para o Projeto Or
Foram selecionadas 5 tarefas que permitiam aos observadores apreciar a compreenso que os
usurios tinham sobre os pontos crticos identificados. As tarefas selecionadas foram:
Tarefa 1: Encontrar um aviso no espao pblico
Tarefa 2: Identificar que um aviso deveria estar no espao privativo, entrar no espao
privativo e encontr-lo
Tarefa 3: Criar um aviso
Tarefa 4: Alterar um aviso
Tarefa 5: Utilizar o mecanismo de busca para encontrar um aviso, identificar quem teria
acesso a ele.
Seleo de usurios participantes
O avaliador deve definir o perfil dos usurios a participarem do teste. Normalmente, o
objetivo ter usurios que representem usurios tpicos do sistema. O usurio tpico
depende do tipo de sistema sendo desenvolvido e seu pblico alvo. Por exemplo,
usurios tpicos de um software educacional podem ser crianas, de um software de
apoio a 3
a
. idade podem ser idosos, ou de um sistema de programao podem ser
usurios experientes. Normalmente o pblico alvo do sistema definido no incio do
ciclo de design. Para a avaliao deve-se identificar participantes que correspondam ao
perfil desejado, o que normalmente pode ser feito atravs de um questionrio breve. Em
alguns casos a aplicao destinada a grupos de usurios de diferentes perfis. Nestes
casos, se recomenda que testes sejam feitos com participantes de cada perfil
identificado.
Para a seleo dos participantes recomendado que se tenha um nmero
equivalente de homens e mulheres no conjunto de participantes do teste, a no ser que o
sexo do participante seja uma das caractersticas do perfil desejado. Alm disso, uma
caracterstica relevante de se considerar na seleo a experincia dos participantes
com o sistema (se este j estiver sendo utilizado), ou com outros similares.
Alm de definir quais usurios poderiam participar do teste, o avaliador deve
definir quantos usurios faro o teste. Vale ressaltar que o objetivo destes testes no
chegar a resultados estatisticamente vlidos, mas se ter indicaes de como melhorar a
qualidade de uso da interface. Tipicamente em testes com usurios se envolve de 5 a 12
usurios (Dumas e Redish, 1999). Nielsen por sua vez recomenda que 5 usurios
participem da avaliao (Nielsen, 2000). Segundo ele, estudos mostram que este
nmero apresenta a melhor relao custo-benefcio. Isto porque o teste com um usurio
capaz de identificar aproximadamente 30% dos problemas da aplicao. Cada novo
usurio, encontra 30% de problemas, destes uma parte representa novos problemas,
enquanto a outra representa problemas encontrados pelos usurios anteriores. Desta
forma, a cada novo teste se reduz o nmero de novos problemas, e se aumenta o nmero
de problemas j encontrados. Segundo Nielsen com 5 usurios se encontra
aproximadamente 85% dos problemas da aplicao e o benefcio dos novos erros
encontrados vale o custo do teste executado. A Figura 6 abaixo ilustra o custo e
benefcio dos testes em funo dos nmeros de problemas encontrados e do nmero de
testes executados. Nos casos em que a aplicao se destina a usurios de perfis distintos,
Nielsen recomenda que para cada perfil identificado se faa a avaliao com 3 (trs)
usurios. Isto porque muitas vezes usurios de perfis distintos identificam os mesmos
problemas.
Figura 6 - Custo x benefcio de execuo de testes.
(Fonte: Nielsen, J.: Test with 5 Users, Alertbox, 2000)
Nielsen ressalta ainda que, embora um teste com 15 usurios permita
potencialmente que se encontre todos os problemas de uma aplicao (ver Figura 6),
vale mais a pena fazer trs testes com 5 usurios do que um com 15. Isto porque com
um teste com 15 usurios, todos os problemas podero ser encontrados, mas a soluo a
ser desenvolvida aps o teste no ser avaliada e pode conter novos problemas. Em
contrapartida trs testes com 5 usurios, permitir que se encontre potencialmente 85%
dos problemas da aplicao no primeiro teste. A soluo desenvolvida ser tambm
avaliada, e 85% dos problemas desta nova soluo, sejam eles inseridos pela nova
soluo, sejam eles j existentes na verso anterior, mas no detectados pelo teste
anterior, sero descobertos. Assim, incrementalmente se caminha para uma melhor
soluo final.
Outro fator a ser considerado na seleo de usurios e preparao do teste a
motivao do usurio. Normalmente, quando o participante um potencial usurio e
no tem resistncia em relao nova tecnologia, ele tem interesse em participar do
teste e contribuir para a melhoria da aplicao. Quando o teste envolve representantes
da sociedade, com freqncia se oferece alguma compensao financeira para a
participao no teste.
Quadro 8 - Seleo dos participantes para o Projeto Or
Para participao dos testes foram selecionados 6 usurios que correspondiam aos perfis do pblico
alvo definidos durante a etapa de design. Como o grupo de potenciais participantes nesta etapa no
era muito extenso, a seleo foi feita a pela equipe de design a partir de uma reunio com os
parceiros do Projeto Or na ASCR em que se discutiu os perfis de participante desejado para o teste.
O grupo de usurios contava com funcionrios e voluntrios da ASCR, 5 mulheres e apenas 1
homem (note-se que na comunidade ASCR tem um nmero muito maior de mulheres envolvidas
que homens), que j utilizavam o computador ou na ASCR ou particularmente e com a faixa etria
variando de 30 e poucos a 60 e poucos anos.
Gerao do material para o teste
Aps definidos objetivos, tarefas e perfis desejados dos participantes do teste, deve-se
ento gerar o material a ser utilizado durante o teste. Este material inclui o questionrio
para seleo de participantes do teste, scripts de apresentao e explicao do processo
de teste aos usurios, formulrios de consentimento do usurio, texto de descrio da
tarefa e roteiros de entrevista ou questionrios.
O questionrio para seleo de participantes identifica as caractersticas
relevantes do perfil de usurio tpico, e permite que candidatos sejam comparados ao
perfil desejado e selecionados. Os scripts de apresentao e explicao do processo e
teste aos usurios tm por objetivo garantir que todos os usurios sero tratados da
mesma forma e recebero as mesmas informaes. Para se executar testes com o usurio
deve-se ter o consentimento formal deste (como ser discutido na seo 6.4.2). Para
isso, deve-se ter um formulrio de consentimento a ser preenchido e assinado antes do
teste.
As tarefas a serem executadas so tambm apresentadas aos usurios por escrito,
na forma de um cenrio, ou seja, de uma descrio de uma situao plausvel e
contextualizada de uso. Este cenrio tem por objetivo permitir ao usurio se identificar
com a situao e tomar a motivao apresentada como prpria. Alm disso, a
apresentao da tarefa de forma uniforme a todos os participantes garante que todos
tero as mesmas informaes ao executar a tarefa.
Com freqncia os testes so seguidos de entrevistas ou questionrios que
buscam entender melhor as aes do usurio ou avaliar sua percepo e satisfao com
a aplicao. Nestes casos, os roteiros de entrevista ou questionrios a serem
apresentados aos participantes tambm devem ser gerados previamente.
Quadro 9 - Gerao de material para o Projeto Or
Para o teste de comunicabilidade do Quadro de Avisos foram gerados os seguintes materiais:
Script de explicao sobre o projeto:
No foi gerado um script para explicao do teste e apresentao do laboratrio. Esta deciso foi
tomada, por ter a equipe de avaliao sido avisada de que os membros da comunidade, voluntrios
para participar do teste, estavam muito nervosos. Desta forma, com o objetivo de deix-los mais
vontade, optou-se por receb-los de forma mais informal explicando para cada um o objetivo e
procedimento do teste, reforando o fato de que era o Quadro de Avisos que estava sendo testado, e
mostrando-lhes o ambiente.
Script de apresentao do Quadro de Avisos e a sua utilidade dentro do contexto da ASCR:
O Quadro de Avisos do Renascer tem por objetivo permitir a melhor divulgao das informaes
e necessidades do Renascer, tanto para os voluntrios quanto para o pblico em geral. Alm de
acesso a informaes gerais e pblicas, os voluntrios tm acesso a informaes privativas,
relacionadas com o trabalho que executam no Renascer. Para ter acesso a estas informaes os
voluntrios devem: (1) estar cadastrados como usurios do Quadro de Avisos; (2) entrar na
pgina deste sistema na Internet; e (3) optar por acesso ao espao privativo da comunidade, para o
qu devem informar seu login e senha na pgina de acesso. Para as atividades de hoje seu login
teste e sua senha senha. Se voc tiver alguma dvida sobre como usar o Quadro de Avisos,
voc pode acessar tanto as informaes de ajuda disponveis localmente atravs do ponto de
interrogao azul, quanto atravs da ajuda geral do sistema.
Documento de consentimento:
O documento garantia ao usurio o seu anonimato, explicava como seriam utilizados os dados
coletados durante o teste, reforava que ele poderia interromper o teste a qualquer momento caso
desejasse e perguntava-lhe se tinha alguma condio a acrescentar para a realizao dos testes e
utilizao dos dados. Aps preenchido este documento era assinado pelo participante do teste e pelo
avaliador.
Texto de descrio da tarefa:
Cada tarefa foi descrita em um cenrio para permitir ao usurio se contextualizar e entender o
que deveria fazer. Abaixo mostramos o exemplo de uma das tarefas utilizadas no teste do
Quadro de Avisos:
Atividade 2:
Voc voluntrio do Renascer e trabalha tanto no atendimento, quanto na recreao. A salinha
de recreao do hospital no momento est fechada, mas na reunio mensal dos voluntrios no
Parque Lage voc soube que ela deve ser reaberta logo. Voc soube tambm que antes de todos
poderem voltar a trabalhar haver uma reunio com os voluntrios da recreao para a
apresentao das novas regras de uso da salinha. Porm, outro dia lhe disseram que a reunio j
foi marcada e que seu horrio/data/local esto disponveis no Quadro de Avisos. Voc ento vai
entrar no sistema para descobrir quando e onde ser esta reunio.
Formulrio de acompanhamento de teste:
Foi feito um formulrio para os observadores do teste. O cabealho do teste possuia a identificao
do participante atravs que deveria ser preenchido com o nmero atribudo a ele e a data do teste, a
seguir continha um espao para anotar as suas observaes relativas ao teste e outro para anotar
perguntas a serem feitas durante a entrevista sobre as aes observadas sobre as quais gostariam de
uma explicao do participante.
Roteiro para entrevista:
Foi feito um roteiro simples que incluia perguntas como Voc achou alguma atividade difcil? e
O que gostou mais/menos no Quadro de Avisos?, alm das perguntas que surgiam a partir da
observao. Para cada pergunta o entrevistador poderia entrar na questo mais profundamente ou
no, conforme julgasse apropriado.
Execuo do teste piloto
Uma vez estando pronto o material para o teste, fundamental que se faa testes-piloto
para se avaliar a qualidade do material gerado. O que se procura observar durante o
teste-piloto se os participantes conseguiram entender corretamente todo o material
apresentado, se o tempo de execuo do teste est dentro do previsto e vivel, se
atravs das tarefas propostas se consegue obter as medidas especificadas e avaliar o
critrio desejado. Alm disso, pode-se aproveitar o teste-piloto para se praticar a
habilidade do avaliador para deixar os participantes vontade para o teste e os
entrevistar. Desta forma se garante que os dados coletados durante o teste permitiro de
fato avaliar os aspectos desejados da aplicao, e no causaro perda de dados ou no
pior caso, invalidao do teste como um todo.
Idealmente, se deve executar testes-piloto at que no se identifique mas
nenhuma necessidade de alterao do material. Caso isto no seja possvel, deve-se
garantir no mnimo a execuo de um teste-piloto. Para participar do teste-piloto o ideal
seria poder contar com potenciais usurios com o perfil desejado. No entanto, se o custo
de envolver usurios for muito alto, ou o acesso a eles for limitado, pode-se executar os
testes-piloto com colegas ou pedir-lhes para comentar o material.
Quadro 10 - Teste piloto para Projeto Or
O material do teste preparado pela equipe de avaliao foi revisto e foi comentado por toda equipe
de design. Uma vez feitas as alteraes necessrias, foi feito um teste piloto com um voluntrio no
associado ASCR. Embora este voluntrio no fosse membro da comunidade Renascer, ele tinha
vrias caractersticas em comum com o perfil dos membros da comunidade desejado para o teste.
Em funo do teste piloto, mais uma vez o material foi ajustado para o teste com os usurios.
6.4.2 Execuo dos Testes em Laboratrio
A execuo dos testes exige a escolha de um ambiente adequado para os testes, a
ateno a questes ticas envolvidas no processo de teste com participao de outros
seres humanos, e ainda deixar os usurios o mais vontade possvel para que possam
agir to naturalmente quanto consigam neste ambiente controlado e artificial.
Ambientes de teste
Os testes normalmente so executados em laboratrios de testes com usurios como por
exemplo o mostrado na Figura 7. Os laboratrios costumam possuir 2 salas, uma para a
execuo do teste (Figura 7a) e outra para observao do teste (Figura 7b). As salas so
separadas por um vidro espelhado, de forma que o participante no enxergue quem se
encontra do outro lado do vidro, mas os observadores possam ver o participante e suas
aes. A sala de teste costuma ser equipada com um computador e espao para o
participante e um avaliador. A sala de observao costuma ter um monitor que replica o
que est sendo visto no monitor do usurio, um outro computador para anotaes. Alm
disso, cmeras de vdeo e gravadores podem estar presentes em uma sala ou na outra, ou
em ambas dependendo do teste a ser executado.

(a) Sala de teste: participante e um
avaliador na sala.
b) Sala de observao: avaliador
observando por trs do vidro espelhado.
Figura 7 Laboratrio de comunicabilidade do Grupo de Pesquisa em
Engenharia Semitica (SERG), na PUC-Rio.
Em alguns casos quando no se tem um laboratrio disponvel pode-se
considerar o uso de equipamento mvel (como cmeras de vdeo, ou sistemas de
registro de interao) e se utilizar uma sala disponvel como laboratrio. Esta opo
tambm pode ser considerada para levar o laboratrio at o usurio, quando este no
pode comparecer ao laboratrio disponvel.
Quadro 11 - Ambiente de teste para Projeto Or
Os testes foram realizados no laboratrio. Um avaliador explicava para o participante o teste,
verificava se tinha alguma dvida em relao ao material que lhe era apresentado e ficava dentro da
sala de teste junto com o participante para dar acesso a algum da equipe durante o teste, caso
alguma dvida surgisse. O avaliador ficava no fundo da sala para interferir o mnimo possvel
(como mostrado na Figura 7a) e fazendo anotaes. Na sala de observao (Figura 7b) ficaram 2
outros avaliadores observando o teste e fazendo anotaes. Alm disso, a interao de cada
participante foi gravada para anlise posterior.
Questes ticas
Na execuo de testes que envolvem outros seres humanos o avaliador deve estar atento
s questes ticas envolvidas e a como lidar com elas. Alguns governos, como o dos
EUA
2
, regulamentam o processo de teste e tm exigncias formais e burocrticas sobre

2
No Brasil esta regulamentao existe na forma de uma resoluo do Conselho Nacional da Sade e se
aplica a todos os profissionais da rea de sade (inclusive psiclogos) que realizam pesquisas com seres
humanos. de se esperar que em breve haja regulamentaes semelhantes para profissionais de outras
reas que fazem pesquisas e trabalhos que afetem seres humanos em situaes como a de testes de
produtos, at porque estes profissionais muitas vezes tm bem menos treinamento para lidar com estas
situaes que profissionais da rea de sade. Disponvel online em:
http://conselho.saude.gov.br/biblioteca/livro.htm.
sua execuo. Para garantir a proteo aos usurios e o atendimento a exigncias ticas
as seguintes diretrizes foram propostas (Preece et al., 2002):
Explicar aos participantes os objetivos do estudo sendo feito e exatamente como
dever ser a participao deles. Deve-se deixar claro o processo de teste, o
tempo aproximado do teste, o tipo de dado sendo coletado e ainda como os
dados sero analisados.
Deixar claro as expectativas de anonimato dos usurios, deixando claro que
dados particulares identificados durante o teste no sero divulgados.
Certificar-se de que os usurios entendem que a qualquer momento podem
interromper o teste, caso desejem.
Sempre que trechos de depoimentos dos usurios forem utilizados eles devem
ser annimos e deve-se retirar descries ou trechos que permitam a
identificao do usurio. Nestes casos, deve-se requisitar autorizao prvia do
usurio e de preferncia mostrar-lhe o relato a ser divulgado.
O usurio deve consentir por escrito na execuo do teste e o documento de
consentimento deve especificar as condies acordadas do teste e deve ser assinado
tanto pelo participante do teste, quanto pelo avaliador. Alm disso, o formulrio deve
permitir ao usurio acrescentar novas condies ao acordo, caso o deseje.
Deixando o usurio vontade
Muitas vezes, as pessoas em uma situao de teste se sentem avaliadas e ficam
nervosas. Principalmente quando os testes so feitos em um ambiente controlado e
artificial. Antes de iniciar o teste importante deixar o participante o mais vontade
possvel. Para isso, deve-se assegurar ao usurio que a aplicao est sendo testada e
no ele, e lembrar-lhe que ele pode interromper o teste a qualquer momento. Alm
disso, tarefas de explorao do software e tarefas fceis no incio do teste ajudam o
usurio a se sentir mais confiante. Da mesma forma, uma tarefa simples no final pode
ajudar o usurio a se sentir bem em relao ao seu desempenho.
Quadro 12 - Deixando o usurio vontade no Projeto Or
O avaliador recebeu cada um dos participantes e inicialmente conversou amenidades e lhes ofereceu
caf com biscoito com o objetivo de deix-los mais vontade. A explicao dos objetivos e
processos do teste foram feitos neste ambiente informal. O avaliador enfatizou sempre o fato de o
Quadro de Avisos (e no o usurio) estar sendo testado para que a equipe pudesse melhor-lo antes
de entreg-lo ASCR para ser usado.
Aplicao do teste
Antes de iniciar o teste o avaliador deve ler para os usurios os scripts de apresentao e
explicao. Apesar de o uso de script reforar o sentimento de ambiente artificial, deve-
se esforar para que o usurio fique vontade. Deve-se ento pedir a ele que leia,
preencha e assine o formulrio de consentimento de execuo do teste, que deve
tambm ser assinado pelo avaliador. Algumas vezes se utiliza questionrios para se
conhecer especifidades sobre o usurio. Isto pode ser feito antes ou aps o teste.
D-se ento incio execuo do teste propriamente dito. Primeiramente, se
apresenta o material escrito relativo s tarefas ao participante, pede-o para ler o material
e verifica-se o entendimento do mesmo. O usurio ento inicia a tarefa, com freqncia
pode-se desejar ou necessrio (no caso do teste de comunicabilidade) registrar o uso
atravs do registro de logs, gravao da interao ou do vdeo. Enquanto o usurio
executa a tarefa o(s) observador(es) faz(em) anotaes sem interromper ou interferir
com a concentrao do usurio. O usurio muitas vezes se volta ao observador para
fazer perguntas sobre as dificuldades sendo vivenciadas. As perguntas relacionadas com
o uso da aplicao ou execuo da tarefa no devem ser respondidas, enquanto que
perguntas que no esto relacionadas com o que se quer observar podem ser
respondidas.
Ao fim do teste, costuma-se entrevistar o participante ou lhe pedir para
preencher o questionrio. Quando se tem uma entrevista pode-se ser tirar dvidas sobre
as aes observadas do usurio, ou sobre as motivaes ou expectativas que o levaram a
realiz-las. Alm disso, atravs da entrevista ou questionrio pode-se colher a opinio
pessoal do usurio sobre sua experincia, sua satisfao com o sistema e sugestes.
Anlise dos dados coletados
Note-se que durante o teste diferentes dados so coletados de diferentes formas: registro
de uso, anotaes de observao, preenchimento de questionrios e conduo de
entrevistas. Na etapa de anlise o avaliador deve analisar os dados coletados durante o
teste para todos os usurios e a partir dele gerar o relatrio do teste. O grande volume de
dados normalmente implica um longo tempo necessrio para sua anlise. Em alguns
casos, alguns dos dados coletados no so sempre analisados, mas apenas para
verificao de comportamentos especficos ou para tirar dvida sobre algum outro dado
analisado. Por exemplo, quando se tem observadores fazendo anotaes durante o teste,
a gravao de vdeo pode ser utilizada apenas em pontos onde uma anotao feita no
ficou clara, ou se gostaria de rever a reao do usurio durante um trecho da interao.
Normalmente, quanto mais cedo se consegue fazer a anlise dos dados aps sua coleta
melhor, uma vez que o que se foi observado ou relatado est fresco na memria do
avaliador.
O relatrio costuma descrever os testes feitos, os problemas encontrados, e
dependendo do nvel de informao que o avaliador tenha sobre as intenes e decises
de design, pode conter tambm hipteses sobre as causas dos problemas observados. O
relatrio no necessariamente inclui propostas de redesign para se solucionar os
problemas identificados.
6.4.3 Testes de Usabilidade
O teste de usabilidade executado em laboratrio 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, eficincia de uso e produtividade, satisfao do
usurio, flexibilidade, utilidade e segurana no uso (Nielsen, 1993; Preece et al., 2002).
Quais destes fatores devem ser priorizados deve ser definido no projeto de design.
Atravs do teste procura-se quantificar o desempenho do usurio. Para isso durante a
preparao de testes em laboratrio descrita anteriormente, para cada medida a ser
observada, deve-se definir quais so os limites mnimos aceitveis, os mximos
possveis (em outras palavras, o melhor e pior caso) e tambm o valor almejado para a
medida no projeto. A quantificao do desempenho normalmente envolve a medio do
tempo e de aes de usurios. Apenas a satisfao do usurio se distingue e
normalmente medida atravs da coleta de opinio do usurio e cujos limites mnimos,
mximos e almejados costumam ser definidos em funo da porcentagem de usurios
que se dizem ou no satisfeitos com o software e o seu nvel de satisfao. Alguns
exemplos de medidas comumente utilizadas no teste de usabilidade so tempo gasto
para se executar uma tarefa, nmero de erros executados, porcentagem de usurios a
conseguirem se recuperar de um erro, ou porcentagem de usurios a se dizerem
satisfeitos com a aplicao, ou a preferirem a aplicao a um outro sistema sendo
utilizado.
Na anlise dos dados coletados durante o teste de usabilidade o avaliador
primeiramente classifica os problemas pela sua gravidade (Nielsen, 1998):
Problema catastrfico: impede que o usurio termine sua tarefa
Problema srio: atrapalha a execuo da sua tarefa
Problema cosmtico: atrasa a execuo e/ou irrita usurios
Alm disso, para cada medida observada, ele verifica a distncia para limites mnimos,
mximos e almejados, determinando se o critrio est em um patamar desejvel ou no.
Atravs dos dados o avaliador verifica o cumprimento de metas que tenham sido
previamente definidas durante a etapa de design.
Quadro 13 - Projeto de teste de usabilidade para Projeto Or
Devido grande importncia da introduo de tecnologia neste projeto, e o objetivo de se avaliar
principalmente como a mensagem estava sendo entendida, optou-se por utilizar o Teste de
Comunicabilidade, e no o de Usabilidade, na avaliao do Quadro de Avisos. Aqui apresentamos
quais seriam alguns critrios a serem considerados, e as possveis medidas a serem alcanadas caso
se tivesse decidido por um teste de usabilidade. Os principais critrios seriam:
Facilidade de uso: O usurio consegue utilizar facilmente o Quadro de Avisos? Sem
cometer muitos erros? O sistema de ajuda eficiente no auxlio as dvidas dos usurios?
Produtividade: O usurio consegue criar e encontrar um aviso rapidamente? Ele til para
a comunidade ASCR?
Satisfao: Os usurios ficaram satisfeitos com o Quadro de Avisos?
Com base nestes critrios as tarefas propostas poderiam ser praticamente as mesmas. A Tarefa 5,
possivelmente se limitaria a verificar o uso do mecanismo de busca e no do entendimento de quem
poderia tambm ter acesso aos avisos encontrados. Alm disso, a descrio dos cenrios de
apresentao da tarefa seriam mais diretos em relao ao objetivo da tarefa. Assim a descrio da
Tarefa 2 para o usurio poderia ser por exemplo:
Atividade 2
Voc voluntrio do Renascer e trabalha tanto no atendimento, quanto na recreao. Foi
colocado no Quadro de Avisos um aviso destinado apenas aos voluntrios da recreao sobre a
reunio marcada para reabertura da salinha. Utilizando o Quadro de Avisos descubra o
horrio/data/local desta reunio.
As medidas a serem observadas seriam:
fator mtodo de medio pior caso nvel almejado melhor caso
Facilidade de
uso
Nmero de erros cometidos Mais de 10 erros No mximo 3
erros
Nenhum erro
Facilidade de
uso
Porcentagem de vezes que o
usurio vai ao sistema de
Para cada tarefa vai
pelo menos 1 vez.
Apenas a 1a. vez
que realiza uma
Nunca
ajuda tarefa complexa
Eficincia para
criar aviso
Tempo gasto para criar um
aviso
5 min 40 segundos 20 segundos
(tempo para
digitar
campos)
Eficincia para
encontrar aviso
Tempo gasto para encontrar
um aviso
No encontrar o
aviso
30 segundos 10 segundos
(tempo para
digitar alguns
campos no
mecanismo de
busca)
Utilidade Freqncia de uso Uma vez a cada
trs dias ou menos
freqente
Uma vez ao dia Mais de uma
vez ao dia
Eficincia do
sistema de ajuda
Porcentagem das vezes que
usurio encontrou o que
procura no sistema de ajuda
Nunca Acima de 90%
das vezes
100% das
vezes
Eficincia do
sistema de ajuda
Consegue resolver o
problema com base no
contedo de ajuda
Nunca Acima de 90%
das vezes
100% das
vezes
Avaliao
inicial
Questionrio (subjetivo) Negativa Positivo Muito
positivo
6.4.4 Testes de Comunicabilidade
Testes de comunicabilidade, como os de usabilidade, devem ser executados em
laboratrio. No entanto o seu objetivo avaliar a interface com relao qualidade da
comunicao do designer para os usurios. Para isto, este mtodo simula a comunicao
do usurio para o designer sobre a interface. Isto feito atravs de um pequeno conjunto
de expresses que o usurio potencialmente pode usar para se exprimir em uma situao
onde acontece uma ruptura na sua comunicao com o sistema (de Souza et al., 1999;
Prates et al., 2000b).
No caso de testes de comunicabilidade, a gravao da interao do usurio com
o sistema durante o teste deve ser feita, pois a anlise ser feita principalmente a partir
deste registro. Alm das anotaes do observador durante o teste, as gravaes em
vdeo tambm podem ser feitas para enriquecer os dados, e permitir a verificao da
reao do usurio relativa a algum trecho da interao observado.
A anlise dos dados dividida em 3 passos:
1. Uma etiquetagem, que consiste em assistir s gravaes da interao e
atribuir a expresso apropriada nos momentos de ruptura da interao;
2. Uma interpretao, que consiste em tabular e consolidar a informao
obtida, ou seja, as expresses obtidas, associando-as a classificaes de
problemas de interao ou diretrizes de design; e
3. Um perfil semitico, que consiste em interpretar a tabela resultante do
passo anterior, dentro do quadro terico da Engenharia Semitica (de Souza,
1993; de Souza et al. 2001), em uma tentativa de se reconstruir a meta-
mensagem sendo transmitida pelo designer ao usurio atravs da interface.
A seguir, apresentamos em detalhe cada uma destas etapas.
Etiquetagem
Durante a etapa de etiquetagem, o avaliador
3
assiste as gravaes da interao feitas
durante a coleta de dados. Ao observar uma ruptura da interao o avaliador associa
seqncia de aes problemtica uma das expresses de comunicabilidade. O efeito
desta etiquetagem semelhante ao de um protocolo verbal (seo 6.4.6) reconstrudo
a partir das evidncias de interao. A reconstruo feita pelo avaliador, por meio de
um conjunto de expresses, definido com o objetivo de ser o conjunto mnimo capaz de
caracterizar suficientemente as rupturas de interao que acontecem durante o uso de
uma aplicao. As expresses foram selecionadas com o intuito de serem naturais e
espontneas, e serem manifestaes plausveis por parte de usurios nestas situaes. A
seguir descrevemos o conjunto de expresses, seus significados e algumas aes de
interface que caracterizam cada uma delas.
Cad?
Ocorre quando o usurio sabe a operao que deseja executar mas no a encontra de
imediato na interface. Um sintoma freqente abrir e fechar menus e submenus e passar
com o cursor de mouse sobre botes, inspecionando diversos elementos de interface
sem ativ-los.
E agora?
O usurio no sabe o que fazer e procura descobrir qual o seu prximo passo. Os
sintomas incluem vagar com o cursor do mouse sobre a tela e inspecionar os menus de
forma aleatria ou seqencial.
O que isto?
Ocorre quando o usurio no sabe o que significa um elemento de interface. O principal
sintoma consiste em deixar o cursor do mouse sobre o elemento por alguns instantes,
esperando que uma dica seja apresentada.
Epa!
O usurio realizou uma ao indesejada e, percebendo imediatamente que isto ocorreu,
desfaz a ao. Os sintomas incluem o acionamento imediato do Undo ou o
cancelamento de um quadro de dilogo aberto indevidamente.
Onde estou?
O usurio efetua operaes que so apropriadas para outros contextos, mas no para o
contexto atual (por exemplo, tenta digitar um dado em um campo desabilitado; digita
um comando em um campo de dado ou um dado no campo reservado para comandos).
Um sintoma tpico desfazer a ao incorreta e mudar em seguida para o contexto
desejado.
Assim no d.
O usurio efetuou uma seqncia (longa) de operaes antes de perceber que estava
seguindo um caminho improdutivo. Os sintomas incluem o acionamento de Undo

3
Os autores do mtodo acreditam que esta etapa tambm pudesse ser executada pelos prprios usurios (Prates et al., 2000b), mas
esta hiptese ainda est sob investigao.
repetidas vezes ou o cancelamento de um ou mais quadros de dilogos abertos
indevidamente.
Por que no funciona?
A operao efetuada no produz o resultado esperado, mas o usurio no entende ou
no se conforma com o fato. O sintoma tpico consiste em o usurio repetir a ao.
U, o que houve?
O usurio no percebe ou no entende a resposta dada pelo sistema para a sua ao (ou
o sistema no d resposta alguma). Os sintomas tpicos incluem repetir a ao ou buscar
uma forma alternativa de alcanar o resultado esperado.
Para mim est bom
Ocorre quando o usurio acha equivocadamente que concluiu uma tarefa com sucesso.
O sintoma tpico encerrar a tarefa e indicar na entrevista ou no questionrio ps-teste
que a tarefa foi realizada com sucesso. O observador, no entanto, sabe que se trata de
um engano, provavelmente causado por uma falha de resposta do sistema ou modo de
visualizao inadequado para a tarefa atual.
Desisto.
O usurio no consegue fazer a tarefa e desiste. O sintoma a interrupo prematura da
tarefa. A causa pode ser falta de conhecimento, tempo, pacincia, informao
necessria, etc.
Vai de outro jeito.
O usurio no consegue realizar a tarefa da forma como o projetista gostaria que ele o
fizesse, e resolve seguir outro caminho, geralmente mais longo ou complicado. Cabe ao
avaliador determinar, se possvel junto ao designer, qual a forma preferencial de
execuo da tarefa.
No, obrigado.
O usurio j conhece a soluo preferencial do designer, mas opta explicitamente por
uma outra forma de interao. O sintoma consiste em uma ocorrncia da ao
preferencial seguida de uma ou mais formas alternativas para se alcanar o mesmo
resultado.
Socorro!
O usurio no consegue realizar sua tarefa atravs da explorao da interface. O
sintoma recorrer documentao ou pedir explicao a outra pessoa.
* * *
Para exemplificar suponha que o participante do teste em um determinado momento
pra o seu cursor sobre um elemento da interface com o objetivo de ver a dica relativa
quele elemento. Ao observar esta ao no filme da interao o avaliador associaria a
ela a expresso O que isto?. Ou ao observar que o usurio percorre opes do menu
procura de uma determinada funo, o avaliador ento associaria a esta poro da
interao a expresso Cad?. Assim, pode-se dizer que o processo de etiquetagem
equivale ao avaliador colocar palavras na boca do usurio (o que chamamos acima de
protocolo verbal reconstrudo), uma vez que ele estaria associando seqncia de
aes o que o usurio poderia ter dito. Vale ressaltar que as expresses Para mim est
bom e Vai de outro jeito no poderiam ser ditas pelo usurio durante a interao,
mas apenas pelo avaliador, ou pelo usurio ao rever o seu prprio filme.
A Figura 8 abaixo mostra a seqncia da aes de um usurio durante o teste do
Projeto Or e a anlise feita pelo avaliador usando as expresses de comunicabilidade.
O participante clica em buscar
avisos, ao entrar na pgina de
busca, imediatamente clica no
boto voltar.
Epa!
O participante clica na
barra de rolagem para ver
os avisos e vai passando o
cursor sobre eles,
procurando o desejado.
Cad?
Participante fica em sem saber qual deve ser seu prximo passo. Fica
em dvida entre duas opes, mas acaba no selecionando nenhuma.
E agora?
Participante no sabe o
que fazer e acessa o
sistema de ajuda.
Socorro!
Figura 8 - Seqncia de aes de um usurio no teste do Projeto Or
Interpretao
Nesta etapa o avaliador deve associar as expresses identificadas a classificaes de
problemas de interao ou diretrizes de design. Utilizamos aqui uma classificao
genrica que define os problemas de interao como sendo de navegao, atribuio de
significado, percepo, falha de execuo da tarefa, e incompreenso ou recusa de
affordance
4
. Problemas de falha na execuo da tarefa so os mais graves, uma vez que
o usurio no consegue atingir o objetivo que o levou a usar a aplicao. Os de
navegao se referem queles nos quais os usurios se perdem durante a interao
com o sistema. Os de atribuio de significado, conforme o nome diz, acontecem
quando o usurio no capaz de atribuir um significado (relevante) a signos
5
encontrados na interface. Os de percepo so quando os usurios no conseguem
perceber alguma resposta do sistema ou seu estado corrente. Para a associao de
expresses a problemas o avaliador poderia utilizar outras classificaes de problemas,
como por exemplo as 8 regras de ouro de Shneiderman (1998) ou ainda as heursticas de
Nielsen (1994).
A classificao proposta apresenta duas outras classes de problemas,
incompreenso e recusa de affordance, que normalmente no fazem parte das

4
Termo que se refere s propriedades percebidas e reais de um artefato, em particular as propriedades fundamentais que determinam
como este artefato pode ser utilizado (Norman, 1988).
5 Signo algo que representa alguma coisa para algum (Peirce, 1931). Assim um signo da interface tudo aquilo que tem um
significado para algum, no caso designer, usurio ou avaliador.
classificaes mais populares (e.g as citadas acima). No caso do problema de
incompreenso de affordance, o usurio no consegue entender uma soluo oferecida
pelo designer, e acaba por executar a tarefa desejada de uma forma mais complicada,
que no caracteriza a soluo principal do designer
6
. Finalmente, no caso de recusa de
affordance, o usurio entende a soluo principal oferecida, mas escolhe no utiliz-la e
em seu lugar utilizar outra forma de interao que julga ser melhor. Esta outra forma
pode ter sido prevista, pretendida, ou no, pelo designer.
A Tabela 1 mostra como as expresses podem ser associadas a estas classes de
problemas. Observe que para as expresses Epa!, Onde estou? e Assim no d a
associao a uma classe de problemas no unvoca e deve ser definida de acordo com
o contexto em que foi observada a ruptura.
A partir da tabulao dos problemas encontrados o avaliador pode definir os
pontos crticos da interao e gerar o relatrio da avaliao.
Tabela 1 - Associao entre expresses e classes de problemas
Problemas de Interao
Expresso de
comunicabilidade
Execuo Navegao Atribuio de
significado
Percepo Incompre-
enso de
affordance
Recusa de
affordance
Cad X
E agora? X X X
O que isto? X
Epa! X X
Onde estou? X X X
Assim no d. X X X
Por que no
funciona?
X X
U, o que houve? X X
Para mim est bom X X
No d. X
Vai de outro jeito X
No, obrigado. X
Socorro! X X X

6 Em casos em que o designer no participa do projeto de avaliao para esclarecer a sua soluo principal, esta associao feita
em funo do entendimento do avaliador sobre qual seria a soluo principal oferecida.
Quadro 14 Teste de comunicabilidade interpretao Projeto Or
Os problemas descritos acima vivenciados pelo participante foram identificados como sendo de
Atribuio de Significado, uma vez que a expectativa da equipe de design era que o participante
entendesse que ele no encontrava o aviso, por ele estar disponvel apenas no espao privativo e no
no pblico, e fosse ento para este espao.
Perfil Semitico
A definio do perfil semitico da aplicao deve ser feito por um especialista em
Engenharia Semitica (de Souza, 1993; de Souza et al. 2001). Neste passo o especialista
interpreta a etiquetagem e tabulao feitas nos passos anteriores dentro do quadro
terico da Engenharia Semitica, em uma tentativa de se reconstruir a meta-mensagem
sendo transmitida pelo designer ao usurio atravs da interface. Desta forma, este passo
acrescenta avaliao problemas identificados na linguagem de interface da aplicao,
podendo fazer consideraes sobre possveis premissas de design e conhecimentos
tticos utilizados.
Quadro 15 - Teste de comunicabilidade - perfil semitico - Projeto Or
O designer pretendia que a aplicao fosse simples de usar, e procurou oferecer um apoio amplo aos
usurios pouco conhecedores de tecnologia. Os usurios compreenderam bem para que servia o
Quadro de Avisos, e acharam que ele seria bastante til para a ASCR. No entanto, vrios dos
participantes no conseguiram entender como utilizar o mecanismo de busca e tiveram dificuldades
em entender a distino entre os espaos pblico e privativo. Desta forma, constatou-se que a
soluo do designer no estava adequada para os usurios pretendidos e precisava ser recontada de
uma forma mais simples e direta. O problema parecia ser causado pelas expectativas do designer de
um conhecimento bsico prvio dos participantes. Por exemplo, que os participantes conhecessem
estratgias de soluo comumente utilizadas em tecnologia amplamente divulgadas, como
mecanismos de busca no qual se especifica a busca medida que se fornece um maior nmero de
parmetros, ou o controle de acesso diferenciado a diferentes espaos de uma aplicao. Com base,
neste diagnstico foi proposta uma nova soluo mais explicativa e com o conjunto de aes
possveis mais evidenciada. Alm disso, optou-se por oferecer apenas o espao privativo durante a
etapa de introduo e consolidao da tecnologia.
6.4.5 Testes de Usabilidade x Testes de Comunicabilidade
A maior diferena entre os testes de usabilidade e comunicabilidade est no conceito de
qualidade de uso que eles pretendem apreciar, conforme seus prprios nomes indicam.
Assim, testes de usabilidade pretendem avaliar a soluo do designer, enquanto os de
comunicabilidade buscam avaliar a comunicao sendo feita sobre esta soluo. Para
isso, os testes de usabilidade normalmente coletam dados quantitativos e buscam
informar designers durante o ciclo de desenvolvimento quais critrios no
correspondem ao objetivo almejado para o software. Testes de comunicabilidade, por
sua vez, coletam dados qualitativos e tm por objetivo informar designers sobre pontos
da sua soluo que no esto sendo transmitidos com sucesso aos usurios.
6.4.6 Protocolos Verbais
Os mtodos que envolvem protocolos verbais normalmente so testes executados em
laboratrio, nos quais os participantes explicitam aquilo que esto pensando, medida
que executam as tarefas propostas. A principal vantagem destes mtodos sobre outros
mtodos de teste em laboratrio permitir que o avaliador tenha acesso aos processos
mentais dos participantes descritos por eles mesmos no decorrer da execuo da tarefa.
Desta forma avaliadores podem compreender melhor os comportamentos, sentimentos e
atitudes dos usurios em relao atividade sendo observada.
Um dos principais mtodos de protocolo verbal utilizado o de pensar alto
(think aloud) (Ericsson & Simon, 1985). Neste mtodo o participante executa os testes
individualmente no laboratrio e narra o que est pensando medida que o faz. Se o
participante fica em silncio por um longo perodo 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 interrupo
pode atrapalhar a atividade do participante. A maior desvantagem deste mtodo que o
participante faz duas coisas ao mesmo tempo: executa a tarefa, e narra suas aes e
pensamentos.
Uma forma de amenizar as desvantagens do mtodo de pensar alto colocar
dois participantes juntos para executar a tarefa. Desta forma, os participantes trocam
idias entre si sobre o que fazer, o que significa o que esto vivenciando e seus
sentimentos e atitudes relativos atividade e aplicao. Ao fazerem isso eles
explicitam seus pensamentos e os avaliadores passam a ter acesso ao que esto
pensando. Este mtodo normalmente conhecido por mtodo de co-descoberta.
6.4.7 Avaliao no Ambiente do Usurio
7
Uma outra forma de se fazer avaliaes ao invs de faz-las em um ambiente
controlado e artificial, faz-las no ambiente natural dos usurios onde a aplicao ser
utilizada de fato. Enquanto testes no laboratrio permitem a identificao de problemas
de interface e interao, avaliaes no contexto do usurio normalmente so utilizadas
principalmente para se facilitar a introduo de tecnologia ou avaliar o uso sendo feito
desta no contexto do usurio (Bly, 1997).
Em avaliaes no ambiente do usurio, normalmente a coleta de dados feita
atravs da observao do uso sendo feito da aplicao e conversas com os usurios. Os
dados podem ser armazenados como anotaes, gravaes de udio ou vdeo, ou uma
combinao de formas. Podem ser armazenados tambm artefatos ou quaisquer
indicadores que auxiliem no entendimento de como as pessoas trabalham no seu prprio
ambiente. Normalmente o dado coletado qualitativo e a anlise feita sobre ele
interpretativa.
Existem duas abordagens principais sobre o papel do avaliador quando atuando
no contexto do usurio (Preece et al., 2002). Na primeira abordagem, o avaliador atua
apenas como observador e deve se esforar para registrar os acontecimentos e no
interferir no contexto. Na outra abordagem, o avaliador atua como participante do
contexto e tem por objetivo explorar ao mximo os detalhes envolvidos no contexto e
nas aes que sucedem nele. Neste caso abordagens etnogrficas so apropriadas e
bastante utilizadas.
Independente da abordagem de atuao do avaliador utilizada, com freqncia o
avaliador utiliza-se de esquemas de apoio sua observao. O objetivo destes esquemas

7
Em ingls Field Studies
guiar a observao, e organizar os dados sendo coletados. Um exemplo de esquema
o proposto por Robson (1993):
Espao: Como a disposio fsica do ambiente e como ele est organizado?
Atores: Quais so os nomes e detalhes relevantes das pessoas envolvidas?
Atividades: O que os atores esto fazendo e por qu?
Objetos: Que objetos fsicos, como por exemplo mveis, esto 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 esto tentando atingir?
Sentimentos: Qual o humor do grupo e dos indivduos?
Uma vez feita a avaliao no ambiente do usurio recomenda-se rever as anotaes e
registros to logo quanto possvel (de preferncia antes de passadas 24hs) para que os
dados estejam frescos na memria e para que se possa explorar detalhes e descartar
ambigidades com outros observadores ou com as pessoas sendo observadas. Alm
disso, na preparao para a avaliao, aspectos sociais e de relacionamento com as
pessoas sendo observadas devem ser levados em considerao, tais como de que forma
ganhar a confiana das pessoas envolvidas na observao e como lidar com questes
delicadas.
6.5. Consideraes Finais
Neste captulo foram apresentados alguns dos principais mtodos analticos e empricos
de avaliao da qualidade de uso de usabilidade e comunicabilidade de interfaces. Estes
mtodos foram desenvolvidos para avaliaes de interfaces de sistemas mono-usurio
de propsito geral. Todos os mtodos propem que o domnio da aplicao e o seu
contexto de uso sejam considerados durante a execuo da avaliao, seja pelos
especialistas que inspecionam a interface, seja pelas tarefas a serem propostas aos
usurios. No entanto, nenhum dos mtodos se prope a apreciar aspectos especficos
relacionados ao domnio da aplicao.
Atualmente, com o barateamento da tecnologia e a sua adoo cada vez mais
ampla no cotidiano das pessoas, alguns domnios carecem de mtodos que possam
avaliar interfaces no s sob a tica da interao, mas tambm do objetivo do domnio
propriamente dito. Pesquisas tm sido desenvolvidas para propor extenses em mtodos
existentes ou para apresentar novos mtodos para sistemas de domnio especfico, como
por exemplo o de sistemas educacionais e ambientes de groupware. Alm de domnios,
novas tecnologias muitas vezes trazem consigo novos aspectos de interao que
precisam tambm ser considerados na sua avaliao, como o caso da Web e telefones
celulares.
Alm de domnios especficos trazerem a necessidade de novos mtodos para se
avaliar a usabilidade ou comunicabilidade de um sistema interativo, eles apontam para
outros aspectos de qualidade de uso que so igualmente relevantes e importantes para o
sucesso do sistema (Prates et al., 2001). Nesta seo sero apresentadas brevemente
extenses propostas a alguns dos mtodos discutidos neste captulo para os domnios de
groupware e educao, e para a tecnologia Web. Em seguida sero descritas algumas
outras qualidades de uso que tm sido apontadas como relevantes para diferentes
domnios. Finalmente, termina-se com uma discusso sobre o custo da avaliao no
processo de design.
6.5.1 Outros ambientes a serem avaliados
Groupware
Groupware um termo que se refere a sistemas que tm por objetivo apoiar o trabalho
cooperativo de pessoas trabalhando em grupo. Os sistemas variam nas atividades,
formas de trabalho, e objetivos aos quais oferecem apoio. Em sistemas multi-usurio os
participantes devem interagir no apenas com o software, mas tambm com os demais
participantes, atravs deste software. Desta forma, os aspectos considerados ao se fazer
avaliao de interfaces de sistemas mono-usurio continuam sendo relevantes, mas no
entanto no so suficientes para apreciar todas as dimenses de interao existentes
nestas aplicaes.
Atualmente, no existem mtodos estabelecidos e reconhecidos para avaliao
de interfaces de groupware. Pesquisadores tm apresentado propostas que visam
estender os mtodos reconhecidos para interfaces mono-usurio, para que eles incluam
aspectos relevantes ao trabalho em grupo e comunicao entre membros. Descrevemos
aqui brevemente algumas propostas que estendem os mtodos discutidos neste captulo.
As propostas apresentadas por mtodos analticos tm como principal motivao
o fato de conseguirem ter um baixo custo. Baker e seus colegas (2001) propem uma
extenso avaliao heurstica de Nielsen para groupware. Para isso, eles apresentam 8
novas heursticas que tm por objetivo guiar o especialista na avaliao do apoio
comunicao, colaborao e coordenao oferecida pelo sistema, assim como na
representao das atividades do grupo na interface para cada um dos membros. Existe
tambm uma proposta para se estender o mtodo de percurso cognitivo para grupos
(Pinelle & Gutwin, 2002). Neste caso prope-se que os avaliadores partam de um
modelo de tarefas de grupo, construam cenrios e a partir dos cenrios avaliem as
tarefas envolvidas no cenrio e para cada uma delas faa um conjunto de perguntas que
os possibilite identificar problemas na interface e nas atividades de colaborao. O
mtodo pode ser feito por um avaliador que se coloca no papel dos diversos membros
do grupo, ou por diferentes avaliadores, cada um assumindo um papel.
Muitas vezes os ambientes so avaliados por observao de uso do grupo ou em
avaliaes no ambiente do grupo. No entanto, observar um grupo pode ser complexo
pelo nmero de indivduos a serem observados e as inmeras variaes entre grupos
(Grudin, 1988). A proposta de extenso do mtodo de avaliao de comunicabilidade
(Prates e de Souza, 2002) tem por objetivo identificar os problemas de interao que
podem impactar a comunicao, colaborao ou coordenao do grupo. Para isso, so
propostas novas expresses que descrevam o problema da interao do grupo, alm de
se incluir no mtodo a considerao sobre quem estaria dizendo a expresso para
quem (e.g. um membro do grupo diria para o grupo Quem est aqui?). Foram
propostos tambm novas categorias de problema que podem ocorrer na interao de um
grupo.
Sistemas educacionais
Ambientes educacionais tm por objetivo apoiar o ensino e aprendizado de um
contedo. Os sistemas podem se destinar a oferecer material instrucional queles que
esto fisicamente remotos, ou cujos horrios disponveis no se encaixam em horrios
determinados por estabelecimentos de ensino, ou ainda complementar o ensino sendo
feito em sala de aula. A interface destes sistemas devem permitir no apenas a interao
do usurio com o sistema, mas o aprendizado de um contedo. Desta forma, mtodos de
avaliao para este domnio devem permitir no apenas a apreciao de qualidades de
uso da interface, mas tambm se ela consegue atingir com qualidade seus objetivos
educacionais.
Alguns pesquisadores nesta rea argumentam que para sistemas educacionais, a
simples extenso de mtodos de avaliao de IHC para este domnio no seriam
suficientes (Squires, 1999), e novos mtodos que levam em conta os objetivos
educacionais precisariam ser propostos (Jones et al., 1999). Com o objetivo de integrar
aspectos de usabilidade e aprendizado Preece and Squires (1999) revisam as heursticas
propostas por Nielsen, luz da teoria educacional scio-cognitivista. Como resultado
eles propem um novo conjunto de heursticas para que educadores avaliem software
educacional.
Web
Com a disseminao da Internet, e posteriormente de portais corporativos Intranet,
surgiram novos aspectos de interface e de interao que precisam ser avaliados. Estes
sistemas so tipicamente multi-usurio, e podem ser assncronos ou sncronos.
Extenses aos mtodos de avaliao existentes vm sendo propostas para lidar com este
tipo de tecnologia. Em geral, estas extenses no modificam os procedimentos de
avaliao, mas sim o tipo de informao coletada e analisada.
Com relao aos mtodos de avaliao analticos, j foram propostas extenses
tanto avaliao heurstica como ao percurso cognitivo. No caso de avaliaes
heursticas, o conjunto de heursticas a serem consideradas estendido, como em Lynch
& Palmiter (2002). Eles propem que sejam includas heursticas especficas do
ambiente Web sobre, por exemplo: contexto, organizao e estrutura; temas e objetivos
de pginas e subsites; foco e distrao; marca (branding) e identidade; mecanismos e
estruturas de controle; navegao e busca; e links quebrados.
No caso do percurso cognitivo, foi proposto um novo mtodo, chamado percurso
cognitivo para a Web (Blackmon et al., 2002), cujo objetivo principal avaliar as
atividades de navegao e busca por informao em um website. Este mtodo visa
estimar, de forma objetiva, o grau de semelhana entre descries de objetivos do
usurio e os textos de cabealhos e links de pginas do website avaliado. Para isto,
utiliza tcnicas de aquisio e representao de conhecimento com base em anlise
semnica latente.
Tambm foram propostas extenses aos mtodos empricos de avaliao. No
caso de avaliao quantitativa, so acrescentados critrios como: profundidade na
rvore de navegao, nmero de vezes em que o usurio volta pgina anterior, nmero
de links acionados a partir de uma mesma pgina, entre outros. J no caso de avaliao
qualitativa, pode-se citar uma proposta inspirada no mtodo de avaliao de
comunicabilidade, aplicada fora do contexto da Engenharia Semitica, e
especificamente ao mtodo de projeto hipermdia OOHDM. Este mtodo visa associar
padres de comportamento durante a interao a problemas de projeto (Gell et al.,
2001).
6.5.2 Outras qualidades de uso a serem avaliadas
Neste captulo tratamos apenas de mtodos de avaliao das qualidades de uso de
usabilidade e comunicabilidade. No entanto, existem vrios outros aspectos de
qualidade de uso que tambm deveriam ser considerados ao se avaliar a qualidade de
um sistema interativo. Assim como usabilidade e comunicabilidade, algumas destas
qualidades se aplicam a qualquer software, como aplicabilidade (apresentada na seo
6.1.3) e acessibilidade, enquanto outras so especficas para determinados domnio,
como aprendizado, colaborao, entretenimento e sociabilidade.
Atualmente um outro conceito de qualidade de uso com que desenvolvedores de
sistemas interativos devem se preocupar acessibilidade. Este conceito est relacionado
com se possibilitar acesso ao sistema a indivduos portadores de alguma deficincia
fsica (WAI). Enquanto em alguns sistemas a acessibilidade uma qualidade desejvel,
em outros ela fundamental, como o caso de sistemas do governo que oferecem aos
cidados servios disponveis na Web. Em muitos pases existem leis que garantem o
acesso a cidados com deficincia a sistemas interativos pblicos, fazendo com que
governos coloquem a acessibilidade como uma exigncia no desenvolvimento de seus
sistemas (e.g. ver lei 508 dos EUA (Section 508, 1998)).
Outras qualidades tm se mostrado essenciais em determinados contextos. Em
contextos como ambientes de trabalho colaborativo, no suficiente que a interface de
um sistema tenha boa usabilidade e comunicabilidade, deve-se avaliar tambm a
qualidade da colaborao que membros alcanam atravs do sistema. Em sistemas
multi-usurio que no tem por objetivo apoiar o trabalho de um grupo, mas sim as
atividades de uma comunidade, uma qualidade de uso fundamental a sociabilidade, ou
seja, como o sistema apia os objetivos de uma comunidade, e as influncias e
interaes sociais que ocorrem nesta (Preece, 2000).
Como vimos, para sistemas educacionais fundamental que se mea a
capacidade do sistema de atingir seus objetivos educacionais e fomentar o aprendizado
(Asdi & Daniels, 2000). Da mesma forma, em sistemas de entretenimento (Westerink et
al., 1994), como jogos, o sistema s ter sucesso se ele for capaz de proporcionar
diverso aos usurios.
6.5.3 Custo de etapas de avaliao para o projeto
Como dito no incio deste captulo, infelizmente h muitos gerentes de projeto que
consideram alto o custo de se fazer avaliaes da qualidade de uso dos sistemas
interativos. No entanto, estudos demonstram que o retorno de investimento deste tipo de
avaliao alto (MauroNewMedia, 2002). Entre outros fatores, o estudo da
MauroNewMedia revela que:
Muito mais caro do que o dinheiro gasto para atrair um cliente, o custo de
convenc-lo a voltar por causa de baixa usabilidade ou servio ruim ao cliente
(em uma razo de 1:100).
Gastos com a melhoria do design grfico de um sistema trazem baixssimo
retorno de investimento. Entretanto, a melhoria do comportamento interativo,
principalmente no que diz respeito busca e ao fornecimento de informao,
traz um retorno de investimento da ordem de 1:50 ou at mesmo 1:100.
A complexidade e conseqentemente o custo do desenvolvimento de um sistema
reduzido quando problemas crticos de qualidade de uso so descobertos e
solucionados no incio do processo de desenvolvimento (em uma razo de 1:10).
A qualidade de uso de um sistema determina o volume de chamadas central de
suporte, cujo custo operacional muito alto.
Para mais informaes sobre retorno de investimento de avaliao e projeto de sistemas
interativos com alta qualidade de uso, sugere-se ao leitor visitar a coletnea de recursos
indicados na pgina http://www.rashmisinha.com/useroi.html (ltima visita: maio de
2003).
Para diminuir os custos de avaliao durante o processo de design, muitas vezes
utiliza-se avaliaes informais e rpidas
8
(Preece et al., 2002). Nestas avaliaes, os
designers tm um retorno de usurios ou consultores sobre suas idias para o design.
Este tipo de avaliao pode ser feito em qualquer etapa de design. Por exemplo, no
incio do design pode-se ter uma reunio com os usurios para se discutir as propostas
de solues, ou antes de se implementar o sistema, para se ter um retorno sobre decises
a serem implementadas, como a estrutura do menu em um sistema Web.
Muitas vezes utiliza-se para estas avaliaes os mtodos apresentados neste
captulo, mas se simplifica o mtodo para se conseguir o retorno de forma mais rpida e
barata. Por exemplo, ao invs de se executar a avaliao heurstica com 5 especialistas,
utiliza-se apenas 2, ou ento se faz testes com uma quantidade menor de usurios, de
forma mais informal e simplifica-se a etapa de anlise. Este tipo de avaliao pode
contribuir para o processo de design, mas de forma alguma substitui uma avaliao mais
completa, que produz resultados mais abrangentes e confiveis.
Referncias
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,

8
Em ingls normalmente chamadas de avaliaes Quick and Dirty.
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 Simpsio 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.463469. 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 (IHC1999). 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 5
th
Asia Pacific Computer-Human Interaction Conference. IEEE
Computer Society, 2-9, 1998.
Gell, N.; Schwabe, D.; Barbosa, S.D.J. (2001) Mtodo de Avaliao de Usabilidade
na Web Baseado em Modelo e Padres de Comportamento. Proceedings of the 7th
Brazilian Symposium on Multimedia and Hypermedia Systems, SBMIDIA 2001.
Florianpolis, SC. Outubro de 2001. pp.1536. Grudin, J. (1988) Why CSCW
Applications Fail: Problems in the Design and Evaluation of Organizational
Interfaces. Proceedings of ACM CSCW88, 85-93.
Hartson, H.R. (1998) Human-Computer Interaction: Interdisciplinary roots and
trends. In The Journal of System and Software, 43, 103-118. 1998.
Hewett, T.; Baecker, R.; Card, S.; Carey, T.; Gasen, J.; Mantei, M.; Perlman, G.;
Strong, G.; Verplank, W. (1992) ACM SIGCHI Curricula for Human-Computer
Interaction. ACM SIGCHI Report, ACM, NY. Disponvel online em
http://sigchi.org/cdg/ [ltimo acesso: maio de 2003].
Jones, A., Scanlon, E. , Tosunoglu, C. , Morris, E., Ross, S., Butcher, P. e Greenberg, J.
(1999) Contexts for evaluating educational software. Interacting with Computers.
Vol. 11 (1999) 499-516.
Karat, J. (1993) The cost-benefit and business case analysis of usability engineering.
InterChi 93, Amsterdam, Tutorial Notes 23.
Lynch, G. and Palmiter, S. (2002) Design and Rapid Evaluation of Usable Web Sites,
CHI2002 tutorial notes.
MauroNewMedia (2002) Professional Usability Testing and return on investment as it
applies to user interface design for web-based products and services. Disponvel
online em http://www.taskz.com/ucd_testing_roi_summary.php [ltimo acesso: maio
de 2003]
Moran, T. (1981) The Command Language Grammars: a representation for the user
interface of interactive computer systems. Em International Journal of Man-Machine
Studies 15:3-50, Academic Press.
Mack, R. & Nielsen, J. (1994) Usability Inspection Methods. New York, NY: John
Wiley & Sons.
Nicolaci-da-Costa, A. M. (2001), Gerando conhecimento sobre os homens, mulheres e
crianas que usam computadores: algumas contribuies da psicologia clnica,
Anais do IV Workshop sobre Fatores Humanos em Sistemas Computacionais
(IHC2001). Florianpolis, 120-131.
Nielsen, J. (1993) Usability Engineering. Academic Press.
Nielsen, J. (1994) Heuristic Evaluation, in Mack, R. & Nielsen, J. (eds.) Usability
Inspection Methods. New York, NY: John Wiley & Sons, 1994, 25-62. Nielsen, J.
(1998) Cost of User Testing a Website, Alertbox. Disponvel online em
http://www.useit.com/alertbox/980503.html [ltimo acesso: maio/2003].
Nielsen, J. (2000) Test with 5 Users, Alertbox. Disponvel online em
http://www.useit.com/alertbox/20000319.html [ltimo acesso: maio/2003].
Norman, D. (1988) Psychology of Everyday Things. BasicBooks. HarperCollins
Publishers, 1988.
Or (2001) Site do Projeto Or. Disponvel em: http://www.serg.inf.puc-rio.br/ore.
Peirce, C.S. (1931-1958). Collected Papers. Edio brasileira: Semitica. So Paulo, Ed.
Perspectiva (coleo estudo, n.46), 1977.
Pinelle, D. and Gutwin, C. (2002) Groupware Walkthrough: Adding Context to
Groupware Usability Evaluation. Proceedings of the CHI 2002.
Prates, R. O.; de Souza, C. S; Carey, T.; Muller, M. J. (2001) Evaluating beyond
usability evaluation. Presented as SIG at CHI 2001, Seattle, USA. Available at
(http://www.serg.inf.puc-rio.br)
Prates, R.O.; Barbosa, S.D.J.; de Souza, C.S. (2000a) A Case Study for Evaluating
Interface Design Through Communicability. Proceedings of the International
Conference on Designing Interactive Systems, DIS2000. New York, NY: ACM
Press, 308-317, 2000.
Prates, R.O.; de Souza, C.S.; Barbosa, S.D.J.; (2000b) A Method for Evaluating the
Communicability of User Interfaces. Interactions 7, 1. New York, NY: ACM Press,
31-38, 2000.
Prates, R.O.; de Souza, C.S. (2002) Extenso do Teste de Comunicabilidade para
Aplicaes Multi-usurio. Cadernos do IME, Volume 13. 46-56, 2002.
Preece, J. (2000) Online Communities. NY, NY: John Wiley & Sons. 2000. Preece,
2000
Preece, J.; Rogers, Y.; Sharp, E. (2002) Interaction Design: Beyond Human-computer
Interaction. New York, NY: John Wiley & Sons. 2002.
Preece, J.; Rogers, Y.; Sharp, E.; Benyon, D.; Holland, S.; Carey, T. (1994) Human-
Computer Interaction. England: Addison-Wesley, 1994. Robson, C. (1993) Real
World Research. Oxford, UK: Blackwell.
Section 508 (1998). Disponvel online em http://www.section508.gov/ [ltimo acesso:
maio/2003].
Shneiderman, B. (1998) Designing the User Interface, 3
rd
Edition. Reading, MA:
Addison Wesley, 1998. Squires, D. (1999) Usability and Educational Software
Design: Special Issue of Interacting with Computers. Interacting with Computers.
Vol. 11 (1999) 463466.
Squires, D. e Preece, J. (1999). Predicting quality in educational software: Evaluating
for learning, usability and the synergy between them. Interacting with Computers.
Vol. 11 (1999) 467483.
Web Accessibility Initiative (WAI). Disponvel online em http://www.w3.org/WAI/
[ltimo acesso: maio/2003].
Wharton, C., Rieman, J., Lewis, C. and Polson, P. (1994) The Cognitive Walkthrough
Method: A Practitioners Guide. In Nielsen, J., and Mack, R.L. (Eds.), Usability
Inspection Methods, John Wiley & Sons, New York, NY.
Westerink, J. H. D. M., Rankin, P. J., Majoor, G. M. M., Moore, P. S. (1994) A New
Technique for Early User Evaluation of Entertainment Product Interfaces,
Proceedings of the Human Factors and Ergonomics Society 38th Annual Meeting
1994 v.2 p.992.