design-demo (maquette UI fictive)

Design demo (UI fictive de produit)

Chargez design-lean d'abord. Ses règles de Direction, de réalisation, ses Tokens et sa porte de composants s'appliquent ici ; cette compétence ajoute ce dont un plan produit a besoin. Le travail de démo se trouve à l'étape 5 du Build lorsqu'une page a besoin d'un aperçu produit, ou s'exécute seul lorsque la démo constitue l'ensemble du travail.

Portes pour un run de démonstration

Porte	Condition de passage	Preuve laissée	Plafond	En cas d'échec au plafond
D1 Planifier	Placement, objet focal, action, résultat et ce qui est laissé de côté écrits avant le code	Le plan	—	—
D2 Cadrer	Une image fixe à la largeur affichée et à 390 n'est pas vide, plate ou encadrée	Deux images fixes	2 recadrages	Remettre avec le défaut de cadrage nommé
D3 Répéter	L'image fixe de l'affiche est définie ; les planches-contact aux deux largeurs ne montrent aucun défaut de la liste à la fin	Planches-contact	3 cycles de film	Remettre avec les défauts restants listés
D4 Porte hôte	gate.js passe sur les propres contrôles de la page hôte, Pause comprise	Totaux de la porte	2 tentatives de correction par vérification	Signaler comme problème ouvert

Configuration (extrayez, ne retapez pas ; le répertoire de base est affiché au chargement de chaque compétence) :

mkdir -p .design && for f in "<répertoire de base design-lean>/SKILL.md" "<répertoire de base design-demo>/SKILL.md"; do python3 - "$f" <<'PY'
import re, sys
for name, code in re.findall(r"`{3}js\n// file: (\S+)\n(.*?)`{3}", open(sys.argv[1]).read(), re.S):
    open(".design/" + name, "w").write("// file: " + name + "\n" + code); print("écrit .design/" + name)
PY
done

Miniature UI produit : une interface crédible, cadrée dans son espace, sous forme d'image fixe ou d'une courte animation où il se passe une chose. Le spectateur reconnaît l'écran et voit la chose se produire. Ce sont des illustrations conçues, non de l'automatisation de navigateur : le script dessine le curseur qui appuie et change la scène. Les règles de réalisation et les Tokens de design-lean restent valables ; cette section ajoute ce dont un plan produit a besoin et remplace le Mouvement de design-lean là où ils diffèrent.

L'idée unique : cela se lit comme un vrai produit, simplifié à ce dont le spectateur a besoin, cadré avec intention, et chaque mouvement a une cause.

Cinq façons dont cela échoue :

• Trop chargé. Du vrai texte dans chaque ligne, des chiffres partout, tout est compact. Plus il y a de détails, plus cela semble généré.
• Fil de fer. Deux blobs gris et un bouton. Construit trop petit, ou dépouillé de ce qui le rendait reconnaissable.
• Encadré. Une fenêtre entière réduite dans une carte avec des marges égales : une capture d'écran collée, pas un plan produit.
• Plat. Chaque objet a le même poids dans la même carte bordée. L'œil n'a nulle part où se poser.
• Fade. Une fenêtre grise avec un curseur, quoi que dise le brief. Le look et l'énergie du brief (un plan, du verre sur de la couleur, une Dynamic Island, une mascotte) sont le sujet ; construisez ce qu'il demande, selon ces règles.

La solution : un écran complet et structuré dans des gris discrets, des vrais mots seulement là où porte l'histoire, des barres de remplissage pour le reste, de l'espace pour respirer, un recadrage qui place l'œil là où est l'histoire. Simplifiez les mots, pas le contexte. Un coin vide, un vide sous une liste, des lignes étalées pour remplir un volet, une fenêtre flottant sur un plateau : inachevé, pas calme.

À quel point forcer. Construisez-le comme une page de lancement sur laquelle vous serez jugé. Ensuite, regardez le cadre comme le ferait le designer le plus exigeant que vous connaissez, celui qui capture la seule mauvaise chose et la renvoie avec "c'est quoi ça ?" : un point décalé de son avatar, une unité sur sa propre ligne, du texte touchant une carte. Si vous pouvez imaginer cette capture, vous avez trouvé la prochaine correction.

