“Deixar o botão principal mais evidente” é uma direção de design, mas ainda não explica o que deve melhorar. Mais cliques podem indicar que mais pessoas encontraram o próximo passo. Também podem significar que a interface incentivou uma ação que elas não pretendiam realizar. Um experimento útil liga uma alteração específica a um resultado relevante.
Imagine uma ferramenta de projetos que pede a criação de um espaço de trabalho antes de salvar uma referência. A equipe quer encurtar essa etapa. Antes de escolher um layout, descreva o obstáculo: pessoas que já escolheram uma referência precisam entender um conceito desconhecido antes de guardá-la. Essa descrição dá ao design um problema concreto para resolver.
Nomeie o comportamento que deve mudar
Escreva a hipótese com clareza: “Se as pessoas puderem salvar a primeira referência antes de nomear um espaço de trabalho, mais delas concluirão esse salvamento na primeira visita.” Identifique o público inicial, a alteração proposta e a ação concluída. Mantenha o resultado próximo o suficiente da mudança para examinar a relação entre eles.
Escolha também um indicador de proteção. Nesse exemplo, salvar mais rápido seria menos útil se as pessoas não conseguissem encontrar a referência depois. Uma tarefa de retorno, um tema recorrente no suporte ou um evento posterior pode revelar essa troca. Decida o que tornaria o resultado inaceitável antes de olhar os dados.
Mantenha a experiência estável
A variação de design e sua feature flag devem representar a mesma mudança. Alguém atribuído ao novo caminho não deve alternar entre a experiência antiga e a nova a cada atualização da página. Documente o que controle e variante realmente exibem, incluindo carregamento, erros e contas que não participam do experimento.
Sempre que possível, deixe alterações sem relação fora da mesma comparação. Se o novo fluxo também muda preços, horários de email e tom do texto, fica mais difícil explicar uma diferença nos resultados. Quando a mudança combinada for intencional, registre esse escopo em vez de atribuir o resultado a um único botão.
Faça o evento corresponder à promessa
Um clique comprova que um botão foi clicado. Não comprova que a referência foi salva. Registre a ação concluída no ponto em que a aplicação a confirmou e diferencie esse evento de tentativas e falhas. Design, engenharia e análise precisam compartilhar a mesma definição de evento.
Antes de iniciar a comparação, percorra os dois caminhos com contas de teste. Confira se a atribuição permanece estável, se os eventos chegam e se cada conclusão é contada uma vez. Uma medição quebrada pode fazer um bom design parecer malsucedido ou uma ação que falhou parecer bem-sucedida.
Leia o resultado junto com seus limites
Evite tratar uma vantagem inicial como decisão suficiente. Registre a quantidade de evidência, a incerteza e as mudanças nos indicadores de proteção. Investigue comportamentos inesperados com feedback qualitativo, em vez de inventar uma explicação apenas a partir de um gráfico.
Use referências no Refcat para explorar formas alternativas de remover o obstáculo e depois documente por que a variação escolhida combina com seu produto. Um experimento é mais útil quando deixa uma explicação reutilizável: o que mudou, quem viveu a mudança, o que foi medido e o que a equipe aprendeu sobre o problema original.