Avaliação com Utilizadores

Avaliação no Ciclo Iterativo

Ao realizarmos qualquer tipo de produto, temos que passar por uma série de etapas de modo a podermos obter o melhor protótipo funcional possível. Na figura abaixo conseguimos ver todos os passos que constituem este ciclo iterativo. Contudo, agora apenas nos vamos focar nos testes.

Para concluir que fizemos um bom trabalho no nosso projeto, temos que realizar uma série de testes com utilizadores exteriores aos membros do nosso grupo para testar a qualidade e utilização no dia-a-dia do que nós fizemos.

Nestes testes pretendemos ter dois objetivos: avaliar e identificar problemas, através de duas componentes distintas:

• Usabilidade
• Experiência de Utilização

Métodos de Avaliação

Contudo, para fazer estes testes temos que nos focar em dois métodos para, como foi referido acima, obtermos as melhores avaliações possíveis e as críticas que geram mais confiança possível. Por isso, realizamos testes analíticos e testes empíricos.

Testes Analíticos

Os teste analíticos referem-se a avaliações heurísticas, a modelos mais preditivos. Isto é, os testes analíticos referem-se somente a como o nosso trabalho está só por si sem haver pessoas a testarem-no. Aos testes analíticos estão associadas a Lei de Fitts e Machine Learning.

Testes Empíricos

Por outro lado, os testes empíricos referem-se a testes de usabilidade, testes A/B, diários, shadowing, contextual inquiry, entre muitos outros. Estes testes já retratam uma interação com os utilizadores externos para compreender até que ponto o nosso produto pode e é preferido para ser utilizado.

Dentro dos testes empíricos, podemos dividir as observações em duas. Temos observações diretas que retratam utilizadores a serem observados a realizar tarefas, seja presencial ou em vídeo. Um bom exemplo de observação direta é o método Wizard of Oz, como foi realizado no primeiro Bake-Off.

Em termos de observação indiretas referimo-nos a dois tipos de interações:

• Manuais - através do uso de diários, por exemplo
• Automáticos - através do registo de interação, isto é, interaction logs

Como usamos um diário?

Diários podem ser usados para verificar a utilização a longo prazo de um produto, ou seja, a utilização mais regular durante uma ou mais semanas do nosso produto. Os diários permitem ao utilizador externo partilhar os seus pensamentos, a sua utilidade, a relação com o produto a um nível mais elevado que após somente uma utilização. O nosso objetivo é criar um produto que incorpore as atividades do dia-a-dia, e os diários são a melhor forma de avaliar isso mesmo.

Case Study: Halo 3

"How Microsoft Labs Invented a New Science of Play"

Com o Halo 3, a Microsoft gerou um registo de interação automático, isto é, tinham milhares de jogadores a jogarem todos os dias, avaliando a qualidade e dificuldade excessiva do mesmo.

O que era registado:

• Timestamp
• Localização do jogador
• Número de balas
• Eventos (morrer, acertar, etc.)
• Para onde está a apontar

Ao avaliar as condições, a Microsoft criou um Heatmap que a cada 5s mudavam a cor do jogador. Desta forma, se havia muitas cores num só sítio então os programadores sabiam que tinham que remodelar o mapa, pois havia muita gente presa nesse sítio, contudo, se o mapa tivesse cores diferentes em lugares diferentes, então tínhamos um bom mapa.

Também viam as munições: o registo automático conseguia avaliar se havia uma zona do mapa em que as balas era todas perdidas, contudo, foi necessário o auxílio do registo direto para compreender o porquê de perderem tantas balas.

Atualmente, é possível lançar um jogo passados apenas 2 ou 3 anos e ir recebendo feedback à medida que os utilizadores vão experimentando e usufruindo do jogo, havendo uma constante remodelação do jogo, em vez de ser necessário esperar 5 anos para poderem lançar o jogo pela primeira vez. Através do feedback e dos testes, os jogos podem melhorar mas ser logo jogados.

Diferentes métodos de Avaliação/Investigação

