Material Complementar - Avaliacao Heuristica

7/31/2019 Material Complementar - Avaliacao Heuristica

1/21

23Avaliao Heurstica

Avaliao Heurstica Even finding some problems is of course much better than finding no problems...

Jakob Nielsen and Rolf Molich

1. A avaliao

Existem basicamente 4 maneiras para se avaliar uma interface com usurio: formalmente,atravs de uma tcnica de anlise; automaticamente, por um procedimentocomputadorizado; empiricamente, por experimentos com testes de usurios; eheuristicamente, simplesmente percorrendo a interface e julgando-a de acordo com suaprpria opinio.

Os princpios bsicos de usabilidade envolvem trs categorias principais: facilidade com quenovos usurios podem efetivamente comear a interagir e alcanar mxima performance;

multiplicidade de maneiras com que o usurio e o sistema trocam informao; e o nvel desuporte que o usurio tem para determinar seu sucesso e a avaliao de suas metas[Romani & Baranauskas, 1998].

A inteno bsica da avaliao identificar elementos que possam causar dificuldades aousurio, porque violam princpios cognitivos conhecidos ou ignoram os resultados empricos

j bem aceitos. So 3 as metas principais da avaliao: examinar a funcionalidade dosistema, o efeito da interface no usurio e identificar problemas especficos de design. Omtodo de avaliao heurstica foca na terceira meta, que relaciona tanto funcionalidadequanto usabilidade da interface. Trata-se de identificar os aspectos negativos do design:elementos que, quando usados em seu contexto intencional, causam resultados inesperadosou confuso entre os usurios [Romani & Baranauskas, 1998].

A avaliao heurstica envolve especialistas avaliando um design com base em um conjuntode critrios de usabilidade ou heursticas. O design examinado em busca de instncias nasquais esses critrios so violados. Um conjunto de critrios proposto originalmente por[Molich & Nielsen, 1990] inclui:

Dilogo simples e natural;

Falar a lngua do usurio;

Minimizar a carga de memria do usurio;

Consistncia;

FeedBack;

Sadas marcadas claramente;

Atalhos;

Mensagens de erro precisas e construtivas;

Prevenir erros.

1.1 O custo-benefcio

Testes de usabilidade podem geralmente requerer custos muito altos. O mtodo descritoaqui tenta diminuir os custos da avaliao apenas prevendo aspectos de uso ao invs deobserv-los diretamente. Esse mtodo no envolve usurios, mas sim, certa forma de


2/21

inspeo. Como no envolve usurios, a avaliao heurstica se torna um mtodo rpido ebarato. Alm disso, no so necessrios equipamentos especiais.

Molic e Nielsen [Molich & Nielsen, 1990] planejaram esse mtodo conhecido comoavaliao heurstica, em resposta necessidade de mtodos de baixo custo que pudessemser utilizados por pequenas empresas que no possuem facilidades, tempo, dinheiro oupessoal treinado para a engenharia de usabilidade. Na avaliao heurstica, so utilizadosavaliadores,no lugar dos usurios, que examinam o sistema ou prottipo, guiados por umconjunto de heursticas de alto nvel [Nielsen, 1992].

A avaliao heurstica uma tcnica analtica e informal, que faz parte da chamadadiscount usability engineering, um mtodo barato, rpido e fcil de usar. Alm disso, aliteratura tem mostrado, em estudos experimentais comparativos com outras tcnicas deavaliao, que a avaliao heurstica tem apresentado melhores resultados, encontrandoproblemas mais srios com menos esforo despendido [Jeffries et. al., 1991][Nielsen,1994][Romani & Baranauskas, 1998].

Figura 1 A curva mostra a razo custo-benefcio, i.e., quantas vezes os benefciosso maiores do que os custos. Por exemplo, a razo igual a 50 provavelmente

corresponder para um custo de R$ 1.000, um benefcio de R$ 50.000.

1.2 Os avaliadores

Testes empricos realizados com diversos avaliadores em vrios estudos da literaturaenvolvendo o mtodo de avaliao heurstica induzem seguinte corrente de pensamento,na qual validaremos no nosso estudo de caso na Seo 3 adiante. Estudos iniciais em[Nielsen, 1989],[Molich & Nielsen, 1990]e[Nielsen & Molich, 1990] mostram quealguns avaliadores obtm resultados melhores do que outros, mas no se engane achando

que os avaliadores ditos bons (mais qualificados, com mais experincia e maiorconhecimento do domnio especfico) obtiveram melhores resultados que os ruins(iniciantes na engenharia de usabilidade). Esse o grande mrito do mtodo de avaliaoheurstica, rpido, prtico, fcil de aprender e barato (por no despender de especialistas).Estudos mostraram que os bons avaliadores so mais eficientes, mas isso no indica queesses avaliadores conseguem descobrir todos os problemas dos avaliadores novatos. Em[Nielsen & Molich, 1990] e [Baker et. al., 2002] foram demonstrados que mesmo osavaliadores inexperientes conseguem descobrir problemas graves na interface, alm clarodos problemas mais fceis que os avaliadores mais experientes acabam s vezes passando


3/21

despercebidos. Estudos em diversas interfaces mostram que pessoas diferentes encontramdiferentes problemas de usabilidade.

AFigura 2 extrada de [Nielsen, 1994] e[Baker et. al., 2002] relacionadas a problemasem interfaces diferentes, comprovam a hiptese levantada anteriormente:

Figura 2 Cada linha representa um avaliador e cada coluna representa um problemade usabilidade. O quadrado preto representa se o problema foi encontrado pelo

avaliador.

Esses grficos mostram que mesmo avaliadores ruins conseguem encontrar os problemasmais graves, que so os mais importantes e o real objetivo de uma boa avaliao. Dessaforma, Nielsen conclui que a melhor forma de se realizar uma avaliao heurstica seria comum agregado de avaliadores escolhidos aleatoriamente, no importando o grau deconhecimento de cada avaliador. Ao final da avaliao individual, as listas de problemas deusabilidade devem ser reunidas e discutidas pelo grupo de avaliadores ou por um perito,para que seja feita uma nica lista com todos os problemas de usabilidade encontrados.

