La conception de produits sans Figma fonctionne lorsqu'un produit dispose déjà d'un système de conception mature. Mon flux de travail de conception de produits IA utilise trois compétences d'agent : ui-design explore neuf directions, ui-implement transforme la direction sélectionnée en produit et ui-walkthrough examine chaque état via le Agent Browser intégré. C'est toujours moi qui prends les décisions ; l'agent s'occupe de la production et du contrôle répétitifs.
La plupart des fonctionnalités des produits ne partent pas d’une page blanche. Une fois qu'un produit existe depuis un certain temps, ses décisions de conception de base existent déjà dans le code. Les boutons, les entrées, les cartes, la navigation, l'espacement, les couleurs, la copie, les états de survol et le comportement mobile ont tous été définis. Reconstruire ces éléments dans Figma signifie souvent faire glisser les mêmes composants sur un autre canevas avant de les reconstruire à nouveau dans le produit.
Le concepteur prend toujours les décisions relatives au produit. L'agent supprime une grande partie des assemblages et des vérifications répétitifs. Cela fonctionne car Zero dispose déjà d'un système de conception raisonnablement mature.
1. Commencez la conception du produit sans Figma avec un système de conception
Travailler sans Figma ne signifie pas travailler sans règles de conception. Cela nécessite des règles plus claires.
Pour Zero, l’agent peut inspecter :
- Composants existants pour les boutons, les entrées, les listes déroulantes, les cartes, les boîtes de dialogue et la navigation
- Espacement, typographie, couleurs, bordures et rayons de coin établis
- États de survol, sélectionnés, désactivés, vides et mobiles existants
- Copier les conventions telles que la casse des phrases et les étiquettes courtes destinées à l'utilisateur
- De vrais écrans qui montrent comment ces pièces sont combinées
Ces références répondent à des questions de conception ordinaires. Une nouvelle entrée devrait ressembler aux entrées déjà livrées. Une nouvelle carte doit utiliser la même surface et le même rayon que la carte existante la plus proche. Un bouton icône doit avoir le même retour de survol que les autres boutons icône.
Cela donne à l'agent une limite. Il peut explorer la structure d’une fonctionnalité sans inventer un nouveau langage visuel pour chaque écran.
Figma est toujours utile lorsqu'une équipe crée une nouvelle marque, un nouveau système de composants ou une interaction sans référence de produit proche. Mais une fois le système mature, le produit en cours d’exécution peut devenir la principale surface de conception. Il s'agit de la version à grande échelle des fonctionnalités du workflow de conception en tant que code que nous avons utilisé pour reconstruire Zero.
2. Utilisez ui-design pour explorer neuf directions de conception de produits
Chaque fonctionnalité doit encore être explorée. Je ne veux pas qu’un agent prenne ma première phrase et la transforme immédiatement en code.
Je commence par ui-design. Je donne à l'agent l'écran actuel, la problématique utilisateur, l'objectif et les principales contraintes. L'agent lit les modèles de produits existants et renvoie une direction recommandée ainsi que neuf alternatives.
En langage clair, la compétence capture l'écran actuel, crée une direction recommandée, explore neuf alternatives distinctes, présente les compromis et attend un choix humain.
La réflexion conceptuelle à l'intérieur de cette instruction
Cette instruction n'est pas seulement une liste de règles visuelles. Il transforme le processus normal d'un concepteur en une séquence reproductible :
- Comprenez avant de proposer. Capturez l'écran actuel et lisez le produit environnant avant de faire quoi que ce soit.
- Pensez en systèmes. Traitez les composants existants, les pages de modèles, les modèles d'interaction et les règles de copie comme matériel de départ.
- Empêcher la réinvention. L'IA a tendance à créer un nouveau modèle lorsque l'invite est vague. L'instruction lui indique de trouver le composant ou la page expédié le plus proche et de le réutiliser au lieu de faire une approximation à partir de la mémoire.
- Explorez avant de choisir. L'ancre Après donne une direction plausible. Les neuf variantes ouvrent différentes décisions concernant la disposition, la hiérarchie, la densité, le point d'entrée et la divulgation.
- Séparez l'exploration de l'engagement. L'agent s'arrête après avoir présenté les options. Un humain compare les compromis et choisit avant le début du code.
- Examinez l'ensemble de l'expérience. La copie, les commentaires de survol, les états, le comportement mobile et la cohérence visuelle font partie de la conception et non du nettoyage après la mise en œuvre.
C'est la réflexion systémique que j'attends de cette compétence : comprendre le produit existant, l'explorer, puis faire un choix explicite.
Voici l’instruction originale complète, reproduite textuellement à partir du flux de travail en direct :
Instruction d’origine complète de ui-design
# vm0 / Zero Règles de conception de l'interface utilisateur
## Workflow : les visuels d'abord, le code plus tard
**Ne passez pas directement au code.** Lorsque cette compétence est invoquée, le premier livrable est toujours un ensemble de maquettes rendues que Ming peut examiner. La mise en œuvre n’a lieu qu’après qu’une direction a été choisie.
### Étape 1 — Capturez le « avant »
- Si un écran existe déjà, affichez son état actuel sous la forme de l'image **avant** (capturez l'écran de l'application en cours d'exécution ou affichez le composant existant sous forme d'aperçu statique).
- Si la demande concerne un tout nouvel écran, le « avant » est soit l'écran existant le plus proche, soit un état vide — indiquez-le explicitement dans la légende.
### Étape 2 — Produire une seule ancre « après »
- Une maquette qui représente votre meilleure interprétation de la demande, obéissant pleinement à toutes les règles ci-dessous (composants, casse de la phrase, entrées/listes déroulantes des détails de l'agent, rayons de la carte du compositeur de discussion, bouton d'ajout de calendrier, survols d'IconButton, surfaces grises-50).
- Associez-le au **avant** côte à côte. Étiquetez-les clairement : `Before` / `After`.
### Étape 3 — Générer 9 explorations de variantes
Après la paire avant/après, produisez **9 maquettes de variantes distinctes** pour le même écran. Chaque variante doit explorer un axe de conception significativement différent – et non 9 ajustements de couleurs. Couvrir une diffusion telle que :
1. Disposition : colonne unique ou fractionnée/barre latérale/grille
2. Densité – compact ou spacieux
3. Hiérarchie – quel élément mène visuellement
4. Traitement de surface : sections plates, regroupées en cartes ou divisées
5. Point d'entrée : action en ligne, CTA dédié ou héros à l'état vide
6. Cadrage de copie – instructif vs minimal vs conversationnel
7. Divulgation – tout ce qui est visible par rapport à la révélation progressive/accordéons
8. Composition : axée sur le contenu ou axée sur le contrôle
9. Une direction volontairement non conventionnelle / "wild card" à voir une fois
Chaque variante doit toujours respecter les éléments non négociables (cas de la phrase, composants de réutilisation, style de saisie/liste déroulante des détails de l'agent, rayons de composition du chat, bouton d'ajout de calendrier, survol d'IconButton, gris-50 neutres). Les variantes explorent *la mise en page et l'emphase*, et non « et si nous ignorions le système de conception ».
### Étape 4 — Présentez, puis attendez
- Montrez toutes les images à Ming dans un seul message : la paire `Before / After` en premier, puis les 9 variantes numérotées de 1 à 9 avec une légende d'une ligne décrivant chacune l'axe exploré.
- Demandez quelle direction (ou quelle combinaison) poursuivre.
- Ne commencez pas la mise en œuvre avant que Ming n’ait choisi une direction.
### Rendu des images
- Chemin préféré : créez des aperçus HTML/React statiques qui utilisent de vrais jetons Tailwind de `turbo/apps/platform`, capturez-les et téléchargez-les via `okou web upload-file`.
- Pour une exploration rapide : la compétence `v0` peut générer des maquettes de variantes à partir d'une invite, mais l'invite doit énumérer explicitement les règles ci-dessous (cas de la phrase, entrées de détails de l'agent, rayon du compositeur de discussion, etc.) afin que la v0 ne produise pas d'interface utilisateur SaaS générique.
- Si la génération d'images n'est pas disponible pour la session, revenez à des wireframes ASCII/textuels clairement étiquetés pour les 11 images (avant, après, 9 variantes) et dites-le - ne sautez jamais silencieusement l'étape visuelle.
---
# Règles de conception
Il s'agit des conventions de conception non négociables pour toute nouvelle interface utilisateur livrée au sein de la plate-forme vm0 (`turbo/apps/platform`). Appliquez-les avant d'écrire des composants et auditez les PR existants par rapport à eux lors de l'examen.
## Principes fondamentaux
1. **Réutilisez, ne réinventez pas.** Vérifiez toujours les primitives existantes dans `turbo/apps/platform/src/components/` et les modèles au niveau de la vue sous `src/views/` avant d'introduire un nouveau composant. Si une interaction similaire est déjà fournie dans les détails de l'agent, le calendrier ou l'éditeur de chat, copiez ce modèle plutôt que d'en concevoir un parallèle.
2. ** Correspond au langage de conception Zero. ** Surfaces douces, gris neutres, rayons généreux, bordures subtiles, pas d'ombres dures. La ligne de base visuelle est « calme, opiniâtre, légèrement éditoriale » – jamais celle par défaut du SaaS.
3. **Parlez depuis le siège de l'utilisateur.** La copie doit décrire ce *qu'ils* sont sur le point de faire ou de voir, et non ce que fait le système. Soyez bref – généralement une seule phrase, maximum deux.
## Modèles de référence (copiez-les directement)
| Élément | Source de référence | Pourquoi |
|---------------------|---------------------------------------------------|-----|
| Saisie de texte / zone de texte | Entrée de la page de détails de l'agent (`src/views/agent-detail/`) | Remplissage établi, bordure, état de focus, traitement d'espace réservé |
| Liste déroulante/sélectionner | Liste déroulante de la page de détails de l'agent | Style de déclenchement établi, rayon du menu, survol des éléments, placement des coches |
| Rayon carte/panneau | Carte de composition de chat (recherchez les composants `composer`) | Définit le rayon canonique de la carte et le style de surface dans l'application |
| Bouton de la page principale | Bouton « Ajouter un planning » sur la page du planning | Le primaire neutre-foncé utilisé partout *en dehors* des modaux |
| Bouton principal modal | La couleur primaire de la marque (uniquement à l'intérieur des boîtes de dialogue/popovers) | Les modaux conservent la couleur primaire de la marque ; les pages ne le font pas |
| Bouton avec icône uniquement | IconButton existant avec arrière-plan de survol | Chaque icône cliquable doit avoir un état de survol visible |
En cas de doute, ouvrez le composant de référence dans la base de code, lisez ses accessoires et ses noms de classe et mettez-les en miroir. Ne vous rapprochez pas de mémoire.
## Règles rédactionnelles
- **Formulation du point de vue de l'utilisateur.** "Connectez votre boîte de réception" bat "Connexion à la boîte de réception requise". "Aucun agent pour l'instant" bat "La liste des agents est vide".
- **La brièveté plutôt que l'exhaustivité.** Une ligne courte surpasse une phrase complète. Garniture de remplissage ("simplement", "s'il vous plaît", "afin de").
- **Cas de phrase pour tout.** Étiquettes, titres, boutons, éléments de menu, colonnes de tableau — tous les cas de phrase ("Fournisseurs de modèles", "Clés API", "Ajouter un planning"). Jamais de cas de titre. Jamais `uppercase` via CSS sur les en-têtes de section. Si vous trouvez une étiquette Title-Case ou tout en majuscules, corrigez-la.
- **Aucune étiquette « décorative » au-dessus des champs ou des sections : elles se lisent comme un formulaire et sont datées. Utilisez une étiquette normale ou ignorez l'étiquette si le champ est évident.
- **Aucune ponctuation finale** sur les étiquettes ou les boutons autonomes. Les points sont destinés au corps du texte et au texte d’assistance.
- Lorsque vous renommez une chaîne, récupérez la base de code de l'ancienne chaîne et testez-la - les étiquettes sont référencées dans les tests et les traductions.
## Composants et structure
- Créez toujours des pages à partir de composants existants (`Button`, `Input`, `Select`, `Card`, `IconButton`, primitives de dialogue, etc.). Les nouveaux composants sont un dernier recours et nécessitent une raison.
- Recherchez une mise en page/un modèle existant (page de paramètres, page de liste, page de détails) et héritez de son échafaudage. Ne redérivez pas la structure des pages.
- Lors de l'ajout à une page de style paramètres, faites correspondre l'espacement des sections, le traitement des séparateurs et la largeur des lignes de formulaire utilisés par les sections voisines.
## Boutons
- **Page principale** (le CTA principal sur une page) → faites correspondre le bouton "Ajouter un planning" sur la page de planning. Il s'agit des boîtes de dialogue extérieures neutres sombres/solides utilisées dans toute l'application.
- **Modal primaire** (le bouton de confirmation à l'intérieur des boîtes de dialogue/popovers) → utilise la couleur primaire de la marque. Les pages ne le font pas.
- **Boutons secondaires/fantômes** → réutiliser les variantes existantes ; n’en inventez pas de nouveaux.
- **Boutons d'icône** → doivent avoir un arrière-plan de survol (généralement `hover:bg-gray-50` ou le jeton de survol IconButton établi). N’envoyez jamais une simple icône sans survol comme cible de clic.
- Tous les boutons doivent respecter les jetons de hauteur existants — n'introduisez pas de tailles uniques.
## Champs de saisie
- Reflétez l'entrée des détails de l'agent : même remplissage, même bordure, même bague de mise au point (ou son absence – vérifiez la référence avant d'ajouter une bague de mise au point), même couleur d'espace réservé.
- Multiligne : utilisez le modèle de zone de texte des détails de l'agent (croissance automatique ou lignes fixes comme dans la référence).
- Ne mettez pas de deux-points à la fin des étiquettes de champ.
- Texte d'assistance sous l'entrée, en gris sourd, sur une seule ligne.
## Listes déroulantes/sélections
- Reflétez la liste déroulante des détails de l'agent : même apparence de déclencheur, même rayon de menu, même remplissage d'éléments, mêmes états de survol/sélectionnés.
- Le menu ne doit pas être plus large que son déclencheur, sauf si le contenu l'exige.
- Évitez les sous-menus imbriqués à moins qu'une liste déroulante existante ne les utilise déjà.
## Cartes et surfaces
- Le rayon de la carte et le style de surface correspondent à la carte du composeur de chat. N'introduisez pas un rayon plus petit ou plus grand sans raison.
- Les bordures sont subtiles (une seule ligne de cheveux dans le jeton de bordure existant). Pas d'ombres portées, sauf si le compositeur du chat en utilise une.
- Surfaces neutres sur remplissages mobiles/gris clair (fonds de pilules actifs, remplissages de conteneurs d'icônes, etc.) → `bg-gray-50`. `gray-100` et `gray-200` ont été qualifiés à plusieurs reprises de trop sombres – commencez par `gray-50`.
## Focus et interaction
- N'ajoutez pas d'ombres de boîte ou de contours `:focus-visible` personnalisés aux éléments de navigation/marketing : réutilisez plutôt le changement de couleur du survol. (La même contrainte s'applique généralement à l'intérieur de la plate-forme, sauf si un composant de référence possède une bague de mise au point explicite.)
- Chaque élément interactif (bouton, bouton icône, ligne, lien) nécessite un état de survol visible. Testez en survolant chacun d’eux avant de considérer le design réalisé.
- Les états désactivés utilisent les jetons désactivés existants ; ne roulez pas à la main une couleur fanée.
## Liste de contrôle de révision
Avant de déclarer une interface utilisateur prête, parcourez :
1. Ai-je réutilisé des composants existants au lieu d’en créer de nouveaux ?
2. Ai-je fait correspondre un modèle/une mise en page de page existante ?
3. Les entrées sont-elles visuellement identiques aux entrées de détails de l'agent ?
4. Les listes déroulantes sont-elles visuellement identiques aux listes déroulantes des détails de l'agent ?
5. Les cartes correspondent-elles au rayon et à la surface du compositeur de chat ?
6. Chaque phrase d'étiquette est-elle casse ? Il reste des casses de titre ou des majuscules ?
7. La copie est-elle courte et rédigée depuis le siège de l'utilisateur ?
8. La page principale est-elle le bouton de style « Ajouter un programme » ? La marque est-elle principalement utilisée uniquement dans les modaux ?
9. Chaque bouton d'icône a-t-il un arrière-plan de survol ?
10. Ai-je survolé chaque élément interactif pour confirmer les commentaires ?
Si la réponse est « non », corrigez-la avant d'ouvrir le PR.
## En cas de doute
- Ouvrez le composant de référence, lisez sa source et copiez la structure.
- Si deux composants de référence ne sont pas d'accord, préférez celui le plus récemment livré (vérifiez le journal git).
- Si la conception a réellement besoin d'une nouvelle primitive, élaborez-la avec Ming avant de la construire - le travail de refonte groupé appartient à un seul PR avec lui en tant que réviseur.
Il n’est pas nécessaire que les neuf options correspondent à neuf modèles finis. Leur travail consiste à me donner suffisamment de latitude pour voir le problème différemment et aller dans la bonne direction. Si un concept se situe en dehors du produit actuel, un prototype autonome React peut toujours aider. Pour cette fonctionnalité, je suis resté dans le système de produit réel.
Un exemple concret : la navigation de Zero
Zero disposait à l'origine d'une barre latérale de 300 pixels contenant les destinations des produits, les agents épinglés et les fils de discussion. Il effectuait trois tâches à la fois. Je voulais séparer ces tâches sans changer la zone de conversation.
La description du produit pour l'exploration était :
/ui-designRejouez la phase de conception de la navigation à trois régions de Zero à partir de la véritable base historique. Séparez les destinations des produits, les agents et les conversations en régions plus claires sans modifier la zone de conversation. Utilisez de vrais jetons, icônes et composants Zero. Produisez un Avant fidèle à la source, un Après fort et neuf variantes véritablement différentes. Ne modifiez pas le code produit et ne présentez pas de maquette comme preuve du navigateur.
La première exploration était trop prudente. Plusieurs options modifiaient les largeurs et les styles de sélection, mais elles ressemblaient toujours à la même barre latérale. J'ai rejeté cet ensemble et demandé à l'agent de rendre les différences visibles au niveau de l'architecture de l'information.
La deuxième manche a renvoyé neuf directions véritablement différentes. Je les ai regroupés dans un tableau 3 × 3 afin qu'ils soient faciles à comparer sans transformer l'article en une longue bande d'images. Chaque vignette s'ouvre dans la visionneuse d'images du blog.
| 1. Navigation supérieure | 2. Tiroir pliable | 3. Discussion en premier |
|---|---|---|
 |  |  |
| Déplacer les destinations au-dessus de la conversation | Masquer les destinations jusqu'à ce que vous en ayez besoin | Faire des conversations l'objet de navigation principal |
| 4. Agent d'abord | 5. Conversation d'abord | 6. Lanceur de commandes |
 |  |  |
| Choisir un agent avant ses fils de discussion | Placer les agents épinglés au-dessus de la conversation active | Ouvrir les destinations à partir d'un menu consultable |
| 7. Rail extensible | 8. Entrée dans le tableau de bord | 9. Quai inférieur |
 |  |  |
| Développez un rail étroit uniquement lorsque cela est nécessaire | Commencer par des travaux récents | Déplacer les destinations vers le bas |
Je n'ai pas choisi un de ces cadres exactement tel qu'il a été dessiné. Je les ai utilisés pour décider ce qui devait rester et ce qui devait changer. La direction finale utilisait un rail de destination étroit, un rail de discussion séparé, cinq agents épinglés visibles et la zone de conversation existante.
Le résultat important de ui-design n’était pas seulement l’image. C'était un bref compte rendu de décision :
- Conserver un rail de destination de 68 pixels et un rail de discussion de 300 pixels
- Afficher cinq emplacements d'agent épinglés
- Gardez la sélection silencieuse mais lisible
- Afficher les conseils de réorganisation uniquement lors du déplacement
- Gardez la conversation et le tiroir mobile existant inchangés
C'était suffisant pour commencer la mise en œuvre.
3. Utilisez ui-implement pour transformer la conception sélectionnée en code
Après avoir choisi une direction et connecté la base de code du produit, l'agent travaille directement dans le code. Je ne redessine pas d'abord le cadre sélectionné dans Figma.
En langage clair, ui-implement ignore l'exploration car la direction a déjà été choisie. Il trouve les composants réels et la structure de page les plus proches, construit avec eux, audite le résultat et vérifie la fonctionnalité dans un navigateur.
Ce que cette instruction protège
- L’orientation choisie ne doit pas être repensée lors de la mise en œuvre.
- L'agent doit commencer par le composant existant et la page de modèle les plus proches.
- La réutilisation l’emporte sur un nouveau composant sauf si le produit présente une réelle lacune.
- L'auto-audit et la vérification du navigateur détectent les copies, les états et les interactions incohérents.
- Si une décision concernant un produit n'est toujours pas résolue, le travail revient à
ui-design.
C'est ainsi que le système de conception reste actif pendant la mise en œuvre. Ce n'est pas un document que l'agent lit une seule fois. Il détermine les composants qu'il choisit et la manière dont il vérifie l'expérience finale.
Voici l’instruction originale complète, reproduite textuellement à partir du flux de travail en direct :
Instruction d’origine complète de ui-implement
# vm0 / Zero Règles de mise en œuvre de l'interface utilisateur
## Workflow – implémenter directement
Lorsque cette compétence est invoquée, **ignorez la phase d'exploration de la maquette et des variantes**. Commencez immédiatement l'implémentation dans `turbo/apps/platform`, en appliquant toutes les règles de conception ci-dessous.
### Étape 1 — Localisez les composants de référence
Avant d'écrire une ligne, ouvrez les composants de référence que vous allez mettre en miroir :
- Entrée / zone de texte → entrée `src/views/agent-detail/`
- Liste déroulante / sélection → liste déroulante `src/views/agent-detail/`
- Rayon de la carte / du panneau → carte du compositeur de chat
- Bouton principal de la page → bouton "Ajouter un planning" sur la page du planning
- Bouton avec icône uniquement → `IconButton` existant avec arrière-plan de survol
Lisez leurs accessoires et leurs noms de classe. Reflétez-les – ne faites pas d’approximation de mémoire.
### Étape 2 — Recherchez le modèle de page existant le plus proche
Ouvrez la page existante la plus proche de la même forme (paramètres, liste, détail) et héritez de son échafaudage : espacement des sections, traitement des séparateurs, largeur des lignes de formulaire. Ne redérivez pas la structure des pages.
### Étape 3 — Créer, puis auto-auditer
Implémentez l'écran avec les primitives existantes de `turbo/apps/platform/src/components/`. Lorsque vous pensez que c'est terminé, parcourez la **liste de contrôle de révision** au bas de cette compétence avant de faire votre rapport. Corrigez chaque réponse « non » avant de déclarer le travail terminé.
### Étape 4 — Vérifiez dans le navigateur
Pour tout travail sur l'interface utilisateur, démarrez le serveur de développement et exercez la fonctionnalité dans un navigateur avant de signaler la tâche comme terminée. Survolez chaque élément interactif, testez le chemin d'or et les cas extrêmes, et surveillez les régressions dans les écrans voisins. La vérification du type et les tests vérifient le code, et non l'exactitude des fonctionnalités. Si vous ne pouvez pas ouvrir le navigateur, dites-le explicitement.
### Quand recourir à ui-design
Si la requête est ouverte (« concevoir une page de paramètres pour X ») sans direction choisie, arrêtez et exécutez la compétence `ui-design` à la place — les variantes avant/après + 9 existent exactement pour ce cas. `ui-implement` est destiné lorsque la direction est déjà décidée.
---
# Règles de conception
Il s'agit des conventions de conception non négociables pour toute nouvelle interface utilisateur livrée au sein de la plate-forme vm0 (`turbo/apps/platform`). Appliquez-les lors de la construction et vérifiez votre propre différence par rapport à eux avant d'ouvrir le PR.
## Principes fondamentaux
1. **Réutilisez, ne réinventez pas.** Vérifiez toujours les primitives existantes dans `turbo/apps/platform/src/components/` et les modèles au niveau de la vue sous `src/views/` avant d'introduire un nouveau composant. Si une interaction similaire est déjà fournie dans les détails de l'agent, le calendrier ou l'éditeur de chat, copiez ce modèle plutôt que d'en concevoir un parallèle.
2. ** Correspond au langage de conception Zero. ** Surfaces douces, gris neutres, rayons généreux, bordures subtiles, pas d'ombres dures. La ligne de base visuelle est « calme, opiniâtre, légèrement éditoriale » – jamais celle par défaut du SaaS.
3. **Parlez depuis le siège de l'utilisateur.** La copie doit décrire ce *qu'ils* sont sur le point de faire ou de voir, et non ce que fait le système. Soyez bref – généralement une seule phrase, maximum deux.
## Modèles de référence (copiez-les directement)
| Élément | Source de référence | Pourquoi |
|---------------------|---------------------------------------------------|-----|
| Saisie de texte / zone de texte | Entrée de la page de détails de l'agent (`src/views/agent-detail/`) | Remplissage établi, bordure, état de focus, traitement d'espace réservé |
| Liste déroulante/sélectionner | Liste déroulante de la page de détails de l'agent | Style de déclenchement établi, rayon du menu, survol des éléments, placement des coches |
| Rayon carte/panneau | Carte de composition de chat (recherchez les composants `composer`) | Définit le rayon canonique de la carte et le style de surface dans l'application |
| Bouton de la page principale | Bouton « Ajouter un planning » sur la page du planning | Le primaire neutre-foncé utilisé partout *en dehors* des modaux |
| Bouton principal modal | La couleur primaire de la marque (uniquement à l'intérieur des boîtes de dialogue/popovers) | Les modaux conservent la couleur primaire de la marque ; les pages ne le font pas |
| Bouton avec icône uniquement | IconButton existant avec arrière-plan de survol | Chaque icône cliquable doit avoir un état de survol visible |
En cas de doute, ouvrez le composant de référence dans la base de code, lisez ses accessoires et ses noms de classe et mettez-les en miroir. Ne vous rapprochez pas de mémoire.
## Règles rédactionnelles
- **Formulation du point de vue de l'utilisateur.** "Connectez votre boîte de réception" bat "Connexion à la boîte de réception requise". "Aucun agent pour l'instant" bat "La liste des agents est vide".
- **La brièveté plutôt que l'exhaustivité.** Une ligne courte surpasse une phrase complète. Garniture de remplissage ("simplement", "s'il vous plaît", "afin de").
- **Cas de phrase pour tout.** Étiquettes, titres, boutons, éléments de menu, colonnes de tableau — tous les cas de phrase ("Fournisseurs de modèles", "Clés API", "Ajouter un planning"). Jamais de cas de titre. Jamais `uppercase` via CSS sur les en-têtes de section. Si vous trouvez une étiquette Title-Case ou tout en majuscules, corrigez-la.
- **Aucune étiquette « décorative » au-dessus des champs ou des sections : elles se lisent comme un formulaire et sont datées. Utilisez une étiquette normale ou ignorez l'étiquette si le champ est évident.
- **Aucune ponctuation finale** sur les étiquettes ou les boutons autonomes. Les points sont destinés au corps du texte et au texte d’assistance.
- Lorsque vous renommez une chaîne, récupérez la base de code de l'ancienne chaîne et testez-la - les étiquettes sont référencées dans les tests et les traductions.
## Composants et structure
- Créez toujours des pages à partir de composants existants (`Button`, `Input`, `Select`, `Card`, `IconButton`, primitives de dialogue, etc.). Les nouveaux composants sont un dernier recours et nécessitent une raison.
- Recherchez une mise en page/un modèle existant (page de paramètres, page de liste, page de détails) et héritez de son échafaudage. Ne redérivez pas la structure des pages.
- Lors de l'ajout à une page de style paramètres, faites correspondre l'espacement des sections, le traitement des séparateurs et la largeur des lignes de formulaire utilisés par les sections voisines.
## Boutons
- **Page principale** (le CTA principal sur une page) → faites correspondre le bouton "Ajouter un planning" sur la page de planning. Il s'agit des boîtes de dialogue extérieures neutres sombres/solides utilisées dans toute l'application.
- **Modal primaire** (le bouton de confirmation à l'intérieur des boîtes de dialogue/popovers) → utilise la couleur primaire de la marque. Les pages ne le font pas.
- **Boutons secondaires/fantômes** → réutiliser les variantes existantes ; n’en inventez pas de nouveaux.
- **Boutons d'icône** → doivent avoir un arrière-plan de survol (généralement `hover:bg-gray-50` ou le jeton de survol IconButton établi). N’envoyez jamais une simple icône sans survol comme cible de clic.
- Tous les boutons doivent respecter les jetons de hauteur existants — n'introduisez pas de tailles uniques.
## Champs de saisie
- Reflétez l'entrée des détails de l'agent : même remplissage, même bordure, même bague de mise au point (ou son absence – vérifiez la référence avant d'ajouter une bague de mise au point), même couleur d'espace réservé.
- Multiligne : utilisez le modèle de zone de texte des détails de l'agent (croissance automatique ou lignes fixes comme dans la référence).
- Ne mettez pas de deux-points à la fin des étiquettes de champ.
- Texte d'assistance sous l'entrée, en gris sourd, sur une seule ligne.
## Listes déroulantes/sélections
- Reflétez la liste déroulante des détails de l'agent : même apparence de déclencheur, même rayon de menu, même remplissage d'éléments, mêmes états de survol/sélectionnés.
- Le menu ne doit pas être plus large que son déclencheur, sauf si le contenu l'exige.
- Évitez les sous-menus imbriqués à moins qu'une liste déroulante existante ne les utilise déjà.
## Cartes et surfaces
- Le rayon de la carte et le style de surface correspondent à la carte du composeur de chat. N'introduisez pas un rayon plus petit ou plus grand sans raison.
- Les bordures sont subtiles (une seule ligne de cheveux dans le jeton de bordure existant). Pas d'ombres portées, sauf si le compositeur du chat en utilise une.
- Surfaces neutres sur remplissages mobiles/gris clair (fonds de pilules actifs, remplissages de conteneurs d'icônes, etc.) → `bg-gray-50`. `gray-100` et `gray-200` ont été qualifiés à plusieurs reprises de trop sombres – commencez par `gray-50`.
## Focus et interaction
- N'ajoutez pas d'ombres de boîte ou de contours `:focus-visible` personnalisés aux éléments de navigation/marketing : réutilisez plutôt le changement de couleur du survol. (La même contrainte s'applique généralement à l'intérieur de la plate-forme, sauf si un composant de référence possède une bague de mise au point explicite.)
- Chaque élément interactif (bouton, bouton icône, ligne, lien) nécessite un état de survol visible. Testez en survolant chacun d’eux avant de considérer le design réalisé.
- Les états désactivés utilisent les jetons désactivés existants ; ne roulez pas à la main une couleur fanée.
## Liste de contrôle de révision
Avant de déclarer une interface utilisateur prête, parcourez :
1. Ai-je réutilisé des composants existants au lieu d’en créer de nouveaux ?
2. Ai-je fait correspondre un modèle/une mise en page de page existante ?
3. Les entrées sont-elles visuellement identiques aux entrées de détails de l'agent ?
4. Les listes déroulantes sont-elles visuellement identiques aux listes déroulantes des détails de l'agent ?
5. Les cartes correspondent-elles au rayon et à la surface du compositeur de chat ?
6. Chaque phrase d'étiquette est-elle casse ? Il reste des casses de titre ou des majuscules ?
7. La copie est-elle courte et rédigée depuis le siège de l'utilisateur ?
8. La page principale est-elle le bouton de style « Ajouter un programme » ? La marque est-elle principalement utilisée uniquement dans les modaux ?
9. Chaque bouton d'icône a-t-il un arrière-plan de survol ?
10. Ai-je survolé chaque élément interactif dans un navigateur pour confirmer les commentaires ?
Si la réponse est « non », corrigez-la avant d'ouvrir le PR.
## En cas de doute
- Ouvrez le composant de référence, lisez sa source et copiez la structure.
- Si deux composants de référence ne sont pas d'accord, préférez celui le plus récemment livré (vérifiez le journal git).
- Si la conception a réellement besoin d'une nouvelle primitive, élaborez-la avec Ming avant de la construire - le travail de refonte groupé appartient à un seul PR avec lui en tant que réviseur.
Il s'agissait de l'invite d'implémentation spécifique à la fonctionnalité :
/ui-implementCommencez à partir de la révision
04d642bb. Ajoutez un bureau divisé par défaut avec un rail de destination de 68 px, un rail de discussion de 300 px et la conversation inchangée. Conservez l'ancienne barre latérale de 300 px lorsque le commutateur est éteint et sur mobile. Affichez cinq emplacements épinglés, conservez l'ordre défini par l'utilisateur et affichez les possibilités de réorganisation uniquement lors d'un glissement actif. N’inspectez pas la fonctionnalité historique ou les améliorations ultérieures tant que les correctifs indépendants, les tests et les preuves du navigateur ne sont pas gelés.
Pour la fonctionnalité de navigation, j'ai demandé à l'agent de conserver l'ancienne barre latérale lorsque la fonctionnalité était désactivée, d'afficher la nouvelle présentation en trois parties lorsqu'elle était activée, de conserver le tiroir mobile existant et de permettre aux utilisateurs de réorganiser les agents épinglés.
Lors de la mise en œuvre, l'agent a découvert un problème important. L'ancien produit mémorisait quels agents étaient épinglés, mais il ne se souvenait pas de leur ordre. Une interaction par glisser-déposer peut sembler correcte, puis réinitialisée après une actualisation.
L’agent a donc fait plus que dessiner l’état de traînée. Il a fait persister la nouvelle commande, actualisé la page et vérifié que la commande était restée. Il a également confirmé que les poignées de réorganisation apparaissaient uniquement pendant le glisser et disparaissaient ensuite.
La livraison de l'implémentation a montré les deux états du bureau que je devais examiner. Je les affiche en pleine largeur pour que l'interface reste lisible. Le comportement mobile apparaît plus tard dans la procédure pas à pas sous la forme d'une capture téléphonique haute densité.
État de repos du bureau
Réorganisation active
À ce stade, j'avais une fonctionnalité fonctionnelle, pas un autre fichier de conception. Mais la mise en œuvre n’est pas encore la fin. J'avais besoin de voir ce qui fonctionnait réellement dans l'aperçu déployé.
4. Utilisez ui-walkthrough pour examiner le produit réel
Les présentations de produits étaient autrefois fastidieuses. J'ouvrirais un aperçu déployé, préparerais le bon compte, activerais et désactiverais des fonctionnalités, cliquerais sur chaque contrôle, redimensionnerais le navigateur, prendrais des captures d'écran et essaierais de me souvenir de l'état représenté par chaque image.
L'agent dispose d'un Agent Browser intégré, je peux donc lui confier ce travail.
Le flux de travail comporte deux étapes principales :
- Énumérez d'abord les scénarios. L'agent transforme les revendications de conception et de mise en œuvre en une liste de contrôle.
- Exécutez la liste de contrôle et joignez des preuves. Il exécute tous les scénarios de l'aperçu déployé et renvoie PASS, FAIL ou BLOCKED avec une capture d'écran pour chaque état significatif.
Ce que cette instruction change concernant la révision
- L'agent répertorie les scénarios avant de commencer à cliquer.
- Il utilise le composant réellement déployé via son Agent Browser intégré.
- Il capture une capture d'écran pour chaque état significatif.
- Il marque chaque point de contrôle PASS, FAIL ou BLOCKED.
- Il ne cache jamais un état indisponible derrière de fausses preuves.
Cela transforme le clic manuel en un package de révision organisé. Je peux examiner ensemble le comportement prévu, le résultat et les preuves.
Les instructions complètes sont ci-dessous. J'ai traduit le nom de la dépendance interne en « Agent Browser intégré » pour plus de clarté pour le lecteur ; la logique du flux de travail est par ailleurs inchangée.
Instruction d’origine complète de ui-walkthrough
# Procédure pas à pas de l'interface utilisateur
Contrôle qualité visuel de bout en bout d'une fonctionnalité frontale vm0/Zero dans son véritable aperçu par PR. Ce flux de travail définit ce qu'il faut vérifier et comment rapporter le résultat ; il ne définit pas les outils d'exploitation de l'interface utilisateur.
## Dépendance requise : Agent Browser intégré
Utilisez le Agent Browser intégré comme source unique de vérité pour chaque interaction avec l'interface utilisateur, notamment :
- Découverte et ouverture de l'aperçu par PR.
- Gestion de la protection contre les aperçus et configuration de la session.
- Inscription, OTP, intégration, paiement du test Stripe et accès à l'application en direct.
- Activation des commutateurs de fonctionnalités.
- Naviguer, interagir avec les contrôles, fournir des données de test ou de simulation, capturer des captures d'écran, télécharger des artefacts, dépanner et nettoyer.
Lisez et suivez les instructions Agent Browser intégrées actuelles avant d'effectuer toute action de l'interface utilisateur. Ne dupliquez pas les commandes spécifiques à l'exécution, la configuration du moteur, les mécanismes de sélection, les scripts de contexte de page, la gestion de session ou les méthodes de nettoyage de processus dans ce flux de travail. Si le Agent Browser intégré change, ses instructions actuelles sont prioritaires.
## Quand utiliser
- Parcourez l’interface utilisateur d’une pull request vm0 dans son aperçu déployé.
- Vérifiez une fonctionnalité dans l'application qui nécessite une authentification, une intégration, une facturation, des changements de fonctionnalités ou un véritable fil de discussion.
- Capturez des captures d'écran fidèles ou une courte vidéo de présentation de la fonctionnalité fonctionnant dans l'application en direct.
## Flux de travail pas à pas
### 1. Établir l'objectif et la portée
- Identifiez le PR, la validation principale, le comportement modifié visible par l'utilisateur et l'aperçu attendu.
- Confirmez que l'aperçu déployé correspond à la tête PR avant de tester.
- Lisez le diff et la description du PR pour en déduire le chemin critique et les états qui démontrent le changement.
- Ne corrigez pas le code, ne résolvez pas les conflits ou ne modifiez pas le comportement du produit au cours d'une procédure pas à pas, sauf si l'utilisateur demande séparément la mise en œuvre.
### 2. Accédez à la fonctionnalité
Utilisez le Agent Browser intégré pour accéder à l'aperçu et atteindre l'état de la fonctionnalité en direct. Suivez ses règles actuelles pour l'authentification, l'intégration, la facturation, les changements de fonctionnalités et les contournements de prévisualisation uniquement.
Si un contournement est utilisé, indiquez-le dans le rapport final. N’utilisez jamais de contournement d’intégration lorsque l’intégration elle-même est en cours de test.
### 3. Définir la matrice d'état visuel
Avant d'interagir, répertoriez le plus petit ensemble d'états qui prouve que la fonctionnalité fonctionne. Incluez les éléments applicables :
- État initial/par défaut.
- État ouvert, survolé, mis au point, sélectionné, développé ou actif.
- États vides et peuplés.
- États activés et désactivés.
- États de réussite, de validation, de chargement et d’erreur.
- Placement, collision, retournement, découpage et comportement réactif.
- Soumission ou action en aval lorsque la fonctionnalité est interactive.
Préférez exercer le changement de comportement réel plutôt qu’un test de fumée générique.
### 4. Pilotez le composant actif
Utilisez le Agent Browser intégré pour toutes les techniques d'interaction et de données de test.
Le contenu simulé ou injecté ne peut être utilisé que pour placer un composant d'application réel dans un état visuel déterministe. Le composant, le style et l'interaction évalués doivent rester l'implémentation en direct de l'aperçu PR.
Pour chaque état simulé :
- Enregistrez quel contenu ou quelle condition préalable a été moqué.
- Distinguez le contenu simulé du comportement réel de l’application.
- N’insinuez jamais que le texte ou les données simulés proviennent d’un modèle ou d’une source de production.
- Exercez les contrôles réels et le câblage en aval partout où l'environnement le permet.
### 5. Capturer des preuves
Utilisez le Agent Browser intégré pour capturer et télécharger des preuves pour les points de contrôle clés. Chaque image doit prouver un état significatif plutôt que répéter la même vue.
Si l'utilisateur demande une vidéo, créez une courte présentation sous-titrée à partir des points de contrôle vérifiés. Les légendes doivent identifier l'action de l'utilisateur et le résultat attendu sans obscurcir l'interface utilisateur.
### 6. Livrer et rendre compte
Rapport:
- Lien PR, URL d'aperçu exacte et validation testée lorsqu'ils sont disponibles.
- Flux d'utilisateurs exact exercé.
- Testez le compte lors de sa création.
- `PASS`, `FAIL` ou `BLOCKED` pour chaque point de contrôle.
- Liens de capture d'écran et un lien vidéo facultatif avec de courtes descriptions.
- Commutateurs de fonctionnalités, contournements, données fictives et autres configurations de test uniquement utilisées.
- Échec des vérifications, blocages d’environnement ou lacunes de vérification.
Ne prétendez pas que la fonctionnalité est vérifiée à moins que le flux de prévisualisation en direct n’ait été exercé et que des preuves n’aient été capturées. Si l'aperçu n'est pas disponible, signalez `BLOCKED` avec la preuve de déploiement plutôt que de remplacer une réplique locale ou statique.
Voici l'invite de présentation spécifique à la fonctionnalité :
/ui-walkthroughUtilisez l'aperçu déployé via le Agent Browser intégré comme seule vérité de navigateur. Prouvez la barre latérale sans fonctionnalités, la division 68px et 300px, l'ordre de destination, les états de survol, les cinq emplacements épinglés, les poignées de glisser uniquement, la réorganisation persistante, la sélection des fils de discussion, le défilement et le tiroir complet de l'iPhone. Renvoyez PASS, FAIL ou BLOCKED pour chaque point de contrôle. Ne remplacez pas un état inaccessible par une réplique.
Pour cette fonctionnalité, l'agent a organisé la procédure pas à pas autour de ces questions :
- L’ancienne barre latérale fonctionne-t-elle toujours lorsque la fonctionnalité est désactivée ?
- La nouvelle structure du bureau apparaît-elle lorsqu'il est activé ?
- Le survol et les états sélectionnés sont-ils visibles mais silencieux ?
- Cinq agents épinglés sont-ils lisibles ?
- Les contrôles de réorganisation restent-ils masqués jusqu'au début d'un glissement ?
- La nouvelle commande survivra-t-elle à un rafraîchissement ?
- Puis-je sélectionner et faire défiler de vrais fils de discussion ?
- Le tiroir mobile existant fonctionne-t-il toujours ?
- Toutes les destinations de navigation sont-elles présentes et dans le bon ordre ?
L'agent a ensuite ouvert l'aperçu déployé en tant que nouvel utilisateur, terminé l'intégration, activé la fonctionnalité et parcouru la liste. Il a testé l'état de repos, l'état de survol, l'état de glissement, le comportement d'actualisation, la sélection des threads, le défilement et la disposition du téléphone.
Le résultat était 11 PASS, 1 FAIL.
L’échec a été utile. La mise en page et les interactions ont fonctionné, mais l'aperçu déployé n'a montré que six destinations de produits. Activity et Insights manquaient et la commande ne correspondait pas au modèle sélectionné.
| Scénario | Résultat |
|---|---|
| Ancienne barre latérale avec la fonctionnalité désactivée | PASS |
| Nouvelle disposition du bureau en trois parties | PASS |
| Survol et états sélectionnés | PASS |
| Cinq agents épinglés | PASS |
| Conseils de réorganisation par glisser-déposer uniquement | PASS |
| Commande enregistrée après actualisation | PASS |
| Sélection et défilement du sujet | PASS |
| Tiroir mobile existant | PASS |
| Contenu et ordre de la destination | FAIL |
La livraison finale était un ensemble de captures d'écran organisé plutôt qu'un dossier d'images sans étiquette. Les captures du bureau sont de 1 440 × 900 pixels et celles du téléphone sont de 1 170 × 2 532 pixels. Ils apparaissent un par un ci-dessous pour que l'interface reste lisible ; cliquez sur n’importe quelle image pour l’agrandir sans quitter l’article.
Fonctionnalité désactivée
Fonctionnalité activée
Disposition du bureau
Survol de la destination
Survol d'un agent épinglé
Traînée active
Commande enregistrée
Tiroir mobile
Cela me permet de revoir une fonctionnalité de manière structurée. Je peux voir les scénarios prévus, le résultat réel déployé et les preuves ensemble. Si quelque chose échoue, je sais exactement où le travail doit revenir.
Comment une équipe adopte ce workflow de conception de produits IA
Le processus complet est court. Les coéquipiers peuvent enregistrer chaque étape sous le nom flux de travail partagé Zero au lieu de reconstruire le processus à partir de la mémoire.
| Scène | Saisir | Sortir |
|---|---|---|
ui-design | Écran actuel, problème, objectif et contraintes | Une direction recommandée, neuf alternatives et un dossier de conception sélectionné |
ui-implement | L'enregistrement de conception sélectionné | Un changement de code révisable et des captures d'écran des principaux états |
ui-walkthrough | La fonctionnalité déployée et son comportement attendu | Une liste de scénarios organisée avec des captures d'écran PASS, FAIL ou BLOCKED |
Un coéquipier n’a pas besoin de reproduire mes goûts en matière de design. Ils doivent fournir un bon contexte, utiliser le système de produits partagés, faire un choix explicite après exploration et examiner les preuves du navigateur. Les trois mêmes points de contrôle humains – problème, direction et acceptation – façonnent également la façon dont nous gérer les agents IA comme une équipe.
Ce flux de travail ne supprime pas la pratique de conception ou le design thinking. Cela les amène aux parties qui comptent le plus : définir le problème, définir les contraintes, comparer les directions, choisir les compromis et juger le produit en cours d'exécution.
Lorsque le système de composants est mature, je n'ai plus besoin de reconstruire chaque fonctionnalité sous forme de blocs déplaçables dans Figma. Je peux travailler avec l'agent directement dans le produit, tandis que le système de conception maintient le résultat cohérent et que la procédure pas à pas maintient le résultat honnête.
Questions fréquentes
Comment créer un workflow de conception de produits IA ?
Commencez par le système de produits existant, et non par une invite vide. Séparez le travail en exploration, mise en œuvre et révision. Laissez l'agent générer des options et effectuer des vérifications répétables, mais laissez le concepteur de produit responsable du problème, de la direction choisie et de l'acceptation finale.
Les concepteurs de produits peuvent-ils travailler sans Figma ?
Oui, lorsque le produit dispose déjà de composants, de modèles de page et de modèles d'interaction stables. Figma reste utile pour un nouveau langage visuel ou une interaction inconnue. Il ne s’agit pas d’interdire Figma ; il s’agit d’éviter de reconstruire les décisions de produits connues sur une seconde toile.
L’IA remplace-t-elle les concepteurs de produits ?
Pas dans ce flux de travail. L'agent assemble les options, modifie le code et vérifie les scénarios. Le concepteur définit toujours le problème, définit les contraintes, compare les compromis, choisit la direction et décide si le produit en cours d'exécution est suffisamment bon pour être expédié.
