Desenhando e colocando no ar um experimento

4º artigo da série Design Growth na Prática

Nos outros artigos da série eu falei dos princípios de PLG, a importância do impacto na hora de priorizar um experimento e do quanto a hipótese deve ter relação com o negócio e as metas da empresa. E tudo isso é bonito nas palavras, mas na hora de colocar em prática passa por muitas etapas, desde a decisão de como colocar o experimento no ar, como desenhar a aposta e finalmente como medir para entender o resultado final.

A decisão de como validar

Um bom portfólio de experimentos é diversificado, dando espaço tanto para pequenas otimizações quanto para inovações estratégicas para resolver os problemas dos clientes. Quando falamos de otimizações podemos dar como exemplo mudanças de copy em um CTA ou até remodelar a estrutura e interface de uma tela. Já sobre inovações estratégicas estamos falando de um projeto maior, como por exemplo pensar em um programa de recomendação e afiliados.

Todos eles são baseados em uma hipótese consistente e testável, com uma solução forte o suficiente para tentar validá-la ou invalidá-la. Estas hipóteses passam ainda por uma fase inicial para estimar o quanto pode melhorar a métrica e calcular o custo x tempo necessário para atingir a amostra, sem isso há muitas chances de resultar em experimentos inconclusivos.

Existem uma série de métodos que podemos utilizar para validar um design: feature fake, price test, blind product test, etc. Aqui na RD Station, na maioria das vezes, um experimento é validado via Teste A/B. Estes testes seguem um modelo científico através da definição de amostra, tempo estimado para ficar no ar até atingir relevância estatística e análise final.

As análises ao final dos experimentos são tanto de forma quantitativa para definir se o experimento é um Win ou Lost, assim como há um período de análises qualitativas com clientes, tudo para dar clareza e aprendizados.

Mas o que considerar para começar o desenho?

Antes do desenho é prática do time criar um “documento do experimento”, sempre liderado pela pessoa PM. Este documento eu costumo dizer que contém ouro! Ele é muito valioso pois traz o histórico por trás da hipótese, o que o mercado tem feito em relação a este problema, define claramente o quanto iremos mexer em termos de dados e qual métricas específicas vamos acompanhar (primária e secundárias).

Exemplo da documentação de um determinado experimento

O documento também é um hub de outras fontes que serviram de apoio pra chegar até aquele momento de priorização, como pesquisas com clientes, por exemplo. Além disso, é ali que começamos a centralizar as principais referências de solução que possam inspirar de alguma forma.

Se até este momento seu experimento continua ‘caindo de pé’, é hora de avançar para definição do que será seu MVT (Minimum Viable Test) para teste da hipótese. Algumas perguntas de apoio para definição são:

• Qual é a forma mais eficiente que nós podemos testar essa hipótese de um jeito válido?
• Qual é a coisa mais agressiva que podemos fazer para testar essa hipótese?

Desenhando o experimento

E pense o seguinte: sempre existirão inúmeras formas para resolver um determinado problema, por isso o ideal é pensar e desenhar múltiplas alternativa de solução. Desta forma abrimos possibilidades para descobrir qual é a solução mais eficiente para testar a hipótese do experimento de um jeito válido.

Com algumas ideias no papel fica prático explorar junto à equipe quais são as vantagens e desvantagens de cada uma delas até definir qual solução será refinada.

Algumas variações da mesma solução começando a ir para o papel

Dessa forma vamos “afunilando” nesta etapa de design, refinando aqui e ali até definir a solução que se apresenta com maior potencial de atingir a hipótese do experimento.

Solução definida e protótipo refinado!

Mas antes de colocar um projeto no ar é importante mitigar possíveis gaps da solução, para isso envolvemos todo o time para feedbacks, além de realizar validações via teste de usabilidade ou teste não moderado, depende de cada caso. O objetivo nesse momento pré-experimento é responder à pergunta: Estamos confiantes que esta solução tem chances de atingir a hipótese e o incremento que estamos estimando? É uma decisão de time, não apenas de PM ou Designer. Se todos estão de acordo vamos em frente, se há concerns, paramos e revisamos.

Dificilmente precisamos entrar no conceito disagree and commit, mas considero isso algo particular de cada time, principalmente devido ao perfil das pessoas e o formato de trabalho de cada empresa.

Teste não moderado realizado com uma solução pré-experimento.

Instrumentação e Implementação

Com a solução definida é o momento de entender cada interação para medir o experimento com precisão. É neste momento que definimos como será implementado o experimento, tanto sobre o viés de tipo de experimento que será realizado (idealmente Teste A/B), quanto qual tecnologia irá utilizar para colocá-lo no ar.

Além disso, também definimos como iremos instrumentar o experimento para garantir que ele terá condições de ser analisado e coletar todos os aprendizados necessários.

No documento do experimento também é detalhado o que deve ser instrumentado

Sempre procuramos responder algumas questões para ajudar a definir como instrumentar seu experimento:

• Onde o Teste A/B se iniciará (mediante a visualização da página, clique)?
• Qual a segmentação que irá participar do experimento? (Ex: apenas brasileiros, clientes, trial, etc)?
• É necessária a exclusão de algum grupo da segmentação? Qual? (Ex: origem de tráfego, idioma, não pagantes, etc)
• Como vou identificar os participantes do grupo controle e variante?
• Quais ações realizadas na solução eu preciso acompanhar? (cliques, vídeo assistido, páginas acessadas, etc)
• Quais ferramentas vou utilizar para fazer essa análise? (quantitativa e qualitativa)

Com todas estas informações é hora de fazer os últimos alinhamentos com o time de engenharia para começar a implementar. Costumo fazer um vídeo de handoff, ali deixo registradas todas as informações de como chegamos até ali, facilitando a comunicação assíncrona e deixando documentado para qualquer pessoa desenvolvedora que for pegar o projeto saber os detalhes da solução.

Logo tem mais…

A partir daqui é hora da engenharia implementar, colocar em produção e começarmos a medir o experimento. Mas daí é assunto para o próximo artigo, onde irei fechar a série com um estudo de caso, mostrando este framework na prática com um experimento do início ao fim, com a decisão de Win ou Lost, as análises qualitativas e quantitativas até a conclusão e os aprendizados.

A hora da verdade: Analisar os dados do experimento!

E espero que estes artigos estejam sendo úteis de alguma forma, especialmente para designers em processo de transição para trabalhar com growth. Entendam que este não é o melhor e nem o processo padrão, este é apenas o modelo que usamos aqui na RD Station. Compartilhem o que estão achando e eu adoraria saber como está sendo feito por aí. Até o próximo artigo! 👋