Bom, descobrimos que no necessariamente precisamos de peritos para avaliar umainterface, mas quantos avaliadores devem ser usados para que obtenhamos um bomresultado? Essa pergunta foi bastante explorada na literatura, e podemos encontrar diversasrespostas que entram em consenso[Nielsen & Molich, 1990][Baker et. al., 2002]. De

acordo com a Figura 3, conclui-se que so necessrios de 3 a 5 avaliadores para que sejamencontrados uma mdia de 60-80% dos problemas da interface avaliada. Pode parecerinsuficiente, porm se voc considerar que se trata de um mtodo barato, intuitivo, de fcilmotivao para faz-lo, no requer um plano avanado e, alm disso, possui rpidaaplicao podemos concluir que um resultado muito bom. importante observar que, sedesejar uma soluo melhor basta seguir a curva do grfico, ou seja, aumente o nmero deavaliadores, utilize tambm alguns avaliadores mais experientes e com maior conhecimentodo domnio, mas tudo isso tem um preo, voc est disposto a pagar e ter tempo paraisso? Lembre-se que achar algum problema melhor do que nenhum.


4/21

Figura 3 Proporo de problemas de usabilidade encontrados utilizando avaliaoheurstica pela mdia de 6 estudos de caso [Nielsen, 1994].

Nielsen em [Nielsen, 1994] recomenda que sejam usados cinco avaliadores. Dessa forma,

com a economia realizada, podem-se realizar outros mtodos de avaliao para que outrosproblemas sejam detectados ou mesmo para afirmar a eficincia do mtodo de avaliaoheurstica [Nielsen & Molich, 1990], j que existe certa crtica em relao ao uso demtodos no estatsticos, comprovado por [Lieberman, 2003] que teve um artigorejeitado por no ser emprico o bastante.

2. Mtodo de Avaliao Heurstica

De acordo com [Nielsen, 1993], cada avaliador normalmente faz duas ou mais iteraessobre a interface para:

Inspecionar o fluxo da interface de uma tela para outra,

Inspecionar cada tela por vez contra as heursticas, examinando caractersticascomo mensagens do sistema, dilogos e assim por diante dentro do escopo dasheursticas.

Uma sesso tpica ir durar entre uma e duas horas, mas se a interface for grande pode sernecessrio um tempo maior. Nas sesses de avaliao, cada avaliador conduz sua avaliaoindividualmente e independentemente dos outros avaliadores, ele no deve discutir com osoutros at que todas as avaliaes estejam prontas. Quando todos os avaliadoresterminarem, eles devem juntar seus problemas em apenas uma nica lista de problemas deusabilidade [Preece et. al., 1994].

O mtodo de avaliao heurstica deve ser visto como parte do processo de designinterativo de uma interface. Ele envolve um pequeno conjunto de avaliadores examinando ainterface e julgando suas caractersticas em face de reconhecidos princpios de usabilidade,

as heursticas [Rocha & Baranauskas, 2000].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 literatura temmostrado que diferentes pessoas encontram diferentes problemas, e, portanto se melhorasignificativamente os resultados da avaliao heurstica utilizando mltiplos avaliadores. Arecomendao que se use de trs a cinco avaliadores (Seo 1.2) [Nielsen, 1992].

2.1 Heursticas revisadas


5/21


6/21

2. Introduo: apresentao de informao aos avaliadores, incluindo objetivos,princpios (heursticas) e material de apoio (formulrios, exemplos, manuais, etc.).

3. Avaliao da Interface: avaliadores testam a interface em busca de problemas deusabilidade. Os problemas encontrados devem ser registrados.

4. Discusso: avaliadores e desenvolvedores (opcional) renem-se para discutir osproblemas detectados e atribuir um grau de severidade aos mesmos.

5. Apresentao dos resultados: divulgao dos problemas e determinao dos maisgraves, que devem ser corrigidos.

Embora represente um aumento no custo, realizar uma avaliao heurstica semespecialistas em usabilidade impossvel. Ao menos um indivduo (orientador) necessriopara apresentar os princpios aos no-especialistas e realizar uma discusso paradeterminar a gravidade dos problemas. Tais discusses ocorrem aps as sesses deinterao e correspondem exposio de problemas encontrados e atribuio consensual degraus de severidade aos mesmos.

Independentemente do perfil e experincia dos avaliadores escolhidos, este mtodo exigeque a interface esteja funcionalmente disponvel, ou seja, implementada, ao menosparcialmente ou como prottipo para que os avaliadores possam utiliz-la. Isto limita aaplicabilidade do mtodo em fases iniciais de um ciclo de desenvolvimento de interface,retardando a descoberta de problemas [Chan & Rocha, 1996].

2.3 Exemplos

A seguir, so apresentados alguns problemas detectados em avaliaes heursticasextrados de [Rocha & Baranauskas, 2000]:

Exemplo1

O antivrus Norton 2000 para NT Server um software projetado para proteger servidoresde rede Windows NT de arquivos infectados por vrus. O software executado no servidorNT e sempre que se tenta gravar/abrir algum arquivo infectado no servidor, o programaapresenta uma mensagem na tela do servidor avisando que o arquivo est infectado, masos usurios em estaes cliente NT no recebem esse aviso. Tem-se, portanto, a heurstica

visibilidade do status do sistema violada. Consequentemente, quando o usuriotrabalhando em uma estao cliente tenta gravar um arquivo infectado no servidor oantivrus impede a gravao e no emite nenhuma mensagem para a estao cliente e ousurio pode ento perder seu trabalho sem saber que isso est ocorrendo. O resultado aperda do arquivo, o que teria sido facilmente prevenido se alguma mensagem de alertafosse exibida estao cliente. Claramente a heurstica ajudar usurios a reconhecer,diagnosticar e corrigir erros tambm violada. Pode-se dizer que a heurstica prevenode erros tambm no respeitada.

Exemplo 2

No sistema Windows quando se quer instalar um novo componente de hardware iniciadoum processo de busca e o indicador de deteco pode ficar parado por muito tempo, comoindicado na janela de dilogo na Figura 4. O usurio fica perdido na maioria das vezes porno saber o que significa esse muito tempo e no sabe se deve ou no reiniciar ocomputador, mesmo porque usurios de sistemas semelhantes sabem quo pouco confivel a relao da barra de deteco com o real andamento da operao (visibilidade dostatus do sistema; ajudar usurios a reconhecer, diagnosticar e corrigir erros).


7/21

