Você está na página 1de 10

ABC da Usabilidade: Anlise Heurstica

A anlise heurstica consiste,


basicamente, em submeter a interface de
um determinado aplicativo avaliao
de alguns especialistas em usabilidade,
conforme um conjunto previamente
determinado de bons princpios de
usabilidade.
por
Ezequiel C. Blasco

21 3 1 0

Bom dia, senhoras e senhores! Conforme prometido no artigo passado, comearei a explicar as
tcnicas de avaliao de usabilidade, uma por uma. Comearei por aquela que eu acho uma das mais
importantes, e certamente a mais fcil, de aplicar: a anlise heurstica.
A anlise heurstica consiste, basicamente, em submeter a interface de um determinado aplicativo
avaliao de alguns especialistas em usabilidade, conforme um conjunto previamente determinado
de bons princpios de usabilidade. Ns denominamos esses princpios de heursticas, sendo o
principal conjunto destas o criado por Jakob Nielsen, que os exps no livro Usability
Engineering (1993). Voltaremos a falar das heursticas de Nielsen adiante.
Preparao da Anlise Heurstica
Para fazer uma anlise heurstica, precisamos dos seguintes ingredientes:

Especialistas em usabilidade (de 3 a 5);


Um prottipo do aplicativo (seja em papel, wireframe, implementao inicial...
qualquer prottipo serve);
Hipteses iniciais sobre os usurios (opcional);
Bateria de atividades (opcional)
Os dois primeiros itens so obrigatrios, afinal, no h avaliao ou teste sem o sujeito
(especialistas) e o objeto (prottipo do sistema). Vale lembrar aqui que a anlise heurstica, por
permitir prottipos no-funcionais e funcionais, pode ser utilizada em qualquer estgio do ciclo de
desenvolvimento. Assim, a anlise heurstica serve para eliminar erros conceituais (isto , vindos de
uma interpretao errada dos requisitos) j na fase inicial do desenvolvimento. Isso evita que esses
erros sejam detectados depois, quando a implementao j est adiantada, e a correo deles exige
uma remodelagem do cdigo (o famoso retrabalho).
As hipteses iniciais sobre os usurios, mesmo sendo opcionais, so itens interessantes a serem
aplicados na anlise heurstica. Explico o porqu: para uma interface ser fcil e agradvel de ser
usada, ela deve levar em conta as necessidades dos usurios. Atualmente, so muitos os perfis
possveis, cada um com caractersticas prprias de aprendizado, expectativas em relao ao
aplicativo, entre outros itens. Logo, desejvel que conheamos o usurio, para que possamos
adaptar a interface s suas necessidades e desejos, a fim de que criemos um produto com boas

possibilidades comerciais. Assim, as hipteses iniciais so instrumentos adequados para serem


utilizados durante a anlise heurstica.
Em relao bateria de atividades, esta ser importante para que o especialista tenha um foco ao
realizar a anlise heurstica. A bateria composta, preferencialmente, por duas classes de tarefas:

Tarefas que os usurios-alvo executariam mais frequentemente dentro do aplicativo;


Tarefas que poderiam apresentar problemas para a compreenso e execuo do
usurio.
Para que essas tarefas sejam corretamente modeladas, importante que as hipteses sobre os
usurios tenham sido corretamente estabelecidas. Elas que iro guiar toda a criao das tarefas,
visto que nas hipteses se estabelecem o perfil de uso e as possveis limitaes do usurio.
Execuo da Anlise Heurstica
Depois da fase de preparao, vem a fase de execuo da anlise heurstica. Essa execuo se d em
trs fases distintas:

1. Anlise individual: nessa fase, cada um dos especialistas analisa individualmente a


