Como escrever o prompt de um app
Um prompt de app não é uma redação. Ele é um pedido, e um pedido bom responde a quatro perguntas antes de descrever qualquer tela.
As quatro coisas que não podem faltar
- Quem usa. Uma pessoa concreta, não "os usuários". Muda tudo saber se quem abre é o cliente, o funcionário ou o dono.
- O que ela faz ali. Um verbo por vez: pedir, agendar, registrar, aprovar, consultar.
- O que fica guardado. É o que vira lista, filtro, busca e relatório depois. É a parte que as pessoas mais esquecem e a que mais custa consertar.
- Quem enxerga o quê. Uma frase basta, e ela evita o defeito mais caro: um cliente vendo o pedido do outro.
Um modelo curto que funciona
Um app para [quem] poder [o que faz]. Cada [registro] guarda [campos]. [Quem] vê só o que é seu; [quem] vê tudo. Quando [algo acontece], o app [avisa alguém / muda o estado].
Quatro linhas cobrem mais do que uma página de desejo solto. O resto se resolve melhor olhando a tela pronta.
O que deixar de fora do primeiro pedido
- tecnologia, se você não tem um motivo específico;
- cores e fonte, a não ser que a marca já exista. Visual é a parte fácil de mudar depois;
- funcionalidade da versão 3. Relatório avançado, painel de métricas e integração entram quando a versão 1 tiver gente usando;
- login, se ainda não existe alguém para logar.
O segundo prompt é mais importante que o primeiro
O primeiro pedido gera o app. Os pedidos seguintes é que fazem ele ficar certo, e eles têm outra forma: em vez de descrever tudo, apontam um ponto.
Um pedido de correção bom tem três partes:
- onde: a tela ou o botão;
- o que acontece hoje;
- o que deveria acontecer.
"Na lista de pedidos, o filtro de data não muda nada quando escolho o mês; deveria mostrar só os pedidos daquele mês." Esse pedido muda pouca coisa. "Melhore a tela de pedidos" convida a reescrever o que já estava bom.
Quando o problema é de layout, o print vale mais que o parágrafo.
Erros que aparecem toda semana
- pedir tudo de uma vez. O app nasce grande, errado em vários lugares, e fica difícil saber qual correção quebrou o quê;
- descrever a solução em vez do problema. "Coloca um campo escondido que guarda o status" tira da IA a chance de acertar de um jeito melhor;
- trocar de assunto no meio. Um pedido, um assunto;
- não dizer a regra de permissão, e depois descobrir na frente de um cliente.
O resumo
- quem usa, o que faz, o que fica guardado, quem vê o quê;
- quatro linhas valem mais que uma página;
- deixe tecnologia e visual para depois;
- correção com onde, o que acontece e o que deveria acontecer;
- um pedido, um assunto, e print quando for layout.