Por que cinco participantes bastam num teste de usabilidade

Cinco participantes bastam para um teste de usabilidade qualitativo, e o número vem de uma curva medida, não de um hábito. Jakob Nielsen e Thomas Landauer modelaram a descoberta de problemas como um processo de Poisson (em inglês) em 1993. O modelo deles estima que um único participante encontra cerca de 31% dos problemas de uma interface. Cinco participantes cobrem perto de 85% deles. A mesma pesquisa também diz onde esse limite está, e a maioria dos times pula essa parte.

De onde vem o número cinco

Jakob Nielsen e Thomas Landauer publicaram “A mathematical model of the finding of usability problems” (em inglês) na conferência ACM INTERCHI’93, em Amsterdã. Eles trataram cada participante como uma chance independente de esbarrar num problema. Em 11 estudos, a detecção de problemas se ajustou bem a um processo de Poisson.

O modelo tem dois termos. N é o total de problemas do design. L é a fatia desses problemas que um participante encontra. A estimativa média de L nos estudos deles foi de 31%. Com esse valor, um participante acha cerca de um terço dos problemas, três acham cerca de dois terços, e cinco acham perto de 85% (Nielsen e Landauer (em inglês)).

O custo também faz parte do argumento. O artigo de 2000 (em inglês) situa a melhor relação benefício-custo entre três e cinco usuários, dependendo do estilo do teste. O cinco é um arredondamento de uma curva, não uma constante da natureza.

Nielsen repetiu a regra para a web em março de 2000, no artigo “Why You Only Need to Test with 5 Users” (em inglês), no site do Nielsen Norman Group. Dois detalhes ali pesam mais que a manchete. A curva mostra que cobrir o conjunto completo de problemas exige cerca de 15 participantes. A recomendação é gastar esse orçamento em três estudos de cinco, em vez de um estudo de quinze, porque o objetivo é um design melhor e não um relatório maior.

O artigo de 2000 ainda diz o que é fácil esquecer: zero usuários produzem zero descoberta. O primeiro participante vale mais que o quinto, e o quinto vale mais que o vigésimo.

Por que o retorno cai rápido depois dos primeiros

Cada participante novo repete parte do que os anteriores fizeram e acrescenta menos coisa nova. A curva de achados novos vai ficando plana. O modelo de 1993 e o artigo de 2000 descrevem o mesmo efeito. O segundo participante ensina menos que o primeiro, e o quinto ensina pouco que os três primeiros não tenham mostrado.

O acompanhamento de 2012 de Nielsen, “How Many Test Users in a Usability Study?” (em inglês), relata uma pesquisa que ele aplicou na própria conferência de UX com 217 respondentes. A prática média nas empresas deles era de 11 participantes por rodada, mais que o dobro da recomendação. As sessões extras custaram dinheiro e trouxeram poucos achados novos.

A alternativa a uma amostra maior é uma segunda rodada. Depois do redesenho, um grupo novo de cinco testa a correção e ainda expõe problemas que a primeira rodada não pegou. O artigo de 2000 (em inglês) situa a primeira rodada perto de 85% dos problemas e diz que a segunda encontra a maior parte dos 15% restantes. Uma terceira rodada limpa o que sobra.

O custo fixo faz parte do argumento. Recrutar, agendar e montar uma sessão custa quase o mesmo para um participante e para cinco. O artigo de 2012 (em inglês) observa que um custo fixo menor por estudo é o que permite rodar muitos estudos pequenos. Diluir esse custo fixo entre cinco pessoas baixa o preço de cada achado.

O que cinco participantes não resolvem

Quatro situações em que cinco é o número errado.

Medir é outra história. Cinco participantes sustentam descoberta. Eles não sustentam um número. O artigo de 2012 (em inglês) de Nielsen fixa o piso de 20 participantes para estudos quantitativos e diz que intervalos de confiança estreitos exigem mais. Card sorting precisa de pelo menos 15 por grupo. Mapas de calor de eyetracking precisam de 39. O artigo de 2006 sobre estudos quantitativos (em inglês) mostra a conta por trás desse piso.

