Resposta rápida: priorizar testes é decidir a ordem do backlog por critério explícito, e não por opinião do cargo mais alto na sala. Os frameworks mais usados são PIE (Potencial, Importância, Facilidade), ICE (Impacto, Confiança, Esforço) e PXL (checklist ponderado). Qualquer um deles funciona melhor do que nenhum — o valor está em tornar o critério visível e discutível.
O problema real: fila infinita, tráfego finito
Um programa de experimentação saudável gera hipóteses mais rápido do que consegue testá-las. Cada página tem tráfego limitado, e cada teste ocupa esse tráfego por semanas. Priorizar mal significa gastar o recurso mais escasso — visitantes — em perguntas que valem pouco. O framework não é burocracia: é a defesa do tráfego contra o "teste do chefe".
PIE: o mais simples de adotar
Nota de 1 a 10 em três eixos, e a média ordena o backlog:
- Potencial: quanto essa página/fluxo pode melhorar? Páginas visivelmente problemáticas pontuam alto.
- Importância: quanto tráfego (e quão valioso) passa por ali? Um checkout vale mais que uma página institucional.
- Ease (facilidade): quão fácil é montar o teste? Texto e layout são fáceis; mudanças que dependem de integração, difíceis.
Fraqueza honesta: "Potencial" é subjetivo. Duas pessoas dão notas diferentes para a mesma página. Funciona melhor quando as notas são discutidas em grupo, com o dado na mesa.
ICE: o mesmo espírito, com confiança explícita
Troca "Importância" por Confiança: quão forte é a evidência por trás da hipótese? Uma hipótese nascida de pesquisa + heatmap + queda no funil pontua alto; uma ideia de reunião pontua baixo. Essa mudança premia exatamente o comportamento certo — hipóteses ancoradas em dados — e pune o achismo na fila.
PXL: para quem quer menos subjetividade
Em vez de notas de 1 a 10, um checklist de perguntas objetivas com pesos: a mudança é visível acima da dobra? afeta o fluxo de todos os visitantes? nasce de dado quantitativo? de dado qualitativo? é fácil de implementar? Cada "sim" soma pontos definidos. Custa mais para preencher e devolve consistência — útil quando várias pessoas alimentam o mesmo backlog.
Na prática: o que os frameworks não dizem
- Tráfego é critério de corte, não de nota. Se a página não fecha amostra em ~6 semanas, a hipótese vai para a geladeira por melhor que seja — cheque antes com a calculadora de amostra.
- Alterne exploração e refinamento. Só testes ousados = alta variância; só micro-otimizações = aprendizado lento. Um mix saudável mantém o programa vivo.
- Agrupe por página. Dois testes na mesma página se atrapalham; sequencie-os e aproveite o aprendizado do primeiro no segundo.
- Reavalie o backlog por rodada. Cada resultado muda a nota de confiança das hipóteses vizinhas.
Um fluxo de priorização que cabe numa tarde
1. Liste todas as hipóteses num quadro único. 2. Pontue com ICE em grupo — dado na tela, não de memória. 3. Corte as inviáveis por tráfego. 4. Sequencie evitando colisão de páginas. 5. Congele o topo da fila por um ciclo: repriorizar toda semana é outra forma de não decidir. O resultado é um roadmap de testes que qualquer pessoa da empresa entende e pode questionar — com critérios, não com hierarquia.
Perguntas frequentes
Qual framework escolher? Comece com ICE — o eixo de confiança educa o time. Migre para PXL se a subjetividade virar problema entre avaliadores.
Como lidar com o "teste do CEO"? Coloque-o no framework como qualquer hipótese. Com critério explícito, a conversa muda de "porque eu quero" para "essa hipótese tem evidência?". Às vezes o CEO tem razão — e agora há um registro do porquê.
Ideias pequenas valem a fila? Se a implementação é trivial e o risco é nulo, considere implementar direto sem teste e monitorar. Tráfego de teste é caro demais para tons de cinza.
Backlog priorizado é metade do caminho; a outra metade é rodar com disciplina: como montar um programa de experimentação.