Protótipo antes da user story: como uso IA para antecipar decisões

Todo PO já viveu esta cena: o escopo foi aprovado, as telas foram aprovadas, as histórias estão bem escritas, e na homologação o cliente clica pela primeira vez no site e diz "ah, mas eu imaginava que funcionasse diferente".

Não é má vontade. É que ninguém consegue avaliar de verdade um produto que só existe no papel. Uma tela estática mostra como algo parece, não como funciona. E a diferença entre as duas coisas costuma aparecer quando o desenvolvimento já começou, que é o momento mais caro para mudar.

O que mudou no meu processo

Nos portais de notícias que conduzo na NVGO, deixei de começar pela especificação. Começo por um protótipo funcional em Next.js, construído com apoio de IA, que o cliente navega como se fosse o site final.

A conversa muda de "imagine que aqui vai ficar..." para "clique aqui e me diga o que achou". E as perguntas que realmente importam aparecem cedo:

• Quantas notícias cabem na home sem que as seções pareçam vazias?
• Onde entram os espaços de anúncio sem atrapalhar a leitura?
• Como fica tudo isso no celular, que é o acesso da maioria dos leitores?
• Esse widget de clima ajuda o leitor ou só ocupa espaço?

Essas decisões são de produto, não de código. Mas só aparecem quando existe algo para clicar.

O fluxo, passo a passo

1. Alinhamento com o cliente. Antes de qualquer tela, as mesmas perguntas: estilo do portal, volume de produção da redação, público, modelo de anúncios e uso no celular.
2. Primeira versão com IA. Uso a IA para gerar e iterar o front-end rapidamente a partir do que foi alinhado. Ela acelera a parte mecânica; as decisões de layout, hierarquia e conteúdo continuam sendo minhas.
3. Validação navegando. O cliente usa o protótipo e eu anoto o que muda. Cada rodada é uma conversa sobre algo concreto, não uma interpretação de documento.
4. Escopo fechado vira backlog. Só aí escrevo as histórias e os critérios de aceite, descrevendo um comportamento que o cliente já viu e aprovou.
5. Passagem para o time. Os desenvolvedores recebem a base, integram com o CMS e revisam o código antes de ir para produção.

Onde a IA ajuda, e onde atrapalha

A IA reduziu muito o tempo entre "tive uma ideia" e "o cliente está clicando nela". Hoje consigo construir sozinho a primeira versão completa de um portal. Mas há riscos, e eles precisam ser gerenciados:

• O protótipo parece pronto. Se o cliente acha que o site está quase no ar, a expectativa de prazo fica distorcida. Deixo claro desde o início que aquilo é uma ferramenta de validação.
• Código de protótipo não é código de produção. O que a IA gera precisa ser revisado pelos desenvolvedores. Por isso a revisão é uma etapa formal, e não um favor.
• O PO pode virar gargalo. Se só eu consigo mexer no protótipo, toda mudança passa por mim. Por isso a passagem para o time acontece assim que o escopo fecha.
• É fácil confundir velocidade com decisão. Gerar dez versões de uma tela é barato; escolher a certa continua exigindo critério. A IA amplia as opções, não as escolhe.

O que ganhei com isso

• Menos retrabalho no desenvolvimento, porque as mudanças de entendimento acontecem antes do código de produção.
• Decisões técnicas mais cedo: limites do CMS, integrações e performance aparecem já no protótipo.
• Conversas melhores com o cliente, porque discutimos algo real e não uma abstração.
• Histórias mais claras para o time, com uma referência navegável do comportamento esperado.

Como começar amanhã

1. Escolha uma funcionalidade em que o cliente costuma mudar de ideia na homologação.
2. Gere uma versão navegável dela com IA, mesmo que simples, antes de escrever as histórias.
3. Valide com o cliente clicando, e anote cada mudança de entendimento.
4. Só então escreva as histórias e combine com os desenvolvedores como o código do protótipo será revisado.

Se a lista de mudanças anotadas no passo 3 for grande, você acabou de economizar esse retrabalho no desenvolvimento.