Figura 4 Deteco de hardware do sistema Windows 98.

Exemplo 3

O software Winzip em uma mesma verso gratuita (no registrada) tem uma tela deabertura onde os botes aparecem em ordem aleatria a cada execuo (Figura 5).Arbitrariamente os botes I Agree e Quit aparecem em ordem trocada levando o usurio a

errar sem saber por que (consistncia e padres; preveno de erros).

Figura 5 Tela de abertura da cpia para avaliao do software Winzip.

Exemplo 4

No Windows Explorer, ao tentarmos excluir um arquivo que est em uso, uma caixa dedilogo aberta (Figura 6). Nessa caixa aparece a mensagem de que no foi possvelacessar 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: oque tem a ver disco cheio com excluir um arquivo (ajudar usurios a reconhecer,diagnosticar e corrigir erros)!

Figura 6 Mensagem de erro do Windows Explorer.

Exemplo 5

No Adobes ImageReady a mensagem de erro da Figura 7 apresentada para o usurio. Amensagem diz que a aplicao no pde ser iniciada porque um ponteiro estava nil.


8/21

Qualquer usurio que no tenha experincia com programao no consegue entender oreal motivo do erro e nem corrigi-lo (coerncia do sistema com o mundo real; ajudarusurios a reconhecer, diagnosticar e corrigir erros).

Figura 7 Mensagem de erro do Adobes ImageReady.

Exemplo 6

No dilogo da Figura 8, a ferramenta Oracles SQL*Net Easy Configuration apresenta umproblema de usabilidade, pois existe uma redundncia de funes (Cancel e ExitSQL*Net...). O usurio acaba ficando confuso, quando na verdade todas conduzem aomesmo resultado (esttica e design minimalista).

Figura 8 Oracles SQL*Net Easy Configuration utility.

Com esses exemplos, podemos, de forma mais clara, perceber que o diagnstico de umproblema associado com as heursticas que foram consideradas traz possibilidadesconcretas de redesign, embora esse no seja o principal objetivo desse mtodo.

2.4 Graus de severidade

O uso efetivo de uma lista de problemas de usabilidade ir requerer que esses problemassejam priorizados com relao gravidade de cada problema. Prioridades so necessriaspara no se despender esforos desproporcionais corrigindo problemas que no iro alterarem muito a interao do usurio com a interface. Graus de severidade so geralmentederivados do impacto gerado pelo problema tanto no usurio quanto no mercado. Por seremmuitas vezes critrios dependentes da aplicao, a definio de graus de severidade no muito bem estabelecida na literatura, mas alguns autores do exemplos de como atribuirgraus de severidade problemas de usabilidade [Nielsen, 1994].

Precisa ser estimado o custo associado implementao das sugestes de redesign.

Certamente, problemas de usabilidade com alto grau de severidade devem ser corrigidosno interessando o quanto custe. Freqentemente, muitos dos problemas no muito gravespodem ser corrigidos com alteraes mnimas de cdigo. Esse compromisso no pode serconsiderado como parte do mtodo de inspeo de usabilidade, pois prefervel ter umarelao completa de todos os problemas sem o pr julgamento da viabilidade ou no da suacorreo. Esta informao importante no momento em que forem alocados recursos paracorrigir os problemas mais srios e se necessrio deixar os menos graves para uma novaverso.

A gravidade de um problema a combinao de trs fatores:


9/21

A freqncia com que ele ocorre: se comum ou raro;

Impacto do problema quando ele ocorre: se fcil ou difcil para o usuriosuper-lo;

A persistncia do problema: problema que ocorre uma nica vez e que ousurio 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, poismuitos problemas simples de serem superados tm um efeito importante na popularidadede um produto[Rocha & Baranauskas, 2000].

difcil conseguir uma boa estimativa de severidade por parte dos avaliadores durante umasesso de avaliao heurstica, pois os avaliadores esto concentrados em encontrar novosproblemas de usabilidade. Tambm, cada avaliador ir apenas encontrar um pequenonmero de problemas, ento a classificao dos problemas do usurio estar incompleta emrelao lista de problemas detectados. Ao invs disso, graus de severidade podem sercoletados atravs de questionrios entregues aos avaliadores depois das sesses deavaliao, listando todos os problemas de usabilidade descobertos, e pedindo a classificaode cada problema. Visto que cada avaliador s identificar um pequeno conjunto de

problemas includos na lista, os problemas precisam estar bem descritos. As descriespodem ser resumos das descries dos problemas encontrados pelos outros avaliadores.Essas descries permitem que os avaliadores avaliem os diversos problemas mesmo queeles no os tenham encontrado. Tipicamente, os avaliadores gastam apenas 30 minutospara fornecer seus graus de severidade. importante notar que cada avaliador devefornecer seus prprios graus de severidade independentemente dos outros avaliadores.

Geralmente, os avaliadores no tero acesso ao sistema enquanto eles esto considerandoa severidade dos vrios problemas de usabilidade. possvel que os avaliadores consigamganhar uma percepo adicional re-visitando partes da interface em execuo do queapenas contando com suas memrias e com as descries dos problemas. Ao mesmotempo, no h dvida de que os avaliadores sero mais lentos se recorrerem a mais umainterao com o sistema. Alm disso, problemas de agenda iro certas vezes tornar difcil

fornecer equipamentos para todos os avaliadores em uma hora conveniente se recursosespeciais so necessrios para executar um sistema prottipo ou se a distribuio dosoftware est limitada devido a certas restries (e.g. um projeto confidencial).

Nielsen ressalta que graus de severidade fornecidos de apenas um avaliador no soconfiveis. Quanto mais avaliadores fizerem o julgamento da severidade dos problemas deusabilidade, maior ser a qualidade da mdia de classificao de severidade, e o uso damdia de classificao feita por trs avaliadores satisfatria para muitos propsitosprticos.

2.5 Extenso das heursticas originais

Alm das heursticas propostas originalmente por Molich e Nielsen em considerao a todosos elementos do dilogo, o avaliador, obviamente, pode considerar qualquer princpio de

usabilidade adicional ou resultados relacionados que possam ser pertinentes a elementos dedilogo especfico. Alm disso, possvel desenvolver heursticas especficas de categoriaque so aplicadas a uma classe especfica de produtos como complemento s heursticasgerais. Uma forma de construir uma lista suplementar de heursticas especficas de umdomnio, executar uma anlise competitiva, testes com usurios em produtos existentesno domnio desejado e tentar abstrair princpios que explicam os problemas de usabilidadeencontrados.