Nem sempre existe um público só. O modelo de 1993 vale para usuários comparáveis, que usam o produto de forma parecida. Nielsen recomenda de 3 a 4 participantes por categoria (em inglês) ao testar dois grupos, e 3 por categoria para três grupos ou mais. O kit de teste de usabilidade do Departamento de Segurança Interna dos Estados Unidos (DHS) (em inglês) diz isso de forma direta. “If you think there might be different behaviors for different types of users, include four of each type.”

Problemas raros ficam invisíveis. Jeff Sauro, da MeasuringU, refez a conta binomial (em inglês) em 2010. Cinco usuários dão 85% de chance de ver um problema que afeta 31% dos usuários. Um problema que afeta 10% dos usuários exige 18 usuários para a mesma chance. Um problema que afeta 1% exige 189. Sauro acrescenta (em inglês) que, em software já lançado, a frequência de um problema costuma ficar abaixo de 10%. Por isso os mesmos cinco participantes acham menos problemas num produto maduro do que num protótipo.

Cinco é uma distribuição, não uma garantia. Laura Faulkner testou 60 usuários em 2003 e sorteou conjuntos aleatórios a partir do grupo inteiro. O artigo dela (em inglês), na Behavior Research Methods, Instruments and Computers volume 35, relata que alguns conjuntos de cinco acharam 99% dos problemas, enquanto outros acharam só 55%. Com 10 usuários, o conjunto mais fraco achou 80%. Com 20 usuários, 95%.

Esse último achado é uma crítica justa, mas não derruba a regra. Mostra que o resultado varia. A média ainda favorece cinco em vez de quinze, e o pior caso é argumento para uma segunda rodada, não para uma sessão gigante. Um risco diferente mora antes da sessão, e dado de pesquisa inválido cobre o que estraga um estudo antes de o primeiro participante chegar.

Como montar o roteiro de tarefas

Tarefa é um objetivo mais um ponto de partida. Um caminho pela interface não é tarefa, é o gabarito.

Escreva a tarefa com as palavras de quem faz, nunca com as palavras da interface. “Ache a fatura que você mandou em março” funciona. “Abra a aba Cobrança e use o filtro de data” entrega o caminho e não mede nada.
Teste primeiro o fluxo mais arriscado. Se a sessão for interrompida, o achado valioso já está registrado.
Mire de cinco a sete tarefas por sessão. O kit do DHS (em inglês) fixa o limite em “not more than 15-20 minutes per participant” de atividade, e o roteiro do digital.gov (em inglês), da Administração de Serviços Gerais dos Estados Unidos, sugere uma duração de sessão como 30 minutos.
Faça o fim ser observável. Você precisa saber se a tarefa terminou, e tarefa sem linha de chegada não pode ser pontuada.
Cubra o estado em que a pessoa chega. Visitante de primeira viagem e cliente recorrente são duas tarefas diferentes, mesmo na mesma tela.
Leia a tarefa em voz alta uma vez e entregue. Se você precisa explicar, a tarefa está quebrada e não o participante.
Faça uma sessão de treino com um colega. Recrute os participantes de verdade para o teste de verdade.

Como conduzir sem induzir a resposta

O trabalho do moderador é observar e ouvir, não ensinar. O kit do DHS (em inglês) enuncia o princípio numa linha: você observa e ouve sem ensinar nem treinar. Cada dica que você dá gasta o achado que você pagou para ter.

