Communitygithub.com

design-lean

Utilisez cette compétence à la place de la compétence de conception intégrée pour créer, peaufiner (dé-slopifier) ou revoir des interfaces UI : pages d'atterrissage, sites, tableaux de bord, écrans d'application. Mêmes règles de conception, exécutées en tant que workflow avec un script de contrôle plus rapide. L'UI de produit factice va vers design-demo.

Qu'est-ce que design-lean ?

La compétence `design-lean` est une version optimisée de la compétence de conception par défaut, conçue pour les plateformes d'agents d'IA comme Claude Code, Cursor ou Codex. Elle remplace la compétence intégrée pour la création, le polissage et la révision d'interfaces utilisateur (UI). Son objectif principal est d'éliminer le 'slop' (contenu générique, médiocre ou non intentionnel) en forçant des décisions de conception explicites et en les vérifiant via un processus de validation en plusieurs étapes (gates). Cela inclut une direction de conception, un fichier de décisions, des règles de conception strictes (typographie, espacement, couleur, etc.) et une validation automatisée via un script `gate.js`. La compétence s'utilise selon trois modes : **Build** (pour la création de nouvelles UI, avec des garde-fous), **Polish** (pour peaufiner des UI existantes sans changer la structure) et **Review** (pour fournir uniquement des retours). Elle évite les designs génériques en rejetant les 'clusters de design par défaut' et en ancrant chaque décision dans un fichier de décisions (`decisions.md`) et une direction de conception unique. Le workflow est conçu pour que l'agent d'IA prenne des décisions de conception intentionnelles, documentées et vérifiables, produisant ainsi des interfaces uniques, pertinentes et de haute qualité, loin des templates standards générés par les modèles.

Compatible avec✓Claude Code~Codex CLI✓Cursor
npx skills add https://github.com/Techychris/claude-design-skills/tree/main/design-lean

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Conception (lean)

Travail d'interface en trois modes, exécutés comme une séquence de portes (gates). Chaque porte a une condition de passage, la preuve qu'elle laisse, un plafond de tentatives et ce qui se passe en cas d'échec. L'UI de produit factice (démos de héros, tuiles bento, visites guidées du curseur) relève de la compétence design-demo, qui charge celle-ci pour ses règles.

Pourquoi cette compétence existe. L'UI par défaut d'un modèle est la moyenne de toutes les UI qu'il a vues : titre centré avec un label au-dessus, une rangée de cartes icônes, des dégradés doux, un seul rayon et une seule ombre grise sur tout. L'intention réside dans le texte, mais la génération de code puise dans des motifs, donc écrire "chaleureux et spécifique" produit encore le template. Chaque choix remonte donc à une décision écrite et est vérifié. Si un autre modèle, avec une consigne similaire, produisait essentiellement le même écran, le travail a échoué. Supprimer le slop est la moitié du travail ; un écran propre qui pourrait appartenir à n'importe quel produit est le prochain template.

Ce qui a préséance sur cette compétence. (1) Une marque réelle, un cahier des charges écrit ou une direction visuelle nommée : suivez-la exactement, même si elle demande quelque chose que cette compétence qualifie de défaut ; listez chaque conflit dans le rapport avec la modification d'une ligne qui appliquerait la règle. Un dégradé violet-bleu, des étincelles ou une lueur comptent comme du slop, même dans un logo, à moins que l'utilisateur ne dise qu'ils font partie de la marque. (2) .design/system.md (ou l'ancien .interface-design/system.md) : lisez-le d'abord ; ces décisions sont prises ; signalez les dérives. (3) Cette compétence, pour tout ce qui reste ouvert.


Workflow

G0 Route

Demandez dans l'ordre ; le premier oui décide.

  1. Uniquement des constats, aucun changement ? → Vérification
  2. UI de produit factice comme illustration ? → charger design-demo
  3. UI existante dont les fonctionnalités, le contenu et l'ordre des sections doivent rester ? → Polissage
  4. Tout le reste, y compris une refonte qui peut changer le contenu ou la structure → Construction