• Entrevistas
• Focus groups
• Questionários online
• Diários
• Sondas culturais
• Observação
• Etnografia
• Experience sampling
• Registo de interação
• Co-desenho
• Casos de estudo
• Contextual inquiry
• Wizard of Oz
• Think-aloud
• Card sorting
• ...

Nos Bake-Offs passámos por muitos destes métodos.

Testes de Usabilidade

Para garantir que os nossos produtos são bons e práticos, é necessário fazer testes à usabilidade. Estes testes permitem ao criador identificar problemas (no design e da aplicação ou produto), descobrir oportunidades para melhorar o design e compreender os utilizadores através dos seus comportamentos e preferências.

Tipos de Testes de Usabilidade

Para o primeiro bake-off, focámo-nos bastante na avaliação formativa, enquanto que no segundo, focámo-nos mais no protótipo final e avaliação sumativa. Isto porque não fazia sentido estarmos a fazer avaliações formativas pois ainda não estava feito.

Formativa: realiza-se durante o processo de desenho, os resultados informam a próxima fase de desenho.

• "O que acontece durante a interação?"

Sumativa: refere-se a uma avaliação final para aferir sucesso.

• "Qual o resultado da interação", ou seja, conseguimos observar o problema mas não como resolve-lo, é o problema das munições referido acima.

Para realizar um bom teste de usabilidade, temos que focar-nos em três parâmetros (elementos) diferentes:

• Participantes
• Tarefas
• Medidas

Participantes/Utilizadores

Os participantes devem ser pessoas próximas do público-alvo, com maior disponibilidade. Também temos que ver uma sample representativa da população humana, ou seja, temos que ter o mesmo número de homens e mulheres de todas as idades (a não ser, claro, que tenhamos um produto específico para um grupo).

Para termos uma boa descrição do nosso grupo de participantes temos que ver a sua Demographic Info.

Mas quantos utilizadores devemos ter para que o nosso produto seja devidamente testado sem problemas?

Segundo Nielsen, devemos disponibilizar 20 utilizadores: 4 iterações com 5 utilizadores cada.

Se tivermos

• 1 utilizador → 33% dos problemas identificados
• 5 utilizadores → 85% dos problemas identificados
• 15 utilizadores → 99% dos problemas identificados

segundo um estudo publicado por Nielsen em 1993.

É necessário um grande número de utilizadores para ter a certeza que há sempre uma média não curta e não manipulável.

Tarefas

As tarefas que apresentamos aos nossos participantes têm que ser bastante bem definidas. Têm que ser:

• Reais e representativas
• O quê e não como
• Específicas
• Mistura de Complexidades
• Avaliação Comparativa
  • não favorecer uma das soluções
  • usar as mesmas tarefas

Por outras palavras, não podemos favorecer uma das soluções, por exemplo, usando ratos melhores ou dizendo comentários do género "passei vários dias e noites a trabalhar nesta parte" (o utilizador já sabe que essa parte específica vai ser mais favorável).

Medidas de Usabilidade

• Tempo para completar a tarefa
• Número de erros cometidos
• Número de tarefas concluídas
• Número de cliques
• Número de consultas à ajuda
• Satisfação do utilizador

Tipos de dados

• Quantitativos (quantidade, específicos e medíveis) - Segundo Bake-Off

  • Completou a tarefa? Sim/Não
  • Quanto tempo demorou?
  • Quantos erros?
  • Qual preferiu? A ou B

• Qualitativo (qualidade, "aberto") - Primeiro Bake-Off

  • O que gostou mais na sua experiência?
  • O que pensa do ecrã principal?
  • Mais difícil de obter?

• Objetivos

  • Não dependem da pré-disposição (bias) inerente ao ser humano (ex.: tempo, erros, frequência cardíaca, etc.)

• Subjetivos

  • Realça a perceção do utilizador (ex.: preferência, SUS, SEQ, etc.)

SUS: acima de 68% é minimamente utilizável, já há valores médios por ser tão utilizado.

SEQ: debriefing se tiveram dificuldade a completar alguma tarefa.

Testes-piloto

Qualquer pessoa pode completá-los, têm que ter 2 a 3 pessoas, é necessário testar procedimento:

