Comment écrire un prompt d'UI pour un agent de codage IA
Transformez une idée de produit imprécise en un prompt d'UI réalisable qui précise l'objectif utilisateur, le comportement, les états, les contraintes et les critères de validation.
Un bon prompt d'UI dit à l'agent qui a besoin de quel résultat, comment l'interface doit se comporter, quels états elle doit gérer, quelles contraintes du projet s'appliquent et comment vérifier le résultat. Nomme un composant seulement quand son comportement convient au travail.
1. Commence par l'objectif de l'utilisateur, pas par un nom de composant
Dis qui essaie de terminer quelle tâche et pourquoi c'est important. Ajoute un terme d'UI seulement après que son comportement correspond à ce travail. Le nom d'un composant est une solution possible, pas l'objectif du produit.
- Faible : ajoute un superbe tableau de bord en glassmorphism.
- Mieux : aider un responsable du support à repérer les tickets non résolus, comprendre l'urgence et ouvrir le ticket suivant sans perdre les filtres actuels.
2. Décris le comportement, les états et les limites
Explique ce qui ouvre l'interface, ce qui change après chaque action, comment elle se ferme et ce qui doit rester enregistré. Inclus les états de chargement, vide, erreur, succès, nouvelle tentative, annulation et permission quand ils peuvent se produire.
3. Choisis un modèle selon son comportement, puis ajoute le style et l'animation
Utilise l'atlas quand tu peux imaginer l'interface mais que tu ne connais pas son nom. Compare les modèles proches avant de choisir. Garde le comportement, le style visuel et l'animation comme des décisions séparées, pour qu'une demande d'esthétique ne change pas discrètement le fonctionnement du produit.
4. Ajoute des critères d'acceptation que l'agent peut vérifier
Change les règles importantes en vérifications observables, réussi ou échoué. Couvre l'utilisation du clavier, le focus visible, les annonces de statut, les petits écrans, le zoom, le mouvement réduit, le chargement, l'échec, la nouvelle tentative et la sauvegarde des données quand c'est pertinent.
5. Donne le contexte du projet avant de demander du code
Nomme la stack existante, le design system, les composants réutilisables, la source de données, la route et les fichiers concernés. Dis à l'agent ce qui ne doit pas changer. Il doit quand même inspecter le vrai projet et ses tests avant de modifier.
6. Utilise une structure de prompt qui garde les décisions visibles
Un ordre utile : résultat, utilisateurs et situation, comportement, états, contenu et données, direction visuelle, accessibilité, contraintes du projet, critères d'acceptation, et travail hors périmètre. Marque les hypothèses et les questions ouvertes au lieu de les cacher.
- Résultat : qui doit pouvoir faire quoi quand ce travail est terminé ?
- Comportement et états : comment le parcours commence, change, se termine, échoue et repart ?
- Vérifications : quelles preuves exactes montreront que le résultat fonctionne ?