Le kit Stageshow

Quand il est disponible, utilisez-le : des parties React (Stage, Window, Phone, Row, Bar, Text, Roll, Count, Collapse, Fly, Connector et plus, avec une API de script Act), environ 70 exemples en or et études de produits, et scripts/film.mjs, qui filme une planche-contact et signale les défauts de cadrage et de mouvement. Cherchez un dossier de compétence stageshow ou un kit/ avec stageshow.css dans le projet. Sinon, avec accès réseau, installez-le (npx skills add benjitaylor/skills --skill stageshow) ou clonez https://github.com/benjitaylor/skills et travaillez depuis stageshow/. Ensuite, son SKILL.md, references/ et l'exemple en or le plus proche sont les règles détaillées ; cette section est le résumé. L'installer exécute les scripts du package de ce dépôt, qu'un sandbox peut bloquer. Sans le kit, construisez en React simple ou HTML et CSS selon les règles ci-dessous et filmez avec le script sous Filmer sans le kit.

Exécution

La majeure partie de la qualité est décidée avant tout code. Écrivez d'abord le plan : où il se trouve, l'objet focal, l'action, le résultat, ce qui peut être laissé de côté.

1. Support et emplacement. Image fixe ou animation (boucle, une fois visible, ou au survol). La page, son fond, sa largeur. Concevez à la taille où il sera vu et montrez-le à 1:1 : environ 720 × 340 pour un héros à côté de texte, 900 à 1100 de large pour un héros pleine largeur, 400 × 300 pour une carte. Jamais en dessous d'environ 320 de large pour une démo ; une tuile bento ou une carte satellite peut être plus petite. Tout ce qui peut tenir dans une colonne de téléphone reçoit un design compact à 358 de large : une refonte (recadrage plus serré, satellite supprimé ou empilé), pas un écrasement.
2. Aspect. Avec le code ou le site du produit à portée de main, prenez ses vrais tokens, icônes, chrome et mots. Sans rien, exécutez la Direction de design-lean pour cela. Choisissez une fidélité : minimale (tout en barres), standard (des mots là où ils portent du sens, des barres ailleurs, par défaut), réaliste (contenu réel partout ; pour une échelle héros, un vrai produit nommé, ou une image fixe dont le sujet est une liste ou une page). Un brief avec un style (kawaii, papier, une couleur d'affiche) reçoit ce style en entier, toujours construit selon ces règles.
3. L'histoire. Choisissez sa forme parmi ce pour quoi le produit est valorisé : ce que l'on ressent en l'utilisant (un curseur fait une chose satisfaisante et le résultat apparaît sous sa main), un flux (quelques écrans racontés comme un objet continu, résultat sur le dernier), ou ce que le système fait (la conséquence arrive ailleurs, le lien visible, généralement pas de curseur). Trois à cinq temps et un résultat, 10 à 16 secondes. Entre une histoire plus riche et un cadre plus calme, choisissez le cadre.
4. Partez d'un exemple en or, puis cadrez-le. Avec le kit, filmez l'exemple en or le plus proche et copiez son dossier comme point de départ ; conservez sa taille de scène, son recadrage, ses tailles de ligne et de type, son espacement et ses temps, puis remplacez son apparence et son contenu par le produit du brief. Une copie qui ne change que le nom n'est pas terminée. Sans le kit, choisissez une disposition dans le tableau ci-dessous et tenez-vous-y de la même manière. Cadrez avant tout mouvement : filmez une image fixe aux deux largeurs ; si elle est plus vide, plus plate ou plus encadrée qu'elle ne devrait, corrigez d'abord le cadre.
5. L'écran. Comptez les vraies chaînes de caractères, généralement 3 à 7 : un budget pour les mots, pas pour les éléments. Ajustez le texte de chaque contrôle avant qu'il ne bouge. Mesurez ce que le curseur touche depuis le DOM ; ne codez jamais en dur les positions.
6. Chorégraphiez. Gardez ce qui apparaît monté et basculez-le pour que les sorties s'animent. Animez la relation, pas seulement l'objet : une nouvelle ligne porte les lignes en dessous ; une surface qui se redimensionne n'étire jamais son texte. Les temps se chevauchent, les groupes se décalent, le résultat tient, la boucle se termine là où elle a commencé ou se réinitialise avec une cause visible.
7. Répétez. Définissez d'abord l'image fixe de l'affiche : le temps qui raconte l'histoire tout seul, jamais pris en plein changement, le résultat laissé à l'écran. Ensuite, filmez la boucle, pas seulement une image fixe : une planche-contact à la largeur affichée et à 390, et parcourez image par image chaque pression, menu, morphose et la jointure de boucle. Une image fixe ne peut pas montrer un saut. Corrigez d'abord le plus grand défaut visible (cadrage, puis hiérarchie, puis mouvement, puis polissage) et refilmez. Plafond : trois cycles de film ; après cela, remettez avec les défauts restants listés. Demandez : sur quoi l'œil se pose-t-il en premier, et est-ce le résultat ? Une fenêtre, une tuile ou un appareil mène-t-il clairement ? Tout "non" est le plus grand défaut. Un script qui passe est nécessaire, pas suffisant. Remettez avec une courte note : l'exemple en or ou la disposition dont vous êtes parti, ce que vous avez changé, ce que vous n'avez pas vérifié.

Cadrage

• Un objet héros, au plus un ou deux satellites (un reçu, un téléphone, une carte de détail) qui portent l'idée. Gardez ce qui identifie le produit : un titre, le vrai chrome, les lignes qui donnent une raison à l'action. Le logo et la navigation sont optionnels.
• Ne recadrez que le remplissage. Le résultat, l'action, ce que le curseur touche et chaque mot réel restent entiers. Une action de remplissage que le recadrage trancherait est supprimée, pas tranchée. Un bouton, une pastille ou une ombre coupé par le bord de la scène est le défaut habituel.
• Recadrez 10 à 40 % du héros hors scène. La fenêtre ou le téléphone remplit au moins deux tiers de la largeur de la scène et dépasse d'un bord. La scène masque tout (overflow: hidden).
• La page est le fond. Sur une page blanche ou sombre, pas de plaque derrière la fenêtre et pas de fenêtre entière avec de l'air sur quatre côtés ; cela flotte. Non cadré (entier, centré, une marge égale au moins aussi profonde que l'ombre) uniquement lorsque le développeur le demande.
• Une gouttière, mesurée dans le recadrage final : chaque distance de bord correspond, une gouttière entière ou bien au-delà. La franchir de moins de 24px ou s'arrêter à quelques pixels est une erreur.
• Les satellites chevauchent le bord du héros, environ à moitié à l'extérieur, par-dessus le chrome (une barre latérale, un en-tête ou une marge), jamais par-dessus le contenu. Deux satellites sont de deux types et tailles différents (une carte et une notification en taille réelle), jamais deux cartes égales empilées. Une UI ancrée (popover, menu, toast) n'est pas un satellite : elle se trouve là où le produit la met.
• Une fenêtre conserve la forme de son appareil : entière à 1,25:1 ou plus large ; en débordement, ce qui est montré est au moins carré. Corrigez par recadrage, jamais en écrasant.
• Ce que l'histoire ouvre reste dans le cadre, à une gouttière de chaque bord sur chaque image ; placez le déclencheur pour que le recouvrement ait de la place. Pas de coins morts au repos ou n'importe où dans la boucle.
• Commencez à plat et de face. La profondeur par l'ombre, l'ordre z, l'échelle et l'opacité ; l'inclinaison seulement là où elle est justifiée (une pile de papiers en désordre), la perspective seulement lorsqu'elle est demandée.
• Téléphones : un téléphone satellite commence à 40 % de la largeur visible de la fenêtre et au moins 220px ; laissez-le dépasser du bas plutôt que de le rétrécir. Les notifications restent aux proportions réelles d'iOS et ne sont jamais coupées. Un téléphone recadré en haut perd sa barre d'état et sa barre de navigation ensemble. Ne dessinez jamais de barre d'état ou d'indicateur d'accueil à la main ; prenez le cadre du kit ou d'une référence réelle.