10/21

Diversos trabalhos foram realizados com o objetivo de estender as heursticas gerais[Romani & Baranauskas, 1998],[Baker et. al., 2001] e[Baker et. al., 2002]. Neles,foram discutidos princpios que visavam um escopo especfico de um determinado domniopara uma dada interface. Por exemplo, as heursticas utilizadas para avaliao de umainterface ditavam o escopo da avaliao, ou seja, em [Baker et. al., 2001] o alvo deavaliao era o quanto o seu ambiente de groupware motivava a colaborao entre os

usurios. Para isso, so necessrias heursticas especficas para trabalho em equipe, ouseja, heursticas projetadas para identificar problemas de usabilidade especficos paratrabalho em grupo, entre equipes separadas por uma grande distncia para trabalharemsobre uma interface de trabalho visual compartilhada. Uma das heursticas criadas era:

Facilitar o descobrimento de colaboradores e estabelecer contato: amaioria dos encontros so informais, no programados, espontneos ou iniciados poruma pessoa. No dia-a-dia, estes encontros so facilitados pela proximidade fsica,onde indivduos prximos podem manter conscincia sobre quem est por perto.Pessoas freqentemente entram em contato com outra atravs de interaes casuais(e.g. se encontrando casualmente em um corredor) e so capazes de iniciar econduzir a conversa sem esforo. No pouco tempo durante a conversa, muito podeacontecer, como a troca de informaes e coordenao de aes. Em comunidades

eletrnicas, a falta de proximidade fsica significa que outros mecanismos sonecessrios para suportar a conscincia e o encontro informal.

Note que a heurstica acima no se encaixa nas heursticas gerais definidas anteriormente,esta avalia um domnio especfico. Veja que os avaliadores esto interessados em avaliaresta caracterstica da interface, o que impede uma perda de tempo e dinheiro avaliandoaspectos da interface que no interessam aos usurios especficos da aplicao. Issosignifica que as heursticas podem ser usadas para avaliao de um aspecto especfico dainterface, elas mesmas ditam o escopo da avaliao. Da a importncia de uma escolha debons princpios de avaliao.

Em [Romani & Baranauskas, 1998] foram definidas heursticas para outro contexto. Ainterface sendo avaliada era um Sistema de Acompanhamento e Avaliao de RebanhosLeiteiros (ProLeite), que usado na organizao das informaes de desempenho produtivoe reprodutivo dos animais de rebanhos leiteiros. O sistema possui grande quantidade deformulrios para entrada de dados, possibilita consultas e emisso de relatrios. Paraatender a categoria de usurios no domnio considerado, que possuem pouca preciso paramovimentos leves e precisos, pois so usurios acostumados a equipamentos pesados erudes como a enxada, [Romani & Baranauskas, 1998] propuseram diversas heursticasque complementam as heursticas gerais. Uma das heursticas propostas era:

Permitir opes de configurao: para facilitar o uso do mouse para usurioscom dificuldade de manipulao deste perifrico, o sistema deve permitir alterar otamanho dos botes para tamanhos maiores. Alm disso, o sistema deve permitir aalterao das cores dos rtulos e cor dos campos de entrada, para facilitar a leitura eprever a possibilidade de execuo do sistema em qualquer tipo de configurao detela (por exemplo, 640X480, 800X600, fontes grandes e pequenas, etc) sem perdade qualidade dos dilogos.

Mas nem tudo perfeito. A extenso das heursticas gerais tambm pode causar problemas.[Baker et. al., 2002] mostrou que a avaliao com as heursticas especficas para umdomnio obteve um desempenho inferior s avaliaes realizadas com as heursticas gerais.Baker atribuiu esse resultado ao fato de que os avaliadores podem ter achado as heursticasespecficas mais difceis de aprender e aplicar do que as heursticas de Nielsen. Mesmoassim, as heursticas especficas obtiveram um resultado satisfatrio considerando o custo-benefcio da avaliao.


11/21

3. Estudo de caso: OriOn

OriOn[1] um grupo de discusso utilizado na Universidade Federal de Ouro Preto paraensino e pesquisa da disciplina Sistemas Interativos. Um grupo de discusso umalocalizao online onde as pessoas interagem com outras atravs da colocao e leitura demensagens sobre tpicos de interesse pessoal e para a comunidade.

O OriOn foi escolhido para realizar a avaliao heurstica justamente para explorar o poderda extenso das heursticas, pois para fazer esse estudo seria interessante definirheursticas especficas para o domnio em questo: comunidades online.

Definida a interface que ser avaliada, seguiremos o processo de avaliao heursticaatravs das etapas de avaliao (Seo 3.1). Definidas as etapas do processo, devemosdeterminar o nmero de avaliadores que sero utilizados (Seo 3.2). Aps a realizao daavaliao e coleta dos dados, faremos a anlise dos resultados (Seo 3.4) comparandocom trabalhos relacionados da rea [Nielsen & Molich, 1990] [Baker et. al., 2002].

3.1 Etapas da avaliao

As etapas para a avaliao heurstica sobre a interface do OriOn so as mesmas definidas

na Seo 2.2, porm existe uma etapa adicional inicial para definir as heursticasespecficas para comunidades online (discutidas na Seo 3.3). Os resultados de cadaetapa do processo de avaliao heurstica sero discutidos na Seo 3.4. As etapas so:

1. Definio das heursticas: especficas para comunidades online, ditando o escopo daavaliao;

2. Definio dos requisitos da avaliao: objeto de avaliao (OriOn), avaliadores (Seo3.2);

3. Introduo: apresentao de informao do mtodo aos avaliadores, incluindo asheursticas para comunidades online (Seo 3.3);

4. Avaliao da interface: os avaliadores testam a interface em busca de problemas queinfrinjam as heursticas apresentadas. Os problemas devem ser registrados;

5. Discusso: um orientador reunir todos os problemas encontrados pelos avaliadores e

eliminar os problemas redundantes. Atribuio de graus de severidade no sernecessria j que o objetivo do nosso estudo no corrigir a interface avaliada;