interface do aplicativo, por um perodo varivel de tempo (usualmente 1-2 horas),
segundo o conjunto de heursticas escolhido. Um relatrio gerado nessa fase,
mostrando cada um dos erros encontrados, indicando em cada um a heurstica violada, o
local do erro e a gravidade do problema, alm das possveis solues imaginadas pelo
especialista.
2. Consolidao da anlise: nessa fase, todos os especialistas, juntamente com o lder da
equipe, renem-se para discutir a respeito dos resultados individuais encontrados. Nessa
consolidao, cada especialista tem acesso a todos os relatrios individuais gerados na
primeira fase. Ao final desta fase, deve ser gerado um relatrio unificado, com todos os
erros encontrados (da mesma maneira que na primeira fase).
3. Reunio final: nessa fase, os especialistas se renem com o cliente (ou o gerente de
projeto) para definir quais sero os erros de interface a ser corrigidos. Claro, em uma
situao ideal, deveramos corrigir todos, mas como temos que lidar com as famosas
limitaes de oramento, ou com recursos esgotados, nem sempre d para voltar
atrs em um erro, principalmente quando estamos falando sobre avaliao somativa.
Heursticas
Certo, voc j conhece os passos corretos, sabe como vai efetuar a anlise heurstica... mas quais so
as heursticas a serem utilizadas (voc deve estar pensando a essa hora)? Calma, que eu vou explicar.
Existem alguns conjuntos de heursticas mais conhecidos do pessoal especialista em usabilidade; os
dois mais conhecidos so as heursticas de Bastien e Scapin (1995) e as heursticas de Nielsen
(1993).
As heursticas de Bastien e Scapin so mais voltadas para a rea da Ergonomia, e so as bases
tericas para a criao da famosa Ergolist, uma checklist desenvolvida pelos pesquisadores da UFSC
para auxiliar na avaliao de interface. As heursticas de Nielsen, por sua vez, cobrem todos os
aspectos das boas prticas de usabilidade, sendo usadas quase universalmente, na academia e na
indstria. So 10 heursticas, ao total, as quais sero explicadas a partir de agora. A vo elas:
Visibilidade do estado do sistema
Um princpio bsico de toda a interface que o usurio deve sempre (eu disse SEMPRE) saber o
estado do aplicativo. Imagine o Windows sem a ampulheta para indicar que o sistema est ocupado...
Ou um navegador que no indique como est o carregamento da pgina Web! Irritante e frustrante,
para dizer o mnimo.
Correspondncia entre o sistema e o mundo real
mais fcil para o usurio aprender um sistema que use palavras que sejam de seu conhecimento
prvio, e que tenha uma interface similar ao ambiente no-computacional de trabalho (quando isso
possvel). Dando um exemplo: o MS Word utiliza em sua interface o paradigma WYSIWYG (what
you see is what you get em uma traduo livre, o que voc v o que voc tem), o que faz com
que ele use a metfora da folha de papel e da rgua para manter uma correspondncia com as
antigas mquinas de escrever. D certo, e por isso o MS Word se tornou o padro de interface para
processadores de texto. J o LaTeX, por sua vez, utiliza-se de uma linguagem de marcao que para
a maioria dos usurios complicada, difcil de entender.
Controle e liberdade do usurio