Disposition	Héros	Utilisation pour
Épinglé, débordement bas	Inset 8–12 % gauche, droite et haut ; 15–35 % au-delà du bas	Cartes de fonctionnalités et tuiles bento
Débordement de coin	Inset 10 % haut et gauche ; 15–35 % au-delà de droite et bas ; satellite sur le bord gauche ou bas	Héros à côté de texte
Scène avec gouttières	Inset 8–20 % de chaque côté sur une scène colorée, hors bas	Moments de marque
Focus satellite	Héros fortement recadré ; un grand satellite (30–40 % de la largeur du héros) porte l'histoire	Une petite chose : une notification, un reçu, une diff
Héros large	Une fenêtre de 900–1100px à 1:1, hors bas ; fidélité réaliste	Héros de page d'accueil en pleine largeur
Paire d'appareils	Desktop 75–80 % de large, hors bas ; téléphone chevauchant le bord droit, un tiers à l'extérieur	Histoires multi-appareils
Beaucoup d'un	Une grille d'une chose hors de chaque bord ; une tuile au point par la profondeur, la seule avec des mots	Échelle montrée par répétition
Recadrage fondu	Fenêtre inset haut et côtés, masquée sur son dernier tiers, remplissage seulement sous le fondu	Quand un bord couperait la fenêtre à une ligne arbitraire
Gros plan	La fenêtre entière à 1.3–1.6x, chrome compris, la ligne de sujet entière	Une carte à propos d'un contrôle
Panneau sur produit	Un panneau de réglages sur la marge du produit, un leader neutre vers ce qu'il a changé	Un réglage et son effet
Coins opposés	Texte en bas à gauche ; le produit suspendu au coin supérieur droit	Tuiles bento avec une ligne de texte

