Guia rápido para conduzir testes não moderados

Ter uma rotina de teste de usabilidade, em modo presencial ou remoto, para validar a eficiência das propostas e conceitos desenvolvidos para um produto é um dos grandes desafios para vários times de desenvolvimento. É um processo que exige muito esforço principalmente nas etapas de recrutamento e agendamento de participantes.

Entretanto, para alguns contextos, onde você precisa checar alguma ação específica e mapear seus efeitos é possível fazer uso de testes não moderados, que não necessitam de acompanhamento de um facilitador. Eu e o Raoni Caselli reunimos aqui alguns aprendizados sobre este tipo de abordagem.

Quando aplicar?

No livro Handbook of Usability Testing Jeffrey Rubin e Dana Chisnell recomendam testes não moderados como uma maneira de complementar testes de usabilidade moderados.

Testes menos complexos, com fluxos simples, compostos de poucos passos (sugestão até 3 cliques), estudos de copy, de posicionamento de componentes, de microinterações e avaliações de look & feel são cenários que podem se beneficiar deste tipo de abordagem que pode ajudar a esclarecer dúvidas pontuais durante uma fase de conceito ou de refinamento de um fluxo.

Como aplicar?

Inge de Bleecker e Rebecca Okoroji em seu Remote Usability Testing sugerem atenção a alguns pontos para a aplicação de um teste não moderado:

• A quantidade de respondentes precisa ser expressiva para ter alguma significância estatística;
• Para cada tarefa proposta, sempre que possível, complemente com o uso de surveys para ter resultados que complementarão os achados obtidos via captura de cliques e heatmaps.
• Atenção na definição do perfil dos participantes pois o setup do teste vai exigir que eles tenham habilidade para interagir com o protótipo sem a ajuda do moderador.
• A estrutura de um teste não moderado exige um cuidado ainda maior na hora do copy. As instruções precisam ser claras, objetivas, sem ambiguidade e devem ter destaque para garantir que serão lidas. Isso minimizará problemas com induções, dúvidas e erros na hora da realização da tarefa.
• O objetivo do estudo deve ser apresentado ao respondente antes do primeiro contato com a interface a ser avaliada. Isso ajuda a mitigar o tempo de leitura com informações secundárias.
• O tempo de leitura das informações na tela deve ser considerado na hora da avaliação de completude.
• Para garantir que tudo ocorra como esperado, um teste piloto é mais que recomendado nessa abordagem.

Qual ferramenta escolher?

Há inúmeras opções de ferramentas disponíveis no mercado para facilitar a aplicação de testes não moderados. A depender dos recursos que pretendemos integrar na atividade, encontrar a ferramenta adequada pode demandar um pouco de tempo. Neste link o Nielsen & Norman Group apresenta uma boa variedade para explorar e conhecer. Lembre-se de considerar na exploração quais recursos a ferramenta dispõe para análise de dados e apresentação de resultados.

Vantagens

• A pessoa usuária pode realizar o teste no momento e local mais conveniente para ela;
• Não requer o acompanhamento de um facilitador;
• Não há despesas com o aluguel e preparação do espaço físico para aplicação do teste;
• Não há despesas com o deslocamento do participante até o local da atividade;
• Otimiza o tempo gasto no processo de recrutamento;
• Atinge um grande volume de respostas a partir de diferentes perfis e contextos em um curto/médio prazo.

Desvantagens

• Mesmo que a clareza das orientações tenham sido testadas, algumas pessoas podem sentir dificuldade para entender os procedimentos pois o cenário não moderado requer certa familiaridade com o uso de recursos digitais;
• Não é possível observar comportamentos, dúvidas e reações no momento que a pessoa está interagindo com o protótipo. Isso dificulta o mapeamento do impacto e do nível de severidade do ponto de vista da pessoa usuária;
• Como outros processos não moderados, não é possível identificar o estado emocional/físico do respondente. ex. feliz, raivoso, com sono, fatores que impactam na tomada de decisão e escolha dos participantes;
• Não temos controle sobre a infra-estrutura e isso pode impactar no tempo de execução da atividade. Ex. A qualidade da conexão pode piorar durante o teste ou interrupções com ligações e pessoas próximas podem acontecer;
• Pode ocorrer uma falha técnica no protótipo e não há como orientá-lo sobre o procedimento para realizar uma nova tentativa;
• Você precisa ter uma base significativa de pessoas usuárias, preferencialmente bem estratificada para te ajudar a fazer boas correlações durante a análise.

