ABC da Usabilidade – Testes Empíricos com Usuários (Fase 1

Olá, senhoras e senhores! Estamos novamente aqui, para falar sobre avaliação de usabilidade e, dessa vez, o assunto será testes empíricos com usuários. “Mas, Ezequiel, o que é exatamente um teste-empírico-com-o-usuário?”, você poderia me perguntar... Calma, calma: dizer que os testes são empíricos reflete a natureza experimental desses testes. Não há métodos formais a serem seguidos, até por que estamos lidando com fatores subjetivos. Compliquei mais? Deixem-me explicar melhor, por favor...

O que é um Teste Empírico?

Fazer um teste empírico com o usuário consiste em observar e monitorar a sua interação com o sistema, em um ambiente parcialmente controlado (um laboratório, preferencialmente), através da execução de uma bateria de atividades. Essas atividades têm por finalidade fazer com que funcionalidades-chave na interface do sistema sejam testadas; isso equivale a dizer que as tarefas são o condutor do teste, o mote para que o mesmo seja realizado (do ponto de vista do usuário). Enquanto o usuário executa as atividades, os facilitadores (ou seja: nós) observam tudo o que é feito, utilizando como recursos auxiliares um ou mais softwares de monitoramento, como keyloggers, capturadores de tela, entre outros.

Parece fácil, não é? Nada mais enganoso... Como nós veremos adiante, o usuário é, por assim dizer, “arisco” a qualquer coisa que se assemelhe a um teste (mesmo que o objeto do teste não seja ele, em absoluto). Mas não se preocupe: mesmo o mais renitente dos usuários não vai conseguir abortar o seu teste se você tomar o devido cuidado com a preparação e andamento do teste.

Do que precisamos para um Teste Empírico?

Antes de tudo, precisamos definir quem serão os usuários. Aqui não há mistérios: certamente, a essa altura já foi feita uma análise detalhada de quais fatias de mercado o seu aplicativo atinge. Aproveite essas informações e descubra mais sobre os seus usuários.

Depois dessa fase, começa o recrutamento de usuários para os testes. A execução desse passo é igualmente simples: basta a aplicação de um questionário em um número razoável de pessoas, com perguntas que possam indicar a você quem tem o perfil similar ao do seu “usuário-alvo”. Certamente você vai conseguir alguns participantes em potencial. Depois, basta fazer o convite e torcer que a pessoa aceite.

A partir daqui é que o nível de dificuldade aumenta: eu já falei que o usuário é o ser mais “arisco” do Universo, quando se trata de testar alguma coisa? Pois bem, vamos ser realistas: nem todas as pessoas contatadas vão aceitar fazer os testes com você. Aliás, segundo a minha experiência, a taxa de aceitação fica – no máximo – 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 hipóteses, você contará com 7 (sete) pessoas.

Aliás, o número de usuários a fazer o teste é um fator crucial. Segundo Jakob Nielsen, o mais respeitado dos especialistas em usabilidade, a relação entre o número de usuários participantes e o percentual de erros encontrados é dado no gráfico adiante mostrado (Figura 1)

Figura 1. Gráfico da razão usuários participantes X percentual de erros (Nielsen 2000)

Segundo esse gráfico, um único usuário consegue achar em torno de 30% dos problemas de usabilidade existentes em uma interface. Porém, podemos observar que a partir de 5 (cinco) de usuários, o aumento no número de usuários não corresponde a um ganho significativo. Ainda segundo Jakob Nielsen, a percentagem de erros de usabilidade encontrada por um grupo de cinco usuários é de 85%, o que representa a melhor relação custo-benefício.

A partir de que você já tenha conseguido os usuários para o teste, você deve decidir com que estrutura vai contar para efetuar os testes. Existem três modalidades de testes com usuários, nesse contexto:

Figura 2. Exemplo de laboratório de usabilidade.

Testes em Laboratório: a melhor opção, se você puder contar com ela. Você dispõe de um laboratório de usabilidade (Figura 2), com todos os equipamentos necessários para levar adiante os seus testes. A grande vantagem é que você pode conduzir os testes em um ambiente controlado, isto é, todas as variáveis são monitoradas e podem ser mudadas conforme a necessidade, exceto uma: a ansiedade do usuário.

Lembram que eu falei que o usuário é “arisco”? Pois é, amigos, o usuário não gosta de fazer parte dos testes porque acha que está sendo sempre avaliado! Mesmo que você repita mil vezes que o objeto da avaliação é o sistema, ele vai sempre tomar um ar de “acusado pela Inquisição”, com medo de ser rotulado como “mentalmente incapaz” pelos avaliadores. E, se essa ansiedade não for driblada, posso garantir que o teste será inválido.

Por isso, trate de ser bonzinho com o usuário, ou ele pode inadvertidamente mandar o seu teste pelos ares.

Testes Presenciais no Ambiente do Usuário: aqui se perde um pouco do controle que havia no teste em laboratório, e existem grandes chances de que fatores externos possam distrair o usuário de suas atividades (como chefes inoportunos, MSN aberto em uma distração do avaliador, entre outros elementos). Porém, temos dois pequenos ganhos nesse contexto: primeiramente, o usuário vai estar imerso em um ambiente real de utilização do software (sem o caráter “inquisitorial” do laboratório de usabilidade). Além disso, o usuário 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 Usuário: aqui, em vez de ter a presença moderadora do avaliador ao lado do usuário, é utilizado um software para monitoramento remoto das atividades. O avaliador fica em um ambiente, o usuário em outro, e as atividades são conduzidas de forma síncrona. Esse método tem a óbvia vantagem de deixar o usuário totalmente à vontade, mas por outro lado, o controle do avaliador vai pelos ares. Conselho pessoal: apenas use essa configuração somente em casos de extrema necessidade. É sério.

Depois de cuidar da forma como você vai conduzir o teste, você deve escolher quais as métricas que serão abordadas e avaliadas. Essa escolha será feita em relação ao objetivo a ser alcançado, isto é, não basta apenas dizer que o seu objetivo é “avaliar a usabilidade do aplicativo”. Deve haver um motivo por trás dessa necessidade de avaliação, sendo alguns dos motivos mais comuns os seguintes:

Assim, faça um teste piloto para ver o tempo médio que a sua bateria de tarefas levará para ser concluída. Caso fique muito curta, podem ser acrescentadas mais tarefas; se ficar muito longa, talvez seja uma idéia interessante dividir ela em várias baterias de tarefas menores, que serão aplicadas aos mesmos usuários, mas em dias distintos.

Também é de fundamental importância a criação de perguntas adequadas para o questionário pós-teste. Dando um exemplo prático: digamos que o seu objetivo, dentro dos testes de usabilidade, seja verificar a eficiência das principais funcionalidades do aplicativo. Neste caso, é necessário verificar quantas tarefas o usuário acha que concluiu com êxito (afinal, ele pode pensar que conseguiu completar uma tarefa, tendo deixado ela pela metade). Também, é necessário perguntar ao usuário coisas como: qual a facilidade de uso do aplicativo, se o usuário gostou de usá-lo, entre outras características que denotam não só a eficiência do aplicativo, mas a satisfação do usuário com o mesmo (características subjetivas).

Se você é uma pessoa de sorte e fez tudo direitinho, a essa altura já tem os cinco usuários para o seu teste empírico. Mas não se dê ainda por vitorioso: se não houve problemas no recrutamento, pode muito bem haver desistências no meio do teste.

E aí, meu caro amigo, você pergunta: “O usuário 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 não pode ser coagido, de nenhuma forma, a continuar um teste ou pesquisa. Ou seja, se o usuário 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 usuário é meu melhor amigo”. E aja de acordo, ok? Quando receber o nosso nobre usuário, trate de ser o mais simpático possível; imagine que você está vendendo um produto para ele, e esse produto é o teste. Você tem que convencer o usuário a participar do teste com boa vontade e disposição, conversando amigavelmente (Ofereça um cafezinho para ele!) e deixando-o o mais à vontade possível.

Após essa sessão de massoterapia no ego do usuário, é importante que você informe a ele qual o seu papel no teste; é aqui que você vai explicar a ele qual o domínio do aplicativo, o porquê de ele estar participando deste teste, e os seus direitos enquanto usuário participante, cuja base está na Portaria nº 196/96. Pelos fatores complicadores que esta portaria nos traz, ela merece alguns parágrafos à 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 Saúde, ela foi estendida para as pesquisas em Computação. Sim, amigos, vocês sabem como é... Na falta de uma lei específica para a grande área da Computação, os doutos juristas da Nação resolveram impingir (em língua de gente: nos forçar garganta abaixo) essa Portaria. É, por assim dizer, uma espécie de “tapa-buraco” da jurisprudência tupiniquim.

Assim, estamos sujeitos à mesma lei que rege pesquisas com medicamentos, novos tratamentos médicos, entre outras pesquisas empíricas que trazem em si riscos inerentes: danos morais, físicos, psicológicos, entre outros. Ou seja: um simples teste de usabilidade pode causar danos da mesma forma que a inserção de uma substância química desconhecida (Nessas horas eu me questiono: por que as pesquisas do IBGE não entram nessa mesma lista de “atividades de risco”?).

Um dos efeitos colaterais mais graves dessa Portaria (e da jurisprudência a ela anexada) é o fato de que, em absoluto, não podemos PAGAR nossos usuários para efetuar testes de usabilidade, visto que isso seria uma COAÇÃO! Sinceramente, eu já li e reli a lei, mas não achei nada que baseasse esse ponto de vista “exótico”, mas nem sou tão douto quanto nossos ilustres profissionais do Direito. Logo, não há discussão possível quanto a esse ponto.

O usuário, nesse contexto, deve ser informado de seus direitos, bem como das condições do teste, como a gravação das telas de interação, e do áudio e vídeo do usuário. Para isso, você vai elaborar um documento citando todos esses direitos; esse documento é denominado termo de consentimento. Ao assinar esse documento, o usuário dá o direito de usar todos os subsídios 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 usuário:

O usuário pode abandonar a sessão de testes quando quiser, sem explicações prévias.
O usuário pode impor condições extras para a realização do teste (desde que elas sejam razoáveis).
O usuário tem o direito de manter o seu nome sob anonimato em divulgações dos dados e em quaisquer análises que possam ser feitas a respeito deles.

Após a assinatura do termo de consentimento, pode-se aplicar a bateria de atividades junto ao usuário participante. Primeiro, apresenta-se o cenário para ele, e certifica-se de que ele entendeu o conteúdo do mesmo. Após, entrega-se a primeira tarefa, aguarda-se a leitura do usuário, e se inicia o monitoramento das atividades (tempo de execução, captura de tela, etc.). Enquanto o usuário vai executando os passos da atividade, o avaliador vai anotando as suas impressões sobre os erros de usabilidade encontrados. No término da primeira atividade, entrega-se a segunda, e assim por diante, até a execução de todas as tarefas.

É importante que no momento da execução do teste pelo usuário, o avaliador se porte da maneira mais neutra possível, isto é, não se deve dar nenhuma dica para o usuário, em relação às tarefas que estão sendo executadas. Assim, o avaliador garante que o teste não ficará “viciado”, isto é, não apresentará nenhum dado espúrio, como sucessos condicionados por informações de terceiros.

Após, passa-se à aplicação do questionário pós-teste, que deve ser o mais sucinto quanto possível, já que o usuário deve estar exausto pela tensão do teste, a esta altura. É interessante que nos lembremos que o usuário é “arisco”, isto é, vai fugir à primeira contrariedade que ele encarar. E ninguém gosta de preencher questionários quilométricos, não é?

A partir daí, a execução do teste estará completa, sendo o próximo passo a análise dos dados obtidos... Mas isso é assunto para um próximo (e mais conciso) post, ok?

Bom, é isso, meus amigos! Abraços!

Gerência - Qualidade e Testes

Leia também