5 ideias para testar ideias
Experimentações rápidas são a melhor forma de coletarmos aprendizados que nos permitam entender quão viável uma ideia é. A testagem de forma rápida, direta, objetiva, ajuda a, com baixo custo, identificar o que realmente faz a diferença. É um ótimo subsídio para avançar com o desenvolvimento de uma funcionalidade sem tantas incertezas, que tanto prejudicam a performance dos times e afetam a produtividade.
Precisamos mudar o jogo do atual panorama de desperdício no desenvolvimento de produtos digitais: 7 em cada 10 funcionalidades construídas são absolutamente inúteis. Isto é tempo, grana e energia dos desenvolvedores (talvez o elemento mais raro hoje em dia), jogados no lixo.
Há várias formas de testar ideias, algumas mais robustas, outras mais empíricas. Vamos explorar algumas que eu já usei, com prós, contras de quem já apanhou no mundo lá fora:
1. UM DIA NA VIDA
Etapa: Exploração
Tema: Desejabilidade
Custo: * *
Tempo de Setup: * *
Tempo de Execução: * * *
Força da Evidência : * * *
Como fazer: O trabalho começa com a definição de personas que carregue alguns dados observáveis. Como essa pessoa se veste? Quais são seus trejeitos? Onde ela consome determinados produtos? Após, identificamos onde essas personas se materializam em pessoas reais, e vamos ao encontro dessas pessoas. O objetivo é observar como a pessoa efetivamente se comporta para realizar o processo que buscamos romper / digitalizar.
Aprendizados práticos: São dois os aprendizados que eu já tive ao fazer observações do tipo “um dia na vida’. O primeiro: muitas vezes estamos inventando algo que não existe. Queremos provocar um novo jeito de comprar um determinado item, que ainda não pode ser praticado pelo usuário. O que fazer? Analogias. Vamos observar como o usuário age em processos semelhantes, ou quão frustrado ele fica por ainda não ter acesso ao que queremos inventar. O segundo aprendizado está no consentimento. Se a observação é em um lugar público, a pessoa observada pode nem saber que está sendo objeto de uma investigação. Se for em um espaço privado (dependências de uma empresa, por exemplo), é necessário o consentimento prévio. Esta busca por consentimento pode gerar artificialidades, portanto deve ser feita de forma sutil.
2. FÓRUNS DE DISCUSSÃO
Etapa: Análise de Dados
Tema: Viabilidade
Custo: *
Tempo de Setup: * *
Tempo de Execução: * * *
Força da Evidência : * *
Como fazer: com base em pesquisas pregressas, se estabelece um questionário base e se define usuários com diferentes níveis de envolvimento no processo. Geralmente se cruzam duas variáveis: especialidade e maturidade digital, mas essas variáveis podem ser discutidas projeto a projeto. O setup do fórum deve considerar três elementos com muita clareza:
- Quem são os participantes, numa rodada de apresentação que gere algum tipo de confiança.
- Qual é o objetivo do fórum.
- Qual será o uso dos insights gerados com o fórum.
O fórum deve ter um facilitador e um redator, que consiga registrar insights quando eles acontecem. O consentimento de todos é importante, principalmente se o fórum será gravado.
Aprendizados práticos: o maior cuidado é com o pêndulo entre eficiência e eficácia. Muitas vezes a discussão vai derrapar para outros temas, que são muito significativos e relevantes para o produto, mas que não são o foco do fórum. Cabe ao facilitador decidir se quer investir esse tempo nessa exploração, mas essa decisão deve ser consciente, não algo que vá acontecendo sem querer.
3. TESTE 404
Etapa: Descoberta de Interesse
Tema: Desejabilidade
Custo: *
Tempo de Setup: *
Tempo de Execução: * * *
Força da Evidência : * * *
Como fazer: esta ideia se divide em duas — a primeira é quando tivermos uma funcionalidade já no ar, mesmo que em caráter experimental, um bom experimento é tirá-la abruptamente, colocando no lugar um link para reclamações. Conta-se quantos clicks tivemos para abrir a solução e quantas reclamações, e com que intensidade elas são feitas. A segunda é antes de termos a funcionalidade: deixamos o link sem nada codado linkado. Conseguimos dessa forma medir rapidamente a desejabilidade da funcionalidade.
Aprendizados práticos: em processos de desenvolvimento com maior interação com as áreas de negócio, a estratégia pode gerar uma “quebra de confiança”, uma vez que os usuários não podem saber que o teste ocorrerá. Caso haja pouca aderência a erro ou a plataforma lide com processos muito críticos, a estratégia pode gerar mais insatisfação do que ajudar na definição de prioridade para a funcionalidade.
4. FINJA SER DONO
Etapa: Protótipos de Discussão
Tema: Desejabilidade
Custo: *
Tempo de Setup: * *
Tempo de Execução: * * * *
Força da Evidência : * *
Como fazer: quando os primeiros palm (sdds) estavam sendo desenhados, o fundador Jeff Hawkins andava com um bloco de madeira no bolso do paletó e sempre que precisava tomar nota de alguma coisa, tirava o bloco de madeira e fingia digitar alguma coisa com uma caneta stylus (sdds) imaginária. O nome da ideia se refere a uma prática comum com crianças nos Estados Unidos, onde uma caixa de papelão faz as vezes de bichinho de estimação, com coleira e tudo, e a criança finge ser o dono daquele bichinho. Se a criança conseguir passear com o “cãozinho”, dar atenção, dar “comida”, etc, os pais a premiam com a adoção de um cãozinho real.
Aprendizados práticos: a prática é extremamente rica, mas é de baixa aplicabilidade, uma vez que o designer ou o líder de produto muitas vezes não é um usuário direto do produto que está construindo. Dessa forma, a simulação do uso daquela funcionalidade ou produto não é muito comum. O que é necessário, nesse momento, é contar com a boa vontade dos usuários e metrificar os resultados, que muitas vezes são subjetivos.
5. SPEED BOAT
Etapa: Descoberta de Preferência e Priorização
Tema: Desejabilidade e Viabilidade
Custo: * *
Tempo de Setup: * *
Tempo de Execução: *
Força da Evidência : * * *
Como fazer: O speedboat é uma forma de representar visualmente o que está impedindo o barco do produto acelerar. Em uma pesquisa com um grupo razoável de usuários (cerca de 15 a 20 usuários), se estuda quais são as âncoras do barco, e quais estão mais pesadas. Um facilitador conduz a discussão, ouvindo de todos as contribuições e ponderando os pesos das âncoras.
Aprendizado prático: O maior cuidado aqui é com a “paralisia por análise”. Deve-se discutir com a profundidade necessária para que se possa entender que uma âncora é válida, mas investir muito tempo na exata posição de qual âncora é mais pesada é contraproducente. Isso deve ser avisado sempre que necessário ao grupo, principalmente no começo da análise.
Para fechar:
Se você quer mais ideias sobre como testar ideias, recomendo dois caminhos. Primeiro é me mandar um email ou comentar algo aqui no post. Abaixo seguem meus contatos e vou adorar conversar com você sobre como seus testes estão sendo feitos. Segundo é dar uma olhada nesse livro aqui, que eu acho demais, apesar de ser um pouco superficial. Ele joga algumas iscas. Quem deve puxar o anzol é você.
Sobre o autor:
Daniel Fernandes é designer e líder da Unidade de Negócios de Times Ágeis para Produtos Digitais. Busca encontrar a coerência entre o que está sendo desenvolvido e a real necessidade dos usuários, e defendê-la arduamente. Joga RPG, gosta de mobilização social, trabalha com facilitação de grupos e acredita que há muito valor naquelas coisas que não fazemos.
Sobre a Unidade de Negócios Times Ágeis para Produtos Digitais:
Provemos toda consultoria e capacidade de desenvolvimento para resolver problemas reais de negócios e necessidades reais dos usuários, alinhando design, métodos ágeis e as melhores práticas de engenharia. Acreditamos que o valor consiste em fazer a coisa certa, do jeito certo.