6. Apresentao dos resultados: divulgao dos resultados obtidos comparados comtrabalhos relacionados [Nielsen & Molich, 1990] [Baker et. al., 2002].

3.2 Avaliadores

O objetivo desse estudo de caso fazer um comparativo com outros trabalhos queutilizaram a avaliao heurstica. Para isso, acompanhando a curva da Figura 3, foramnecessrios apenas quatro avaliadores para realizar toda a avaliao de forma satisfatria.Os avaliadores foram selecionados entre estudantes do curso de Cincia da Computaoque j fizeram alguma disciplina da rea de IHC. Assim, todos os avaliadores tiveramalguma experincia em relao aos conceitos de sistemas iterativos.

3.3 Heursticas

Para que a avaliao da interface do OriOn seja feita sobre os aspectos relevantes de umacomunidade online, foram definidas algumas heursticas que levam em consideraoprincpios como sociabilidade e usabilidade para ambientes online. Para isso, devemoslembrar que:

Comunidades so dinmicas; mudam e evoluem constantemente, influenciadaspela personalidade dos participantes, atividades do grupo, e por algumas influncias


12/21

externas. Por exemplo, o que pode ser importante no incio de uma comunidade podeno ser mais tarde.

Tecnologia no o fator mais importante em comunidades online. Membrosso.

A partir de guias definidos em [Preece, 2000] e de um estudo sobre as expectativas de

usurios potenciais a respeito de grupos de discusso virtuais [da Silva et. al., 2003],podemos definir algumas heursticas:

1. Definir um propsito claramente: uma comunidade deve possuir um nome claro esignificativo e conter uma descrio clara e concisa sobre o seu propsito.

2. Prover acesso: para que os usurios tenham acesso comunidade necessrio queseja descrito claramente os requerimentos tcnicos e outras informaes adicionaisessenciais para o acesso dos usurios. No utilizar URLs longos e com caracteresincomuns. Utilizar cores padres para os links (e.g. azul, para links no seguidos, evermelho, para links j visitados), a mudana dos padres pode causar confuso.Prevenir perodos longos de download, limitando o uso desnecessrio de grficos eanimaes que podem se tornar cansativos para os usurios em futuros acessos.

3. Facilitar a comunicao: ajudar os participantes a fazerem suas intenes claras

provendo emoticons e um menu de gestos auxiliam o processo de comunicao.Prover ferramentas de edio (e.g. fontes, smbolos, verificador ortogrfico, etc.) paraa postagem de falas. Disponibilizar diferentes formas de visualizao e estruturaoda discusso para que cada usurio se sinta confortvel com a de sua preferncia.Deve-se distinguir as mensagens que j foram lidas das que ainda no foram. Permitirque seja realizado um certo tipo de filtragem de informao e fornecer resumos sobreas discusses.

4. Motivar a comunidade: as discusses em uma comunidade online devem ter umauxlio para que sejam efetivas para todo o grupo de discusso. Para isso, deve-seencorajar a confiana, empatia e cooperao dos participantes. Focar no propsito dacomunidade aumenta a proximidade entre os membros. Estabelecer polticas, paraencorajar o processo de comunicao, ajuda a conter agresses e outros tipos decomportamentos inapropriados.

5. Definir uma poltica de registro: deve-se definir uma poltica de registro de novosusurios, bem como uma poltica que permita ou no a entrada de visitantes nacomunidade. Os procedimentos de registro e login devem ser realizados com o menornmero de passos possveis e descritos claramente. Incluir uma ajuda para essasatividades auxilia o processo, bem como uma forma de usurios recuperarem emodificarem suas senhas de maneira rpida, fcil e segura.

6. Garantir segurana: uma comunidade deve proteger informao confidencial. Paraisso, toda informao, das discusses realizadas, deve permanecer na comunidade etodos os membros devem concordar com uma poltica de privacidade.

7. Navegao:deve-se prevenir a ocorrncia de pginas rfs, que no esto ligadas aosite da comunidade, levando os usurios a becos sem sada. Para que a navegaoocorra de forma satisfatria, deve-se fornecer um suporte, ou seja, um mapa de site

claramente definido. Esse mapa deve aparecer em qualquer lugar que o usurio estejano site, para que auxilie os usurios a criarem um modelo mental de como partesdiferentes do site se inter-relacionam.

8. Consistncia das informaes: manter as informaes atualizadas e completas.Manter a consistncia tambm muito importante (terminologias, fontes, nome demenus, navegao, etc.).

9. Participao na gesto: lembre-se de que quem mantm a comunidade so os seusmembros, por isso, deve existir algum mecanismo que delegue alguma forma degesto para os membros da comunidade. Decises de acesso, por visitantes, s


13/21

discusses do grupo; decises a respeito de membros que no contribuem nasdiscusses; decises sobre a aparncia do grupo, etc.

3.4 Resultados

Depois de realizada a avaliao e coletados os problemas encontrados pelos avaliadores, osproblemas redundantes foram eliminados e o restante dos problemas foram contabilizados

em um total de 17 infraes das heursticas para comunidades online:Problema 1. No existecomo opo exibir o nome do grupo e muito menos uma descrioclara sobre o seu propsito. O usurio que est entrando no grupo, no tem como saberqual o seu propsito (Figura 9). Antes de logar ou de cadastrar, o usurio no tem nenhumadescrio sobre do que se trata o grupo, e nem em qual est cadastrado, mesmo depois deestar logado, ele no tem nenhuma descrio do grupo. Uma soluo seria para todos osgrupos, colocar uma breve descrio do grupo, com os seus propsitos bem claros para oque o usurio possa saber se realmente o que ele esperava. (Definir um propsitoclaramente).

Figura 9 Tela inicial do OriOn.

Problema 2. O ambiente possui um nome claro (OriOn - Orientao Online), mas nopossui uma descrio clara sobre o ambiente (Figura 9). Somente quem o conhece ou quemde inicio explora o OriOn, observando a disposio das informaes, sabe que se trata deum ambiente de discusso on-line. Poderia haver um link "Sobre" para uma tela com umpargrafo ou um pequeno texto descrevendo o OriOn. (Definir um propsito claramente).

Problema 3. O OriOn no possui uma descrio dos requisitos mnimos de sistema parauma execuo adequada do ambiente (Figura 9). Deveria ser disponibilizado na tela de loginum link para uma descrio dos requisitos mnimos do sistema. Caso este for pequeno (umafrase), talvez seja interessante disponibilizar na prpria tela de login (e.g. no rodap datela). (Prover Acesso).