Surface : page (lue et défilée : page d'atterrissage, marketing, portfolio, événement, site d'organisation ; s'appuie sur le héros, le texte, l'imagerie, le rythme des sections) ou écran d'application (travaillé : tableau de bord, admin, paramètres, tableaux, boîte de réception, outils ; s'appuie sur la hiérarchie, la densité, les états, les tokens). Un site produit qui montre son application est une page ; les fragments d'application sur ce site suivent les règles des écrans d'application.

Registre des portes

PorteCondition de passagePreuve laisséeLimiteEn cas d'échec à la limite
G1 DirectionLe test sans nom passe ; la personne confirme, ou une règle de saut s'appliqueBloc Direction2 tours d'explorationPrendre l'option la plus forte, la marquer comme hypothèse dans le rapport
G2 Révision du planChaque endroit où une consigne similaire aboutirait au même est révisé ; .design/decisions.md écritdecisions.md1 révisionProcéder ; lister les défauts restants dans le rapport
G3 Composantgate.js --only <nom> passe à 1440 et 390, et le composant suit decisions.md ou enregistre une exceptionUne ligne dans le journal de porte2 tentatives de correction par vérificationEnregistrer comme problème ouvert avec sa cause ; continuer seulement si rien d'autre n'en dépend
G4 PageL'exécution complète de gate.js passe ; les quatre tests et la liste de contrôle de jugement passentTotaux de la porte, captures d'écran desktop et mobile3 cycles de renduSignaler ce qui échoue encore
G5 RapportChaque champ du modèle de rapport est rempli ou marqué comme aucunLe rapport——
R1 Constats (Vérification)Chaque constat a un critère, un emplacement, une sévérité et une correction concrèteListe de constats—Supprimer les constats sans preuve

La Construction exécute G1–G5. Le Polissage exécute G1, puis G4 et G5 : ses passages traversent tout l'écran, donc il ne vérifie qu'une fois à la fin au lieu de par composant. La Vérification exécute G0 et R1.

Règles de saut pour l'attente G1 : la personne a dit de simplement le faire ; une marque ou un cahier des charges fixe déjà la direction ; un seul petit composant à l'intérieur d'un design existant.

Exécutions sans surveillance. Lorsque personne n'est là pour répondre (exécution planifiée, la personne a dit qu'elle reviendrait, ou une question est restée sans réponse), n'attendez pas à G1. Prenez la direction, énoncez-la en haut du rapport comme une hypothèse avec la ligne qui la changerait, et continuez. Ignorez la génération d'images payante et utilisez l'option suivante dans Visuels. Une exécution de Polissage qui ne trouve aucun slop signale ses améliorations suggérées sans les appliquer. Une redirection ultérieure devrait coûter un message.

En Construction, un seul composant en cours à la fois. Contrôlez-le, enregistrez-le, puis commencez le suivant. Un échec est corrigé maintenant, pas collecté pour la fin : les problèmes s'accumulent.


Direction

Intention

Répondez avant toute décision visuelle ; gardez-la comme un brief concis.

  • Qui est cet humain ? La personne réelle : où elle est, ce qu'elle faisait il y a cinq minutes, ce qu'elle fera ensuite.
  • Que doit-elle accomplir ? Le verbe : noter ces soumissions, trouver le déploiement défaillant. Cela décide ce qui mène, ce qui suit, ce qui se cache.
  • Comment cela devrait-il se ressentir ? Des mots qui ont du sens : chaleureux comme un carnet, froid comme un terminal, dense comme une salle des marchés. "Propre et moderne" ne signifie rien.

