Como escrever um prompt de UI para um agente de programação com IA
Transforme uma ideia de produto vaga em um prompt de UI pronto para construir, com objetivo do usuário, comportamento, estados, restrições e verificações de aprovação ou reprovação.
Um bom prompt de UI diz ao agente quem precisa de qual resultado, como a interface deve se comportar, quais estados ela precisa cobrir, quais restrições do projeto valem e como verificar o resultado. Dê o nome de um componente só quando o comportamento dele servir para o trabalho.
1. Comece pelo objetivo do usuário, não pelo nome do componente
Diga quem está tentando terminar qual tarefa e por que isso importa. Use um termo de UI só depois que o comportamento dele combinar com esse trabalho. O nome de um componente é uma solução possível, não o objetivo do produto.
- Fraco: Adicione um belo dashboard em glassmorphism.
- Melhor: Ajude um líder de suporte a encontrar tickets não resolvidos, entender a urgência e abrir o próximo ticket sem perder os filtros atuais.
2. Descreva o comportamento, os estados e os limites
Explique o que abre a interface, o que muda depois de cada ação, como ela fecha e o que precisa continuar salvo. Inclua estados de carregando, vazio, erro, sucesso, tentar de novo, cancelar e permissão sempre que eles puderem acontecer.
3. Escolha um padrão pelo comportamento e só depois adicione estilo e movimento
Use o atlas quando você consegue imaginar a interface mas não sabe o nome dela. Compare padrões parecidos antes de escolher. Mantenha comportamento, estilo visual e movimento como decisões separadas, para que um pedido estético não mude escondido como o produto funciona.
4. Adicione critérios de aceite que o agente consiga verificar
Transforme regras importantes em verificações observáveis de aprovação ou reprovação. Cubra uso de teclado, foco visível, avisos de status, telas pequenas, zoom, movimento reduzido, carregamento, falha, tentar de novo e persistência de dados onde fizer sentido.
5. Dê o contexto do projeto antes de pedir código
Diga qual é a stack atual, o design system, os componentes reutilizáveis, a fonte de dados, a rota e os arquivos que estão no escopo. Diga ao agente o que não pode mudar. Mesmo assim, ele deve inspecionar o projeto real e os testes antes de editar.
6. Use uma estrutura de prompt que deixe as decisões visíveis
Uma boa ordem é: resultado, usuários e situação, comportamento, estados, conteúdo e dados, direção visual, acessibilidade, restrições do projeto, critérios de aceite e o que está fora do escopo. Marque suposições e perguntas em aberto em vez de escondê-las.
- Resultado: quem deve conseguir fazer o quê quando esse trabalho terminar?
- Comportamento e estados: como o fluxo começa, muda, termina, falha e se recupera?
- Verificações: qual evidência exata vai mostrar que o resultado funciona?