Os testes de usabilidade têm uma fama imerecida de serem caros e demorados. Quando as pessoas ouvem "investigação com utilizadores", imaginam um espelho falso, um moderador com uma prancheta e um calendário de duas semanas. Essa versão dos testes existe e tem a sua utilidade — mas não é a de que a maioria das equipas de produto precisa na maior parte do tempo.
A versão de que a maioria das equipas precisa é mais simples: cinco utilizadores, um protótipo em Figma ou um ambiente de teste (staging), uma videochamada e 45 minutos por sessão. Bem feita, revela a maioria dos problemas graves de usabilidade antes do lançamento. Feita com regularidade — mesmo que apenas uma vez por sprint —, produz uma melhoria cumulativa na qualidade do produto que nenhuma análise pós-lançamento consegue replicar.
Eis como fazê-lo, do zero.
Cinco participantes é o número certo para a maioria dos testes de usabilidade. A investigação de Jakob Nielsen concluiu que cinco utilizadores descobrem cerca de 85% dos problemas de usabilidade, com retornos decrescentes a partir daí. Fazer três sessões com cinco utilizadores em diferentes momentos do processo de design vale mais do que uma sessão com quinze.
Os critérios de recrutamento importam mais do que o número. Um teste de usabilidade com cinco pessoas que correspondem de perto ao seu utilizador-alvo revela problemas reais. Um teste com quinze pessoas que não correspondem gera ruído. Defina dois ou três critérios de triagem — função, contexto de utilização, nível de familiaridade com a tecnologia — e mantenha-se fiel a eles.
O caminho de recrutamento mais rápido para a maioria das equipas é enviar um e-mail aos utilizadores existentes que autorizaram contacto. Ofereça um incentivo modesto — um cartão de oferta de £20 chega para uma sessão de 45 minutos. Procure marcar as sessões na mesma semana; quanto maior o intervalo entre o recrutamento e os testes, maior a taxa de faltas.
O erro mais comum na elaboração do guião é escrever as tarefas como instruções: "Clique em Definições, depois navegue até Notificações e altere a sua preferência para..." Isto diz ao utilizador o que fazer, o que significa que está a testar se ele sabe seguir indicações, não se a interface é intuitiva.
Escreva antes as tarefas como cenários: "Imagine que tem recebido muitas notificações e quer receber alertas apenas quando alguém o menciona diretamente. Mostre-me o que faria." Isto dá ao utilizador um objetivo realista e permite-lhe observar como navega de facto — incluindo onde se confunde.
A parte mais difícil de moderar um teste de usabilidade é resistir ao impulso de ajudar. Quando um utilizador se confunde, todo o instinto diz para intervir e mostrar onde clicar. Mas a confusão é o dado. Um utilizador que está a ter dificuldades está a dizer-lhe que há algo errado na interface — e no momento em que intervém, perde o sinal.
Peça aos utilizadores que pensem em voz alta durante a sessão: "À medida que avança, diga-me apenas o que está a ver e o que está a pensar." Isto produz um fluxo contínuo de dados sobre o seu modelo mental. Repare não só nos erros, mas nas hesitações — um utilizador que faz uma pausa de três segundos antes de clicar no botão certo revelou, ainda assim, um problema de design, mesmo que tenha acabado por conseguir.
O passo da síntese é onde se cria a maior parte do valor — e onde a maioria das equipas corta caminho. As notas em bruto de cinco sessões não são conclusões. Passam a ser conclusões quando se faz um debrief em equipa, se agrupam as observações por tema e se atribuem classificações de gravidade.
Faça o debrief no mesmo dia das sessões, enquanto as observações estão frescas. Agrupe os problemas em três níveis: crítico (os utilizadores não conseguiram concluir a tarefa), moderado (os utilizadores concluíram a tarefa, mas com dificuldade ou erro significativos) e menor (atrito que não impediu a conclusão). Os problemas críticos têm de ser corrigidos antes do lançamento. Os moderados devem ser priorizados no sprint seguinte. Os menores vão para o backlog.
Escreva as conclusões numa única página: os três principais problemas críticos, com evidência de pelo menos dois participantes em cada um, e uma alteração de design proposta para cada um. O que precisar de mais espaço do que isso pertence a um documento à parte.