• Duração
• Instruções
• Tarefas
• Questionário

Testes A/B

Uma das maneiras mais comuns de testar a usabilidade de um produto é através dos testes A/B. Estes testes têm o objetivo de verificar qual a melhor opção de cor, logótipo, layout de página web, tipografia, botões, etc.

"A/B testing is like flossing! All of us should be doing it but most of us are not."

Google's 41 Shades of Blue

Um bom exemplo de testes A/B é o Google's 41 Shades of Blue: nestes testes, a Google mostrou 41 cores diferentes aos seus utilizadores; sempre que alguém entrava no motor de pesquisa, ia para um bucket e assim a empresa podia ver qual a cor que tinha mais sucesso. Apesar de não ser evidente à priori, uma simples mudança de cor fez com que a empresa ganhasse mais $200m por ano.

Esta teste levou a um conflito entre as equipas de Engenharia e de Design na Google, dado a decisão de qual a melhor cor ter sido tomada com base numa experiência prática com utilizadores reais em vez de só com base na expertise da equipa de Design.

Como dividir os grupos?

Existem duas maneiras de dividir os grupos para fazer os testes:

• Intergrupos: "Between-subjects", é necessário ter em atenção que temos que recrutar o dobro das pessoas e temos que ter em atenção que os grupos têm que ser comparáveis (ex.: um grupo que tem vacina e outro que não).

• Intragrupos: "Within-subjects", cada grupo testa as duas interações, vamos trocando a ordem do uso dos sistemas (aprendizagem, fatiga).
  • foi o que fomos fazendo nas aulas práticas durante os bake-offs.

Contudo, temos que ter atenção que há uma série de fatores que influenciam as pessoas. Por exemplo, se um grupo já testou 40 vezes o projeto A pode estar mais viciado nesse projeto, ou pode estar mais cansado desse projeto e tem uma opinião mais influenciada.

Então, como lidamos com os efeitos da ordem de utilização? Temos que ir alterando os testes a cada produto, counter-balancing.

Exemplo

3 sistemas ou versões: A, B, C

Utilizador 1: A B C

Utilizador 2: A C B

Utilizador 3: B A C

Utilizador 4: B C A

Utilizador 5: C A B

Utilizador 6: C B A

Counter-balancing funciona de uma forma fatorial, resumidamente:

• 3 sistemas: 3! = 6 utilizadores
• 4 sistemas: 4! = 24 utilizadores
• 5 sistemas: 5! = 120 utilizadores

Variáveis Dependentes e Independentes

Variáveis Dependentes:

• O seu valor depende do sistema a testar
• Variáveis medidas no estudo (tempo, erros, SUS)
• Relacionados com o objetivo do protótipo

Variáveis Independentes:

• Não dependem das variáveis que estamos a medir
• Características da solução (layout, cor, etc.)
• Características dos participantes (idade, etc.)

Exemplo do segundo bake-off:

• Teste sumativo
• Intragrupos (se testado nos labs)
• Variáveis dependentes
  • Tempo, taxa de erro
• Variáveis independentes
  • Solução mais recente do grupo x (esquema de cores, representação do alvo a escolher, etc.)
• Dados quantitativos

Efeitos Secundários

Deparamo-nos agora com um problema, um problema de fixação funcional, feito por Duncker em 1945. Duncker colocou à frente dos seus participantes uma vela, uma caixa de pioneses e fósforos e pediu para cada pessoa arranjar uma forma para que a vela fosse acendida mas não pingasse cera para a mesa. Contudo, dividiu os participantes em dois grupos:

• Grupo A tinha os pioneses dentro da caixa
• Grupo B tinha os pioneses fora da caixa

Como os pioneses estavam fora da caixa era mais evidente para o grupo B que a caixa trabalhava como outro elemento que pudesse ser utilizado e não somente como um suporte para os pioneses. Assim, o grupo B acabou mais rapidamente a experiência.

Em 1962, Glucksberg testou a mesma experiência, mas adicionou mais uma variável:

• Obter o tempo médio de resolução
• Recompensa pelo tempo mais rápido. Top 25% recebe $40, mais rápido recebe $150.