Problema 4. H no Orion muitas imagens pesadas que so carregadas toda vez que seabre uma nova tela (Figura 10). Desta forma uma conexo lenta pode ter dificuldades paracarregar as telas do OriOn e a interao com o ambiente se torna cansativa edesestimulante. Definir frames (HTML) para que certas partes do ambiente, com imagenspesadas, no sejam recarregadas novamente com a interao (e.g. a barra de ttulo e abarra de opes lateral direita) pode ajudar. (Prover Acesso).


14/21

Figura 10 Tela de Temas e Assuntos.

Problema 5. Na pgina inicial e em outras pginas do Orion, alguns links tm a corvermelha mesmo que nunca tenham sido visitados. Ex.: na pgina inicial, o link cadastre-se aqui vermelho, mesmo que o usurio nunca tenha tentado se cadastrar (Figura 9).Colocar os links com cores padres. Ex.: Azul para links nunca clicados, vermelho para links

j visitados. (Prover Acesso).

Problema 6. No existe um editor para a postagem de falas (Figura 11). Criar um editorcompleto com verificador ortogrfico, barra de ferramentas, emoticos e menu de gestospara facilitar a postagem de falas e tornando a discusso mais agradvel. (Facilitar acomunicao).

Figura 11 Tela para postar fala.

Problema 7. O OriOn possui uma nica maneira de visualizar as discusses (Figura 12).Esse layout de apresentao das discusses pode agradar alguns membros, mas outrospodem se sentir incomodados ou no gostar do mesmo layout. Para aumentar aproximidade entre um membro e o ambiente, poderia haver outros layouts disponveis parapersonalizao do OriOn. O membro deveria escolher o que mais lhe agradaria na tela de


15/21

edio de perfil. Um tipo interessante de visualizao a visualizao em rvore quepermite uma viso geral do andamento da discusso e facilita a identificao dos pontosonde a discusso est mais polmica. (Facilitar a comunicao).

Figura 12 Visualizao da discusso.

Problema 8. H um mecanismo que avisa a um membro que existem novas falas (i.e. nolidas) e atravs da interao na tela de Temas e Assuntos o mesmo descobre em qualdiscusso que elas ocorreram, mas dentro da discusso no existe uma forma de distinguirfalas novas de falas j lidas (Figura 13). Para resolver este problema, as falas novaspoderiam ser apresentadas com um fundo de cor diferente, ou at mesmo, o texto em cordiferente. Isto para que esta fala se destaque em relao s outras. (Facilitar acomunicao).

Figura 13 Visualizao da discusso, informao das novidades e sistema de busca.

Problema 9. Existe uma ferramenta para a filtragem da discusso, contudo, a ferramentano d muitas opes para o usurio (Figura 13). Criar uma ferramenta completa, parafiltragem, utilizando tcnicas mais especializadas, para esta funo, para facilitar a procura


16/21

do usurio por certos termos em determinado perodo de tempo e por usurios especficos.(Facilitar a comunicao).

Problema 10. No existe no OriOn um mecanismo de gerao de resumo das discusses.Para que um novo membro obtenha uma leitura geral das discusses, este deve percorreras discusses fazendo uma leitura das falas. Uma forma rpida de obter esta leitura geralseria muito interessante. Para uma soluo parcial, a criao de uma ferramenta quefornea uma interface para a impresso amigvel da discusso. (Facilitar a comunicao).

Problema 11. No existe uma forma de motivao para que os usurios participem mais emelhor do Orion. A comunidade no tem uma pessoa que fica responsvel por ficarmotivando, ficar sempre observando e continuando o assunto tentando fazer com que osmembros tambm participem. Promover premiaes ou bonificaes para os usurios quemais e melhor participarem, serve de estmulo para que o usurio sempre participeveementemente de forma sria e respeitosa. Tambm pode-se escolher um motivador, ousempre ir revezando entre os membros. (Motivar a comunidade).

Problema 12. O usurio no consegue mudar sua senha, ou caso tenha esquecido no temcomo recuperar, a no ser entrar em contato com o administrador, esperando at que elepossa passar uma nova senha. Forneceruma opo segura para mudana e modificao desenha pelo usurio. (Definir uma poltica de registro).

Problema 13. No existe no OriOn um mecanismo de registro on-line. Novos membrospara obterem acesso devem procurar os gestores, administradores do ambiente paraconseguir o acesso como membro. Definir um mecanismo de registro disponibilizado na telade login do OriOn. Desta forma, novos usurios poderiam ser adicionados de forma maisdinmica, mas claro, somente com a liberao dos gestores e/ou administradores.(Definir uma poltica de registro).

Problema 14. No existe uma poltica de privacidade. Os usurios no sabem quais so aspolticas e regras quanto privacidade no grupo. Quando o usurio cadastrar, ele ter queaceitar a poltica de privacidade, para que esteja sabendo como funciona o grupo e dapunio aos usurios que desrespeit-la. (Garantir segurana).

Problema 15. No existe um mapa do site para facilitar a navegao dos usurios. Criarum mapa do site mostrando a estrutura do site para facilitar a navegao dos usurios.(Navegao).

Problema 16. No existe nenhum mecanismo que delegue aos usurios uma participaona gesto do grupo. Os usurios simplesmente postam informaes. Possibilitar aosusurios uma participao na gesto, como polticas de acesso pelos visitantes e decisessobre membros que no contribuem nas discusses. Com a participao na gesto o usuriofica mais motivado a participar do grupo. Os usurios poderiam modificar a aparncia dogrupo em conjunto e algumas funcionalidades, para o grupo ter a "cara" de seus usurios.(Participao na gesto).

Problema 17. No OriOn, no existe um mecanismo explcito para definir quem est

moderando ou gerindo as discusses. O simples fato de que um membro criou umadiscusso, no impe que esta ir moderar esta discusso. No existe uma definio depapis no OriOn (e.g., moderador, membro, visitante). Na atual situao, todos que temacesso no OriOn so todos membros de igual poderes. A definio de tipos de usuriosdiferentes poderia solucionar esta questo. Poderia haver: moderadores, membros evisitantes. Os moderadores poderiam ser eleitos atravs de uma votao entre os membrosdo OriOn, de forma rotativa. Estes teriam a responsabilidade de manter as discussesativas, levantando questes, intimando os membros a participarem etc. Os membrospoderiam: eleger os moderadores, tornar-se moderadores por um certo tempo e participar