Une grille bento est un ensemble : une tuile héros, puis une fenêtre, une stat, un objet et un diagramme, chacun d'un type différent ; planifiez la grille avant toute tuile.

L'image fixe

• Retenue. Des chaînes réelles sur le titre, la chose sur laquelle on agit, ce qui est tapé, le résultat ; le reste est des barres. Les barres sont du remplissage sur les bords ; les barres là où l'œil se pose paraissent inachevées. Là où l'histoire touche une liste, deux ou trois lignes réelles. Dans une petite surface, une ligne est une ligne : avatar, nom, valeur. Les largeurs de remplissage varient d'une ligne à l'autre (60, 45, 70, 52). L'étiquette et la valeur correspondent : tous deux des mots ou tous deux des barres. Un nombre peut être grand. Dites le signal de la fonctionnalité une fois, pas dans l'en-tête, le satellite et chaque ligne.
• Gardez le contenu signature du domaine : pochettes d'album, miniatures, avatars (chaque avatar nommé a sa propre couleur). Échangé, c'est une liste générique.
• Pas de titre pour un nom fictif et pas de nom de produit à l'écran à moins que le brief ne s'appuie dessus et que le vrai produit ne le montrerait là. Le titre d'une fausse app est un div, jamais h1 à h6 : la démo vit à l'intérieur du plan de page de quelqu'un d'autre.
• Typographie : tailles UI réelles de 11 à 15px, mises à l'échelle par la scène, jamais 7px. Hauteur de ligne du petit texte au moins 1,3. Monospace seulement pour le code, les identifiants et les nombres alignés.
• Espacement : les mots gardent un inset de 12px de tout bord de fenêtre, carte, panneau ou ligne survolée (jamais en dessous de 8) ; les barres peuvent déborder, les mots non. Rembourrage de ligne 12px, 8 pour une liste dense. Un titre au-dessus de son sous-titre est espacé de 4 à 6px. Un bouton garde 8px ou plus du champ au-dessus. Pas de quasi-tangentes : les bords à 1 à 3px de distance se lisent comme des accidents ; alignez exactement ou séparez d'au moins 8.
• Centrage optique : centrez une étiquette sur ses lettres (text-box: trim-both cap alphabetic) dans les pilules, boutons et avatars. Un montant centré centre ses chiffres, avec le signe de la devise accroché à l'extérieur à right: 100%.
• Les icônes viennent d'un ensemble, jamais de votre main : d'abord le propre pack du produit, sinon un ensemble choisi avec intention (style SF pour le chrome Apple, Material Symbols pour Android, sinon Phosphor, Iconoir, Radix, Tabler, Heroicons ou Lucide), une taille (14–16px) et un trait par scène, rempli à 14px et en dessous. Les emojis sont du contenu, jamais des icônes. Les logos d'autres produits sont leurs vraies marques dans leurs proportions d'origine, jamais une imitation.
• Fonctionnalités AI : pas d'étincelle, de baguette ou d'étoile et pas de violet comme couleur AI ; montrez ce que l'IA fait (la question envoyée, la réflexion, la réponse qui arrive en continu avec sa hauteur, les sources à la fin). La propre icône du produit est acceptable même si c'est une étincelle.
• N'inventez pas de composants. Utilisez les parties du kit (Row, Bar, Text, etc.) ou construisez en HTML/CSS simple selon ces règles. Un composant inventé (une barre de recherche personnalisée, un menu déroulant fait maison) attire l'attention sur l'invention, pas sur le produit.

