Dans les termes du Skill
Une discipline axée sur le métier pour concevoir des UI produit — tableaux de bord, panneaux d'administration, applications SaaS, outils, pages de paramètres, interfaces de données — avec les décisions qu'une équipe de design de premier plan prendrait. Il impose un brief de travail avant le code : qui est l'humain, le verbe unique qu'il est venu accomplir, et ce que l'interface doit faire ressentir, en des mots qui ont du sens.
À partir de là, il prescrit une exploration du domaine (domaine, univers de couleurs, signature, valeurs par défaut rejetées), une échelle typographique construite sur un ratio où le poids et la couleur assurent la hiérarchie, une stratégie de profondeur unique et assumée, des tokens sémantiques plutôt que des valeurs codées en dur, ainsi que les fondamentaux de finition et de mouvement — chiffres tabulaires, rayon concentrique, durées sous 300ms, aucune animation sur les actions à haute fréquence. Explicitement non destiné aux pages d'atterrissage, sites marketing, campagnes ou travaux de marque uniquement.
Ce qu'il produit
- Une proposition Suggest + Ask nommant Domain, Color world, Signature, Rejecting et Direction.
- Des spécimens rendus en ligne — échantillons de palette, échelle typographique dans la vraie police, cartes d'élévation superposées, la signature comme un vrai composant — lorsqu'un outil de rendu est présent ; l'implémentation elle-même finit toujours dans la base de code.
- Un fichier .interface-design/system.md enregistré, contenant la direction, la stratégie de profondeur, les décisions de hiérarchie et les motifs de composants répétés, rédigé uniquement après que l'utilisateur ait dit oui.
Fonctionnement
- 01Rédiger le brief de travail
Avant tout code, répondre à qui est l'humain, quel verbe il doit accomplir, et à quoi l'interface doit ressembler — resté compact sauf si la direction a besoin d'être confirmée.
- 02Explorer le domaine produit
Produire quatre livrables avant de proposer une direction : au moins 5 concepts de domaine, 5+ couleurs issues du monde physique du produit, un élément signature, et 3 valeurs par défaut évidentes à rejeter.
- 03Proposer et confirmer la direction
Commencer par un bloc Suggest + Ask nommant Domain, Color world, Signature, Rejecting et Direction, puis vérifier que la direction semble juste avant de construire.
- 04Rendre les spécimens quand c'est possible
Si la session dispose d'un outil de rendu visuel en ligne, montrer la palette, l'échelle typographique, les paliers d'élévation et la signature sous forme de vrais composants plutôt que de les décrire ; sinon, revenir au code.
- 05Construire à partir de l'existant, puis vérifier
Inspecter l'application, les tokens, les motifs de composants et system.md, corriger l'implémentation, exécuter le build, le typecheck ou les tests disponibles, puis vérifier visuellement aux largeurs desktop et mobile.
- 06Proposer d'enregistrer les motifs
Après une tâche, proposer d'enregistrer la direction, la stratégie de profondeur, les décisions de hiérarchie et les motifs de composants répétés afin que les sessions suivantes restent cohérentes.