Comment écrire le prompt d'une application
Le prompt d'une application n'est pas une rédaction. C'est une demande, et une bonne demande répond à quatre questions avant de décrire le moindre écran.
Les quatre choses qui ne peuvent pas manquer
- Qui l'utilise. Une personne concrète, pas "les utilisateurs". Tout change selon que celui qui ouvre est le client, l'employé ou le patron.
- Ce qu'elle y fait. Un verbe à la fois : commander, réserver, enregistrer, approuver, consulter.
- Ce qui est stocké. C'est ce qui devient ensuite la liste, le filtre, la recherche et le rapport. C'est la partie la plus oubliée et la plus coûteuse à réparer.
- Qui voit quoi. Une phrase suffit, et elle évite le défaut le plus cher : un client qui voit la commande d'un autre.
Un modèle court qui marche
Une application pour que [qui] puisse [ce qu'il fait]. Chaque [enregistrement] stocke [champs]. [Qui] ne voit que le sien ; [qui] voit tout. Quand [quelque chose arrive], l'application [prévient quelqu'un / change l'état].
Quatre lignes couvrent plus qu'une page de souhaits épars. Le reste se règle mieux devant l'écran terminé.
Ce qu'il faut laisser hors de la première demande
- la technologie, sauf raison précise ;
- couleurs et typographie, sauf si la marque existe déjà. Le visuel est la partie facile à changer ensuite ;
- les fonctions de la version 3. Rapports avancés, tableau de métriques et intégrations viennent quand la version 1 a des utilisateurs ;
- le login, s'il n'y a encore personne à connecter.
Le deuxième prompt compte plus que le premier
La première demande génère l'application. Les suivantes sont celles qui la rendent juste, et elles ont une autre forme : au lieu de tout décrire, elles pointent un endroit.
Une bonne demande de correction a trois parties :
- où : l'écran ou le bouton ;
- ce qui se passe aujourd'hui ;
- ce qui devrait se passer.
"Sur la liste des commandes, le filtre de date ne change rien quand je choisis un mois ; il devrait montrer seulement les commandes de ce mois." Cette demande change très peu. "Améliore l'écran des commandes" invite à réécrire ce qui allait déjà bien.
Quand le problème est la mise en page, la capture vaut mieux que le paragraphe.
Les erreurs qui reviennent chaque semaine
- tout demander d'un coup. L'application naît grande, fausse à plusieurs endroits, et il devient difficile de savoir quelle correction a cassé quoi ;
- décrire la solution au lieu du problème. "Ajoute un champ caché qui garde le statut" retire à l'IA la chance de faire mieux ;
- changer de sujet en cours de route. Une demande, un sujet ;
- ne pas énoncer la règle de permission, et le découvrir devant un client.
Le résumé
- qui l'utilise, ce qu'il fait, ce qui est stocké, qui voit quoi ;
- quatre lignes valent mieux qu'une page ;
- laissez technologie et visuel pour plus tard ;
- une correction porte où, ce qui se passe et ce qui devrait se passer ;
- une demande, un sujet, et une capture quand c'est la mise en page.
Une demande prête pour créer la vôtre
Crée une app pour un éducateur canin. Les maîtres enregistrent leur chien avec race, âge et le comportement qu'ils veulent corriger ; des forfaits de 4 ou 8 séances payés par carte ou par un moyen de paiement local ; le maître réserve chaque séance sur un créneau libre, à domicile ou au parc, avec un rappel par e-mail ; après chaque séance, je note ce qui a été travaillé et les exercices à faire à la maison, que le maître voit dans l'app ; le solde de séances du forfait ; et un tableau de bord rien que pour moi avec l'agenda de la semaine, les forfaits qui arrivent à expiration et le chiffre d'affaires.
Gratuit pour commencer. La première version arrive en quelques minutes et vous l’ajustez en discutant.