Communitygithub.com

halftone-ch/drawn-ui

Dessine des illustrations calmes de l'interface d'un produit réel (cartes blanches, texte sous forme de barres, une partie surélevée, teintée dans la couleur du produit, fond transparent) pour des études de cas, pages d'accueil, README, diapositives ou documentation.

Qu'est-ce que drawn-ui ?

Cette compétence (skill) génère des dessins d'interface utilisateur simplifiés et élégants, à partir des écrans réels d'un produit. Contrairement à une capture d'écran qui semble collée, le dessin stylisé évoque le travail d'un designer, protège la vie privée (le texte est remplacé par des barres) et s'adapte au thème sombre ou clair. Le processus est strict : lecture du produit réel, sélection des moments clés, extraction de la teinte principale, spécification dans un fichier JSON, puis génération d'un SVG via un script Python et Playwright. Le résultat final est un fichier SVG autonome, accessible, et prêt à être intégré dans une documentation, un site vitrine ou un cas d'usage.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/halftone-ch/drawn-ui/tree/HEAD/skills/drawn-ui

Demander à votre IA préférée

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

Documentation

Drawn UI

Un écran dessiné représente un produit tel qu'un designer le croquerait pour une étude de cas : l'interface réelle, simplifiée jusqu'à ne laisser que sa structure, teintée dans la propre couleur du produit. On y lit un travail de conception là où une capture d'écran semble plaquée, et il ne montre jamais de données privées, car tout texte est remplacé par des barres.

L'aspect reste calme car les règles sont peu nombreuses et strictes. Chaque projet reste lui-même, car la teinte, les écrans et la partie surélevée proviennent du projet. L'endroit où les dessins vont (une héroïne, une grille, une liste de fonctionnalités, une diapositive) dépend de celui qui les utilise.

Travailler dans cet ordre

  1. Lire le produit réel. Ses écrans actuels, depuis le code, l'application ou le fichier de design. Chaque dessin provient d'un écran ou d'un composant réel. N'inventez jamais une métaphore (balances flottantes, portes, flèches entre les cartes) : si le produit ne l'a pas, le dessin ne le montre pas.
  2. Choisir les moments. À quoi sert chaque dessin : un écran, un composant, un état. Un ensemble montre différents composants, pas un seul composant avec plus de détails à chaque fois.
  3. Prendre l'accent. La propre teinte ou couleur de marque du produit. scripts/tint.py "#hex" montre les tons qu'elle donne. Plus d'accents uniquement s'ils signifient quelque chose dans le produit (couleurs de statut, une paire de marque).
  4. Écrire le cahier des charges. drawings.json, format dans references/spec.md (lisez ses sections sur les tailles, le soulèvement et les tons avant de dessiner), avec l'exemple dans examples/ledger/drawings.json à côté. Dimensionnez chaque dessin pour l'espace qu'il va remplir.
  5. Dessiner et vérifier. python3 scripts/draw.py drawings.json --shots (la capture d'écran nécessite Playwright avec Chromium). Corrigez chaque problème qu'il imprime, puis ouvrez out/shots/sheet.png et regardez. Les chiffres signalent, les yeux décident : coins vides à l'intérieur d'une carte, dessin qui penche d'un côté, une pile qui ressemble à des pilules. Répétez jusqu'à ce qu'il réussisse et paraisse calme.

Les règles

  1. Un dessin ne contient aucun mot. Tout texte devient des barres : hauteurs 12, 8, 6 ou 4, largeurs par pas de 4, complètement arrondies.
  2. Cartes blanches, un rayon par rôle (cartes 12, boîtes intérieures 8, lignes 4, téléphones 32), une ombre de carte, une ombre de soulèvement.
  3. Une partie par dessin peut se soulever de sa carte : elle ne part que d'un seul côté, de 16 à 72 (24 à 40 rend le mieux), jamais au-delà du haut ou du bas de la carte, avec 8 ou plus autour d'elle. Un dessin de 600 ou plus peut en soulever deux. La partie soulevée remplace ce qu'elle soulève, elle ne le recouvre pas à moitié.
  4. Un accent par dessin, utilisé sur la chose qui compte dans cet écran.
  5. Au plus un glyphe de ligne par dessin, tracé à 1.5 avec des extrémités rondes.
  6. Pas de fond par défaut : le dessin vient avec juste assez de place pour ses ombres et repose sur la page où il est placé. Avec "ground": true, il obtient un fond teinté, qu'il remplit à 65 à 75 pour cent en largeur et hauteur, centré.
  7. Tout à 1:1 sur une grille de 4. Les dessins d'un même ensemble qui côte à côte partagent une échelle : dessinez-les à la taille à laquelle ils sont montrés, et faites correspondre les hauteurs lorsqu'ils sont en ligne.
  8. Les téléphones sont de 1 à 2.05.

Utiliser la sortie

Les fichiers out/<id>.svg sont autonomes, portent leur propre largeur et hauteur, et s'adaptent à la page : clairs sur fond blanc, sombres sur fond noir. Ils suivent le réglage système du lecteur, et une classe dark ou light (ou data-theme) sur un parent en force un. Ils sont aria-hidden, avec des identifiants espacés par dessin, afin que plusieurs puissent être placés en ligne sur une même page. Les formes portent des classes de rôle (p-ground, p-card, p-bar, p-dot, p-glyph, p-hi pour la partie soulevée) pour un mouvement au survol ; out/index.html montre un exemple calme avec une réponse Reduce Motion. Un dessin trop large pour un téléphone reçoit un deuxième dessin plus étroit ; ne le compressez jamais.

Concevoir dans Figma à la place : les mêmes règles s'appliquent, et les valeurs du cahier des charges correspondent une à une aux cadres (mise en page automatique pour les cartes, position absolue uniquement pour la partie soulevée). Exportez chaque fond en SVG.

Quand les règles entrent en conflit avec le produit

Un produit sans accent unique peut utiliser son neutre le plus foncé. Un écran qui n'a de sens qu'avec deux points forts peut être deux dessins. Pliez une règle à la fois et dites laquelle.

Skills associés