Escolar Documentos
Profissional Documentos
Cultura Documentos
____________________________________________________________________
AVALIAO DE INTERFACES
For a company to say 'we dont need evaluation' is just the same as saying 'our system designers dont need to see anything when they are driving: they can drive with their eyes shut and achieve the goal that they want'. You cant possibily produce a good product blindfolded. Brian Shackel apud Preece et al., 1994, p. 600
INTRODUO
Avaliao no deve ser vista como uma fase nica dentro do processo de design e muito menos como uma atividade a ser feita somente no final do processo e se "der tempo". Idealmente, avaliao deve ocorrer durante o ciclo de vida do design e seus resultados utilizados para melhorias gradativas da interface. claro que no se pode pretender efetuar extensivos testes experimentais durante todo o processo de design, mas tcnicas informais e analticas devem ser utilizadas. Nesse sentido existe uma forte correlao entre avaliao e as tcnicas de modelagem e construo de prottipos discutidas no Captulo 3, pois essas tcnicas garantem que o design est constantemente sob avaliao. E na maioria de modelos de desenvolvimento de interfaces usveis a avaliao tem um papel central, como no modelo Estrela (Hix e Hartson, 1993) apresentado no captulo anterior (Figura 4.1).
Anlise da tarefa Anlise funcional
Implementao
Prototipao
AVALIAO
Especificao de requisitos
Diferentes tipos de avaliao so necessrias em diferentes estgios do design. Nos estgios bem iniciais onde idias esto sendo exploradas e tentadas, muitas vezes testes bastante informais so suficientes. Por exemplo, depois de uma sesso de discusso (brainstorming) para explorar diferentes metforas, o conjunto inicial de opes certamente estar bem reduzido. Outras vezes, principalmente em estgios um pouco mais avanados do processo, avaliaes mais formais devem ser planejadas. Os fatores determinantes de um plano de avaliao incluem (Nielsen, 1993; Hix and Hartson, 1993; Preece et al., 1994; Schneiderman, 1998):
162 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ estgio do design (inicio, meio ou fim) quo pioneiro o projeto (bem definido versus exploratrio) nmero esperado de usurios quo crtica a interface (por exemplo, um sistema de controle de trfego areo versus um sistema de orientao de um shopping) custo do produto e oramento alocado para o teste tempo disponvel experincia dos desingers e avaliadores
O domnio do plano de avaliao pode estar entre um ambicioso teste de dois anos, com mltiplas fases, de um novo sistema de controle de trfego areo at um discreto teste de trs dias com seis usurios de um sistema interno de contabilidade. Da mesma forma, o custo pode variar de 10 % at 1% do custo total do projeto. Mesmo considerando que uma atitude irresponsvel no efetuar alguma forma de avaliao, deve-se ter claro que um certo grau de incerteza sempre permanece mesmo aps exaustivos testes com mltiplos mtodos. Perfeio no possvel, portanto qualquer planejamento deve prever mtodos de avaliao contnua e reparo de problemas durante todo ciclo de vida de uma interface. Deve-se ter em vista ao analisar mtodos de avaliao que eles apresentam resultados bastante satisfatrios para grande parte dos sistemas em condies normais de uso, mas a performance de sistemas com grande complexidade de entradas, como por exemplo, as emergncias de um sistema de controle de um reator nuclear ou de trfego areo, so muito difceis de serem testadas. O objetivo deste captulo no apresentar todas as possveis tcnicas de avaliao e nem prescrever exatamente quando e como us-las. Estaremos tratando com mais detalhe trs tcnicas que julgamos representativas: uma delas a mais tradicional que o teste com usurios e as outras duas, avaliao heurstica e percurso cognitivo, por serem as que apresentam mais e melhores resultados prticos, alm de poderem ser aprendidas com certa facilidade. E discutiremos ao longo do captulo as razes da existncia de diferentes abordagens de avaliao. Ressaltamos que na maioria das situaes prticas uma ou mais tcnicas so adotadas e adaptadas de forma a atender as necessidades especficas da interface sob avaliao. Geralmente os recursos disponveis tm um grande impacto no tipo de avaliao a ser feita. Portanto, selecionar a tcnica de avaliao adequada envolve escolher, misturar e adaptar tcnicas a partir do conjunto de tcnicas disponveis.
OBJETIVOS DA AVALIAO
De forma geral, se faz avaliao para conhecer o que os usurios querem e os problemas que eles experimentam, pois quanto melhor informados sobre seus usurios os designers estiverem, melhor sero os design de seus produtos.
Avaliao de Interfaces 163 ____________________________________________________________________ Muitas questes poderiam ser objetivo de uma avaliao. O setor de marketing poderia estar interessado em como o produto de sua empresa se compara com produtos de outros competidores do mercado. Por exemplo, se a funcionalidade e a aceitao do produto melhor, ou pelo menos igual, do principal competidor. Produtos tambm podem ser avaliados no sentido de verificar se esto de acordo com padres especficos, como as normas ISO, por exemplo. Avaliaes so necessrias para responder dvidas que surgem durante o processo de design e desenvolvimento de um produto. Em muitos pontos do processo de design as pessoas de desenvolvimento necessitam respostas a questes de modo a verificar se suas idias so realmente o que os usurios necessitam ou desejam. Desse modo, avaliao direciona e se mescla ao design, auxiliando na criao de um produto til e usvel, como visto no Captulo 3. Em contraste, podemos ter as avaliaes que ocorrem depois do produto desenvolvido e que se preocupam em fazer julgamentos sobre o produto final: sua performance considerando produtos competitivos, sua adequao uma determinada famlia de produtos, etc. Como um dos focos desse livro em design estaremos neste captulo nos atendo mais s avaliaes feitas durante o processo de design e seus resultados. Resumidamente, podemos dizer que avaliao tem trs grandes objetivos: avaliar a funcionalidade do sistema, avaliar o efeito da interface junto ao usurio e identificar problemas especficos do sistema. A funcionalidade do sistema importante no sentido de estar adequada aos requisitos da tarefa do usurio, ou seja, o design do sistema deve permitir ao usurio efetuar a tarefa pretendida e de modo mais fcil e eficiente. Isso inclui no somente ter a funcionalidade adequada disponvel, mas tambm torn-la usvel, na forma de aes que o usurio precisa efetuar para executar a tarefa. Avaliao nesse nvel envolve tambm medir a performance do usurio junto ao sistema, ou seja, avaliar a eficincia do sistema na execuo da tarefa pelo usurio. Adicionalmente, preciso medir o impacto do design junto ao usurio, ou seja, avaliar sua usabilidade. Isso inclui considerar aspectos tais como: avaliar quo fcil aprender a usar o sistema; a atitude do usurio com relao ao sistema; identificar reas do design as quais sobrecarregam o usurio de alguma forma, por exemplo, exigindo que uma srie de informaes sejam relembradas; etc. Muitos dos mtodos concentram a avaliao sobre aspectos padro de usabilidade, como o uso de guidelines como apresentado no Captulo 3. O terceiro objetivo da avaliao identificar problemas especficos com o design, ou seja, identificar aspectos do design os quais quando usados no contexto alvo, causam resultados inesperados ou confuso entre os usurios. Isso claro est correlacionado tanto com a funcionalidade quanto com a usabilidade do design.
164 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ Atendendo a esses objetivos pode-se classificar os mtodos de avaliao em duas dimenses: se usurios reais esto ou no envolvidos e se a interface est ou no implementada. Considera-se implementao qualquer prottipo executvel (Whitefield et al., 1991). Nessas dimenses estaremos neste captulo tratando de dois grupos de mtodos: inspeo de usabilidade (predictive evaluation) - sem envolver usurios e podendo ser usado em qualquer fase do desenvolvimento de um sistema (implementado ou no) testes de usabilidade - mtodos de avaliao centrados no usurio que incluem mtodos experimentais ou empricos, mtodos observacionais e tcnicas de questionamento (como nos mtodos etno-grficos vistos no Captulo 3). Para se usar esses mtodos necessria a existncia de uma implementao real do sistema em algum formato que pode ser desde uma simulao da capacidade interativa do sistema, sem nenhuma funcionalidade, um prottipo bsico implementando, um cenrio, ou at a implementao completa.
Outros grupos de mtodos que no sero tratados neste captulo incluem: Experimentos controlados - envolvem efetuar um bem projetado e controlado experimento de laboratrio. Tem-se sempre definida uma hiptese a ser testada e todas as variveis de interesse necessitam ser controladas. Conhecimento estatstico necessrio para validar os resultados. Controlar todas as variveis dentro de interaes complexas envolvendo humanos alm de difcil de validade muito questionvel. A metodologia experimental seguida, tendo-se o experimentador controlando certas variveis enquanto examina outras. Os experimentos so feitos em laboratrios especialmente construdos para esse fim e existe muito rigor na observao e monitoramento do uso do sistema. Os dados coletados so analisados quantitativamente de modo a produzir mtricas que guiem o design (Preece et al, 1994; Dix et al., 1998). Mtodos de avaliao interpretativos - o objetivo desse tipo de avaliao possibilitar aos designers um maior entendimento de como os usurios se utilizam dos sistemas em seu ambiente natural e como o uso desses sistemas se integra com outras atividades. Portanto, alguma forma de participao do usurio na coleta, anlise ou interpretao dos dados bastante comum. Os mtodos que pertencem a esse grupo incluem avaliao participativa e conceitual que so dois mtodos desenvolvidos especialmente para avaliar IHC, e avaliao etnogrfica, uma tcnica emprestada da antropologia, conforme discutido no Captulo 3. Formas de registro como vdeos e udio podem ser feitas como em outros mtodos mas a forma de anlise bastante diferenciada (Preece et al, 1994; Monk et al, 1993; Greenbaum e Kying, 1991).
INSPEO DE USABILIDADE
Define-se inspeo de usabilidade como um conjunto de mtodos baseados em se ter avaliadores inspecionando ou examinando aspectos relacionados a usabilidade de uma interface de usurio. Os avaliadores podem ser especialistas em usabilidade, consultores de desenvolvimento de software, especialistas em um determinado padro de interface, usurios finais, etc. Diferentes mtodos de inspeo tm objetivos diferentes, mas normalmente inspeo de usabilidade proposta como um modo de avaliar design de interfaces baseado no julgamento de avaliadores e so sustentados pela confiana depositada em seus julgamentos. Os mtodos variam no sentido de como os julgamentos so efetuados e em quais critrios se espera que o avaliador baseie seus julgamentos. Pode-se contrastar os mtodos de inspeo com outros modos de se obter dados de usabilidade: automaticamente, onde medidas de usabilidade so computadas executando-se um software de avaliao que recebe como entrada uma especificao formal da interface; empiricamente, testando a interface com usurios reais; formalmente, usando modelos exatos e frmulas para calcular as medidas de usabilidade; e informalmente, usando a habilidade e experincia de avaliadores. Inspees de usabilidade correspondem a categoria de mtodos informais. No estado atual da arte, mtodos automticos no funcionam e mtodos formais so muito difceis de serem aplicados no funcionando bem quando se tem interfaces complexas e altamente interativas (Kahan e Prail, 1994). Mtodos empricos ou testes de usabilidade so o principal modo de avaliar interfaces e certamente o mais tradicional (estaremos discutindo mais profundamente no decorrer deste captulo). Mas geralmente, usurios reais so difceis e caros para serem recrutados de forma a se poder testar todas as fases do desenvolvimento evolutivo de uma interface. Muitos estudos demonstram que muitos problemas encontrados por mtodos de inspeo no so detectados com testes de usurios e vice-versa. Esses estudos sugerem que os melhores resultados so obtidos combinando testes com usurios e inspees.
OBJETIVOS DA INSPEO
Inspeo de usabilidade objetiva encontrar problemas de usabilidade em um design de uma interface de usurio e com base nesses problemas fazer recomendaes no sentido de eliminar os problemas e melhorar a usabilidade do design. Isso significa que inspees de usabilidade so feitas em um estgio onde a interface est sendo gerada e a sua usabilidade (e utilidade) necessita ser avaliada Problemas de usabilidade podem ser definidos como aspectos da interface do usurio que podem causar uma usabilidade reduzida ao usurio final do sistema.
166 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ Usabilidade, como j visto em captulos anteriores, um termo bastante amplo que se refere a quo fcil para o usurio final aprender a usar o sistema, quo eficientemente ele ir utilizar o sistema assim que aprenda como usar e quo agradvel o seu uso. Tambm, a frequncia e a severidade dos erros do usurio so consideradas como partes constituintes da usabilidade. Entretando, um usurio pode achar um elemento da interface problemtico por muitas razes: torna o sistema difcil de aprender, torna-o lento na execuo de suas tarefas, causa erros de uso, ou pode ser simplesmente feio e desagradvel. Muito do trabalho da inspeo de usabilidade classificar e contar o nmero de problemas de usabilidade. Esta anlise depende da exata definio do que um problema de usabilidade e julgamentos de como diferentes fenmenos constituem manifestaes de um nico problema. Freqentemente, muito difcil fazer essas distines, mas na maioria dos casos bom senso suficiente para determinar o que um problema de usabilidade. Para uma definio geral de problema de usabilidade, pode-se dizer que qualquer aspecto de um design onde uma mudana pode melhorar uma ou mais medidas de usabilidade. A identificao dos problemas na interface importante, mas apenas uma parte de um grande processo. Depois de ser gerada a lista de problemas de usabilidade, a equipe de desenvolvimento precisa fazer um redesign da interface de modo a tentar corrigir a maior quantidade possvel de problemas. Para que isso seja feito sero precisos outros tipos de informaes e anlises dentro do contexto mais amplo da engenharia de usabilidade. Mtodos de inspeo de usabilidade so geralmente melhores na deteo de problemas do que na direo de como melhorar a interface, mas tipicamente relatrios gerados a partir dos mtodos contm sugestes para redesign. Em muitos casos, conhecendo sobre o problema de usabilidade, clara a maneira de corrig-lo. Alm disso, muitos dos mtodos sugerem encontros entre a equipe de avaliadores e a equipe de desenvolvimento, quando esta distinta, para discutir solues de redesign. O uso efetivo de uma lista de problemas de usabilidade ir requerer que esses problemas sejam priorizados com relao gravidade de cada problema. Prioridades so necessrias para no se dispender esforos desproporcionais corrigindo problemas que no iro alterar em muito a interao do usurio com a interface. Graus de severidade so geralmente derivados do impacto gerado pelo problema tanto no usurio quanto no mercado. Por serem muitas vezes critrios dependentes da aplicao, a definio de graus de severidade no muito bem estabelecida na literatura, mas alguns autores do exemplos de como atribuir graus de severidade problemas de usabilidade (Nielsen, 1994; Karat, 1994; Desurvire, 1994). Precisa ser estimado o custo associado implementao das sugestes de redesign. Certamente, problemas de usabilidade com alto grau de severidade devem ser corrigidos no interessando o quanto custem. Freqentemente, muitos dos problemas no muito graves podem ser corrigidos com alteraes mnimas de cdigo. Esse compromisso no pode ser considerado como parte do mtodo de inspeo de
Avaliao de Interfaces 167 ____________________________________________________________________ usabilidade, pois prefervel ter uma relao completa de todos os problemas sem o pr julgamento da viabilidade ou no da sua correo. Concluindo, ressaltamos que mtodos de inspeo podem ser aplicados em fases iniciais ou finais do design e o resultado um relatorio formal dos problemas identificados com recomendaes para mudanas. Alternativamente, e fortemente recomendvel, a inspeo pode resultar em uma discusso ou apresentao para os designers e gerentes do projeto. Avaliadores precisam estar sensveis habilidade profissional e ao alto grau de envolvimento da equipe de desenvolvimento, e as sugestes devem ser feitas com cuidado: difcil para algum que tem um contato inicial com o sistema efetuando uma inspeo entender todas as razes de design e histria de desenvolvimento de uma interface. Da os revisores anotarem os possveis problemas para discusso, mas as decises de como corrigir devem ser deixadas sob responsabilidade dos designers. Uma inspeo pode demorar de 12hs at 40hs, dependendo da complexidade da interface e de seus procedimentos operacionais, alm do contexto da tarefa que necessariamente dever ser conhecido pelo avaliador.
MTODOS DE INSPEO
Dentre os diversos mtodos de inspeo existentes podemos destacar: Avaliao Heurstica: feita a inspeo da interface tendo como base uma pequena lista de heursticas de usabilidade. Esse mtodo ser discutido com mais detalhe na prxima seo deste captulo. Reviso de Guidelines: a interface analisada no sentido de verificar se est de acordo com uma lista de guidelines de usabilidade. Geralmente essa lista contm uma seqncia de cerca de 1.000 guidelines, o que torna o uso desse mtodo muito raro dada a expertise que exigida de um revisor. Inspeo de Consistncia: o avaliador verifica a consistncia dentro de uma famlia de interfaces, quanto terminologia, cores, layout, formatos de entrada e sada, e tudo o mais dentro da interface. Tambm avaliado o material online de treinamento e de ajuda . Percurso Cognitivo: o avaliador simula o usurio "caminhando" na interface para executar tarefas tpicas. Tarefas mais freqentes so o ponto inicial de anlise, mas tarefas crticas, tais como recuperao de erro, tambm so percorridas. Percurso cognitivo foi desenvolvido para interfaces que podem ser aprendidas de forma exploratria, mas tambm so teis em interfaces que
168 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ exigem muito treinamento. Esse mtodo ser discutido em seo prxima deste captulo. Segundo Nielsen (1993), os mtodos de inspeo de usabilidade no exigem muito esforo de quem pretende us-los e podem ser facilmente integrados aos mais variados esquemas de produo de software. No necessrio modificar fundamentalmente o modo como sistemas so desenvolvidos e gerenciados de modo a obter grandes benefcios da inspeo de usabilidade. Os resultados so rpidos e fornecem concretas evidncias de quais aspectos da interface devem ser aperfeioados. Percurso cognitivo e avaliao heurstica so os precursores dos mtodos de inspeo de usabilidade e geralmente no exigem uma grande experincia ou longo treinamento para que possam ser utilizados. Alm disso, a utilizao deles proporciona uma relevante experincia educacional para designers novatos. A exposio a preocupaes adicionais de usabilidade tem se mostrado um meio efetivo de incrementar a perspectiva e valor do desenvolvimento de software orientado para o usurio. Esses dois mtodos estaro sendo apresentados com detalhe nas prximas sees deste captulo.
AVALIAO HEURSTICA
A maioria dos mtodos de inspeo tero um efeito significativo na interface final somente se forem usados durante o ciclo de vida do projeto. Infelizmente, isso ainda no uma realidade. Muitos desenvolvedores consideram os mtodos intimidadores, muito caros, difceis e que necessitam muito tempo para serem aplicados (Nielsen, 1994). No sentido de inverter essa tendncia Nielsen prope a denominada engenharia econmica de usabilidade - discount usability engineering - (Nielsen, 1989; Nielsen, 1993) com mtodos que so baratos, rpidos e fceis de serem usados. Avaliao heurstica o principal mtodo dessa proposta. Segundo o autor, fcil (pode ser ensinada em 4hs); rpida (cerca de 1 dia para a maioria das avaliaes); e to barata quanto se deseje.
Avaliao de Interfaces 169 ____________________________________________________________________ De modo geral, difcil de ser feita por um nico avaliador, porque uma nica pessoa nunca capaz de encontrar todos os problemas de usabilidade de uma interface. A experincia tem mostrado que diferentes pessoas encontram diferentes problemas, e portanto se melhora significativamente os resultados da avaliao heurstica utilizando mltiplos avaliadores. A recomendao que se use de trs a cinco avaliadores. A avaliao heurstica feita em um primeiro momento individualmente. Durante a sesso de avaliao cada avaliador percorre a interface diversas vezes (pelo menos duas) inspecionando os diferentes componentes do dilogo e ao detetar problemas os relata associando-os claramente com as heursticas de usabilidade que foram violadas. As heursticas (Tabela 4.1 e Tabela 4.2), so regras gerais que objetivam descrever propriedades comuns de interfaces usveis (Nielsen, 1994). __________________________________________________________________ 1. Dilogo simples e natural
simples significa informao no irrelevante ou raramente utilizada natural refere-se adequao tarefa usar conceitos do mundo do usurio no usar termos computacionais especficos no fazer com que o usurio tenha que relembrar coisas de uma ao em uma prxima ao deixar informao na tela at ela no ser mais necessria seqncia de aes aprendidas em uma parte do sistema devem poder ser aplicadas em outras partes dar conhecimento aos usurios do efeito que suas aes tm sobre o sistema se o usurio entra em uma parte do sistema que no lhe interessa, ele deve ser capaz de sair rapidamente sem estragar nada no colocar o usurio em armadilhas auxiliar o usurio experiente a evitar extensos dilogos e mensagens de informaes que ele no quer ler informar ao usurio qual foi o problema e como corrig-lo sempre que encontrar uma mensagem de erro, verificar se aquele erro poderia ser evitado
2.
3.
4.
Ser consistente
5.
Prover feedback
6.
7. Prover Shortcuts
8. 9. Mensagens de erro construtivas e precisas
Prevenir erros
__________________________________________________________________
TABELA 4.1 - LISTA ORIGINAL DE HEURSTICAS DE USABILIDADE (NIELSEN, 1990)
170 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ __________________________________________________________________ 1. Visibilidade do status do sistema
sistema precisa manter os usurios informados sobre o que est acontecendo, fornecendo um feedback adequado dentro de um tempo razovel sistema precisa falar a linguagem do usurio, com palavras, frases e conceitos familiares ao usurio, ao invs de termos orientados ao sistema. Seguir convenes do mundo real, fazendo com que a informao aparea numa ordem natural e lgica usurios frequentemente escolhem por engano funes do sistema e precisam ter claras saidas de emergncia para sair do estado indesejado sem ter que percorrer um extenso dilogo. Prover funes undo e redo. usurios no precisam adivinhar que diferentes palavras, situaes ou aes significam a mesma coisa. Seguir convenes de plataforma computacional melhor que uma boa mensagem de erro um design cuidadoso o qual previne o erro antes dele acontecer tornar objetos, aes e opes visveis. O usurio no deve ter que lembrar informao de uma para outra parte do dilogo. Instrues para uso do sistema devem estar visveis e facilmente recuperveis quando necessrio usurios novatos se tornam peritos com o uso. Prover aceleradores de formar a aumentar a velocidade da interao. Permitir a usurios experientes "cortar caminho" em aes freqentes. dilogos no devem conter informao irrelevante ou raramente necessria. Qualquer unidade de informao extra no dilogo ir competir com unidades relevantes de informao e diminuir sua visibilidade relativa mensagens de erro devem ser expressas em linguagem clara (sem cdigos) indicando precisamente o problema e construtivamente sugerindo uma soluo.
2.
3.
4.
Consistncia e padres
5.
Preveno de erros
6.
7.
8.
9.
Avaliao de Interfaces 171 ____________________________________________________________________ Depois dessa etapa inicial, as listas de problemas dos avaliadores so consolidadas em uma s. Tipicamente uma sesso de avaliao, em sua etapa individual, dura cerca de duas horas. Sesses mais extensas de avaliao podem ser necessrias para o caso de interfaces muito grandes ou muito complexas, com um substancial nmero de componentes de dilogo. Nesse caso, recomendvel dividir a avaliao em pequenas sesses, cada qual avaliando um cenrio especfico de interao. Adicionalmente ao conjunto de heursticas gerais a ser considerada em cada componente do dilogo, o avaliador pode tambm considerar heursticas especficas da categoria do produto sendo analisado, por exemplo, heursticas derivadas da anlise de produtos similares e seus resultados de uso. Por exemplo, um sistema altamente dependente de menus ou com dilogo centrado na entrada de informaes via formulrios pode definir heursticas que avaliem especificamente a usabilidade desses componentes mais relevantes. Um exemplo, o mencionado por Romani e Baranauskas (1998) quando apresentam o resultado da avaliao heurstica de um sistema denominado Sistema de Acompanhamento e Avaliao de Rebanhos Leiteiros (ProLeite), que usado na organizao das informaes de desempenho produtivo e reprodutivo dos animais de rebanhos leiteiros. O sistema possui grande quantidade de formulrios para entrada de dados, possibilita consultas e emisso de relatrios. A partir dos resultados da avaliao heurstica do sistema mostrada a necessidade de um conjunto de heursticas de categorias especficas, para captar aspectos especficos do domnio considerado.
1.
Opes de menu significativas e agrupadas logicamente: O agrupamento e os nomes das opes do menu so pistas para o usurio encontrar a opo requerida.
2.
Facilidade no modo de operao: O sistema deve prover um modo de operao facilitado, principalmente para sistemas de entrada de dados. Tais sistemas so construdos a base de formulrios de entrada de dados sendo importante minimizar a quantidade de toques do usurio. Agrupamento lgico e seqencial dos campos: O sistema deve dispor os campos de forma lgica e seqencial nos formulrios. O agrupamento lgico facilita a entrada de dados tanto para usurios iniciantes quanto experientes. Diferenciao entre campos no editveis, obrigatrios e opcionais: O sistema deve prover cor de fundo diferenciada para campos no editveis sinalizando para o usurio que determinados campos em um formulrio no precisam ser digitados. O sistema deve fornecer alguma forma de identificao para campos obrigatrios para auxiliar na entrada de dados pois evidencia quais campos devem ser preenchidos e quais podem ficar em branco. Facilita a entrada dos dados e acaba evitando erros. Permite identificao do tipo de dado e quantidade de caracteres: No sistema deve
3.
4.
5.
7.
8.
9.
TABELA 4.3 HEURSTICAS ESPECFICAS (ROMANI E BARANAUSKAS, 1998) Dentre as heursticas especficas definidas listamos algumas na Tabela 4.3. Como pode ser observado as heursticas especficas so um refinamento das heursticas gerais, provendo somente meios de uma avaliao mais especficas dos componentes de um dilogo. Como durante a avaliao heurstica os avaliadores no estaro usando o sistema de fato, ou seja, para efetuar tarefas reais, possvel efetuar a avaliao em interfaces que existam apenas em papel e que ainda no foram implementadas. Se o sistema de domnio no especfico ou para ser usado pela populao em geral ou os avaliadores so peritos no domnio, nenhuma assistncia adicional necessria. Caso contrrio, ser preciso prover meios de auxiliar o avaliador de forma a que ele seja capaz de usar o sistema adequadamente. Uma forma ter sempre uma pessoa da equipe de desenvolvimento disponvel para responder perguntas dos avaliadores. Outra maneira, prover cenrios tpicos de uso ( ver Captulo 3), listando os vrios passos que um usurio deveria efetuar para realizar um conjunto de tarefas reais. Tal cenrio deve ser construdo com base na anlise da tarefa dos usurios reais de modo a ser to realstico quanto possivel. Esta uma abordagem usada com freqncia e com bastante sucesso.
Avaliao de Interfaces 173 ____________________________________________________________________ Como dissemos, o resultado de uma avaliao heurstica uma lista de problemas de usabilidade da interface com referncias aos princpios de usabilidade que foram violados. O avaliador no pode simplesmente dizer que no gosta de um determinado aspecto, tem que justificar com base nas heursticas e tem tambm que ser o mais especfico possvel e listar cada problema encontrado separadamente. Geralmente a avaliao heurstica no objetiva prover meios de corrigir os problemas ou um modo de avaliar a qualidade de um redesign. Entretanto, como ela explica cada problema encontrado referenciando as respectivas heursticas que foram violadas, geralmente no difcil gerar um design revisado baseado nas diretrizes que foram providas pelo prncipio de usabilidade violado.
EXEMPLOS
HEURSTICA
DE
PROBLEMAS
ENCONTRADOS
NA
AVALIAO
Estaremos apresentando alguns problemas isolados detetatos em avaliaes heursticas, de forma a deixar mais claro o tipo de resultados que podem ser obtidos pelo mtodo. Importante observar que muitas vezes um nico componente de dilogo fere mais que uma heurstica e isso ser indicado em nossos exemplos. Exemplo 1 Em um sistema para oferecimento de cursos a distncia denominado TelEduc1, a ferramenta de correio eletrnico no permite o envio de mensagens sem o preenchimento do campo assunto (subject). Essa caracterstica uma fonte de erros constante, pois a maioria dos sistemas de correio permite isso, emitindo apenas um aviso. A heurstica violada a de preveno de erros. Tambm deve ser observada a mensagem de erro inadequada - Voc no informou o assunto da correspondncia - usando o termo correspondncia que no natural no contexto de mensagens (Figura 4.2). Heurstica violada - consistncia e padres. A recuperao do erro tambm difcil, pois ao retornar tela de composio da mensagem ela tem que ser completamente refeita. Portanto, mais uma heurstica violada - ajudar os usurios a reconhecer, diagnosticar e corrigir erros . Exemplo 2 Outro exemplo, extrado do componente Lista de Discusso da mesma ferramenta de ensino a distncia do exemplo anterior. No sistema TelEduc as telas tm sempre o mesmo formato: dividida em dois frames, o da esquerda sempre est presente e contm a relao de todas as ferramentas disponveis no ambiente e o da direita muda conforme a ferramenta escolhida. Quando se seleciona Lista de Discusso, a direita aparece uma
http://www.nied.unicamp.br/tele_educ
174 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ nova tela onde se tem todas as listas abertas e as operaes possveis com elas (Figura 4.3).
Avaliao de Interfaces 175 ____________________________________________________________________ Ao se selecionar a opo Ver que possibilita ler as mensagens de uma determina lista a tela substituda e se tem acesso s mensagens trocadas. E nessa tela temos uma coleo de heursticas no respeitadas, algumas delas: Esttica e design minimalista; consistncia e padro - existem dois componentes que tm exatamente a mesma funo. Um a flecha no topo direito da tela e outro o boto em baixo a direita. Um deles deve ser eliminado. A flecha tem o problema adicional de confundir com a flecha de back da maioria dos browsers (preveno de erros). E o boto Voltar tem que ser mais especfico indicando para onde vai voltar (ou ento pode-se pensar que simplesmente um back anlogo ao do browser, o que tambm ocasiona a quebra da heurstica preveno de erros ). Compatibilidade do sistema com o mundo real - as mensagens podem ser vistas em diversas ordens (cronolgica, alfabtica por remetente, etc.) mas dificilmente um usurio no especialista vai saber o que em ordem de rvore com relao ao ttulo da mensagem Reconhecimento ao invs de relembrana; consistncia e padro- a pergunta mais freqente dos usurios em como fazer para alterar a ordem das mensagens. Dificilmente se apercebem que basta um clique no rtulo do campo da mensagem que a ordem alterada. Deveria ser provida uma forma que tornasse visvel essa funcionalidade. Tambm importante que outras ferramentas anlogas (como o correio exemplificado anteriormente) consistentemente apresentassem a mesma funcionalidade (pois depois de aprendida na lista, a funcionalidade vira fonte de erro dada a inconsistncia entre as ferramentas anlogas).
Exemplo 3 O antivrus Norton 2000 para NT Server um software projetado para proteger servidores de rede Windows NT de arquivos infectados por vrus. O software executado no servidor NT e sempre que se tenta gravar/abrir algum arquivo infectado no servidor, o programa apresenta uma mensagem na tela do servidor avisando que o arquivo est infectado, mas os usurios em estaes cliente NT no recebem esse aviso. Tem-se portanto a heurstica visibilidade do status do sistema violada. Consequentemente, quando o usurio trabalhando em uma estao cliente tenta gravar um arquivo infectado no servidor o antivirus impede a gravao e no emite nenhuma mensagem para a estao cliente e o usurio pode ento perder seu trabalho sem saber que isso est ocorrendo. O resultado perda do arquivo, o que teria sido facilmente prevenido se alguma mensagem de alerta fosse enviada estao cliente. Claramente a heurstica ajudar os usurios a reconhecer, diagnosticar e corrigir erros tambm violada.
176 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ Exemplo 4 No sistema Windows quando se quer instalar um novo componente de hardware inciado um processo de busca e o indicador de deteco pode ficar parado por muito tempo, como indicado na janela de dilogo (Figura 4.4). O usurio fica perdido na maioria das vezes por no saber o que significa esse muito tempo e no sabe se deve ou no reiniciar o computador, mesmo porque usurios de sistemas semelhantes sabem quo pouco confivel a relao da barra de deteo com o real andamento da operao (visibilidade e status do sistema; ajudar os usurios a reconhecer, diagnosticar e corrigir erros).
Exemplo 5 No Dia das Crianas o provedor ZAZ (http://www.zaz.com.br) fez uma pgina especial que dava entrada para uma pgina de jogos (Figura 4.5). Nessa pgina uma coleo de termos tcnicos encontrada e as crianas, potencialmente usurios novatos, no conseguem entender o que tem que fazer para atingir seu objetivo, que jogar (compatibilidade do sistema com o mundo real).
Exemplo 6 O software Winzip em uma mesma verso gratuita (no registrada) tem uma tela de abertura onde os botes aparecem em ordem aleatria a cada execuo (Figura 4.6). Arbitrariamente os botes Accept e Quit aparecem em ordem trocada levando o usurio a errar sem saber porque (consistncia e padres; preveno de erros).
Exemplo 7 No sistema de entregas da declarao de Imposto de Renda ao tentar desistir do programa de instalao o usurio recebe uma caixa de dilogo onde o No est a direita do Sim (Figura 4.7). Isso foge completamente ao padro de dilogo de toda aplicao Windows em caixas de dilogo do tipo Sim/No sendo fonte constante de erro (consistncia e padres; preveno de erros). Vale a pena observar que esse programa da categoria de softwares de uso eventual e mesmo que internamente esteja sendo adotado o padro de colocar a escolha mais provvel em primeiro lugar, o padro Windows deveria ter sido respeitado, pois o usurio no ir usar o software
178 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ muito tempo de forma a poder aprender esse padro interno especfico. Outro aspecto a ser observado o uso indevido da palavra abortar na caixa de dilogo (compatibilidade do sistema com o mundo real).
Exemplo 8 No Windows Explorer ao tentarmos excluir um arquivo que est em uso uma caixa de dilogo aberta (Figura 4.7). Nessa caixa aparece a mensagem de que no foi possivel acessar o arquivo, e recomenda ao usurio que verifique se o disco est cheio ou protegido, e finalmente se o arquivo no est sendo usado. No h usurio que no se confunda: o que tem a ver disco cheio com excluir um arquivo! (ajudar os usurios a reconhecer, diagnosticar e corrigir erros)
Exemplo 9 A pgina de entrada do site do AltaVista2 tem uma enorme redundncia de links para a funo de busca (Figura 4.8). O usurio efetivamente no sabe qual usar, quando na verdade todas conduzem ao mesmo resultado (esttica e design minimalista).
Exemplo 10 O Microsoft Word possui, no canto inferior esquerdo da tela, 4 botes, que servem para selecionar o modo de exibio do texto: normal, layout online, layout da pgina, e estrutura de tpicos (Figura 4.9). Atravs desses botes o usurio pode alterar facilmente o modo de exibio de seu documento. Mas quando o modo de layout online selecionado, os botes desaparecem, e o usurio fica sem saber como retornar ao modo de exibio anterior (Figura 4.10). O retorno s pode ser feito indo no menu Exibir e selecionando um dos outros modos (reconhecimento ao invs de relembrana)
http://www.altavista.com
FIGURA 4.10 - TELA DO EDITOR DE TEXTOS WORD PARA WINDOWS MOSTRANDO TEXTO NO
FORMATO LAYOUT
Avaliao de Interfaces 181 ____________________________________________________________________ Exemplo 11 No Editor do Netscape quando se est editando um documento html, constantemente necessria a visualizao do documento no browser, para se testar links ou visualizar a forma do documento. O mesmo ocorre quando se est no browser e se deseja editar o documento (Figura 4.11). Portanto estas duas opes so bastante usadas por desenvolvedores de pginas, logo sempre deveriam ser oferecidos atalhos para essas opes ( a partir do browser e a partir do editor), o que no ocorre no produto em questo (flexibilidade e eficincia de uso)
FIGURA 4.11 - TELAS DO BROWSER NETSCAPE COM MENUS DO MODO COMPOSER E NAVIGATOR
Exemplo 12 O Help do sistema Netscape no muito extenso (Figura 4.12). Ele no preserva nenhum contexto, ou seja, sempre aberta a mesma tela, independente do usurios estar no Navigator ou Mail, por exemplo (help e documentao). No ndice esquerda da tela, o usurio no sabe quando deve dar um clique na palavra ou na bola ( que o link) ao lado da palavra (trs primeiras palavras da tela), ou seja, o usurio no identifica onde est o link, inclusive na parte de baixo da tela as palavras que so os links (consistncia e padres; preveno de erros). Ainda nessa tela tem-se a opo Find e a opo Look For que tm exatamente a mesma funcionalidade. O mesmo acontece com o X na barra em baixo da tela cuja funcionalidade a mesma do X na barra inicial (padro para fechar janelas). Isso confunde o usurio achando que o X em baixo para sair de tudo e no simplesmente fechar a janela( esttica e design minimalista).
Com esses exemplos, podemos de forma mais clara perceber que o dignstico de um problema associado com as heursticas que foram consideradas fonte do problema efetivamente traz possibilidades concretas de redesign, apesar desse no ser o objetivo da avaliao. Como dissemos, uma possibilidade para estender o mtodo de avaliao heurstica, de forma a prover efetivas solues de redesign, fazer uma sesso de discusso final envolvendo a equipe de avaliadores e representantes da equipe de desenvolvimento. Essa discusso no precisa ser formalmente conduzida e deve estar focalizada nos principais problemas de usabilidade. Outro ponto que fortalece a existncia dessa reunio que nela podem ser levantados os aspectos positivos do design, pois a avaliao heurstica no trata desse importante aspecto. Aspectos positivos so todas as caractersticas importantes e boas em uma interface que de forma alguma deveriam ser alteradas ou eliminadas em um redesign.
GRAUS DE SEVERIDADE
Adicionalmente lista de problemas de usabilidade detetados, a avaliao heurstica pode ser usada para avaliar a gravidade de cada problema. Esta informao importante no momento em que forem alocados recursos para corrigir os problemas mais srios e se necessrio deixar os menos graves para uma nova verso. A gravidade de um problema a combinao de trs fatores: a frequncia com que ele ocorre: se comum ou raro impacto do problema quando ele ocorre: se fcil ou difcil para o usurio super-lo a persistncia do problema: problema que ocorre uma nica vez e que o usurio pode superar desde que saiba que ele existe, ou se os usurios sero repetidamente incomodados por ele
Finalmente, claro que preciso considerar o impacto do problema no mercado, pois muitos problemas simples de serem superados tem um efeito importante na popularidade de um produto. Dada essa diversidade de componentes, usualmente se faz uma tabela onde todos aparecem combinados de modo bastante subjetivo como pode ser visto na Tabela 4.4. __________________________________________________________________
1. 2. eu no concordo que isso um problema de usabilidade um problema cosmtico somente - precisa ser corrigido somente se sobrar algum tempo no projeto
3. 4.
problema de usabilidade menor - corrig-lo deve ter prioridade baixa problema de usabilidade grave - importante corrig-lo, deve ser dada alta prioridade
5.
_____________________________________________________________
TABELA 4.4 - LISTA DE GRAUS DE SEVERIDADE DE PROBLEMAS ENCONTRADOS EM UMA AVALIAO HEURSTICA (ADAPTADO DE NIELSEN, 1994, P. 49)
184 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ Dificilmente se ter uma tabela de valores que expresse de maneira objetiva os componentes de gravidade de um problema para todos os sistemas. Elas so construdas quase que caso-a-caso e ser a experincia dos avaliadores que ir determinar a coerncia na atribuio de valores. Nielsen (1994) apresenta uma srie de resultados procurando certificar a confiana nos julgamentos de severidade. Ele conclui que a taxao de severidade feita por um nico avaliador no confivel. Quanto mais avaliadores julgam a gravidade de problemas a qualidade cresce rapidamente, e taxao feita por trs ou quatro avaliadores satisfatria para a maioria dos problemas prticos. Como a atribuio de graus de severidade no possvel de ser feita enquanto no se tem uma relao completa dos problemas, depois da sesso de avaliao apresentado ao conjunto de avaliadores uma lista de graus de severidade e a relao completa de todos os problemas encontrados e cada avaliador atribui individualmente graus de severidade aos problemas.
Avaliao de Interfaces 185 ____________________________________________________________________ muito especfico e atribuio de graus de gravidade que podem parecer um pouco complicadas de inicio por exigirem uma certa expertise dos avaliadores. Mas o mais importante que se pode comear a fazer avaliao heurstica sem considerar esses aspectos e sem muita experincia com avaliao. Segundo Nielsen (1994) os principais componentes de uma avaliao heurstica podem ser resumidos como: avaliadores devem percorrer a interface pelo menos duas vezes. Na primeira vez devem se concentrar no fluxo e na segunda nas componentes individuais do dilogo. a interface deve ser inspecionada com base em uma lista de princpios de usabilidade, as denominadas heursticas, e todos os problemas devem ser justificados e detalhados o mximo possvel. combinar os problemas encontrados por 3 a 5 avaliadores e fazer com que trabalhem individualmente (sem que um influencie o outro)
Depois do trabalho individual o ideal ter uma reunio final de discusso, incluindo representantes da equipe de desenvolvimento de forma a se ter sugestes para redesign. E graus de severidade podem ser atribudos aos problemas caso haja necessidade de priorizar a correo de problemas. Usar o mtodo, no somente melhora a interface sob anlise, como tambm beneficia futuros projetos, o que um efeito colateral da inspeo que julgamos extremamente importante.
PERCURSO COGNITIVO
Percurso cognitivo (Lewis et al. 1990; Polson et al. 1992a) um mtodo de inspeo de usabilidade que tem como foco principal avaliar o design quanto sua facilidade de aprendizagem, particularmente por explorao. O foco na aprendizagem foi motivado por resultados de estudos que apontavam que usurios preferem aprender a usar um software por explorao (Carroll and Rosson, 1987; Fisher, 1991). Ao invs de investir tempo em treinamento formal ou leitura de extensivo material de apoio, usurios preferem aprender sobre um software enquanto trabalham em suas tarefas usuais, adquirindo conhecimento sobre as caractersticas do software medida que delas necessitem. Esta abordagem de aprendizagem incremental de certa forma assegura que o custo da aprendizagem de uma determinada caracterstica em parte determinado pelo seu benefcio imediato ao usurio.
186 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ O que estamos pretendendo nesta seo prover uma descrio detalhada de como se faz um percurso cognitivo, em que fase do desenvolvimento do sistema, etc. Portanto, no estaremos explorando os aspectos tericos que subsidiaram o desenvolvimento do mtodo, que podem ser vistos em Polson et al. (1992a).
Fase de anlise
Objetiva contar uma estria verossmil que informe sobre o conhecimento do usurio e objetivos, e sobre o entendimento do processo de soluo de problemas que leva o usurio a "adivinhar" a correta soluo. Analistas respondem 4 questes: Os usurios faro a ao correta para atingir o resultado desejado? Os usurios percebero que a ao correta est disponvel? Os usurios iro associar a ao correta com o efeito desejado? Se a ao correta for executada os usurios percebero que foi feito um progresso em relao a tarefa desejada? uma estria verossmil de fracaso ser contada se algumas das questes acima tiver resposta negativa
1. 2. 3. 4.
Avaliao de Interfaces 187 ____________________________________________________________________ Durante o processo de percurso o grupo de avaliadores considera, em seqncia, cada uma das aes necessrias para completar a tarefa. Para cada ao, os analistas tentam contar uma estria sobre interaes tpicas de usurios com a interface. Eles perguntam o que o usurio tentaria fazer nesse ponto a partir das aes que a interface deixa disponveis. Se o design da interface for bom, a inteno do usurio far com que ele selecione a ao apropriada e tenha conhecimento disso, ou seja, em seguida ao a interface dever apresentar uma resposta clara indicando que progresso foi feito na direo de completar a tarefa.
188 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ sobre o processo associado ao modelo terico que o embasa. Esse conhecimento pode influenciar em prximas decises de design que o desenvolvedor tenha que tomar. Portanto, o processo de avaliao pode ser usado em fases bastante iniciais do processo de design por designers individuais, desenvolvedores ou grupos de designers. De modo geral, percurso cognitivo tem um impacto positivo em todas as fases do design e do processo de desenvolvimento. Muitas vezes as tarefas do usurio, centrais na aplicao, escolhidas para avaliao so utilizadas como carros-chefe de teste de campo e propaganda.
Avaliao de Interfaces 189 ____________________________________________________________________ dados de uma base de dados, a base de dados usada como exemplo dever ser grande ou pequena, dependendo do uso pretendido do sistema. Qual a correta seqncia de aes para cada tarefa e como descrita? Para cada tarefa, deve haver uma descrio de como se espera que o usurio veja a tarefa antes de aprender sobre a interface. Tambm deve haver uma descrio da seqncia de aes para resolver a tarefa na atual definio da interface. Essas aes podem incluir movimentos simples como "pressionar a tecla ENTER" ou "mover o cursor para o menu File", ou, podem ser seqncias de diversas aes simples que o usurio tpico pode executar como um bloco, tais como "Logar no sistema" para usurios experientes em UNIX, ou selecionar o "Salvar como do menu File" para usurios experientes em Windows. A deciso sobre a granularidade da descrio depende muito da expertise do usurio alvo. A grosso modo, pode-se definir que a descrio deve ser equivalente a descrio que seria colocada em um tutorial eficiente. Qual a interface definida? A definio da interface precisa descrever os prompts que precedem cada ao requerida para completar as tarefas que esto sendo analisadas como tambm a reao da interface para cada uma de suas aes. Se a interface j est implementada, toda informao estar disponvel na implementao. Entretanto, algumas caractersticas importantes do sistema so difceis de serem apreciadas como, por exemplo, o tempo de resposta, cores, temporizao em interfaces com fala, e interaes fsicas. Para uma interface descrita em papel, o detalhamento da definio da interface ir depender da experincia pretendida dos usurios alvo com sistemas que j existem. Por exemplo, a preparao para analisar uma aplicao Windows dirigida para usurios experientes em Windows, no precisa prover uma descrio detalhada da aparncia padro de menus Windows; uma descrio simples de seus contedos suficiente.
190 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ descrio grosseira da tarefa que tem que efetuar (2) exploram a interface e selecionam as aes que eles imaginam as mais adequadas para efetuar a tarefa ou parte dela (3) observam a reao da interface para verificar se suas aes tiveram o efeito desejado e (4) determinam qual ao efetuar a seguir. A teoria tambm aponta algumas heursticas especficas que os usurios aplicam quando tomam suas decises. Em particular, usurios freqentemente seguem a estratgia de "label-following", a qual os faz selecionar uma ao se o rtulo para essa ao combina com a descrio da tarefa (Engelbeck, 1986). Por exemplo, se o usurio deseja "imprimir um arquivo" poder selecionar uma ao com o rtulo (ou cone) "imprimir" ou "arquivo". As caratersticas crticas da interface, so portanto, aquelas que provem uma ligao entre a descrio do usurio para a tarefa e a ao correta, e aquelas que provem feedback indicando o efeito da ao do usurio. Conforme o percurso vai avanando o analista aplica essa teoria ao relatar e avaliar sua estria de como o usurio escolheria a ao prevista pelo designer em cada passo. Os analistas ao contarem suas estrias devem responder a quatro questes: Os usurios faro a ao correta para atingir o resultado desejado? Suponha que em uma determinada aplicao antes de mandar imprimir um documento preciso selecionar uma determinada impressora. O usurio ir saber que tem que fazer isso antes de executar a tarefa de impresso? Os usurios percebero que a ao correta est disponvel? Se a ao estiver disponvel no menu e for facilmente identificada no h problema. Mas suponha que para imprimir um documento seja necessrio dar um clique em um cone com o boto esquerdo do mouse. O usurio pode no pensar nunca nisso. Os usurios iro associar a ao correta com resultado desejado? Se existe um item de menu claro e facilmente encontrado informando "Selecionar Impressora" ento no h problemas, mas se no menu s tem a opo "ImpSis" a as coisas talvez no sejam to evidentes. Se a ao correta for executada os usurios percebero que foi feito um progresso em relao a tarefa desejada? Se aps a seleo o usurio tiver um feedback informando "Impressora Laser XXX da sala YY selecionada" ento sem problemas. O pior caso a ausncia de resposta. Essas questes servem de guia para construir as estrias, no sendo requisitos obrigatrios, mas so as mais usadas. Podem ser definidos pelo analista outros critrios que o levem a contar estrias verossmeis. No caso de seguir o critrio das quatro questes acima, a falha em qualquer uma das questes implicar em problemas com a interface.
ESTRIAS DE SUCESSO
ESTRIAS DE FRACASSO
Para se ter uma idia mais clara do tipo de estrias que analistas geram durante um percurso, iremos apresentar alguns pequenos exemplos de estrias de sucesso e de fracasso verossmeis, de interfaces que existem ou existiram efetivamente.
EXEMPLOS DE ESTRIAS DE SUCESSO Estria de sucesso 1: Um usurio experiente em Windows inicia uma tarefa dando um clique no cone da aplicao para abr-la. Defesa da Credibilidade usurio abre a aplicao porque ele sabe que deve abrir uma aplicao para us-la usurio conhece por experincia que pode dar clique sobre o cone da aplicao
192 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ usurio sabe por experincia que o clique a ao a ser usada mudanas na tela ou na barra de menu sinalizam o inicio da aplicao
Deve-se notar que as trs primeiras partes dessa estria no seriam vlidas para uma pessoa novata no uso de computadores, e a segunda e terceira no seriam vlidas para pessoas inexperientes em Windows.
Estria de sucesso 2: Um usurio experiente em Windows abre o menu Tabela para preparar uma tabela em um editor de textos. Defesa da Credibilidade usurio est tentando preparar uma tabela pois essa a tarefa usurio abre o menu Tabela pois o ttulo Tabela claramente relacionado com o que ele est querendo fazer usurio sabe que pode abrir um menu e essa a ao a ser feita se o ttulo parece bom, por experincia com o Windows usurio sabe que tudo est indo bem quando da leitura das opes do menu.
Estria de sucesso 3: Um usurio de carto de crdito est usando o sistema telefnico para obter informaes sobre seu saldo. O sistema diz "entre com o nmero de seu carto" e o usurio disca seu nmero. Defesa de Credibilidade usurio entra com o nmero porque o sistema informou isso para ele usurio usa as teclas do seu telefone porque elas esto visveis e no existe outra possibilidade para entrar o nmero usurio conhece o nmero do carto pois dele o carto e ele tem ento acesso ao nmero usurio sabe que as coisas esto indo bem quando o sistema comea a dizer os nmeros de um menu de opes de servio.
CARACTERSTICAS COMUNS DE SUCESSOS Com esses exemplos em mente, podem ser resumidos os quatro pontos que os analistas consideram em cada passo e suas caractersticas mais relevantes: 1. Usurios iro conhecer Qual resultado querem alcanar: Porque parte da tarefa original, ou
Avaliao de Interfaces 193 ____________________________________________________________________ 2. Porque eles tm experincia no uso do sistema, ou Porque o sistema diz a eles o que devem fazer
Usurios iro saber que Uma ao est disponvel: Por experincia, ou Observando algum dispositivo, ou Observando a representao de uma ao Usurios iro saber Qual ao adequada para o resultado que esto tentando obter: Por experincia, ou Porque a interface prov um prompt ou rtulo que conecta a ao ao que ele est tentando fazer, ou Porque as outras aes no parecem corretas Usurios iro saber que As coisas esto indo bem depois da ao: Por experincia, ou Por reconhecer a conexo entre a resposta do sistema e o que ele est tentando fazer
3.
4.
Muitos desses pontos enfatizam a importncia de se conhecer como o usurio descreve a tarefa. Quando o sistema usa a mesma terminologia que o usurio, ele provavelmente ir escolher a ao correta. O mesmo acontece com a resposta do sistema (feedback) quando dada na linguagem do usurio. Quando termos no usuais so utilizados pelo sistema, o usurio poder encontrar dificuldades em obter sucesso sem um conhecimento adicional.
EXEMPLOS DE ESTRIAS DE FRACASSOS Estrias de sucesso requerem sucesso em todos os quatro critrios de anlise, enquanto estrias de fracasso tipicamente falham em apenas um dos quatro critrios implicando em que uma estria verossmil no possa ser contada. Vamos ento agrupar nossos exemplos de estrias de fracasso de acordo com o critrio em que falham. Critrio 1: Os usurios faro a ao correta para atingir o resultado desejado? Exemplo 1: Considerando um usurio de Windows com familiaridade com editores grficos bsicos, que ao usar um editor de gifs animados (Figura 4.13) tenta dar um zoom in na figura sob edio. Para isso ele tem que alterar o nmero que est na caixa de dilogo esquerda, no topo da tela (inicialmente com 100%).
Estria de fracasso: Os usurios iro acionar diretamente o boto com o sinal de menos pois esse o padro de cone usado na maioria dos editores para dar zoom in. No obteriam portanto o resultado desejado pois o respectivo boto elimina o ltimo gif editado da seqncia de gifs. Exemplo 2: Considerando um usurio experiente em Windows e com conhecimentos bsicos do editor de textos Word. Ele quer numerar as pginas de um texto colocando a numerao no seguinte formato pg nmero, centralizado no topo da pgina. Para fazer isso ele ter que ir ao menu View, selecionar a opo Header and Footer e a editar o formato desejado da numerao em uma caixa de entrada que aberta no texto, conjuntamente com uma caixa de ferramentas nomeada Header e Footer (figura 4.14)
FIGURA 4.14 TELAS DO EDITOR DE TEXTOS WORD PARA WINDOWS COM MENUS VIEW E TELA DE EDIO DE HEADER
Estria de fracasso: Dificilmente o usurio ir associar a ao de numerar pginas em um determinado formato com a opo View. Ele ir certamente escolher o item de menu Insert com a opo Page Numbers e Format Page Numbers em seguida, falhando em sua ao. Critrio 2: Os usurios percebero que a ao correta est disponvel? Exemplo 1: Em um particular programa que gera grficos (pizza, barras, etc.), para se alterar a fonte e outras especificaes do ttulo de um grfico deve-se dar um duplo clique no ttulo do grfico e somente dessa forma, ir abrir uma caixa de dilogo que permitir a edio desejada. Considerando usurios experientes em interfaces grficas. Estria de fracasso: os usurios freqentemente no consideram a possibilidade de usar um duplo clique nesse contexto Exemplo 2: No sistema sistema operacional Windows 95 para se desligar o computador deve-se dar um clique no boto Iniciar. Considerando-se usurios novatos em Windows. (Figura 4.15) Estria de fracasso: Usurios principiantes no descobrem que essa a ao a ser adotada para se desligar corretamente o computador.
Com freqncia, sistemas orientados por comando tm falhas com relao a esse critrio. Usurios geralmente sabem o que querem fazer (por exemplo, abrir um diretrio, mudar a proteo de um arquivo, listar um arquivo, etc), mas eles muitas vezes no sabem, e nem sempre conseguem encontrar, o nome do comando. Critrio 3: Os usurios iro associar a ao correta com o efeito desejado? Exemplo 1: Em um processador de textos, orientado a menus, existem dois menus. Um tem de menu chamado FORMAT e outro chamado FONT. Estilo de fontes so parte do menu FORMAT. Considerando usurios iniciantes. Estria de fracasso: Os usurios no sabero qual menu escolher se quiserem colocar uma palavra em itlico. Exemplo 2: Considerando o exemplo mencionado anteriormente sobre a colocao de nmero de pginas no processador de textos Word do Windows no formato pg - nmero da pgina
Avaliao de Interfaces 197 ____________________________________________________________________ Estria de fracasso: Mesmo considerando que os usurios saibam que esse formato de numerao tenha que ser colocado sob a forma de Header, dificilmente iro associar a operao de inserir um Header com o menu View. Critrio 4: Se a ao correta for executada os usurios percebero que foi feito um progresso em relao tarefa desejada? Exemplo: No sistema Windows NT, para desligar o computador deve ser acionado o menu iniciar da mesma forma que no sistema Windows (Figura 4.15). Depois de selecionada a opo correta aparece na tela uma caixa de dilogo para o usurio iniciar novamente o sistema. Estria de fracasso: Usurios muitas vezes no percebem que sairam do sistema com sucesso. Ao invs disso, alguns usurios automaticamente do um clique ou enter e se vem presos em um loop. Alguns outros problemas que devem ser observados durante um percurso e que podero resultar em estrias de fracasso: Time outs: alguns sistemas, especialmente os baseados em telefone ou que requisitam senhas (como os caixas automticos por exemplo), do ao usurio um tempo determinado para tomar a ao. Tentar determinar se o tempo dado est adequado considerando o usurio alvo. Aes difceis fisicamente: apertar teclas simultaneamente, especialmente quando devem ser pressionadas ou soltas em uma determinada ordem, difcil. Tambm a dificuldade em selecionar um componente muito pequeno na tela com o mouse ou toque. Problemas desse tipo existem em editores grficos que muitas vezes exigem um controle motor muito fino para desenhar uma simples linha. Terminadores de ao: usurios geralmente esquecem aes que indicam que alguma parte da tarefa est concluda, como colocar um ";" ou "." aps um comando em uma linguagem de programao. Isso porque para o usurio bvio o trmino. Isso ocorre mesmo com usurios muito experientes que sabem o que deve ser feito e mesmo assim esto sempre tendo que efetuar correes.
De maneira geral, lidar com o problema eliminando ou reagrupando aes sempre prefervel a tentar corrigir os problemas usando prompts ou feedback. Quando a
Avaliao de Interfaces 199 ____________________________________________________________________ interface apresenta uma srie de problemas que indicam uma concepo de design que no confere com a descrio que o usurio tem da tarefa, o designer precisa avaliar a possibilidade de corrigir esses problemas efetuando uma reorganizao global da interface ao invs de ficar corrigindo problemas locais.
200 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ Portanto, todo mtodo de avaliao no pode ser considerado completo e sim complementar suas caractersticas com outros mtodos.
TESTE DE USABILIDADE
Teste com usurio um mtodo fundamental de usabilidade. Desenvolvedores tradicionais resistem idia, dizendo que teste de usabilidade sem dvida alguma uma boa idia, mas limitaes de tempo e de recursos os impedem de faz-lo. Mas esse cenrio est mudando muito rapidamente. Gerentes de desenvolvimento esto percebendo que ter agendado testes de usabilidade um poderoso incentivo para o trmino da fase de design. E a surpresa que resultados prticos tm demonstrado que testes de usabilidade no somente tm acelerado muitos projetos como tambm tm produzido uma significativa reduo em seus custos (Gould and Lewis, 1985; Gould et al., 1991; Karat, 1994). O movimento em direo aos testes de usabilidade estimulou a construo de laboratrios de usabilidade (Dumas and Redisch, 1993; Nielsen, 1993). A IBM fez em Boca Raton, Flrida, uma sofisticada construo com 16 laboratrios dispostos em crculo com uma base de dados centralizada para registrar a performance e o log de uso de produtos testados. Muitas outras empresas seguiram o exemplo e abraaram a idia com bastante fora. Isso demonstra a crescente preocupao com o usurio, que est permeando a maioria dos desenvolvimentos atuais. Um laboratrio de usabilidade geralmente abriga uma pequena equipe de pessoas com experincia em teste e design de interface de usurio. A equipe do laboratro geralmente entra em contato com representantes da equipe de desenvolvimento no incio de um projeto, de forma a estabelecer um plano de teste com datas definidas e custos alocados. Ela tambm participa na fase inicial de anlise da tarefa e reviso de design, fazendo sugestes e provendo informaes, e ajudando no desenvolvimento do conjunto de tarefas para o teste de usabilidade. A disponibilidade de um laboratrio no deve ser considerada condio para a realizao de um teste de usabilidade e sim como uma grande facilitao. Quase todas as formas de teste podem ser feitas nos mais diversos locais, desde que devidamente preparados. Tambm no deve ser considerada uma condio a existncia de avaliadores experientes para se efetuar um teste. Bons resultados tm sido obtidos com experimentadores novatos que aprendem o mtodo de teste (Nielsen, 1992; Wright and Monk, 1991)
OBJETIVOS
E PLANO DE TESTE
Antes de qualquer teste ter inicio preciso estabelecer seus objetivos pois isso tem um impacto significativo no tipo de teste a ser feito. A principal distino se o teste tem como objetivo obter uma ajuda no desenvolvimento ou um teste que visa avaliar a qualidade global de uma interface. No primeiro caso interessa saber em detalhe quais aspectos da interface esto bons ou ruins, e como o design pode ser melhorado. uma forma mais gradual de analisar a interface, e nesse caso usualmente se aplica o teste denominado pensar em voz alta (thinking- aloud test) que veremos a seguir. No segundo caso, como se quer uma viso mais global de uma interface em fase final de definio geralmente se utiliza testes que dem medidas de performance que apresentaremos em sees a seguir. Em qualquer uma das situaes deve ser desenvolvido um plano detalhado de teste onde, dentre outras mais especficas, as seguintes questes devem ser respondidas: O objetivo do teste: o que se deseja obter? Quando e onde o teste ir acontecer? Qual a durao prevista de cada sesso de teste? Qual o suporte computacional necessrio? Qual software precisa estar a disposio? Qual dever ser o estado do sistema no inicio do teste? Quem sero os experimentadores? Quem sero os usurios e como sero conseguidos? Quantos usurios so necessrios? Quais as tarefas que sero solicitadas aos usurios? Qual critrio ser utilizado para definir que os usurios terminaram cada tarefa corretamente? Quanto o experimentador poder ajudar o usurio durante o teste? Quais dados sero coletados e como sero analisados uma vez que tenham sido coletados? Qual o critrio para determinar que a interface um sucesso? (p. ex: nenhum problema de usabilidade novo com severidade maior ou igual a 3)
Deve-se sempre estar atento a dois problemas vinculados a um teste de usabilidade: a confiabilidade e a validade. Como confiabilidade entendemos o grau de certeza de que o mesmo resultado ser obtido se o teste for repetido; e como validade, o fato dos resultados de teste refletirem os aspectos de usabilidade que se deseja testar. No quesito confiabilidade deve-se estar atento s diferenas individuais entre os usurios. Por exemplo, cuidar do grau de confiana que se d a afirmaes do tipo: usurio A usando a interface X executa uma tarefa 40% mais rpido que o usurio B usando a interface Y que no necessariamente significam que a interface A tem melhor qualidade, pois no incomum ter-se um grupo de usurios onde o melhor usurio 10 vezes mais
202 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ rpido que o mais lento e que os 25% melhores so 2 vezes mais rpidos que os 25% piores (Egan, 1988) Quanto validade, o que se gostaria de assegurar que o resultado obtido tenha realmente significado considerando-se o produto real em uso e fora da situao de laboratrio. Deve-se ento nesse ponto estar atento escolha dos usurios, escolha das tarefas e diferena entre equipamentos (situao de teste e situao real) A regra principal para se efetuar a escolha dos usurios que sejam to representativos quanto possvel com relao aos usurios reais do sistema. O ideal seria envolver usurios reais do sistema, mas isso nem sempre possvel. Se o grupo de sujeitos no composto de usurios reais, ele deve ter idade e nvel educacional similar ao grupo de usurios alvo. Tambm similar deve ser sua experincia com computadores, com o tipo de sistema que est sendo testado e o conhecimento do domnio da tarefa. Certamente no conveniente testar uma interface voltada para o pblico em geral e utilizar estudantes de computao como grupo de teste: eles certamente no so representativos da populao de usurios alvo. Os usurios devem ser tratados com respeito e principalmente serem informados de que a interface e no eles que esto sendo testados. Geralmente se sentem sob muita presso na situao de teste e isso os leva a aprenderem mais lentamente e a fazerem mais erros, sentindo-se estpidos quando experimentam dificuldades. Os experimentadores devem ser preparados no sentido de terem conhecimento extenso sobre a aplicao e a respectiva interface de usurio. No precisam saber como o sistema foi implementdo, mas devem estar prontos a lidar com problemas que afetem o teste, por exemplo, problemas que levem o sistema a cair. Nada impede que sejam os prprios designers desde que esses estejam preparados no sentido de manter uma certa iseno no sentido de no mascarar os resultados do teste. Geralmente eles tendem a ajudar muito os usurios e a antecipar situaes de erro, dado seu extenso conhecimento da interface. As tarefas a serem feitas durante um teste devem ser as mais representativas possveis e devem dar uma cobertura razovel das partes mais significativas da interface. Devem poder ser completadas no tempo definido para uma sesso de teste (de 1 a 3 horas). Devem ter grau de dificuldade gradativa para dar mais confiana ao usurio e devem ser planejadas para que possam ser interrompidas a qualquer tempo, caso o usurio assim o deseje. A descrio de cada tarefa a ser efetuada deve ser feita por escrito e deve ser to realista quanto possvel e inserida em um cenrio de uso. Geralmente, um teste piloto efetuado com um pequeno grupo (de 1 a 3) de usurios, para refinar todos os procedimentos definidos.
ETAPAS DE UM TESTE
Basicamente um teste composto de quatro etapas: Preparao Nessa etapa se garante que tudo estar pronto antes do usurio chegar. Muito cuidado deve ser tomado com relao aos equipamentos que sero utilizados, devem estar "limpos" (de resultados de outros teste, alarmes sonoros, etc). Introduo uma fase muito importante, onde os usurios so apresentados situao de teste e de alguma forma colocados a vontade. Alguns pontos que devem ser falados aos usurios nessa introduo podem ser destacados: O propsito do teste avaliar o sistema e no o usurio No devem se preocupar em ferir sentimentos dos experimentadores (designers) com suas observaes Os resultados do teste serviro para melhorar a interface do usurio Relembrar que o sistema confidencial e no deve ser comentado com outros (que inclusive podem vir a ser futuros usurios em outros testes) A participao no teste voluntria e podem parar a qualquer tempo Os resultados do teste no sero colocados publicamente e o anonimato do participante estar garantido Explicar sobre o uso de gravaes de vdeo ou audio que estaro sendo feitas (o ideal no gravar a face do usurio) Explicar que podem fazer qualquer pergunta durante o teste, mas que nem sempre o experimentador ir ajud-los ou responder suas questes Instrues especficas sobre a forma do teste (p. ex.: falar em voz alta, ou fazer as atividades o mais rpido que puder, etc.) Teste Durante o teste deve ser escolhido somente um experimentador para falar com o usurio, para evitar confuso, e importante que: evite qualquer tipo de comentrio ou expresses sobre a performance ou observaes do usurio evite ajudar o usurio, a no ser que ele esteja realmente em dificuldades muito graves Sesso final Depois do tempo definido para completar as tarefas - usualmente de 1 a 3 horas os participantes so convidados a fazerem comentrios ou sugestes gerais, ou a responderem um questionrio especfico.
Gravar em vdeo os participantes efetuando as tarefas sempre um recurso valioso para uma posterior reviso. Analisar vdeos um trabalho extremamente difcil e
204 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ tedioso, portanto sempre devem ser feitas cuidadosas anotaes ou coletados logfiles durante o teste de modo a reduzir o tempo dispendido em encontrar acontecimentos crticos (Harrison, 1991). A reao de designers vendo esses vdeos de usurios cometendo erros muito poderosa e motivadora. Quando designers vem usurios repetidamente acessando o menu errado, eles se convencem que rtulos e posies devem ser mudadas. Uma tcnica efetiva durante um teste de usabilidade solicitar que os usurios pensem em voz alta sobre o que esto fazendo. A atmosfera informal de uma sesso que usa essa tcnica extremamente agradvel, e freqentemente leva muitas sugestes espontneas de melhorias.
Os comentrios dos usurios devem ser criteriosamente analisados e nunca aceitos indiscriminadamente pois podem dar falsa impresso das razes de um determinado problema. Os usurios tm teorias nem sempre verdadeiras. A principal fora dessa tcnica mostrar o que os usurios esto fazendo e porque esto fazendo enquanto esto fazendo, evitando as racionalizaes posteriores. No sentido de incentivar o pensar em voz alta muitas vezes se coloca usurios trabalhando aos pares de forma a produzirem mais conversas a medida que um
Avaliao de Interfaces 205 ____________________________________________________________________ participante explica para o outro seus procedimentos, sem a inibio de estar falando com algum que "sabe mais" sobre o sistema. Essa alternativa muito usada em testes que envolvem crianas como sujeitos do teste. Outra alternativa ao pensar em voz alta fazer com que o usurio comente depois suas aes gravadas em vdeo. Isso auxilia quando se est tambm interessado em obter dados qualitativos de performance, mas deve ser levado em conta que todo o teste demora pelo menos o dobro do tempo.
MEDIDAS DE PERFORMANCE
Estudos de medidas quantitativas formam a base de muitas pesquisas tradicionais em fatores humanos, como visto no Captulo 2. Tambm so importantes em usabilidade para avaliar se os objetivos de usabilidade foram efetivamente atingidos e tambm para comparar produtos competitivos. Em usabilidade tem-se o critrio de eficincia de uso como uma das guidelines de usabilidade. Dentro desse, so fundamentais algumas medidas de performance na forma de tomadas de tempo, por exemplo. Como e quando marcar tempos deve ser decidido a priori de acordo com os dados necessrios na coleta. Por exemplo, se se quer saber quanto o usurio demora fazendo uma determinada tarefa preciso primeiro definir quando comea e quando termina a tarefa e depois se o tempo ser cronometrado pelo prprio usurio, pelo computador, pelo experimentados, etc. Medidas tpicas de usabilidade que so quantificveis incluem: O tempo que o usurio gasta para fazer uma determinada tarefa O nmero de tarefas de diferentes tipos que so completadas em determinado limite de tempo A razo entre interaes de sucesso e de erro O nmero de erros do usurio O nmero de aes errneas imediatamente subseqentes O nmero de comandos (ou diferentes comandos) ou outras caractersticas que foram utilizados pelo usurio O nmero de comandos ou outras caractersticas nunca utilizados pelo usurio O nmero de caractersticas do sistema que o usurio consegue se lembrar na sesso subseqente ao teste A freqncia de uso de manuais ou do sistema de help e o tempo gasto usando esses elementos do sistema Quo freqentemente o manual/sistema de help resolveu o problema do usurio A proporo entre comentrios do usurio favorveis e crticos com relao
206 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ ao sistema O nmero de vezes que o usurio expressou frustrao (ou alegria) A proporo de usurios que disse preferir o sistema a outro sistema competidor A proporo de usurios utilizando estratgias eficientes e ineficientes A quantidade de tempo morto - quando o usurio no est interagindo com o sistema (ou esperando resposta ou pensando) O nmero de vezes que o usurio desviou do objetivo da tarefa
Certamente somente um pequeno subconjunto de medidas pode ser coletado em uma particular situao de teste. A maioria dos testes de usabilidade so feitos em laboratrios onde os usurios so observados diretamente pelos avaliadores. Entretando, a localizao remota e distribuda dos usurios - freqentemente na rede, atualmente o principal ambiente para distribuio e uso de aplicaes de software, tais como os CSCW - dificulta, e at impede, a possibilidade da observao direta em testes de usabilidade. Tambm deve ser considerado que a rede em si e o trabalho remoto tm se tornado parte intrnseca de padres de uso. Adicionalmente, desenvolvedores muitas vezes tm dificuldade em conseguir usurios representativos que possam participar de testes de usabilidade nos laboratrios; e o contexto de trabalho do usurio dificilmente consegue ser reproduzido em situao de laboratrio. Todos esses fatores muitas vezes tornam o custo de um teste de usabilidade proibitivo. Essas barreiras para o teste de usabilidade tm levado uma extenso do teste para alm dos limites dos laboratrios e comeam a surgir mtodos de teste de usabilidade remotos, tipicamente usando a rede como uma ponte de acesso aos usurios em seu ambiente natural de trabalho. Define-se portanto um teste de usabilidade remoto como aquele em que o observador que efetua a observao e anlise e o usurio esto separados em tempo e espao. Alguns resultados preliminares apontam para a efetividade desses mtodos que usam tipicamente uma combinao dos mecanismos de comunicao eletrnicos, como tele-conferncia por exemplo, e software especificamente construdos para coletar dados de uso (Hartson et al, 1996) Temos tambm como modalidade de teste de usabilidade os denominados testes de campo que objetivam colocar novas interfaces em ambientes reais de uso por um determinado perodo de tempo. Testes de campo do melhor resultado quando se pode dispor de software que geram arquivos log que capturam erros, comandos usados, freqncia de acesso a helps e mais algumas medidas de produtividade. Quando se conta somente com a resposta do usurio os resultados no so muito satisfatrios. Somente cerca de 20% dos usurios inscritos participam ativamente do teste; os demais esto mais interessados em obter uma primeira verso do produto. Um dos maiores testes de campo j realizados foi o efetuado pela Microsoft na avaliao da verso Beta do Windows 95, onde cerca de 400.000 usurios em todo o
Avaliao de Interfaces 207 ____________________________________________________________________ mundo receberam verses preliminares do software e foram convidados a enviar comentrios.
CONSIDERAES FINAIS
Designers e profissionais de IHC procuram por mtodos rpidos e baratos de avaliao de interfaces em substituio aos testes de laboratrio que geralmente so caros e muitas vezes sem possibilidade de serem realizados por falta de condies estruturais. Em virtude dessa situao, as tcnicas de avaliao denominadas mtodos de inspeo de usabilidade foram propostas com a promessa de oferecer informao de usabilidade de modo mais rpido e barato que os tradicionais testes de usabilidade. Os mais populares desses mtodos incluem avaliao heurstica e percurso cognitivo vistos anteriormente em detalhe neste captulo. Esses mtodos, cada qual com seus procedimentos prprios, provem dados que podem ser usados quando testes de usabilidade no so possveis ou em conjuno com eles. Mas resultados de experimentos comparativos confirmam que at o momento eles no substituem os testes com usurio. Existe certamente um fator econmico a considerar na adoo de mtodos de inspeo mas a relao custobenefcio precisa ser bem analisada. Um amplo estudo (Desurvire, 1994) comparando testes de usabilidade, avaliao heurstica e percurso cognitivo apresenta alguns resultados interessantes: Os resultados dos mtodos de inspeo so melhores quando os avaliadores so especialistas em avaliao. Mesmo assim, no substituem o teste de usabilidade: nos experimentos relatados os melhores avaliadores, usando o mtodo de melhor performance, no detetaram em mdia 56% dos problemas encontrados no teste de usabilidade. Avaliao heurstica permite uma avaliao global da interface faciltando a identificao de melhorias na interface. Foi a mais eficaz na deteco de erros e principalmente na identificao da maioria de erros srios. Alm disso a de menor custo. Teste de usabilidade o mais eficaz em detetar erros, mas o mais caro. O custo de um teste de usabilidade da ordem de 50 vezes o custo dos mtodos de inspeo (isso est mudando com a introduo da metodologia de testes remotos). Todos os problemas srios so encontrados mas perde na deteco de consistncia Percurso cognitivo falha em identificar problemas gerais e recorrentes pois observa detalhes menores diretamente ligados execuo de uma tarefa. Foi
208 Design e Avaliao de Interfaces Humano-Computador ____________________________________________________________________ o que apresentou melhores resultados quando utilizado por no especialistas em usabilidade mas desenvolvedores de software. Cada mtodo tem pontos fortes e pontos fracos e ainda no se tem resultados substanciais de pesquisas comparando os mtodos para que se possa efetivamente dizer qual o melhor e em qual situao. Certamente cada situao de projeto ir requerer uma forma de avaliao. Acreditamos que o principal problema a no disponibilidade de especialistas em usabilidade em situaes de pequenas empresas desenvolvedoras de software (Chan e Rocha, 1996). Mas tendo como parmetro que qualquer avaliao melhor que nenhuma, ela deve ser feita de qualquer forma e a conseqente gerao de conhecimento em usabilidade ser uma das melhores conseqncias. Quanto Web no existem ainda metodologias especficas para avaliao de Web sites. Conforme visto do Captulo 1 guidelines comeam a ser definidas (Nielsen, 1999) e iro possibilitar a definio de mtodos de avaliao que levem em conta as especificidades desses design. Certamente os parmetros de usabilidade permanecem e no decorrer do livro muitos exemplos extrados de sistemas da Web foram mencionados, mas existe o componente da informao que certamente deve ser considerado em um processo de avaliao. Spool et al. (1999) relata alguns estudos de caso de avaliaes de Web sites. Eles consideram que informao o tema central e focalizam seus estudos em avaliar quanto um site bom em prover informao s pessoas de forma a auxili-las a tomarem decises. E concluem que quanto mais um site ajuda uma pessoa a encontrar a informao que est procurando mais usvel ele . De modo geral, so ainda resultados parciais quanto a usabilidade de sistemas baseados na Web e que ainda devero ser mais aprofundados e formalizados.
REFERNCIAS:
Carrol, J. M., e Rosson, M. B. (1987) The paradox of the active user. Em J.M. Carrol (ed.) Interfacing Thought: Cognitive Aspects of Human-Computer Interaction. Cambridge: Bradford Books/MIT Press Desurvire, H. W. (1994) Faster, Cheaper!! Are usability Inspection Methods as Effective as Empirical Testing? Em J. Nielsen (ed.) Usability Inspection Methods. John Wiley, New York Dix, A., Finlay, J., Abowd, G., Beale, R. (1998) et al. . Human-Computer Interaction. Prentice Hall Europe Dumas, J. and Redish, J. (1993) A Practical Guide to Usability Testing. Ablex, Norwood, NJ Egan, D. E. (1988) Individual differences in human-computer intercation. Em M. Helander (ed.). Handbook of Human-Computer Interaction. Amsterdam: Elsevier Science Publishers Engelbeck, G. E. (1986) Exceptions to generalizations: Implications for formal models of human-computer interaction. Master Thesis. Department of Psychology, University of Colorado, Boulder Fisher, G. (1991) Supporting learning on demand with design environments. Proceedings of the International Conference on Learning Sciences (Evanston, IL, August): 165-172 Gould, J. D., e Lewis, C. (1985) Designing for usability: Key principles and what designers think. Communications of the ACM 28, 3:300-311 Gould, J., Boies, S. J., e Lewis, C. (1991) Making usable, useful, productivityenhancing computer applications. Communications of the ACM 34, 1: 74-85 Greenbaum, J., Kyng, M. eds. (1991) Design at Work: Cooperative Design of Computer Systems. Hillsdale, NJ: Lawrence Erlbaum Assoc. Hartson, H. R., Castilho, J. C., Kelso, J. (1996) Remote Evaluation: The Network as an Extension of the Usability Laboratory. Disponvel na Web em http://www.acm.org/sigchi/chi96/proceedings/papers/Hartson/hrh_texto.htm. Consulta 09/03/2000 Hix, D. and Hartson, H. R. (1993) Developing User Interfaces: Ensuring Usability Through Product and Process. John Wiley and Sons, New York
Kahn, M.J., Prail, A. (1994) Formal usability Inspections. Em J. Nielsen (ed.) Usability Inspection Method. John Wiley, New York Karat, C. (1994) A Comparison of user Interface Evaluation Methods. Em J. Nielsen (ed.) Usability Inspection Methods. John Wiley, New York Lewis, C. (1982) Using the 'thinking-aloud' method in cognitive interface design. IBM Research Report RC9265 (#40713), IBM Thomas J. Watson Research Center, Yorktown Heights, NY Lewis, C., Polson, P., Wharton, C. and Rieman, J. (1990) Testing a walkthroug methododology for theory-based design of walk-up-and-use interfaces. Proceedings ACM CHI'90 Conference (Seattle, WA, April 1-5):235-242 Molich, R. and Nielsen, J. (1990) Improving a human-computer dialogue. Communications of the ACM 33,3: 338-348 Monk, A., Wright, O., Haber, J., Davenport, L. (1993) Improving your HumanComputer Interface: A Practical Technique. New York: Prentice-Hall Nielsen J. (1989) Usability engineering at a discount. Em G. Salvendy et al. (eds.). Designing and Using Human-Computer Interfaces and Knowledge Based Systems. Amsterdan:Elsevier Science Publishers Nielsen, J. (1992) Finding usability problems through heuristic evaluation Proceedings ACM CHI'92 Conference (Monterey, CA, May 3-7): 373-380 Nielsen, J. (1993) Usability Engineering. Academic Press, Cambridge, MA Nielsen, J. (1994) Heuristic Evaluatin. Em J. Nielsen (ed.) Usability Inspection Methods. John Wiley, New York Nielsen, J. (1999) Design Web Usability. New Riders Publishing Polson, P. e Lewis, C. (1990) Theory-based design for easily learned interfaces. Human Computer Interaction 5, 2&3:191-220 Polson, P., Lewis, C., Rieman, J. e Wharton, C. (1992a) Cognitive Walkthroughs: A method for theory-based evaluation of user interfaces. International Journal of ManMachine Studies, 36:741-773 Preece, J., Sharp, H., Benyon, D., Holland, S., Carey, T. (1994) Human-Computer Intercation, Addison-Wesley
Avaliao de Interfaces 211 ____________________________________________________________________ Spool, J., Scanlon, T. Schoeder, W. Snyder, C. e DeAngelo, T. (1999) Web Site Usability: A Designers Guide. Morgan Kaufmann Publishers Romani, L. S. e Baranauskas, M.C.(1998) Avaliao heurstica de um sistema altamente dependente do domnio. Relatrio Tcnico IC-98-26 , July. Disponvel na Web em: http://www.dcc.unicamp.br/ic-tr-ftp/ALL/Titles.html Chan, S. e Rocha, H.V. (1996) Estudo comparativo de mtodos para avaliao de interfaces homem-computador.Relatrio Tcnico IC-96-05, September. Disponvel na Web em: http://www.dcc.unicamp.br/ic-tr-ftp/ALL/Titles.html Schneiderman, B. (1998) Design the User Interface: Strategies for Human-Computer Interaction. Addison Wesley Longman, Inc. Wharton, C., Rieman, J., Lewis, C., Polson, P. (1994) The Cognitive Walkthrough: A Practitioners Guide. Em J. Nielsen (ed.) Usability Inspection Methods. John Wiley, New York Whitefield, A., Wilson, F., and Dowel, J. (1991) A framework for human factors evaluation. Behaviour & Information Technology 10, 1 (January-February), 65-79 Wright, P. C. and Monk, A. F. (1991) The use of think-aloud evaluation methods in design. ACM SIGCHI Bulletin 23, 1:55-71