17/21

das discusses. Os visitantes somente poderiam visualizar as discusses, sem nenhumdireito dentro do ambiente (e.g., postar falas, criar discusses etc). (Participao nagesto).

Analisando o nmero de problemas encontrados por cada avaliador, podemos construir oseguinte grfico:

Figura 14 Proporo de problemas de usabilidade encontrados utilizando avaliaoheurstica no OriOn.

A Figura 14 corresponde com a curva da Figura 3, demonstrando que a avaliao heursticarealmente necessita de poucos avaliadores (pelo menos trs) para achar uma mdia entre60-80% dos problemas da interface avaliada.

Alm disso, analisando de perto quais problemas cada avaliador encontrou, podemosconstruir outro grfico que tambm demonstra certa correspondncia com os resultados daliteratura, validando certos aspectos da avaliao heurstica:

Figura 15 Cada linha representa um avaliador e cada coluna representa um problemade usabilidade. O quadrado preto representa se o problema foi encontrado pelo

avaliador.

A Figura 15 comprova a nossa hiptese levantada na Seo 1.2 de que pessoas diferentesencontram diferentes problemas de usabilidade. Os avaliadores ditos bem sucedidosacabam s vezes deixando os problemas fceis para trs, enquanto que os avaliadoresditos malsucedidos tambm conseguem encontrar os problemas difceis mesmo tendoencontrado menos problemas que os avaliadores em geral.

4. ConclusesOs resultados de uma avaliao heurstica vo ser muito melhores se no for utilizadoapenas um avaliador, e se os avaliadores utilizados no mantiverem nenhum contato entresi. O nmero de problemas de usabilidade encontrados por um agregado de avaliadorescresce rapidamente no intervalo entre um e cinco avaliadores, mas esse crescimentodiminui prximo a dez avaliadores. A partir do estudo de caso feito e dos experimentos deoutros autores, podemos concluir que a avaliao heurstica pode ser realizada de formasatisfatria utilizando-se de trs a cinco avaliadores.


18/21

As maiores vantagens da avaliao heurstica so:

Mtodo de baixo custo;

Mtodo rpido;

Mtodo fcil de aplicar e de entender;

Bom para descobrir que existem desfalques na interface;

Bom para delimitar o escopo da avaliao.

As desvantagens da avaliao heurstica so:

Dependncia das heursticas para se realizar a avaliao;

Ainda no foram definidas heursticas para todos os tipos de interface;

Heursticas ruins ou difceis levam a uma avaliao de baixa qualidade;

Os avaliadores, geralmente, se limitam aos exemplos de problemasapresentados nas heursticas, diminuindo o poder de alcance das mesmas;

No existe a preocupao com a interpretao do avaliador, s existe oerro se a interface no respeitar a heurstica.

Esse estudo realizado sobre o mtodo de avaliao heurstica comprovou a sua eficincia,mediante ao baixo custo e curto prazo de tempo para se realizar uma avaliao com umnmero pequeno de avaliadores e encontrando um nmero satisfatrio de problemas nainterface.

O mtodo simples e fcil de aprender, porm a avaliao fica altamente dependente dautilizao de boas heursticas. Sendo que essas mesmas heursticas podem prejudicar aqualidade da avaliao realizada pelos avaliadores, pois muitos avaliadores ficam presosapenas aos exemplos apresentados para uma determinada heurstica, no explorando o seuverdadeiro potencial. Isso s comprova que a avaliao fica restrita as heursticas e suas

sugestes, o que pode tornar a avaliao um tanto quanto limitada, pois no levada emconsiderao a interpretao do avaliador em relao aos elementos da interface, levandoerros ainda desconhecidos pela heurstica a nunca serem descobertos.

Exerccios