Testando a abordagem

Para verificar a eficiência da aplicação de testes não moderados preparamos um cenário cujo objetivo principal era entender se o novo visual de uma página do produto RD Station CRM estava fácil de entender, navegar e gerenciar. Isso envolveu a criação de algumas atividades com o foco em tarefas de gestão de contato com o cliente, como edição de informações e localização de dados específicos.

A integração com o Figma somada a opção de ter disponível uma versão gratuita nos fez optar pelo Maze. Verificamos a possibilidade de testar outras ferramentas como o Useberry, mas tivemos dificuldades na integração e o fato do Maze já ter sido utilizado antes por outros membros do time influenciou nossa escolha.

https://maze.design/#khcgov19be-

Setup do teste

• As perguntas iniciais, objetivas, buscavam identificação do perfil: tempo de contato com o produto e o perfil de atuação na empresa;
• O Maze denomina de missão cada atividade a ser avaliada. Após as perguntas iniciais, os respondentes foram apresentados às missões. Após algumas discussões e pensando em não sobrecarregar os participantes, um total de 6 missões foi definido para ser avaliado.
• Para evitar ambiguidade e dúvidas na hora de entender o objetivo de cada missão, dedicamos um tempo extra para revisar a descrição de cada missão;
• Uma escala Likert de 5 pontos foi usada para avaliar a percepção sobre o nível de dificuldade (geral) ao realizar todas as atividades. Ela foi aplicada logo após o participante finalizar todas as missões;
• Para finalizar, aplicamos uma questão subjetiva (não mandatória) para coletar sugestões de melhoria.

Para evitar que os usuários se perdessem e não conseguissem voltar sozinhos para telas anteriores evitamos fluxos longos, com muitos passos e navegação entre telas. Isso ajudou a tornar o teste mais objetivo e dinâmico.

Resultados

• O resultado foi bastante satisfatório, trouxe muitos insights e respostas sobre a forma como usuários perceberam e interagiram com um novo componente que estávamos testando;
• Com a análise dos dados de cada teste, conseguimos avançar em algumas suposições sobre o entendimento das funcionalidades de gestão da página do contato;
• O Maze trabalha com caminhos sequenciais (paths) e desta maneira considerou completude de tarefa apenas quando o respondente percorria o flow estabelecido, não considerando outros caminhos alternativos como sucesso direto, apenas indireto. Para esses outros caminhos contarem como direto, precisam estar também mapeados no Maze;
• Durante a análise, percebemos que algumas melhorias poderiam ter resultado em dados menos distorcidos. Notamos que as pessoas passaram um tempo maior na primeira tela e o fato do primeiro contato com o protótipo ser imediatamente uma tarefa impactou diretamente o tempo de performance, pois muitos usaram esse momento para explorar a novidade. Soma-se a isto o fato do protótipo apresentar uma proposta de Redesign em todas as telas apresentadas;
• O Maze apresentou bugs, principalmente quando o protótipo possuía a abertura de “overlays” ou quando possuía alguma animação, às vezes não considerando a completude de uma missão mesmo com o usuário fazendo tudo corretamente;
• Ter uma definição de sucesso direto e indireto é confusa, pois qualquer interação fora dos caminhos mapeados resulta em um sucesso indireto, que por sua vez baixa a nota de usabilidade dada pela ferramenta para a missão;
• A forma de apresentação dos dados é bem agradável — o que possibilita apresentar os resultados direto de sua plataforma. Assim que atingimos um certo número de respondentes, N>100, foi possível compartilhar o link ou enviar o resumo com resultados parciais em formato pdf.

Tela do Maze com apresentação dos resultados do teste