Si le brief ne nomme pas le sujet, proposez un sujet concret, un public cible et une tâche principale, et confirmez ; si le contexte permet une hypothèse responsable, énoncez-la en une ligne et procédez. L'intention est systémique : si la sensation est chaleureuse, les surfaces, le texte, les bordures, les accents et la typographie sont tous chaleureux. "C'est courant" ou "ça marche" n'est pas une raison.

Exploration du domaine

Produisez les quatre éléments : domaine (5+ concepts et métaphores du monde du sujet) ; monde de couleurs (5+ couleurs de sa version physique) ; signature (un seul élément que seul ce produit pourrait avoir, utilisé de manière cohérente là où il convient) ; défauts à rejeter (les trois choix évidents, chacun avec son alternative). Test sans nom : lisez la proposition en supprimant le nom du produit ; si personne ne peut dire à quoi ça sert, explorez à nouveau (limite : 2 tours).

Bloc Direction

Produit :    [ce qu'il fait, pour qui, une phrase]
Caractère :  [2-3 mots concrets, pas propre/moderne/élégant/minimal/premium]
Monde :      [lieu ou matériau auquel il appartient ; définit la teinte neutre, l'accent, les visuels]
Moments :    [1-2 endroits qui reçoivent une couleur riche et des détails, choisis dans le contenu]
Signature :  [le seul détail que seul ce produit a]
Rejeté :     [défaut → alternative] × 3

Présentez-le avec un petit spécimen lorsque le rendu est disponible (vrais échantillons de couleur, l'échelle typographique dans la vraie police, la signature en tant que vrai composant), puis demandez "Cette direction vous semble-t-elle correcte ?" (G1).

Regroupements de design par défaut autour desquels la génération gravite. Chacun est légitime pour certains briefs mais apparaît indépendamment du sujet ; là où le brief laisse un axe libre, ne le dépensez pas ici : (1) crème chaud proche de #F4F1EA avec un sérif à fort contraste et un accent terre cuite proche de #D97757 ; (2) presque noir avec un accent vert acide ou vermillon ; (3) filets de journal, rayon zéro, colonnes denses de journal ; (4) le kit de cartes SaaS : cartes arrondies identiques, un rayon, la même ombre grise douce, lavis dégradés ; (5) chrome de template : étiquettes en capitales espacées, chaînes méta A · B · C, étiquettes MOT — fragment, presque noir teinté pour le noir, étiquettes de données monospace, → sur les boutons, accents violets ou indigo.

Fichier de décisions

Après la direction, écrivez .design/decisions.md une fois : les jetons de palette et pourquoi, les polices et l'échelle et pourquoi, la stratégie de profondeur et pourquoi, la base d'espacement et la densité et pourquoi, la signature et où elle apparaît, les trois défauts rejetés. Cela remplace la re-justification de chaque composant. À G3, la question de jugement est une ligne : ce composant suit-il decisions.md ? S'il s'en écarte, enregistrez l'exception et sa raison dans la ligne du journal de porte.


Règles de conception

Les règles marquées (vérifié) sont mesurées par gate.js ; la liste de contrôle G4 ne couvre que le reste.

Hiérarchie et composition

  • Un point focal par vue : nommez ce pour quoi la personne est venue et faites-le gagner par la taille, le contraste, la position ou l'espace.
  • Le poids et la couleur font plus que la taille. Une même taille de 14 px contient trois niveaux : valeur 600 primaire, étiquette 500 secondaire, méta 400 atténué.
  • La densité est une décision en pixels, choisie au départ et répétée : les panneaux d'outils avec un padding de 12 à 16 semblent serrés ; 24 semble être un dépliant.
  • Respirez de manière inégale : serré à l'intérieur d'un groupe, plus lâche entre les groupes.
  • Les proportions parlent : une barre latérale de 280 px signifie que la navigation sert le contenu ; 360 signifie qu'ils sont égaux.
  • Retenue : environ 60/30/10 neutre, ton secondaire, accent. Dépensez l'audace à un endroit, puis supprimez un accessoire.

Espacement

  • Chaque marge, padding, écart et hauteur fixe est un multiple de 4 (vérifié) ; un léger décalage de 2 px à l'intérieur de petits contrôles est acceptable.
  • Les choses égales sont égales : une hauteur de ligne et un écart par liste, un padding par ensemble de cartes ; un padding symétrique sauf si le contenu l'exige.
  • Les choses s'alignent : les icônes dans une colonne, les étiquettes sur une seule ligne de base, les nombres alignés à droite.
  • Pages : sections espacées de 80 à 128 sur desktop, nettement plus que tout écart à l'intérieur d'une section. Applications : padding de page 24-32.

Couleur

  • Une rampe neutre teintée vers le monde pour les fonds, surfaces, bordures et texte ; une teinte sur les surfaces, ne changeant que la luminosité. Dans les applications, les surfaces restent proches du neutre et le contenu porte la couleur.
  • Quatre rôles de texte : primaire, secondaire, atténué, désactivé.
  • Un accent dans le chrome, utilisé rarement : l'action primaire, la sélection, le seul nombre qui compte. Dans les moments choisis, la couleur peut être riche si chaque couleur signifie quelque chose. Une vraie couleur de marque devient l'accent et quitte les surfaces.
  • Contraste 4,5:1 pour le texte du corps et l'accent avec le texte, 3:1 pour les grands textes (vérifié).
  • Les couleurs sémantiques portent un sens uniquement, ton sur la palette, légèrement désaturées sur fond sombre. Le texte courant en encre pleine.
  • Les couleurs proviennent de jetons, jamais de valeurs brutes dans le CSS des composants (vérifié).
  • Pas de dégradés de teinte à teinte sur les surfaces, texte dégradé, lueurs ou ombres colorées, lavis radiaux, taches ou bordures néon. Un dégradé n'est autorisé que comme un changement de ton au sein d'un même neutre, ou un écran neutre sous du texte sur une photo.

Surfaces, bordures et profondeur

  • Une seule stratégie de profondeur : bordures uniquement (technique, dense), ombres subtiles (accessible), ombres superposées (premium), ou décalages de tons de surface.
  • L'élévation est discrète. Sombre : chaque étape de quelques points de luminosité (page → carte → surélevé) plus des filets. Clair : repos 0 0 0 1px rgba(0,0,0,.06), 0 1px 2px rgba(0,0,0,.05), flottant 0 8px 24px rgba(0,0,0,.06). Élévation sombre : 0 0 0 1px rgba(255,255,255,.08).
  • Filets : couleur de texte primaire à 6-10% d'opacité (12% sur fond sombre), dans une petite progression : séparateur, standard, accent, anneau de focus.
  • Barre latérale : identique à la page ou un pas plus profond sur fond sombre, séparée par un filet, jamais une teinte différente. Popups un niveau au-dessus de leur parent. Entrées légèrement plus sombres que leur environnement.

Typographie

  • La typographie porte la personnalité. Une famille est normale, deux est la limite et clairement distincte ; une police d'affichage uniquement pour les grands titres. Une vraie police de marque reste.
  • Choisissez un rapport : environ 1,2 pour une UI dense, 1,25 pour la plupart des UI de produit, 1,333 pour les pages expressives. Cinq tailles par page au maximum.
  • Poids 400 et 500 ; 600 pour les chiffres et les rares emphases ; 700-900 uniquement si un cahier des charges de marque le dit.
  • Casse de phrase partout ; pas d'étiquettes en capitales espacées, pas d'emphase en italique, pas de mot de titre unique mis à part par l'italique, le gras ou la couleur.
  • Espacement des lettres 0 en dessous de 16 px, environ -0,02 em à partir de 40 px, -0,03 em à partir de 56 px. Hauteur de ligne du corps environ 1,5, corps sérif légèrement plus. Longueur de ligne 45-75 caractères.
  • Nombres : chiffres tabulaires (vérifié), un format partout.
  • text-wrap: balance sur les titres, pretty sur le corps ; -webkit-font-smoothing: antialiased sur la racine.

Icônes

Les emojis utilisés comme icônes ou décoration deviennent des icônes linéaires d'un seul ensemble (celui du projet, sinon lucide), 16 ou 18 px, trait 1.5, dans la couleur de leur rôle de texte, même largeur de boîte par ligne, 8-10 px de l'étiquette. Supprimez les icônes qui n'ajoutent rien ; une catégorie qui a besoin de couleur reçoit un point de statut.

Texte

  • Écrivez du côté de la personne (ils gèrent les notifications, pas la configuration du webhook) ; décrivez, ne vendez pas.
  • Les titres disent ce que le produit fait pour qui, en utilisant les faits de la page. Si le nom d'un concurrent s'adapte encore, réécrivez.
  • Les boutons disent ce qui se passe ("Enregistrer les modifications") ; une action conserve son nom tout au long du flux ("Publier" → "Publié").
  • Les erreurs disent ce qui s'est passé et comment la corriger, sans s'excuser. Les états vides invitent à l'action suivante.
  • Voix active, verbes simples ; pas de points d'exclamation, de titres d'accroche, de mots d'engouement (surpuissant, fluide, déverrouiller, magique, révolutionnaire) ou Alimenté par l'IA partout. Des étiquettes courtes (Recherche). Un changement nomme sa comparaison (+12% vs mois dernier). Pas de point final sur les titres, étiquettes, boutons ou toasts.
  • N'inventez jamais de preuve : pas de clients, citations, avis, logos ou statistiques. Un contenu d'exemple là où le brief laisse des lacunes est acceptable et va dans le rapport pour confirmation.

La structure signifie quelque chose

Les contours, bordures, numérotation, surlignes et séparateurs encodent l'information. 01 / 02 / 03 uniquement pour une séquence réelle. Les badges comme PRO, Nouveau ✨ disparaissent à moins qu'ils ne portent du sens, puis deviennent du texte discret. Les compteurs et les méta sont du texte discret, pas des pilules.

Mise en page : pages

  • Le héros s'ouvre avec la chose la plus caractéristique du monde du sujet, sous sa forme la plus appropriée. Un grand nombre avec une petite étiquette et un dégradé uniquement si c'est vraiment le meilleur.
  • Le premier écran répond à la première question du visiteur en gros caractères, porte le h1, une action principale et au plus une secondaire.
  • Les héros les plus forts : une image de scène bord à bord avec le titre sur sa partie calme, ou une division asymétrique avec le visuel au moins à moitié. Des piles centrées uniquement pour les héros courts sans visuel.
  • Navigation : logo, les liens existants, un bouton ; connexion en tant que lien texte. Pas de pilules flottantes ou de verre.
  • Chaque section : un titre, une composition différente de ses voisines, son contenu complet. Pas de bandes mortes. Le pied de page est une fermeture conçue, pas un plan du site.
  • Petits écrans : empilez dans l'ordre de lecture et recomposez ; pas de texte en dessous de 11 px ; pas de défilement horizontal (vérifié).

Mise en page : écrans d'application

  • Proportions réelles : le shell remplit la fenêtre d'affichage, barre latérale 240-280, contenu fluide et plafonné près de 1440-1600, barre supérieure 56-64. Jamais une colonne étroite centrée.
  • Variez les tailles : statistiques compactes au-dessus d'un graphique large, jamais une rangée de cartes identiques. Le graphique principal prend au moins les deux tiers de la largeur et 280-360 de hauteur.
  • Cartes de statistiques : étiquette, chiffre, changement avec sa comparaison ; pas de sparklines ou icônes de remplissage ; pas de chiffre répété ailleurs.
  • Choisissez t

… (tronqué pour la traduction)

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

Skills associés