O usurio quer ter a liberdade de no ser tolhido pela interface a seguir passos especficos; ele quer
ter o controle, quer poder errar e depois voltar na ao cometida. Imagine um aplicativo onde no
existam condies de se desfazer uma ao. Ou pior, um aplicativo onde voc tenha que seguir um
passo-a-passo milimetricamente exato para, por exemplo, formatar uma clula em uma tabela.
Chato, tedioso e irritante.
Consistncia e padronizao
Uma interface deve manter uma consistncia grfica e lxica durante toda a interao. Explico: no
deve haver duas palavras ou dois cones diferentes indicando a mesma funcionalidade, assim como
no deve ter uma palavra ou um cone representando duas funcionalidades diversas. Tambm, a
identidade visual do aplicativo ou site deve permanecer constante em todas as telas de interao.
Seno, o nosso amigo usurio vai ficar bem confuso...
Preveno de Erros
Preveno nunca fez mal a ningum, no ? Ento, j que a preveno faz parte da nossa vida, por
que no estender isso para os nossos aplicativos? Se o usurio pode colocar algum dado errado
naquele formulrio, faa com que ele saiba como preencher os campos com dados corretos
(mscaras e dicas marginais fazem to bem nessas horas...). Lembro de uma vez em que eu
preenchia um formulrio quilomtrico; na hora de colocar a data de nascimento, eu coloquei no j
decantado formato DD/MM/AAAA (era um site brasileiro, antes que me perguntem). Quando eu
confirmei o envio dos dados surpresa! os dados deveriam ser postos no formato DD-MMAAAA. E como, por Deus, eu iria adivinhar que era assim, se no havia a mnima pista no site? Ah,
claro, me esqueci de dizer que todos os dados que eu havia inserido haviam sido apagados do
formulrio que beleza, no?
Reconhecimento em vez de lembrana
Um usurio no pode ficar raciocinando onde est o acesso a uma funcionalidade, dentro da
interface. Pelo contrrio, o usurio deve fazer uso do seu conhecimento de interfaces anteriores para
ir direto ao ponto, sem ficar pensando: Onde est a funo X?. Em outras palavras, as instrues
de uso do sistema devem estar visveis ou facilmente acessveis sempre que necessrio. Alm disso,
o usurio no deve ter que se lembrar de informao de uma parte do dilogo para uma outra (como
acontece em certos aplicativos Web, que pedem cinco vezes o mesmo dado, em diferentes
formulrios que fazem parte do mesmo processo haja pacincia!).
Flexibilidade e eficincia de uso
Uma interface deve ter vrias maneiras de acionar uma mesma funo. Atalhos de teclado, por
exemplo, podem tornar a interao do usurio experiente mais rpida e eficiente, enquanto recursos
como a barra de ferramentas e o menu servem aos usurios inexperientes. Outro aspecto que deve
ser cuidado a opo de operao manual em casos onde o default o sistema acionar uma funo
automaticamente; isso deve ser levado em conta principalmente em aplicativos que lidem com
situaes de perigo, como softwares mdicos e de navegao area.
Projeto esttico e minimalista
interessante que a interface oferea um visual que no prejudique o usurio, tanto no uso de cores
quanto na distribuio de informao. Um aplicativo que oferea um baixo contraste diminui a
legibilidade da interface, enquanto a utilizao de cores muito vivas ou de elementos piscantes
(prontos para pularem no seu rosto feito aliens famintos) faz com que os olhos se cansem
rapidamente. J em relao distribuio de informao, interessante que se restrinja ao necessrio
para guiar o usurio naquele momento, dentro da interface (a nossa velha conciso). Muitas unidades
de informao aparecendo ao mesmo tempo deixam o usurio confuso, e s vezes essa o motivo
principal do abandono de sites de servios (em relao aos ambientes Web).
Recuperao de Erros
Do que adianta uma interface, ao ocorrer um erro qualquer, jogar no rosto do usurio uma mensagem
ininteligvel? Todos ns j sofremos com isso, afinal, a Tela Azul da Morte j nossa velha
conhecida: seu aparecimento sbito, alm de provocar terror, no ajuda em nada. Afinal, qual de ns,
meros mortais, consegue traduzir aqueles erros de sistema malucos que aparecem ali? s vezes, nem
So Google ajuda nesses casos! Portanto, o meu recado : as mensagens de erro devem ser claras,
ajudando o usurio a corrigir o que fez de errado com informaes simples e concisas.
Ajuda e Documentao
Quem gosta de utilizar o sistema de ajuda de um aplicativo? Nem eu, nem voc, nem o Papa Bento
gostamos de usar, e sabe por qu? Simplesmente, o sistema de ajuda, em geral, a LTIMA coisa a
ser feita dentro do ciclo de desenvolvimento (nas duas horas restantes, usualmente...)! E a, meus

amigos, o festival de aberraes evidente: textos muito longos (o pessoal f do Linux que me
perdoe, mas aquelas MANs que o sistema oferece, valha-me Deus!), informaes fora de contexto e
m arquitetura de informao so os viles da vez. Portanto, meus amigos, a ajuda deve ser fcil de
ser encontrada, focada na tarefa do usurio, descrevendo a tarefa passo-a-passo, sem ser muito
grande.
Escala de erros
Como eu disse anteriormente, as violaes de heurstica (ou mais comumente, erros) devem ser
colocadas em uma escala de gravidade, para que o cliente ou gerente de projeto tenha uma idia de
onde ele deve agir primeiro. Nesse contexto, sugerida essa (j tradicional) escala:

Nvel 0: No encarado necessariamente como um problema de usabilidade.