1. Um sistema de resposta por voz, um sistema computacional acessado atravs de umtelefone. O sistema, chamado aqui de Sistema Bancrio, uma interface operada pelotelefone para acesso conta do usurio. A tarefa do usurio no dilogo de exemplo foitransferir R$ 1.000 da poupana para a conta corrente do prprio usurio. As nicas opesde entrada do usurio so 12 botes iguais aos de um telefone comum (os dgitos 0-9 e oscaracteres especiais * e #). A nica resposta do sistema atravs de fala e algumas vezesefeitos sonoros. A tecla # significa o fim da entrada do usurio. Enquanto o usurio nopressionou a tecla #, possvel pressionar duas vezes a tecla * para corrigir a entrada. Umexemplo de dilogo entre um usurio (U) e oSistema Bancrio (S) mostrado a seguir:

(1) S: Entre um para informao sobre conta, trspara transferncias entre suas prprias contas, ...(2) U: 3# {o usurio interrompe o sistema}(3) S: Entre a conta de origem da transferncia(4) U: 1234567890# {nmero da poupana}(5) S: Entre a conta destino da transferncia


19/21

(6) U: # {uma abreviao para conta corrente}(7) S: Entre com o valor em centavos(8) U: 100000#(9) S: Do nmero de conta doze, trinta e quatro,cinqenta e seis, setenta e oito, noventa, para onmero de conta, conta primria, uma transferncia

de um mil reais est para ser feita. Pressione um paraconfirmar, zero para cancelar.(10) U: 1#(11) S: Voc no tem acesso para usar esta funo.

Os nmeros dos enunciados no fazem parte do dilogo, apenas so usados parareferenciar enunciados individuais. Tente encontrar problemas de usabilidade utilizando omtodo de avaliao heurstica atravs das nove heursticas originais. Dica:conhecido umtotal de 16 problemas[Nielsen, 1992].

2. Sua tarefa aconselhar uma companhia sobre a qualidade do dilogo humano-computador de um de seus sistemas. A administrao da companhia quer ter certeza que

usurios inexperientes conseguiro obter resultados rapidamente quando usarem o sistema.Com isso em mente, voc deve apontar o mximo de problemas de usabilidade no dilogoutilizando o mtodo de avaliao heurstica atravs das nove heursticas originais.

A funcionalidade bsica do sistema pr-determinada. O propsito deste exerccio criticaro dilogo do sistema e no sua funcionalidade. Novas funes possivelmente elevaro ausabilidade do sistema mas sugestes para novas ou mudanas nas funes no fazemparte desse exerccio.

Sua soluo deve consistir de uma lista com todos os problemas de usabilidade que vocpde encontrar no dilogo. Voc pode incluir sugestes de como aperfeioar o dilogo paraevitar os problemas e at pode especificar um dilogo aprimorado. Seu objetivo principal articular os problemas de usabilidade identificados, do que meramente indicar para elesmudanas em um design alternativo.

O Sistema de Catlogo Telefnico

Este sistema parte de um servio da Manhattan Telephone (MANTEL)[2] para usuriosdomsticos. Usurios tpicos tm pouco conhecimento sobre processamento de dados. Elespodem discar para o sistema, que prover o nome e endereo de um assinante nos EstadosUnidos, dado o nmero de telefone do assinante.

Para simplificar o exerccio, ns fizemos as seguintes suposies. Para cada nmero detelefone, temos somente um assinante. Todos os nmeros de telefone consistem deexatamente dez dgitos (3 dgitos para cdigo de rea e os outros 7 dgitos para o nmero).O computador do usurio possui um monitor alfanumrico, monocromtico com 24 linhas de80 caracteres cada e um teclado com teclas extras encontradas na maioria dos teclados,incluindo 10 teclas de funes marcadas como PF1-PF10. Uma tela mostrada na figura

abaixo:


20/21

Especificao

O usurio entra neste sistema selecionando Catlogo de Telefone a partir do menuprincipal do MANTEL. O sistema ento lana o seguinte prompt:

ENTRE O N DE TELEFONE DESEJADO E ENTER

Se o usurio entrar com qualquer coisa que no seja exatamente dez dgitos, o sistema responde:

NMERO ILEGAL. TENTE NOVAMENTE!

Se o usurio entra com um nmero de telefone que no est em uso, o sistema responde:

NMERO DE TELEFONE DESCONHECIDO

Se o cdigo de rea do telefone 212 (cdigo de rea de Manhattan), o sistema ir normalmente

mostrar a tela correspondente a figura anterior em cinco segundos. Para outros cdigos de rea, osistema precisa recuperar a informao necessria de bancos de dados externos; isto pode durar cercade 30 segundos.

Dica: so conhecidos 29 problemas. Para ajud-lo a iniciar a avaliao, aqui est um dosproblemas de usabilidade, bem como uma sugesto de como melhorar o dilogo: O designda tela usa apenas letras maisculas, apesar de que ns sabemos que estudos sobre fatoreshumanos alertam que a mistura de letras maisculas e minsculas muito mais legvel.Est OK usar letras maisculas para um nmero limitado de palavras que voc queiraenfatizar[Molich & Nielsen, 1990].

RefernciasBibliogrficas[Baker et. al., 2001] Baker, K., Greenberg, S. e Gutwin, C. Heuristic Evaluation ofGroupware Based on the Mechanics of Collaboration. Proceedings of the 8th IFIP WorkingConference on Engineering for Human-Computer Interaction (EHCI01). (Maio 11-13,Toronto, Canada), 2001.[Baker et. al., 2002] Baker, K., Greenberg, S. e Gutwin, C. Empirical Development of aHeuristic Evaluation Methodology for Shared Workspace Groupware. Proceedings CSCW02.(Novembro 16-20, New Orleans, Louisiana, USA), 2002.


21/21

[Chan & Rocha, 1996] Chan, S. e Rocha, H. V. Estudo comparativo de mtodos paraavaliao de interfaces homem-computador. Relatrio Tcnico IC-96-05, 1996.

[da Silva et. al., 2003] da Silva, E. J., Nicolaci-da-Costa, A. M., de Souza, C. S., Prates, R.O. Expectativas de usurios potenciais a respeito de grupos virtuais de discusso.

[Jeffries et. al., 1991] Jeffries, R., Miller, J. R., Wharton, C., Uyeda, K. M. User InterfaceEvaluation in the Real World: A Comparison of Four Techniques. Em ACM CHI ConferenceProceedings, pp. 119-124, 1991.[Lieberman, 2003] Lieberman, H. The Tyranny of Evaluation. MIT Media Lab. Disponvelem: http://web.media.mit.edu/~lieber/Misc/Tyranny-Evaluation.html. Acessado em: 26 deAbril de 2005.

[Molich & Nielsen, 1990] Molich, R. e Nielsen, J. Improving a human-computer dialogue.Communications of the ACM33, 3 Maro, 338-348, 1990.

[Nielsen & Molich, 1990] Nielsen, J. e Molich, R. Heuristic Evaluation of User Interfaces.Proceedings ACM CHI90 (Seattle, WA, 1-5 Abril): 249-256, 1990.

[Nielsen, 1989] Nielsen, J. 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, 1989.

[Nielsen, 1992] Nielsen, J. Finding usability problems through heuristic evaluation.Proceedings ACM CHI92 Conference (Monterey, CA, 3-7 Maio): 373-380, 1992.

[Nielsen, 1993] Nielsen, J. Usability Engineering. Academic Press, Cambridge, MA, 1993.

[Nielsen, 1994] Nielsen, J. Heuristic Evaluation. Em J. Nielsen (ed.) Usability InspectionMethods. John Wiley, New York, 1994.

[Preece et. al., 1994] Preece, J., Sharp, H., Benyon, D.,Holland, S., Carey, T. Human-Computer Interaction, Addison Wesley, 1994.

[Preece, 2000] Preece, J. Online Communities: Designing usability, supporting sociability.John Wiley & Sons, Ltd.

[Rocha & Baranauskas, 2000] Rocha, H. V. e Baranauskas, M. C. C. Design e Avaliaode Interfaces Humano-Computador. So Paulo, 2000.

[Romani & Baranauskas, 1998] Romani, L. S. e Baranauskas, M. C. C. Avaliaoheurstica de um sistema altamente dependente do domnio. Relatrio Tcnico IC-98-26,Julho, 1998.

[1] www.orion.iceb.ufop.br

[2] O nome MANTEL e o sistema foram inventados somente para o propsito deste exerccio. Qualquer relaocom companhias ou servios de informaes existentes mera coincidncia.

Documents

Material Complementar - Avaliacao Heuristica