Como testar uma ideia antes de construí-la

Para testar uma ideia antes de construí-la, liste o que precisa ser verdade para ela funcionar, escolha a crença que é ao mesmo tempo a mais importante e a menos comprovada e faça o teste mais barato capaz de mostrar que ela está errada. Decida de antemão qual resultado conta como aprovação, faça o teste com pessoas reais em condições reais e então escolha continuar, mudar ou parar. Você não está testando se as pessoas gostam da ideia. Está testando se a coisa mais arriscada em que você acredita sobre ela se sustenta.

Por que "mostramos para as pessoas e elas gostaram" não é um teste

A validação mais comum é uma apresentação seguida de aplausos. As pessoas são educadas, sobretudo com colegas e sobretudo quando a ideia é apresentada com capricho. O que as pessoas dizem que fariam e o que de fato fazem costumam estar muito distantes.

Um teste de verdade tem três características. Mira uma premissa específica. Tem uma meta de aprovação combinada antes de alguém ver os resultados. E pede que as pessoas façam algo, como dar tempo, dar informação, mudar um hábito ou se comprometer, em vez de dar uma opinião. Se o seu teste não pode falhar, é uma demonstração.

Como testar uma ideia: sete passos

1. Escreva a ideia numa frase com um quem e uma mudança

"Um app para estudantes" é uma categoria, não uma ideia que possa ser testada. "Estudantes do primeiro ano que perdem aulas conseguem se atualizar em até 24 horas com um resumo curto gravado pelo professor" pode ser testado. Diga para quem é, o que essas pessoas vão fazer de diferente e o que melhora para elas.

2. Liste todas as premissas por trás dela

Pergunte à equipe: o que precisa ser verdade para isso funcionar? Insista em pelo menos quinze crenças. Agrupe-as em três perguntas muito usadas na prática do design: as pessoas querem isso (desejabilidade), conseguimos entregar (viabilidade técnica) e conseguimos sustentar (viabilidade do negócio)? As equipes costumam listar primeiro os riscos técnicos, porque é confortável discuti-los. Os riscos que afundam ideias estão com mais frequência na desejabilidade e na sustentabilidade do negócio.

Um pré-mortem, a técnica de Gary Klein de imaginar que o projeto já fracassou e perguntar por quê, é uma forma rápida de trazer à tona premissas que as pessoas relutam em dizer em voz alta.

3. Encontre a premissa mais arriscada

Posicione cada premissa em dois eixos: quão importante ela é para a ideia e quanta evidência vocês já têm. Isso é o mapa de premissas, popularizado por David J. Bland. O canto superior esquerdo, crítico e não comprovado, é onde vocês testam primeiro. Escolham uma, duas no máximo. Todo o resto espera.

Uma verificação útil: "Se isso se mostrar falso, a ideia morre ou só muda?" Testem as que a matariam.

4. Transforme-a numa hipótese com meta de aprovação

Escreva-a como uma hipótese neste formato: Acreditamos que [quem] vai [fazer o quê] porque [motivo]. Saberemos que é verdade se [resultado mensurável] em [prazo].

Defina a meta de aprovação antes de fazer o teste e deixe-a por escrito. "Pelo menos 8 de 20 estudantes que perderam uma aula abrem o resumo em até um dia" é uma meta. "Os estudantes reagem bem" não é. Combinem também o que vão fazer se o resultado ficar abaixo ou no meio do caminho. Equipes que pulam isso sempre encontram um jeito de ler o resultado como boa notícia.

5. Escolha o teste mais barato que possa provar que você está errado

Ajuste o teste à premissa, não à ferramenta de que você gosta:

• As pessoas querem isso? Uma porta falsa (ofereça o serviço ou o botão e conte quem tenta usar, depois explique com honestidade), uma página de inscrição ou um pré-compromisso, como reservar um horário.
• Vão usar do jeito que esperamos? Um protótipo em papel ou um teste de usabilidade moderado com uma versão rústica.
• O valor se sustenta no uso real? Um teste concierge: entregue o serviço à mão para poucas pessoas, às claras, antes de automatizar qualquer coisa.
• A experiência funciona antes de a tecnologia existir? Um Teste Mágico de Oz: o usuário interage com o que parece um serviço funcionando, enquanto uma pessoa faz o trabalho nos bastidores. O termo foi cunhado por John F. Kelley na pesquisa em interação humano-computador por volta de 1980.
• Qual de duas versões funciona melhor? Um experimento A/B, quando você tiver tráfego ou usuários suficientes para comparar.

O custo se mede em dias, não em dinheiro. Um bom primeiro teste leva de um a dez dias. Se precisa de aprovação de orçamento, provavelmente vocês estão construindo, não testando. Para ideias sobre como fazer o próprio artefato do teste, veja o protótipo mais barato que você pode fazer esta semana.