Ao motivar os participantes, no grupo que tinha os pioneses na caixa, ou seja, os participantes que necessitavam de mais criatividade, o grupo com recompensa foi mais lento, enquanto no grupo que tinha os pioneses dentro da caixa, o grupo com recompensa foi mais rápido.

Associar recompensa a desempenho aumentou o foco mas restringe a criatividade, é bom para tarefas simples com instruções claras.

Efeito de Hawthorne / Efeito do Observador

"It was suggested that the productivity gain occurred as a result of the motivational effect on the workers of the interest being shown in them." - Henry A. Landsborg, 1958

Por outras palavras, quando há mais pressão, há um ganho de produtividade.

Novelty effect: quando vemos algo novo, ficamos mais excitados sem razão. O produto até pode não ser nada de especial, mas, só por ser algo novo, temos curiosidade. Por isso, temos que testar o produto mais do que uma vez para testar o quão bom e prático é.

Ética avaliação com utilizadores

Assumimos logo à partida que a ética provém de senso comum e que os cientistas são boas pessoas que nunca nos irão pôr numa posição desconfortável ou contra o nosso ser e as nossas crenças, contudo a História conta algo bastante diferente.

Existem vários casos em que, apesar dos cientistas estarem bem intencionados, as suas experiências acabam não só por prejudicar mas como mesmo traumatizar os participantes. Um grande exemplo de tal é a Stanford Experiment, em que um grupo de investigadores pretendia investigar o comportamento humano numa sociedade na qual os indivíduos são definidos somente pelo grupo em que se encontram. Assim, dividiram os participantes em dois grupos, uns que representavam os polícias e outro que representavam os prisioneiros. Contudo, ao fim de muito pouco tempo, os policias, com o poder que lhes subiu à cabeça, já estavam a maltratar a nível não só emocional mas também físico, os prisioneiros. Esta experiência ficou tão conhecida que em 2015 saiu um filme sobre a mesma.

Contudo existem muitos outros exemplos de experiências que acabaram de uma forma não muito favorável para os participantes, como é o caso de Tuskegee syphilis study ou até mesmo Milgram experiment.

Por isso, ao começarmos a testar o nosso projeto com participantes é necessário ter em conta algumas considerações éticas.

Considerações éticas

Temos que sempre manter em consideração que os testes podem causar stress, desconforto, entre outros sintomas aos nossos participantes e por isso é da responsabilidade de quem está a realizar o teste de antecipar e aliviar esses sintomas.

Os participantes são voluntários, por isso consentimento para o que quer que seja é de extrema importância; é necessário evitar pressão para participar, não obrigando ninguém a tal; informar os participantes que podem termninar a qualquer momento; realçar que quem está a ser testado é o sistema, NUNCA os utilizadores; e tornar os dados anónimos/proteger dados.

Também é necessário manter em consideração que existem certas populações vulneráveis, com quem devemos ter ainda mais cuidado, nomeadamente crianças, pessoas com deficiência ou minorias.

Por último, qualquer teste tem que ter uma aprovação de uma comissão de ética para ser realizado.

Três princípios de investigação com pessoas

Resumidamente, existem três princípios muito importantes ao fazer investigação e testes com participantes:

1. É necessário haver respeito pelas pessoas:

• Os indivíduos têm autonomia e escolha
• Não podem ser usados como meio para atingir um fim
• É necessário proteger os mais vulneráveis
• É necessário usar consentimento informado

2. Beneficência (fazer o bem):

• Obrigação de fazer o bem
• Obrigação de não prejudicar
• Obrigação de prevenir danos
• Minimizar riscos, maximizar benefícios
• Bondade além do dever
• Avaliação de riscos e benefícios

3. Justiça:

• Garantir igualdade
• Dividir riscos e benefícios pela amostra
• Recrutamento de participantes justo

É sempre necessário ter em conta vários aspetos sobre as pessoas, nomeadamente a nível de crenças, religião, princípios entre outros. Contudo não nos precisamos obrigatoriamente de focar em aspetos como hobbies ou atitudes habituais de uma pessoa, visto que já não afetam a ética de forma alguma.