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).

sistema usurio
ao interpretao

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 (). 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 (). 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 (; ): 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 (). Mais recentemente, foi elaborado o conceito de comunicabilidade, que busca avaliar o processo implcito de comunicao designerusurio, que se d atravs da interface (Prates et al. 2000b,). J o conceito de aplicabilidade est relacionado

flexibilidade de um sistema, em particular com relao sua utilidade em uma variedade de situaes (). 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 (; 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 (). 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 prdefinido. 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 (). 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 (). 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 (). 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 bsico1 de heursticas (). 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

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 (). 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? Onde est o elemento de interface correspondente ao prximo passo? Que aes a interface torna disponveis? O elemento de interface revela seu propsito e comportamento? O usurio consegue identificar os elementos de interface?

O usurio perceber que a ao correta est disponvel?

O usurio associar o elemento de interface correto meta a ser atingida?

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. 2. 3. 4. 5. Entrar no espao privativo do Quadro de Avisos Entrar login e senha Selecionar a opo Criar Avisos Preencher campos (pelo menos os obrigatrios) 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 (). 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 3a. 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 b) Sala de observao: avaliador avaliador na sala. 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 EUA2, regulamentam o processo de teste e tm exigncias formais e burocrticas sobre

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 (): 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, devese 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 Facilidade uso Facilidade uso de de mtodo de medio Nmero de erros cometidos Porcentagem de vezes que o usurio vai ao sistema de pior caso Mais de 10 erros Para cada tarefa vai pelo menos 1 vez. nvel almejado No mximo erros 3 melhor caso Nenhum erro Nunca

Apenas a 1a. vez que realiza uma

ajuda Eficincia para criar aviso Tempo gasto para criar um aviso 5 min

tarefa complexa 40 segundos 20 segundos (tempo para digitar campos) 10 segundos (tempo para digitar alguns campos no mecanismo de busca) Mais de uma vez ao dia 100% vezes 100% vezes Muito positivo das

Eficincia para encontrar aviso

Tempo gasto para encontrar um aviso

No encontrar aviso

30 segundos

Utilidade

Freqncia de uso

Uma vez a cada trs dias ou menos freqente Nunca

Uma vez ao dia

Eficincia do sistema de ajuda Eficincia do sistema de ajuda Avaliao inicial

Porcentagem das vezes que usurio encontrou o que procura no sistema de ajuda Consegue resolver problema com base contedo de ajuda Questionrio (subjetivo) o no

Acima de 90% das vezes Acima de 90% das vezes Positivo

Nunca

das

Negativa

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 metamensagem 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 avaliador3 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

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.

Epa!

O participante clica em buscar avisos, ao entrar na pgina de busca, imediatamente clica no boto voltar.

Cad?

O participante clica na barra de rolagem para ver os avisos e vai passando o cursor sobre eles, procurando o desejado.

E agora?
Participante fica em sem saber qual deve ser seu prximo passo. Fica em dvida entre duas opes, mas acaba no selecionando nenhuma.

Socorro!
Participante no sabe o que fazer e acessa o sistema de ajuda.

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 affordance4. 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 signos5 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

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 designer6. 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 Percepo significado IncompreRecusa de enso de affordance affordance

Cad E agora? O que isto? Epa! Onde estou? Assim no d. Por que funciona? U, o que houve? Para mim est bom No d. Vai de outro jeito No, obrigado. Socorro! X X no

X X X X X X X X X X X X X X X X X X X

X 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) (). 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 Usurio7

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 (). 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

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 (). 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 (). 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 (), 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 ().
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 (). 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 (). 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 rpidas8 (). 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, 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.

Em ingls normalmente chamadas de avaliaes Quick and Dirty.

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 5th 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) HumanComputer 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, 3rd 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