Animation

• Un geste par scène : ce que le curseur fait (appuyer, glisser, taper), la réaction du système (un volet qui apparaît, un nombre qui change, une ligne qui se déplace), le résultat. Pas de deuxième geste avant que le premier ne soit terminé.
• Le curseur est assez grand pour être vu (32–40px), ne bouge que pour agir, reste immobile ou disparaît pendant les résultats, et revient si le geste suivant nécessite une nouvelle position. Son apparence correspond à l'OS (noir sur contenu clair, blanc sur contenu sombre, avec ou sans remplissage selon la plateforme).
• Les animations durent 200 à 400ms pour une réaction, 300 à 600ms pour une transition, 600 à 1200ms pour un résultat qui s'installe. Aucune animation en dessous de 100ms n'est perceptible. Utilisez cubic-bezier(.32,.72,0,1) (rapide au début, lent à la fin) pour les entrées, cubic-bezier(.5,0,.82,.5) (lent au début, rapide à la fin) pour les sorties.
• Boucle : la dernière image revient à la première en 400–800ms, avec le curseur qui revient à sa position de départ si nécessaire. Une boucle qui saute ou scintille est un défaut.

Filmer sans le kit

# Prenez le script de film du dépôt stageshow ou écrivez le vôtre :
# Il doit capturer la scène aux deux largeurs, produire une planche-contact, et signaler les défauts de cadrage et de mouvement.
# Utilisez Puppeteer ou Playwright pour le rendu et puppeteer-screenshot ou sharp pour la planche-contact.
node scripts/film.mjs --width 720 --width 390 --output contact-sheet.png

Le script vérifie :

• Défauts de cadrage : bords vides, objets coupés, texte tronqué, espacement inégal, objet héros trop petit (< 50 % de la scène).
• Défauts de mouvement : images vides, images identiques (pas d'animation), sauts de boucle, scintillement.

Références et exemples

• Dépôt : https://github.com/benjitaylor/skills
• Dossier du kit : stageshow/
• Exemples en or : stageshow/references/gold/ (contient ~70 études de produits et dispositions)
• Exemples de défauts : stageshow/references/flaws/ (montre les cinq modes d'échec)

Commandes rapides

# Installer le kit
npx skills add benjitaylor/skills --skill stageshow

# Copier un exemple en or pour démarrer
cp -r stageshow/references/gold/hero-copy .design/demo-hero && cd .design/demo-hero

# Filmer la scène
node ../../stageshow/scripts/film.mjs --width 1100 --width 390 --output contact.png

# Vérifier avec gate.js
node ../../stageshow/scripts/gate.js --page index.html --controls pause

Notes finales

• Travaillez toujours à partir d'un exemple en or lorsque le kit est disponible. Cela garantit que le cadrage, l'espacement et les temps sont corrects dès le départ.
• Testez aux deux largeurs (affichée et 390) à chaque itération. Une démo qui a fière allure sur un écran large mais casse sur mobile est inacceptable.
• Le résultat est la priorité. L'utilisateur doit comprendre ce que fait le produit en une seconde. Si ce n'est pas clair, refaites le cadrage et la disposition avant de toucher aux animations.
• Restez simple. Un écran bien cadré avec trois mots et une barre vaut mieux qu'un écran surchargé avec dix mots et cinq éléments. La retenue est la marque d'une démo professionnelle.