6. Faça o teste com pessoas reais e observe

Teste com as pessoas para quem a ideia é, não com colegas fazendo o papel delas. Mantenha as condições o mais perto possível do real: o lugar delas, o aparelho delas, a pressão de tempo delas. Observe mais o que fazem do que o que dizem.

Registre o que vê numa matriz de captura de feedback: o que funcionou, o que não funcionou, dúvidas levantadas e ideias novas. Anote as surpresas na hora; no dia seguinte elas já se apagaram.

Se o teste envolve o público, diga claramente às pessoas o que está sendo testado e obtenha as aprovações que sua organização exige. Testar não justifica enganar ninguém.

7. Decida: continuar, mudar ou parar

Compare o resultado com a meta que vocês definiram. Depois tomem, em voz alta, uma de três decisões:

• Continuar: a premissa se sustentou. Passem para a próxima mais arriscada.
• Mudar: ela se sustentou em parte, ou para outro grupo. Ajustem a ideia e testem de novo.
• Parar: ela não se sustentou. Registrem o que aprenderam e encerrem. Parar uma ideia depois de um teste de duas semanas é um bom resultado; pará-la depois de um ano de construção, não.

Escreva uma nota curta: o que testaram, o que aconteceu, o que decidiram e por quê. Esse registro é o que permite a uma equipe aprender de uma ideia para outra, em vez de recomeçar do zero a cada vez.

Exemplo ilustrativo

Ilustrativo. Uma universidade na Austrália queria construir um app de monitoria entre pares para estudantes do primeiro ano de engenharia. O plano preliminar era um desenvolvimento de seis meses.

A equipe listou 22 premissas. No mapa de premissas, a mais arriscada não era técnica. Era esta: "Estudantes do segundo ano vão dedicar uma hora por semana à monitoria de calouros em troca de créditos acadêmicos, e não de pagamento." Se isso falhasse, o app não teria quem conectar.

A hipótese: "Se oferecermos créditos acadêmicos, pelo menos 15 estudantes do segundo ano vão se inscrever para um horário de monitoria em uma semana." Eles colocaram um formulário simples de inscrição no boletim do curso do segundo ano, conduziram tudo à mão como um teste concierge e juntaram monitores e alunos por e-mail.

Nove se inscreveram, abaixo da meta. Mas as conversas de acompanhamento foram reveladoras: vários disseram que dariam monitoria em dupla, não sozinhos, porque não tinham certeza do próprio conhecimento. A equipe mudou a ideia para monitoria em dupla, rodou o formulário de novo e obteve 21 inscrições. O app continuou sem ser construído. O próximo teste era se os calouros de fato iriam aparecer.

O que fazer e o que evitar

Faça

• Teste uma premissa de cada vez e dê nome a ela no plano de teste.
• Defina uma meta de aprovação e uma regra de decisão antes de ver os resultados.
• Prefira testes em que as pessoas agem a testes em que elas comentam.
• Mantenha o primeiro teste abaixo de duas semanas.
• Trate "parar" como um resultado útil e registre o porquê.

Evite

• Apresentar a ideia e contar elogios.
• Testar com colegas quando a ideia é para clientes ou cidadãos.
• Construir um protótipo caprichado para testar se alguém quer aquilo.
• Mudar a meta depois que os resultados chegam.
• Enganar os participantes; uma porta falsa precisa terminar com uma explicação honesta.

Perguntas frequentes

Qual é a forma mais rápida de validar uma ideia? Encontre a premissa que mataria a ideia se fosse falsa e faça um teste que peça a pessoas reais que ajam, como reservar um horário, se inscrever ou usar uma versão operada à mão. Muitos testes assim cabem numa semana.

Qual a diferença entre um teste concierge e um Teste Mágico de Oz? No teste concierge, as pessoas sabem que alguém está entregando o serviço à mão. No Teste Mágico de Oz, o serviço parece automatizado para o usuário enquanto uma pessoa trabalha nos bastidores. O concierge testa o valor; o Mágico de Oz testa a experiência de um sistema futuro.

De quantas pessoas preciso para testar uma ideia? Em testes iniciais que procuram problemas numa experiência, um punhado de participantes muitas vezes revela as principais questões. Em testes que medem demanda, defina primeiro uma meta em números e depois alcance pessoas suficientes para que esse número signifique algo.

Para onde ir agora

Comece pelo mapa de premissas e pelo guia de teste de hipótese e depois escolha entre o teste concierge e o Teste Mágico de Oz, conforme o que precisa aprender. Se ainda está escolhendo quais ideias testar, leia como priorizar ideias e, para o conjunto completo de métodos, veja qual ferramenta de inovação usar.