// artigos · product-discipline
Briefing do cliente é sintoma, não diagnóstico.
Arrive Inn pedia 'mais filtros'. O problema era opções demais, não de menos. Como descobri que briefing é tradução, não design.
O Arrive Inn pedia "mais filtros". A conversão era baixa, o catálogo era amplo, e a feature da vez era um sistema de filtragem refinado. Lógica comercial clássica.
Se eu tivesse dado esse briefing pra uma IA, ela teria construído os filtros. Perfeitamente. Com autocomplete, range sliders, badges de categoria. Tudo bonito, tudo funcionando. E tudo inútil: porque o problema não era falta de filtros.
O abandono acontecia entre listagem e detalhe. Os usuários desistiam porque viam opções demais, não opções de menos. Mais filtros piorariam o problema.
O defeito estrutural do briefing
Todo briefing é uma tradução: alguém sentiu um problema, conversou com alguém, aquele alguém escreveu algumas frases. Pelo caminho, o problema virou solução. "Usuários não conseguem achar o que querem" virou "construa mais filtros".
IA adora briefing. É o tipo de input que ela sabe executar literalmente: descreva a feature, ela constrói a feature. Zero questionamento. E zero questionamento é exatamente onde o projeto morre.
A IA não distingue "resolva isso" de "faça isso". Se o prompt diz "construa filtros", ela constrói filtros. Não pergunta se filtros são a resposta.
O filtro que eu codifiquei
Isso é o princípio 2 do Taste Loop: "desenha pra jornada, não pra feature". E virou uma regra operacional no dev757: antes de dar qualquer prompt pra IA, eu faço duas perguntas:
-
Que jornada essa feature habita? "Mais filtros" habita "escolher onde ficar". Não é a mesma coisa. A jornada tem listagem, detalhe, comparação, dúvida, medo, alívio, reserva. Cada parada tem suas próprias métricas.
-
Que sinal eu esperaria ver se o briefing estivesse certo? "Mais filtros" só faz sentido se o abandono acontecer na tela de filtros. Se for em outro lugar, a hipótese não se sustenta.
No Arrive Inn, eu testei isso antes de tocar em código. A decisão real foi trocar filtragem por curadoria: três perguntas de intent na entrada, três opções pré-selecionadas na saída. 21× mais rápido. O briefing literal não gerava isso: o briefing era uma amostra da dor, não uma receita.
Como isso muda o prompt
Quando eu orquestro IA, o prompt não começa com "construa X". Começa com o contexto da jornada. Em vez de "construa um sistema de filtros", o prompt fica mais ou menos assim: "o usuário está tentando escolher entre muitas opções e está abandonando na listagem. O sinal de sucesso é reduzir tempo de listagem pra booking. Sugira abordagens."
A IA agora propõe em vez de transcrever. E o Prescription Filter (as 7 perguntas do Taste Loop) decide se a proposta vale a pena.
Como isso se conecta ao Taste Loop
O princípio 2 é o filtro que entra antes do Prescription Filter. Se eu não sei que jornada a feature habita, nem vale a pena rodar as 7 perguntas: a pergunta certa ainda não foi feita.
No dev757, isso tá codificado como anti-pattern: "Transcrever spec em código em vez de desenhar a jornada. Viola princípio 2." Qualquer agente que leia o arquivo sabe que "implementar o briefing" nunca é o primeiro passo.