Nvel 1: Problema esttico que no tem necessidade de ser corrigido, a menos que haja
tempo e recurso disponvel.
Nvel 2: Pequeno problema com baixa prioridade na correo.
Nvel 3: Problema com alta prioridade de correo.
Nvel 4: Catstrofe de usabilidade, ou seja, o produto s ser liberado se a correo for
feita. Ao final, o relatrio das violaes de heurstica vai ficar similar tabela abaixo
mostrada.
Tabela 1. Exemplo de tabela para relatrio de avaliao heurstica.

Heurstica Violada Erro


Local
Gravidade
Recuperao de
As mensagens de Mensagens de 2
Erros
erro so pouco Erro (JavaScript)
claras
Consistncia e
Usa-se os termos Mensagens de 3
Padronizao
Salvar e
aviso de
Gravar com o gravao
mesmo sentido,
na interface
...
...
...
...

Soluo
Colocar
mensagens de erro
mais claras
Uniformizar a
referncia do
(provavelmente
usando a palavra
Salvar
...

Esse relatrio ser redigido dessa forma tanto na avaliao individual (1 fase) quanto na
consolidao da anlise (2 fase). O relatrio deve ser entregue ao cliente, para que, com base nas
informaes ali apresentadas, e em suas necessidades de projeto, ele possa decidir quais sero os
erros corrigidos.
Concluses
A anlise heurstica uma tcnica adequada para ser usada em qualquer fase do desenvolvimento do
aplicativo. Fcil, rpida e barata, ela exige apenas um tremendo bom-senso por parte dos
avaliadores, que devem ficar atentos ao reporte correto dos erros. Para isso, interessante adotar a
utilizao de hipteses sobre os usurios, bem como de uma bateria de testes escolhida para cobrir as
principais funcionalidades e os possveis erros dos usurios (baseados nas hipteses sobre os
mesmos).
Os resultados conseguidos na anlise heurstica (principalmente se utilizadas as heursticas de
Nielsen) so abrangentes, estando adequados para a pronta aplicao. Porm, o seu grande problema
que a Anlise Heurstica no capta os aspectos subjetivos da interface (os quais so dados atravs
dos testes com os usurios). Por isso ela deve, sempre quando possvel, ser aplicada em um contexto
formativo, onde estejam tambm previstas avaliaes empricas com os usurios. Alis, esse o
assunto do qual vamos falar no prximo artigo. Aguardem e confiem.
Bom, isso! Se precisarem de esclarecimentos, escrevam para
ezequiel.blasco.(arroba).testanywhere.com.br.
Read more: http://www.linhadecodigo.com.br/artigo/2355/abc-da-usabilidade-analiseheuristica.aspx#ixzz3M1sDdWwD

ABC da Usabilidade Testes Empricos


com Usurios (Fase 1 Preparao)
Fazer um teste emprico com o usurio
consiste em observar e monitorar a sua
interao com o sistema, em um
ambiente parcialmente controlado (um
laboratrio, preferencialmente), atravs
da execuo de uma bateria de
atividades.
por
Ezequiel C. Blasco

0002

Ol, senhoras e senhores! Estamos novamente aqui, para falar sobre avaliao de usabilidade e,
dessa vez, o assunto ser testes empricos com usurios. Mas, Ezequiel, o que exatamente um
teste-emprico-com-o-usurio?, voc poderia me perguntar... Calma, calma: dizer que os testes
so empricos reflete a natureza experimental desses testes. No h mtodos formais a serem
seguidos, at por que estamos lidando com fatores subjetivos. Compliquei mais? Deixem-me
explicar melhor, por favor...
O que um Teste Emprico?
Fazer um teste emprico com o usurio consiste em observar e monitorar a sua interao com o
sistema, em um ambiente parcialmente controlado (um laboratrio, preferencialmente), atravs
da execuo de uma bateria de atividades. Essas atividades tm por finalidade fazer com que
funcionalidades-chave na interface do sistema sejam testadas; isso equivale a dizer que as
tarefas so o condutor do teste, o mote para que o mesmo seja realizado (do ponto de vista do
usurio). Enquanto o usurio executa as atividades, os facilitadores (ou seja: ns) observam tudo
o que feito, utilizando como recursos auxiliares um ou mais softwares de monitoramento,
como keyloggers, capturadores de tela, entre outros.
Parece fcil, no ? Nada mais enganoso... Como ns veremos adiante, o usurio , por assim
dizer, arisco a qualquer coisa que se assemelhe a um teste (mesmo que o objeto do teste no
seja ele, em absoluto). Mas no se preocupe: mesmo o mais renitente dos usurios no vai

conseguir abortar o seu teste se voc tomar o devido cuidado com a preparao e andamento do
teste.
Do que precisamos para um Teste Emprico?
Antes de tudo, precisamos definir quem sero os usurios. Aqui no h mistrios:
certamente, a essa altura j foi feita uma anlise detalhada de quais fatias de mercado o seu
aplicativo atinge. Aproveite essas informaes e descubra mais sobre os seus usurios.
Depois dessa fase, comea o recrutamento de usurios para os testes. A execuo desse
passo igualmente simples: basta a aplicao de um questionrio em um nmero razovel de
pessoas, com perguntas que possam indicar a voc quem tem o perfil similar ao do seu usurioalvo. Certamente voc vai conseguir alguns participantes em potencial. Depois, basta fazer o
convite e torcer que a pessoa aceite.
A partir daqui que o nvel de dificuldade aumenta: eu j falei que o usurio o ser
mais arisco do Universo, quando se trata de testar alguma coisa? Pois bem, vamos ser
realistas: nem todas as pessoas contatadas vo aceitar fazer os testes com voc. Alis, segundo a
minha experincia, a taxa de aceitao fica no mximo na casa dos 70%. Portanto, trate de
caprichar e garantir pelo menos umas 10 (dez) pessoas com potencial para participar dos testes,
que, na melhor das hipteses, voc contar com 7 (sete) pessoas.
Alis, o nmero de usurios a fazer o teste um fator crucial. Segundo Jakob Nielsen, o
mais respeitado dos especialistas em usabilidade, a relao entre o nmero de usurios
participantes e o percentual de erros encontrados dado no grfico adiante mostrado (Figura 1)

Figura 1. Grfico da razo usurios participantes X percentual de erros (Nielsen 2000)


Segundo esse grfico, um nico usurio consegue achar em torno de 30% dos problemas
de usabilidade existentes em uma interface. Porm, podemos observar que a partir de 5 (cinco)
de usurios, o aumento no nmero de usurios no corresponde a um ganho significativo. Ainda
segundo Jakob Nielsen, a percentagem de erros de usabilidade encontrada por um grupo de
cinco usurios de 85%, o que representa a melhor relao custo-benefcio.

A partir de que voc j tenha conseguido os usurios para o teste, voc deve decidir com
que estrutura vai contar para efetuar os testes. Existem trs modalidades de testes com usurios,
nesse contexto:

Figura 2. Exemplo de laboratrio de usabilidade.


Testes em Laboratrio: a melhor opo, se voc puder contar com ela. Voc dispe de um
laboratrio de usabilidade (Figura 2), com todos os equipamentos necessrios para levar adiante
os seus testes. A grande vantagem que voc pode conduzir os testes em um ambiente
controlado, isto , todas as variveis so monitoradas e podem ser mudadas conforme a
necessidade, exceto uma: a ansiedade do usurio.
Lembram que eu falei que o usurio arisco? Pois , amigos, o usurio no gosta de fazer
parte dos testes porque acha que est sendo sempre avaliado! Mesmo que voc repita mil vezes
que o objeto da avaliao o sistema, ele vai sempre tomar um ar de acusado pela Inquisio,
com medo de ser rotulado como mentalmente incapaz pelos avaliadores. E, se essa ansiedade
no for driblada, posso garantir que o teste ser invlido.
Por isso, trate de ser bonzinho com o usurio, ou ele pode inadvertidamente mandar o seu teste
pelos ares.
Testes Presenciais no Ambiente do Usurio: aqui se perde um pouco do controle que havia no
teste em laboratrio, e existem grandes chances de que fatores externos possam distrair o
usurio de suas atividades (como chefes inoportunos, MSN aberto em uma distrao do
avaliador, entre outros elementos). Porm, temos dois pequenos ganhos nesse contexto:
primeiramente, o usurio vai estar imerso em um ambiente real de utilizao do software (sem o
carter inquisitorial do laboratrio de usabilidade). Alm disso, o usurio vai se sentir bem
mais vontade, estando em um ambiente que ele j est acostumado e, de certa forma, domina.
Testes Remotos no Ambiente do Usurio: aqui, em vez de ter a presena moderadora do
avaliador ao lado do usurio, utilizado um software para monitoramento remoto das
atividades. O avaliador fica em um ambiente, o usurio em outro, e as atividades so conduzidas
de forma sncrona. Esse mtodo tem a bvia vantagem de deixar o usurio totalmente vontade,

mas por outro lado, o controle do avaliador vai pelos ares. Conselho pessoal: apenas use essa
configurao somente em casos de extrema necessidade. srio.
Depois de cuidar da forma como voc vai conduzir o teste, voc deve escolher quais as
mtricas que sero abordadas e avaliadas. Essa escolha ser feita em relao ao objetivo a ser
alcanado, isto , no basta apenas dizer que o seu objetivo avaliar a usabilidade do
aplicativo. Deve haver um motivo por trs dessa necessidade de avaliao, sendo alguns dos
motivos mais comuns os seguintes:
Em relao ao tempo estimado para a realizao de um teste, interessa que ele no seja muito
curto, nem muito longo. Pela minha experincia, um teste proveitoso e pouco cansativo para
o usurio leva entre 40 minutos e 1 hora para ser concludo, entre explicaes prvias,
aplicao das atividades e preenchimento do questionrio ps-teste. Um teste mais curto
pouco proveitoso, por abordar poucas funcionalidades; por outro lado, um teste mais extenso
cansa o usurio, aumentando as suas chances de desistncia.

Assim, faa um teste piloto para ver o tempo mdio que a sua bateria de tarefas levar
para ser concluda. Caso fique muito curta, podem ser acrescentadas mais tarefas; se ficar
muito longa, talvez seja uma idia interessante dividir ela em vrias baterias de tarefas
menores, que sero aplicadas aos mesmos usurios, mas em dias distintos.
Tambm de fundamental importncia a criao de perguntas adequadas para o
questionrio ps-teste. Dando um exemplo prtico: digamos que o seu objetivo, dentro
dos testes de usabilidade, seja verificar a eficincia das principais funcionalidades do
aplicativo. Neste caso, necessrio verificar quantas tarefas o usurio acha que concluiu
com xito (afinal, ele pode pensar que conseguiu completar uma tarefa, tendo deixado ela
pela metade). Tambm, necessrio perguntar ao usurio coisas como: qual a facilidade
de uso do aplicativo, se o usurio gostou de us-lo, entre outras caractersticas que
denotam no s a eficincia do aplicativo, mas a satisfao do usurio com o mesmo
(caractersticas subjetivas).
Se voc uma pessoa de sorte e fez tudo direitinho, a essa altura j tem os cinco usurios
para o seu teste emprico. Mas no se d ainda por vitorioso: se no houve problemas no
recrutamento, pode muito bem haver desistncias no meio do teste.
E a, meu caro amigo, voc pergunta: O usurio pode largar tudo e sair voando para a
liberdade, no meio do teste?. Sinto muito, mas esse direito garantido a ele: segundo a
Portaria 196/96, que regula as atividades de teste e pesquisa com seres humanos (e eu
ainda vou voltar a falar sobre essa lei em outro artigo), o ser humano no pode ser
coagido, de nenhuma forma, a continuar um teste ou pesquisa. Ou seja, se o usurio
cismar que voc bobo, feio e mau, ele te abandona e o teste vai pelos ares.
Portanto, respire fundo e repita comigo o mantra: O usurio meu melhor amigo. E aja
de acordo, ok? Quando receber o nosso nobre usurio, trate de ser o mais simptico
possvel; imagine que voc est vendendo um produto para ele, e esse produto o teste.
Voc tem que convencer o usurio a participar do teste com boa vontade e disposio,
conversando amigavelmente (Oferea um cafezinho para ele!) e deixando-o o mais
vontade possvel.

Aps essa sesso de massoterapia no ego do usurio, importante que voc informe a ele
qual o seu papel no teste; aqui que voc vai explicar a ele qual o domnio do aplicativo,
o porqu de ele estar participando deste teste, e os seus direitos enquanto usurio
participante, cuja base est na Portaria n 196/96. Pelos fatores complicadores que esta
portaria nos traz, ela merece alguns pargrafos parte...
A Portaria n 196/96 um dispositivo legal que trata das pesquisas realizadas com seres
humanos. Originalmente concebida para as pesquisas na rea da Sade, ela foi estendida
para as pesquisas em Computao. Sim, amigos, vocs sabem como ... Na falta de uma
lei especfica para a grande rea da Computao, os doutos juristas da Nao resolveram
impingir (em lngua de gente: nos forar garganta abaixo) essa Portaria. , por assim
dizer, uma espcie de tapa-buraco da jurisprudncia tupiniquim.
Assim, estamos sujeitos mesma lei que rege pesquisas com medicamentos, novos
tratamentos mdicos, entre outras pesquisas empricas que trazem em si riscos inerentes:
danos morais, fsicos, psicolgicos, entre outros. Ou seja: um simples teste de usabilidade
pode causar danos da mesma forma que a insero de uma substncia qumica
desconhecida (Nessas horas eu me questiono: por que as pesquisas do IBGE no entram
nessa mesma lista de atividades de risco?).
Um dos efeitos colaterais mais graves dessa Portaria (e da jurisprudncia a ela anexada)
o fato de que, em absoluto, no podemos PAGAR nossos usurios para efetuar testes de
usabilidade, visto que isso seria uma COAO! Sinceramente, eu j li e reli a lei, mas
no achei nada que baseasse esse ponto de vista extico, mas nem sou to douto quanto
nossos ilustres profissionais do Direito. Logo, no h discusso possvel quanto a esse
ponto.
O usurio, nesse contexto, deve ser informado de seus direitos, bem como das condies
do teste, como a gravao das telas de interao, e do udio e vdeo do usurio. Para isso,
voc vai elaborar um documento citando todos esses direitos; esse documento
denominado termo de consentimento. Ao assinar esse documento, o usurio d o direito
de usar todos os subsdios gerados no teste dentro do contexto da pesquisa, assim como
se declara ciente dos direitos que lhes cabe. Descreve-se a seguir alguns dos direitos do
usurio:
o
o

O usurio pode abandonar a sesso de testes quando quiser, sem explicaes prvias.
O usurio pode impor condies extras para a realizao do teste (desde que elas
sejam razoveis).
o O usurio tem o direito de manter o seu nome sob anonimato em divulgaes dos
dados e em quaisquer anlises que possam ser feitas a respeito deles.
Aps a assinatura do termo de consentimento, pode-se aplicar a bateria de atividades
junto ao usurio participante. Primeiro, apresenta-se o cenrio para ele, e certifica-se de
que ele entendeu o contedo do mesmo. Aps, entrega-se a primeira tarefa, aguarda-se a
leitura do usurio, e se inicia o monitoramento das atividades (tempo de execuo,
captura de tela, etc.). Enquanto o usurio vai executando os passos da atividade, o
avaliador vai anotando as suas impresses sobre os erros de usabilidade encontrados. No
trmino da primeira atividade, entrega-se a segunda, e assim por diante, at a execuo
de todas as tarefas.

importante que no momento da execuo do teste pelo usurio, o avaliador se porte da


maneira mais neutra possvel, isto , no se deve dar nenhuma dica para o usurio, em
relao s tarefas que esto sendo executadas. Assim, o avaliador garante que o teste no
ficar viciado, isto , no apresentar nenhum dado esprio, como sucessos
condicionados por informaes de terceiros.
Aps, passa-se aplicao do questionrio ps-teste, que deve ser o mais sucinto quanto
possvel, j que o usurio deve estar exausto pela tenso do teste, a esta altura.
interessante que nos lembremos que o usurio arisco, isto , vai fugir primeira
contrariedade que ele encarar. E ningum gosta de preencher questionrios
quilomtricos, no ?
A partir da, a execuo do teste estar completa, sendo o prximo passo a anlise dos
dados obtidos... Mas isso assunto para um prximo (e mais conciso) post, ok?
Bom, isso, meus amigos! Abraos!

Read more: http://www.linhadecodigo.com.br/artigo/2374/abc-da-usabilidade-testes-empiricos-com-usuarios-fase1-preparacao.aspx#ixzz3M1sJs19M