• Sentimos dificuldade no momento de configurar o mapeamento de caminhos alternativos para a conclusão da missão. Verificamos que em alguns momentos, a interação não funcionava bem com o Overlay, por esse motivo, optamos por não configurar fluxos alternativos. Não foi possível verificar a performance de tempo para quem optou concluir a atividade por meio de outra sequência de ações;
• A sequência das missões foram iguais para todos os participantes, permitindo o aprendizado ao longo do teste de como completar uma missão antes mesmo de chegar nela e dificultando a análise das últimas missões . Se o Maze permitisse a randomização das missões, poderia reduzir esse viés;
• Teste não moderado foi uma boa opção para verificar a relação entre o contexto da tela e o impacto de uma determinada interação. Uma interação pode ter impacto diferente a depender do contexto e do objetivo proposto em cada tela. Conseguimos aprender sobre a usabilidade de um novo componente criado para o Design System do RD Station, aplicado em um contexto de uso do produto;
• Sobre os aprendizados com o setup do teste: algumas instruções não estavam tão claras e acabaram direcionando alguns respondentes para outras missões;
• Por fim, sobre o nosso objetivo inicial, identificar pontos de melhoria e entender o quanto a nova proposta estava compreensível e intuitiva para navegar, os resultados indicaram que o aprendizado sobre como usar foi satisfatório mesmo para aqueles que não estavam familiarizados com esse tipo de atividade. Durante o teste observamos que o mesmo tipo de interação foi executado de forma mais rápida conforme a progressão nas missões.

Boas práticas baseadas nos resultados de vários experimentos

• Caso exista mais de uma maneira, em diferentes pontos da tela, para realizar a mesma tarefa, é importante considerá-la na avaliação. Considere a possibilidade de ter diferentes versões do teste para conseguir verificar qual dos caminhos foi o mais percorrido, assim como o tempo de completude para cada alternativa;
• Tente descrever com clareza as tarefas, valide o texto com pessoas de diferentes perfis, preferencialmente pessoas não técnicas. É uma boa forma de verificar o quanto o texto está ou não está claro;
• Aplique alguns testes piloto para verificar as especificidades do fluxo e checar se tudo está funcionando como esperado. 5 testes já te ajudam a identificar pontos críticos na estrutura do teste;
• Tenha uma tela de introdução para explicar o contexto do estudo e dar uma visão geral sobre as atividades que serão executadas. Isso ajudará a diminuir o tempo do participante ao entrar em contato com a tela inicial. Em um segundo experimento com o Maze, colocamos uma tela de boas vindas, sem interações, só com a imagem do protótipo, isto diminuiu o bounce de 57% para índices entre 3 e 17% na primeira tela. Evite retrabalhos e esforços desnecessários;
• Embora seja tentador continuar coletando dados, ao iniciar a análise encerre o experimento;
• Não coloque muitos passos dentro de uma mesma missão/tarefa. Além de ser mais tranquilo para quem testa, fica mais simples para analisar. Recomendamos tarefas que possam ser realizadas em 3 cliques;
• Muito cuidado com a resolução e peso do protótipo. O Maze gerencia a exibição do protótipo diferente do que foi definido no Figma. Vale testar antes em tamanhos de tela menores e conexões mais lentas (dá pra simular);
• Não use overlays no protótipo, a depender do posicionamento dos componentes o overlay bloqueia a ação de interação e impede a completude da tarefa;
• Se for usar a conta gratuita do Maze lembre-se que não será possível extrair os dados brutos para tabular em planilha;
• Para evitar que os participantes abandonem o processo no meio do teste, use uma pequena quantidade de missões;
• Evitar o uso de animações e overlays, dar preferência a transição entre páginas, mesmo para mostrar interações simples como hover. Isso garante que o teste funcione para todos, diminuindo possíveis bugs e métricas alteradas;
• Para evitar erros e cliques no lugar errado, limite a quantidade de interações em cada missão avaliada. Em nosso segundo experimento usamos um protótipo com 3 grandes áreas interativas e observamos que isto pode ter causado distrações e até desistências em algumas missões.

Para saber mais

Remote Usability Testing, actionable insights in user behavior across geographies and time zones por Inge De Bleecker & Okoroji Rebecca.

Remote Usability tests: moderated and unmoderated por Amy Shade. Disponível em: https://www.nngroup.com/articles/remote-usability-tests/

Handbook of Usability Testing, how to plan, design, and conduct effective tests por Jeff Rubin & Dana Chisnell.