Diga o enquadramento antes. O roteiro do digital.gov (em inglês) abre com a frase de que não existem respostas erradas e pede que a pessoa pense em voz alta o máximo possível.
Fique em silêncio por dez segundos depois que a pessoa parar de falar. A segunda frase costuma ser a útil, e ela só aparece se você esperar.
Responda pergunta com pergunta. “O que você esperava que acontecesse?” mantém a pessoa falando. “Fica no canto superior direito” encerra a sessão cedo.
Nunca confirme. Palavras como “certo”, “exato” e “boa” ensinam o participante sobre o que você quer ouvir pelo resto da sessão.
Não diga o nome da função. No instante em que você fala o nome do botão, você testou o seu vocabulário e não a interface.
Jogue a culpa no design. “Esta tela confunde e a culpa é nossa” libera a pessoa para admitir a falha.
Peça a última vez real. “Quando você fez isso de verdade pela última vez, e como foi?” produz memória em vez de opinião.
Deixe as perguntas de opinião para o fim, ou corte. O que a pessoa diz que faria e o que ela faz na tela são conjuntos de dados diferentes.

O que anotar durante a sessão

Anote o que aconteceu, na ordem em que aconteceu, com as palavras que o participante usou.

A ação. O que a pessoa clicou, digitou ou rolou, e onde isso estava na tela.
O resultado da tarefa. Concluiu, concluiu com dificuldade ou falhou. Esse campo sozinho carrega a maior parte da análise depois.
A fala. Uma frase curta com as palavras do participante, ao lado da ação que ela explica.
A expectativa. O que a pessoa disse que esperava ver antes de agir. A distância entre expectativa e tela é o achado.
A gravidade. Se aquilo bloqueia a tarefa, se custa tempo, ou se é cosmético. Ordene por esse campo, não pelo volume da reclamação.
O contraexemplo. Registre quem passou direto, senão você redesenha para a pessoa que falou mais alto.
O marcador de tempo. Se a sessão for gravada, o time code transforma uma memória vaga num trecho que você reproduz para o time.

Um moderador e um anotador é a divisão prática. O kit do DHS (em inglês) coloca um moderador na sala e é ele quem anota. Um segundo observador pega os momentos que o moderador perde enquanto fala.

Como transformar achado em decisão

Agrupe por problema, não por participante. Três pessoas batendo na mesma parede é um problema com contagem três, e essa contagem é a sua estimativa de frequência.
Ordene por gravidade vezes frequência. Um bloqueio visto uma vez passa na frente de um detalhe cosmético visto cinco vezes.
Decida cada item de uma das três formas: corrige, adia com motivo escrito, ou aceita como trade-off. O motivo escrito é o que evita o mesmo debate no próximo trimestre.
Corrija os bloqueios no redesenho e mantenha o resto da lista visível. Achado que sai da sala e não entra em nenhum backlog é achado pago e jogado fora.
Teste a correção com um grupo novo de cinco. O artigo de 2000 (em inglês) é explícito ao dizer que um redesenho é uma afirmação e não uma prova, e que uma segunda rodada verifica a afirmação.
Guarde os contraexemplos no relatório. Eles marcam as partes do produto que já funcionam e não devem ser mexidas.

A regra sobrevive porque a alternativa é pior. Cinco participantes, uma tarefa real e um moderador que fica quieto produzem mais decisão de usabilidade por hora do que quinze participantes respondendo a um roteiro indutor. O número não é o método. A tarefa e o roteiro são o método.

Um argumento parecido sobre escolher a camada que já carrega o comportamento está no post sobre HTML semântico. Uma nota sobre testar a decisão antes de construir está no post sobre checkout.

Onde o Nielsen Norman Group diverge

O próprio NN/g não fica num número só. O artigo de 2000 (em inglês) enuncia a regra fixa, e o acompanhamento de 2012 (em inglês) a amolece. Para projetos de custo fixo baixo, o artigo de 2012 coloca o ótimo em dois usuários por estudo. Ele também relata que o próprio NN/g costumava rodar perto de oito usuários em consultoria. Discount Usability: 20 Years (em inglês) acrescenta que a recomendação de 1989 era três usuários, e que Nielsen passou para cinco como um acordo prático.

Os números quantitativos também se movem. O artigo de 2006 (em inglês) trata 20 usuários como suficientes para uma margem de erro perto de 19%. Já o artigo de 2021 (em inglês) coloca intervalos de confiança estreitos em 40 participantes ou mais. Este post trata a regra qualitativa como assentada e lê os dois números quantitativos como uma faixa.