MonoKelvin/mono-ui-prototype

Conception de prototypes UI haute qualité

1. Objectif principal

Tout faire pour obtenir des interfaces produit esthétiques, tout en garantissant leur facilité d'utilisation.

Le livrable doit ressembler à un véritable produit réalisé par un designer expérimenté, et non à un prototype générique utilisant des modèles, des cartes empilées ou une simple palette de couleurs différente. L'accent est mis sur l'identité globale, la hiérarchie visuelle, le rendu typographique, la composition, les relations de couleurs, le langage graphique, les animations et le niveau de détail.

• Priorité à l'esthétique, mais sans sacrifier la convivialité : Le visuel et la fonctionnalité sont conçus ensemble ; on ne supprime pas des fonctionnalités pour gagner en simplicité de façade.
• Le style est dicté par le produit : Les approches sobres, raffinées, vivantes, avant-gardistes, somptueuses ou expérimentales sont autorisées. Le « minimalisme haut de gamme » n'est pas la seule solution acceptable.
• Conception audacieuse et autonome : N'attendez pas que l'utilisateur fournisse les couleurs, les polices, la mise en page et les paramètres d'animation. Comprenez les besoins et explorez proactivement la meilleure solution.
• Refuser l'aspect « template » : N'utilisez pas par défaut les mises en page SaaS courantes, les palettes de couleurs fixes, les cartes uniformes et les combinaisons de composants génériques.
• Déduction indépendante : Même pour des catégories de produits similaires, le design doit avoir sa propre expression en fonction du contenu et du positionnement. Ne réutilisez pas mécaniquement la solution visuelle du projet précédent.

Principes de référence pour le design

Les décisions de design peuvent s'appuyer sur les principes éprouvés suivants, mais ne les recopiez pas sous forme d'exemples ou de paramètres fixes :

• Hiérarchie visuelle, proportions, équilibre, contraste, Gestalt et point focal.
• Grille, composition, rythme, espace blanc, cohérence et identité de marque.
• Cohérence, découvrabilité, divulgation progressive, feedback et accessibilité.
• Personnalité typographique, qualité des glyphes, contexte de lecture et associations de polices.
• Continuité du mouvement, accélération/décélération naturelles, relations spatiales et retour d'interaction.

Références : NNGroup Principes de conception visuelle · Figma Principes de conception UI · IBM Design Language · Apple HIG Motion

Ne pas réutiliser les pages existantes

• Pour une nouvelle page, ne lisez pas, ne capturez pas, n'analysez pas les pages existantes dans le répertoire ui/, et ne copiez pas leur code HTML/CSS/JS comme point de départ.
• Ne réutilisez pas les couleurs, polices, squelettes de mise en page, combinaisons de composants et paramètres d'animation de la session précédente. Les différences de conception ne doivent pas se limiter à un changement de couleur, de texte ou d'image ; il faut repenser la structure de l'information et l'expression visuelle.
• Seules les lectures de cette compétence, de skills/ui-metadata/SKILL.md, des instructions d'utilisation de tools/ et des références fournies par l'utilisateur pour cette session sont autorisées.
• Lorsque l'utilisateur demande explicitement de modifier une page existante, ne lisez que cette page.

2. Comprendre d'abord le produit, puis décider du design

Déterminez d'abord le positionnement du produit, les utilisateurs cibles, les scénarios d'utilisation, les caractéristiques du contenu et la personnalité de la marque, puis décidez de l'orientation visuelle. Ne considérez pas les catégories ci-dessous comme des modèles, ce ne sont que des pistes de conception :

Personnalité du produit	Expressions de conception à explorer
International / Marque anglophone	Texte concis, polices expressives, typographie à grande échelle, espacement des lettres et blancs, photographie et symboles
Tendance / Créatif / Jeune	Composition audacieuse, forte personnalité typographique, icônes et symboles, formes géométriques, chiffres visualisés et relations de couleurs flexibles
Outil professionnel / Logiciel de bureau	Organisation claire de l'information, polices soignées, densité d'information confortable, feedback d'état subtil et couleurs sobres
Technologie / IA / Produit de données	Polices modernes, visualisation de données, graphiques structurels, feedback dynamique et identité technologique reconnaissable
Culture / Art / Marque de contenu	Mise en page éditoriale, polices avec empattement ou polices de caractères, photographie, effets de matière, espace blanc et couleurs évocatrices
Consommation haut de gamme / Style de vie	Polices raffinées, imagerie produit, matière et lumière/ombre, texture détaillée et expression de marque sobre mais distincte

Vous pouvez combiner différentes directions ou proposer une direction originale plus adaptée au produit actuel. N'appliquez pas mécaniquement un nom de style.

Conteneur de livraison

Type	Critère de décision	Cadre et défilement	Limites du canevas
A Logiciel	Back-office, outil, tableau de bord	Affichage fenêtre complète ; défilement local pour longues listes et longs textes	Verrouillé dans la fenêtre ; les calques ne dépassent pas
B Page Web	Marque, page d'atterrissage, site de contenu, portfolio	Flux de document naturel ; défilement vertical sur toute la page	La fenêtre d'affichage est le canevas, pas de limites
C App	Mobile-first, application désignée / téléphone / mini-programme	Cadre aux proportions du téléphone ; défilement uniquement dans le cadre	Verrouillé dans le cadre du téléphone
D Composant	Lecteur, lightbox, zone de téléchargement, etc., contrôle unique	Taille naturelle selon le contenu ; défilement local interne	Verrouillé dans le cadre du composant

Si l'utilisateur précise le type, suivez sa demande ; sinon, déduisez-le de la fonction. Le conteneur ne détermine que la méthode d'affichage, pas le style visuel.

Points clés de conception du conteneur

A Logiciel

• Faites en sorte que la fenêtre, l'arrière-plan et le contenu forment une relation d'affichage complète ; le cadre est au service du produit, n'ajoutez pas de décorations superflues pour un effet flottant.
• Priorisez la coexistence naturelle des informations principales et des actions courantes ; les contenus complexes sont gérés par un zonage raisonnable et un défilement local.
• Commencez par bien répartir l'espace et la mise en page responsive, puis décidez des zones de défilement ; ne masquez pas les problèmes de mise en page par le recadrage, la dissimulation des barres de défilement ou un zoom global.
• Sur écran étroit, privilégiez la réorganisation, le regroupement et l'ajustement de la présentation des informations ; ne laissez pas les fonctions principales disparaître.
• La largeur du logiciel ne doit pas dépasser 85 % de la largeur totale de la fenêtre, et la hauteur 90 % ; laissez un espacement autour pour centrer l'affichage.

B Page Web

• Choisissez une structure adaptée au contenu : narration longue page, navigation modulaire, écran d'accueil immersif, etc.
• La page doit avoir un rythme visuel et une hiérarchie de contenu ; évitez de répéter la même disposition pour chaque bloc.
• Vous pouvez ajouter des animations déclenchées par le défilement en fonction des besoins narratifs ; ne forcez pas l'ajout d'effets de défilement pour respecter une règle.

C App

• Adoptez une navigation adaptée aux appareils mobiles, une disposition à une colonne ou adaptée au contexte, et des commandes faciles à utiliser.
• Personnalisez visuellement les contrôles natifs si nécessaire, mais sans nuire à l'accessibilité et à l'expérience utilisateur.
• Les zones tactiles, la navigation en bas de l'écran et le défilement du contenu doivent être conformes aux habitudes d'utilisation des mobiles réels.
• Il est recommandé de concevoir aux dimensions d'un iPhone (sans nécessairement créer l'îlot dynamique ou le composant de la caméra frontale).

D Composant

• Le composant doit prendre forme naturellement en fonction de son utilisation et de son contenu, sans utiliser une coque de logiciel complète.
• Concentrez-vous sur la conception des états : inactif, survol, focus, chargement, succès, erreur, etc. Tous les changements d'état doivent être clairs, cohérents et compréhensibles.

Les limites des calques pour les quatre types ci-dessus sont unifiées dans la section suivante.

Limites du conteneur : verrouiller l'interface dans le canevas (obligatoire pour Logiciel / App / Composant)

Il s'agit d'une contrainte stricte, pas d'une préférence de style. La limite d'une page Web est la fenêtre d'affichage du navigateur ; un logiciel, une App, un composant a ses propres limites. En dehors du canevas, il n'y a que la « scène » (arrière-plan du podium). Une fois que les boîtes de dialogue, les tiroirs, les masques, les flous gaussiens dépassent du canevas, l'interface passe d'« un logiciel » à « une capture d'écran de page Web » – c'est la faille la plus courante de ce type de prototype.

Architecture à trois couches

Le produit lui-même est placé dans le canvas, la stage ne sert qu'à centrer et à fournir l'arrière-plan ; aucun élément sémantique du produit n'est placé sur la stage.

body > .stage          Scène : centrage + arrière-plan, ne contient pas de contenu produit
       └ .canvas      Canevas : limites de l'interface produit
          ├ Contenu produit (barre de titre / zone principale / barre latérale…)
          └ .layer     Groupe de calques : boîte de dialogue, tiroir, menu déroulant, Toast
              ├ .scrim  Masque : assombrissement + flou
              └ .dialog Boîte de dialogue

Propriétés clés (pseudo-code) :

.canvas {
  position: relative;    /* Référence de positionnement pour les calques */
  contain: paint;        /* Recadrage + ancre les descendants fixed au canevas, indispensable */
  overflow: hidden;      /* Tout contenu débordant est coupé */
  isolation: isolate;    /* Isolement de la superposition et de l'échantillonnage de l'arrière-plan dans le canevas */
  container-type: size;  /* Optionnel : permet d'utiliser cqw/cqh à l'intérieur */
  width: min(1440px, 100%);
  height: min(900px, calc(100svh - 2 * var(--stage-pad))); /* Si container-type est utilisé, la hauteur et la largeur explicites sont obligatoires */
}

.layer  { position: absolute; inset: 0; }              /* Référence au canevas, jamais fixed */
.scrim  { position: absolute; inset: 0;               /* Les dimensions = dimensions du canevas → la zone de flou est strictement égale au canevas */
          background: rgb(8 10 14 / .45); backdrop-filter: blur(10px); }
.dialog { position: relative; width: min(720px, 78cqw); max-height: 82cqh;
          display: flex; flex-direction: column; }
.dialog-body { flex: 1; min-height: 0; overflow: auto; }  /* Seule la zone de contenu défile */

Pourquoi contain: paint est obligatoire

Testé (Edge, 1400×1200) : avec seulement overflow: hidden, les éléments position: fixed à l'intérieur du canevas se positionnent toujours par rapport à la fenêtre d'affichage du navigateur et s'échappent. Ce n'est qu'en ajoutant contain: paint (ou transform / filter / will-change: transform / contain: layout) que fixed s'ancre au canevas et est recadré. container-type: size seul ne suffit pas, il doit être combiné avec contain: paint. Si vous n'avez pas besoin de cqw/cqh, vous pouvez supprimer container-type.

Interdictions

• Utiliser position: fixed pour les calques dans le canevas – le référentiel est la fenêtre d'affichage, ils déborderont naturellement.
• Utiliser vw / vh / dvh pour dimensionner les éléments à l'intérieur du canevas – les unités de la fenêtre d'affichage feront nécessairement éclater le canevas.
• Appliquer des masques, des flous, des ombres sur body, .stage ou des éléments en dehors du canevas.
• Utiliser transform: scale() pour zoomer/dézoomer le canevas afin de le « faire entrer » dans l'écran – le texte, le flou et les ombres seront tous flous. La bonne méthode est de définir la taille avec min() + une adaptation interne.
• Faire apparaître du contenu sémantique du produit (texte explicatif, boutons, graphismes décoratifs) sur la scène en dehors du canevas.

Spécifications de taille des boîtes de dialogue (obligatoire pour les logiciels)

Par défaut, orientation paysage : largeur > hauteur. Les boîtes de dialogue d'un logiciel doivent de préférence adopter une conception large.

Volume de contenu	Orientation du rapport	Taille suggérée (par rapport au canevas)	Remarque
Élevé (tableaux, graphiques, longs formulaires, éditeur)	Largeur > Hauteur, rapport 16:9 ou 4:3	Largeur 60%–80% du canevas, hauteur ne dépassant pas 75% du canevas	Privilégiez 16:9 pour beaucoup de contenu, puis 4:3 ; nécessaire pour les dispositions côte à côte afin de ne pas gaspiller l'espace horizontal
Moyen (panneaux de paramètres, formulaires à plusieurs champs)	Largeur > Hauteur	Largeur 480–640px, hauteur 320–420px	Restez en paysage, mais ne remplissez pas tout l'espace
Faible (confirmation, champ unique, information)	Peut être proche du carré	Largeur 320–420px, hauteur 220–320px	Le format portrait est également acceptable ; ne forcez pas la largeur juste pour respecter un rapport
Liste verticale (longue liste, arborescence, sélecteur)	Hauteur > Largeur	Largeur 320–400px, hauteur 60%–80% du canevas	Le format portrait est une exception autorisée : une liste unique est naturellement verticale
Espace de travail (agenda, tableau Kanban, édition plein écran)	Proche de la taille réelle du canevas	Laissez une marge de 16–24px dans le canevas	Toujours pas en fixed, toujours dans le canevas

Ordre de décision : demandez d'abord « le contenu nécessite-t-il d'être côte à côte ? ». Si c'est le cas, ou si une lisibilité horizontale est requise (tableaux, graphiques, code, timeline) → paysage ; liste unique / arborescence / formulaire étape par étape → portrait.

Mise en œuvre : utilisez aspect-ratio pour le rapport, max-height pour la sécurité, cqw pour la largeur et cqh pour la hauteur.

.dialog--wide   { width: min(72cqw, 860px); aspect-ratio: 16 / 9; max-height: 78cqh; }  /* Beaucoup de contenu */
.dialog--panel  { width: min(56cqw, 680px); aspect-ratio: 4 / 3;  max-height: 78cqh; }  /* Beaucoup de contenu, compact */
.dialog--compact{ width: min(32cqw, 380px); aspect-ratio: 5 / 4; }                        /* Peu de contenu */
.dialog--tall   { width: min(30cqw, 360px); height: min(72cqh, 620px); }                   /* Liste verticale unique */

Si le contenu est trop haut, max-height s'applique et le rapport peut être rompu – c'est intentionnel : il vaut mieux un rapport légèrement modifié qu'un contenu débordant du canevas.

Autres contraintes :

• La boîte de dialogue doit être centrée dans le canevas, avec un espace blanc d'au moins 24px sur tous les côtés ; ne touchez pas les bords, ne dépassez pas du canevas.
• Si le contenu dépasse, seul .dialog-body doit défiler ; l'en-tête et le pied de page restent fixes.
• Le masque d'assombrissement doit être de couleur rgb(0 0 0 / .35) à rgb(0 0 0 / .5), avec un flou de 8–16px ; sa zone d'effet doit être strictement égale au canevas.
• Dans un même logiciel, les boîtes de dialogue qui apparaissent en groupe doivent avoir des tailles cohérentes (même taille pour le même type) ; n'utilisez pas un rapport 16:9 et une barre haute et étroite.

3. Processus de conception

Avant de commencer, lisez skills/ui-metadata/SKILL.md et écrivez metadata.json dans le répertoire de la page conformément à ses spécifications.

0. Déclaration de source pour les entrées d'image (imageToUI)

Lorsque l'utilisateur utilise « une ou plusieurs images » comme entrée pour la génération (c'est-à-dire « faire une UI à partir d'une image », « reproduire une image », « l'IA reconnaît l'image et la reproduit à l'identique »), vous devez écrire le champ imageToUI dans metadata.json pour enregistrer la source de cette image, afin que la carte de la galerie puisse retrouver l'image de référence originale et permettre de cliquer pour la voir. Le traitement dépend du type d'entrée :

• L'entrée est une URL d'image (commence par http://, https:// ou //) : écrivez directement ce lien dans imageToUI, par exemple "imageToUI": "https://dribbble.com/shots/15820088-Furniture-Board-Desktop-concept". La galerie affichera une icône d'image ; un clic ouvrira la source dans un nouvel onglet.

• L'entrée est une chaîne base64 ou un chemin d'image local : l'IA doit d'abord demander à l'utilisateur de choisir entre deux options, et ne doit pas traiter silencieusement :

  1. Fournir l'URL source de l'image (recommandé pour les références avec une source publique, comme Dribbble / Behance / un lien vers une maquette) ; ou
  2. Permettre à l'IA de copier l'image dans le répertoire ui/<slug>/assets/ comme source d'archivage (fortement recommandé – garantit une source traçable, consultable hors ligne et publiée avec le prototype), puis écrivez imageToUI comme un chemin relatif, par exemple "./assets/source-<slug>.png".

  ⚠️ Il est interdit d'écrire la chaîne base64 ou le chemin absolu local tel quel dans imageToUI : un chemin local est inaccessible sur le serveur de la galerie, et base64 ne peut pas être ouvert par un navigateur ; l'icône de la carte sera cassée. N'écrivez pas ce champ tant que l'utilisateur n'a pas fait de choix explicite.

Règles pour les valeurs du champ (la galerie catalog.mjs les interprète ainsi, voir skills/ui-metadata/SKILL.md) :

• Commence par http:// / https:// / // → considéré comme un lien externe, le clic redirige.
• Autre (commence par ./assets/..., assets/...) → considéré comme une ressource dans le répertoire du prototype, résolu en /prototypes/<slug>/... et ouvre l'image dans un nouvel onglet.
• Vide / non écrit → la carte n'affiche pas cette icône.

1. Définir la tâche de conception

Déterminez le positionnement du produit, le scénario utilisateur, les tâches principales, la priorité des informations et l'élément clé de l'écran d'accueil. Préparez d'abord un texte réel et des données raisonnables, puis concevez la présentation ; évitez le contenu factice.

2. Déterminer l'orientation visuelle

Utilisez une brève description de conception pour clarifier l'identité de la page. Il n'est pas nécessaire de remplir un format fixe ou un tableau de paramètres. Réfléchissez au moins à :

• L'impression visuelle globale et la personnalité de la marque.
• Comment la typographie, la composition et la hiérarchie de l'information expriment le contenu.
• Comment la typographie établit la personnalité et la qualité.
• Comment les couleurs créent l'ambiance, l'identification et les points d'attention.
• Comment les icônes, les graphismes, la photographie ou la visualisation de données participent à l'expression.
• Si l'animation peut améliorer l'expérience et quel langage d'animation adopter.

3. Établir un système de design

Créez des variables CSS et des styles réutilisables en fonction des besoins de la page. Les couleurs, polices, tailles de police, espacements, rayons de bordure, bordures, ombres et animations doivent avoir une logique de conception cohérente, mais le nombre, les valeurs et les proportions ne sont pas imposés.

Ne transformez pas le système de design en un tableau de paramètres qui limite la créativité. Vous pouvez l'ajuster de manière flexible, mais chaque choix doit servir l'effet global.

4. Points clés de la conception visuelle

4.1 Typographie et composition

• Faites en sorte que l'utilisateur sache immédiatement où regarder en premier, puis comprenne naturellement le reste de l'information.
• Utilisez la taille de police, le poids de la police, la personnalité de la police, la couleur, la position, l'espace blanc et l'alignement pour établir une hiérarchie, sans vous appuyer sur des cartes et des bordures.
• Explorez les grilles, l'asymétrie, le désalignement, les colonnes, la superposition, l'immersion, le style éditorial ou d'autres compositions en fonction du contenu.
• Autorisez des contrastes de taille audacieux, des césures spéciales et une tension visuelle, mais l'ensemble doit rester cohérent et lisible.
• La page doit avoir des variations de densité, de poids et de rythme ; évitez que toutes les zones soient également utilisées.
• Ne partez pas du principe que la mise en page sera centrée, symétrique, avec des cartes de même largeur ou une disposition de blocs identique.
• Le design visuel doit aider l'utilisateur à comprendre et à accomplir sa tâche, et ne pas seulement rechercher un bel effet de capture d'écran.

4.2 Relation entre fonctionnalité et minimalisme

La fonctionnalité complète et l'esthétique visuelle doivent être réalisées ensemble. Le minimalisme ne consiste pas à supprimer des fonctionnalités.

• Offrez des capacités complètes que l'utilisateur attend raisonnablement en fonction de la catégorie du produit. Ne supprimez pas arbitrairement des fonctionnalités pour rendre la page plus vide, plus simple ou pour une meilleure capture d'écran.
• Optimisez d'abord l'architecture de l'information, le regroupement des fonctions, l'emplacement des accès, le flux d'interaction et l'expression visuelle.
• Utilisez la divulgation progressive, les actions contextuelles, les accès rapides, l'expression par icônes, les menus et les tiroirs pour réduire la charge visuelle.
• Les fonctions à haute fréquence doivent être faciles à trouver et à utiliser ; les fonctions à basse fréquence peuvent être rangées, mais ne doivent pas être cachées au point d'être impossibles à trouver.
• Les icônes peuvent réduire la quantité de texte, mais elles doivent être faciles à comprendre ; les actions importantes doivent conserver une étiquette textuelle si nécessaire.
• Ne supprimez une fonction que si l'utilisateur demande explicitement un minimalisme prioritaire, une suppression des fonctions redondantes, ou si la fonction ne fait effectivement pas partie du produit, et dans ce cas expliquez pourquoi.
• Les points d'entrée des fonctions, les états et les retours doivent être complets ; ne créez pas de contrôles qui existent visuellement mais ne répondent pas réellement.

4.3 Texte et expression de l'information

• L'interface n'est pas un manuel d'utilisation. Si vous pouvez exprimer clairement en peu de mots, ne rédigez pas de longs paragraphes explicatifs, mais ne sacrifiez pas les informations nécessaires pour économiser des caractères.
• L'interface ne doit contenir aucun texte ou graphisme lié à « démonstration / prototype / simulation » : n'écrivez pas « mode démonstration », « données d'exemple », « données mock », « compte de test », « ceci est un prototype » ; n'utilisez pas de bulles d'annotation, de flèches, de marqueurs numérotés, de cadres de mise en évidence pédagogiques ; n'utilisez pas de « schéma », « image factice », « Lorem ipsum », « à compléter ». Chaque mot, chaque icône dans l'interface doit être un contenu réel du produit.
• Concevez le prototype comme une interface de produit officiellement lancée : le texte doit ressembler à des données métier réelles, les graphiques doivent avoir des relations de valeurs crédibles, l'état vide doit écrire son propre texte d'orientation, les messages d'erreur doivent décrire des situations que l'utilisateur rencontrera vraiment. Pour les parties irréalisables (interfaces serveur), expliquez-les dans la note de livraison, ne les écrivez pas dans l'interface.
• Pour les marques anglaises ou les pages internationalisées, vous pouvez utiliser des mots concis, des étiquettes courtes, des caractères de grande taille et des symboles visuels.
• Les pages tendance et créatives peuvent utiliser davantage d'icônes, de symboles, de graphismes et de chiffres visualisés ; les outils professionnels doivent donner la priorité à la clarté de l'information.
• L'expression en français doit être naturelle et précise ; n'introduisez pas de force des mots anglais ou des abréviations sans signification pour la décoration.
• Le texte doit être concret et informatif ; évitez les mots marketing vides, les titres redondants et les guides auto-descriptifs.
• Pour les états, les tendances, les processus, les catégories et les proportions, choisissez des icônes, des graphiques, des diagrammes structurels ou du texte en fonction du coût de compréhension ; n'imposez pas un seul mode d'expression.

4.4 Conception typographique (point clé)

N'utilisez pas la police système par défaut comme solution finale. Sauf pour les longs corps de texte, les informations denses et les scènes prioritaires à la lecture, choisissez activement une police.

• Pour un aspect haut de gamme / design / marque, cherchez activement une police d'affichage ou une combinaison de polices ; n'utilisez pas la police par défaut.
• Les titres, les logotypes, les chiffres clés, le corps de texte et les informations auxiliaires peuvent utiliser des polices de différentes personnalités, mais la combinaison doit être cohérente ; n'empilez pas trop de polices.
• Anglais : sans empattement géométrique, sans empattement humaniste, Grotesk, avec empattement, étroit / large, Display, manuscrite, expérimentale, choisissez en fonction de l'identité ; n'utilisez pas Inter par défaut.
• Français/autres langues : polices modernes sans empattement, polices avec empattement/romaines, polices rondes, polices manuscrites, polices d'affichage spéciales ; les polices d'affichage ne sont utilisées que pour les titres et les textes courts ; pour les longs corps de texte, privilégiez la lisibilité.
• Chiffres : la ligne de base, la hauteur d'empan, la largeur, l'alignement doivent être cohérents ; n'utilisez pas de polices artistiques de largeurs inégales.
• Le poids, la largeur, l'espacement des lettres, la casse, l'italique et la césure peuvent tous créer un effet design ; ne vous contentez pas de changer le nom de la police.
• Taille de police minimale par défaut : 12px (limite inférieure, pas une règle absolue) ; pour les petits logos / textes intégrés dans les motifs, la taille peut être réduite selon les besoins. Pour la mise en page, utilisez des retours à la ligne adaptatifs basés sur la largeur ; ne forcez pas la césure.

Voir la section 6 pour les sources de polices, les références CDN et la gestion des chargements lents.

4.5 Conception des couleurs

N'utilisez pas un ensemble de valeurs de couleur, un rapport de couleurs ou une couleur d'accentuation fixes. Déterminez d'abord l'identité du produit, puis explorez audacieusement les relations de couleurs appropriées.

Envisagez des gris sophistiqués, des couleurs neutres, des couleurs peu saturées, des couleurs naturelles, des contrastes chauds/froids, des couleurs de marque, des contrastes vifs, des teintes sombres luxueuses, des systèmes monochromes, etc. Les couleurs peuvent être sobres ou vives ; l'important est la coordination, la hiérarchie, la reconnaissance et l'expression émotionnelle.

Les teintes froides comme le vert brumeux, le vert d'eau, le bleu brumeux ne doivent pas être placées en tête de l'exploration des couleurs – aujourd'hui, la plupart des interfaces conçues par l'IA adoptent ce style, le risque de similitude est trop élevé ; gardez-les comme solution de dernier recours.

• Les couleurs doivent avoir un rôle clair : établir une relation claire entre l'arrière-plan, le contenu, le texte, les points d'attention et les états.
• La couleur d'accentuation ne doit pas être une couleur fixe ; choisissez-la en fonction de la marque et du contenu de la page.
• Vous pouvez utiliser des dégradés, de la transparence, des textures et des effets de lumière/ombre, mais ils doivent avoir un objectif de conception ; ne considérez pas les dégradés, la lueur ou l'effet de verre comme un signe de qualité par défaut.
• Le contraste des couleurs doit garantir que le texte et les contrôles importants sont reconnaissables ; ne sacrifiez pas la lisibilité pour l'ambiance.
• Ne rendez pas la page terne, sans point d'attention ni vie, en recherchant une faible saturation ou des gris sophistiqués.

4.6 Icônes, graphismes et images

• Les icônes, symboles, formes géométriques, illustrations, photographies et visualisations de données peuvent tous faire partie du langage visuel principal, sans se limiter au texte et aux cartes.
• Choisissez un style graphique en fonction de l'identité du produit, en veillant à ce que les lignes, les proportions, la texture et le mode d'expression soient cohérents.
• Les icônes fonctionnelles doivent être faciles à identifier ; les graphismes de marque ou créatifs peuvent être plus personnels.
• Ne mélangez pas des bibliothèques d'icônes de styles radicalement différents ; n'utilisez pas d'émojis à la place d'icônes fonctionnelles officielles.
• Les graphismes doivent avoir un objectif d'expression : aider à l'identification, expliquer une relation, transmettre un état, façonner la marque ou renforcer la tension visuelle.
• Les images doivent avoir une composition, une couleur et une logique de contenu claires ; évitez les collages aléatoires ou les images sans rapport pour remplir la page.

4.7 Détails et finition

• Faites attention au rendu des polices, à l'espacement des lettres, à l'alignement, aux limites, aux proportions des icônes, à la hiérarchie, aux états d'interaction et aux détails du contenu.
• Utilisez les bordures, les lignes de séparation, les ombres, les rayons, les textures et les effets de transparence selon les besoins ; n'ajoutez pas de la décoration pour la décoration.
• Les composants doivent être cohérents entre eux, mais des différences visuelles raisonnables sont autorisées pour les zones clés.
• La page ne doit pas être soignée uniquement sur l'écran d'accueil ; les zones de défilement, les pop-ups, les menus, les états vides et les états d'erreur doivent également être entièrement conçus.
• Ne sacrifiez pas la lisibilité, la maniabilité et la vitesse de réponse réelles pour ressembler à une « maquette de design ».

4.8 Les bordures ne doivent pas être rognées (lecture obligatoire pour les conteneurs de recadrage)

Lorsqu'un composant avec une bordure est placé dans un conteneur parent qui rogne le contenu, la marge intérieure du conteneur parent doit être ≥ la largeur maximale de la bordure de tous les états du composant. Sinon, la bordure est coupée, et l'absence de bordure donne l'impression d'un « rendu défectueux ».

Mécanisme

overflow: hidden rogne la padding box (boîte de contenu + marge intérieure) du conteneur :

• La marge intérieure du conteneur peut absorber le débordement des éléments enfants → une marge intérieure suffisante permet d'afficher la bordure ;
• Mais box-shadow (externe) et outline sont dessinés en dehors de la boîte de bordure, la marge intérieure ne peut pas les rattraper.

Solutions (par ordre de priorité)

1. box-sizing: border-box global (recommandé) – élimine le débordement à la racine :

*, *::before, *::after { box-sizing: border-box; }

2. Laisser une marge pour la bordure dans le conteneur parent – padding ≥ largeur de la bordure + 1px. Testé : avec une bordure de 4px, si padding ≤ 6px, la bordure de droite est rognée ; avec ≥ 7px, elle est intacte. Une marge exactement égale à la largeur de la bordure (4px) est encore rognée, il faut absolument laisser une marge supplémentaire.

3. Utiliser une ombre portée intérieure (inset) à la place de la bordure – ne prend pas de place, jamais rognée :

.card { border: 0; box-shadow: inset 0 0 0 1px var(--line); }

Interdictions

• Utiliser box-shadow externe / outline comme bordure permanente (dessiné en dehors de la boîte de bordure, rogné immédiatement) ;
• Utiliser une marge négative pour fusionner les bordures adjacentes (forcément rogné en cas de recadrage).

Quand la bordure n'apparaît qu'au survol

Scénario le plus fréquent : l'état normal est correct, mais dès que la souris survole, un morceau de bordure manque. Utilisez une bordure transparente comme espace réservé et ne modifiez que la couleur. Le changement ne saute pas et ne déborde pas :

.item { border: 1px solid transparent; transition: border-color .18s; }
.item:hover { border-color: var(--line); }

Vérifiez chaque composant conformément au point 13 de l'auto-vérification de la section 9.

4.9 Uniformisation du style des contrôles natifs

Les contrôles natifs du navigateur (barre de défilement, menu déroulant select, état de focus de input / textarea, couleur d'accentuation de checkbox / radio / range, sélecteur de date, etc.) sont rendus par le système. Leur apparence diffère de celle de l'interface utilisateur peinte sur mesure, ce qui constitue la faille la plus négligée et la plus susceptible de nuire à la cohérence globale. Tous les contrôles natifs présents dans la page doivent être intégrés dans le langage visuel du produit, sans conserver l'apparence par défaut du système.

• Barres de défilement : WebKit utilise ::-webkit-scrollbar*, Firefox utilise scrollbar-width / scrollbar-color pour unifier la couleur, le rayon et l'état de survol de la piste et du pouce ; appliquez uniquement aux zones de défilement locales, avec une largeur modérée (environ 8–10px), n'ajoutez pas de gras globalement.
• Champs de saisie : input / textarea / select utilisent appearance: none pour peindre les bordures, les rayons et les états de focus focus-visible sur mesure, sans utiliser les bordures et les ombres intérieures par défaut du navigateur.
• Menu déroulant select : Le panneau d'options natif option ne peut pas être profondément personnalisé ; utilisez appearance: none + flèche de déploiement peinte sur mesure, et maintenez la cohérence avec les boutons et les champs de saisie à l'aide de variables --control-*. Si la recherche, le regroupement ou la surbrillance personnalisée sont nécessaires, utilisez un menu déroulant peint sur mesure au lieu du select natif.
• Couleur d'accentuation : Pour checkbox / radio / range / progress, utilisez accent-color: var(--brand), ne conservez pas le bleu système.
• Saisies composites : Les panneaux de couleur, de date, d'heure, etc., ne peuvent pas être personnalisés ; pour les produits importants, remplacez-les par des éléments peints sur mesure ou limitez le format de saisie.

Points clés : les marges intérieures, la taille de police, le rayon et l'état de focus de tous les contrôles natifs doivent être intégrés dans les variables de conception (par exemple --control-bg / --control-border / --control-radius / --control-focus), en maintenant le même langage visuel que les cartes et les boutons, et en éliminant les « deux langages ».

5. Conception et mise en œuvre des animations

Les animations font partie intégrante de la conception UI, elles ne se limitent pas à ajouter un effet de survol à un bouton. En fonction de l'identité du produit et des besoins de l'utilisateur, déterminez activement le rôle des animations dans l'interface.

5.1 Évaluer d'abord le besoin d'animation

• Lorsque l'utilisateur demande explicitement des animations de qualité, des effets avancés, des animations fluides, du dynamisme, de l'immersion, un aspect cinématographique, des visuels dynamiques ou des exigences similaires, faites de l'animation un élément central de la conception. Utilisez activement des bibliothèques d'animation professionnelles comme GSAP pour réaliser des effets complexes, ne vous contentez pas de simples transitions CSS.
• Pour les sites web de marque, les présentations créatives, les lancements de produits, les portfolios, les narrations interactives et autres pages adaptées à l'expression dynamique, vous pouvez concevoir activement des entrées rythmées, des narrations par défilement, des effets de parallaxe, des animations de texte, des déformations graphiques, des révélations par masque, des mouvements en couches et des transitions fluides.
• Pour les outils professionnels, les back-offices et les interfaces à haute fréquence d'opération, les animations doivent aider à comprendre l'état, établir des relations spatiales et fournir un retour ; elles peuvent être raffinées et fluides, mais ne doivent pas nuire à l'efficacité.
• Lorsque l'utilisateur ne demande pas explicitement d'animations complexes, concevez avec modération en fonction de l'identité du produit ; n'ajoutez pas d'effets de mouvement insignifiants pour faire étalage de vos compétences.
• Ne faites pas apparaître tous les éléments avec la même transition de fondu enchaîné et de glissement vers le haut, et ne laissez pas chaque composant agir indépendamment.

5.2 Qualité de l'animation

• Évitez les mouvements linéaires mécaniques : les déplacements spatiaux, les zooms et les transitions d'interface utilisent généralement une accélération, une décélération, une atténuation non symétrique ou un ressort naturels. Le mouvement linéaire n'est approprié que pour les rotations à vitesse constante, les barres de progression, le défilement continu et autres scénarios qui le nécessitent réellement.
• Utilisez des atténuations de qualité : en fonction de la distance du mouvement, de la sensation de masse de l'élément et du contexte, choisissez des courbes ease-out, ease-in-out, power, expo, back, spring, etc. Utilisez les rebonds excessifs avec parcimonie, évitez les oscillations bon marché.
• Ajoutez une sensation d'amortissement si nécessaire : les panneaux de grande taille, les calques, le glissement, le suivi, l'aimantation et les transitions spatiales peuvent avoir une inertie, un amortissement, un rebond ou un ressort pour rendre le mouvement plus naturel.
• Le mouvement doit avoir une cause et un effet : l'entrée, la sortie, le déploiement, le repliement, le changement, le glissement et les changements d'état doivent correspondre à l'intuition de l'utilisateur concernant l'espace et les objets.
• L'orchestration doit avoir un rythme : utilisez des décalages, des chevauchements, des enchaînements continus et des mouvements en couches, mais avec une hiérarchie ; ne faites pas bouger tous les éléments en même temps de manière aléatoire.
• Les animations doivent répondre au contenu et aux actions : évitez les boucles permanentes sans signification, les flottements continus et les animations d'arrière-plan qui accaparent l'attention.
• Priorité aux performances : privilégiez les propriétés adaptées à la composition, comme transform et opacity. Soyez prudent avec les filtres complexes, le flou et les effets en temps réel sur de grandes surfaces, pour éviter de perdre des images.

5.3 Utiliser en priorité gsap-skills et GSAP

Avant de créer une animation GSAP, vérifiez d'abord : si la compétence gsap-skills est déjà installée sur le système/agent actuel, utilisez-la pour obtenir l'API et les méthodes les plus récentes ; si ce n'est pas le cas, demandez activement à l'utilisateur de confirmer et recommandez-lui d'exécuter npx skills add https://github.com/greensock/gsap-skills pour l'installer (à la décision de l'utilisateur), puis utilisez-la pour la conception des animations. N'utilisez pas de mémoire des usages GSAP obsolètes.

Pour les animations complexes (narrations d'entrée, déclenchement par défilement, orchestration avec Timeline, glisser-déposer interactif, coordination multi-éléments), utilisez GSAP en priorité :

• Utilisez Timeline pour orchestrer un ensemble d'animations (étiquettes, chevauchements, imbrications, callbacks), au lieu d'une multitude de delay indépendants.
• Utilisez ScrollTrigger pour le déclenchement par défilement ; pour le défilement fluide, le mot par mot, le chemin, l'inversion, etc., importez les plugins nécessaires.
• Pour les retours d'état simples, utilisez les transitions CSS / keyframes ; n'importez pas une bibliothèque si ce n'est pas nécessaire.
• Importez via CDN (par exemple gsap@3), conformez-vous aux conventions techniques de la section 8 ; gérez les animations de manière modulaire pour faciliter la lecture / pause / inversion / réinitialisation / nettoyage.

5.4 Opérations continues, interruptions et reprise

Les animations interactives doivent prendre en compte les opérations continues de l'utilisateur : en cas de nouvelle opération, enchaînez naturellement à partir de l'état visuel actuel, sans scintillement, sans revenir à la position initiale, et sans que l'état de l'animation ne soit déconnecté de l'interface utilisateur réelle.

• États réversibles (déploiement/repli, marche/arrêt) : réutilisez la même Timeline avec reverse() / play() pour une inversion naturelle, sans recréer.
• Valeurs cibles en changement continu (glisser-déposer, suivi du curseur) : utilisez gsap.quickTo() pour que le mouvement suive toujours la dernière entrée, sans créer une nouvelle interpolation à chaque fois.
• Enchaînement de séquences multiples : utilisez Timeline / Timeline imbriquée / callbacks / machine à états pour une gestion unifiée, sans créer d'animations indépendantes qui se disputent la même propriété.
• Distinguez, en fonction de la sémantique de l'interaction, « continuer la séquence / lire en sens inverse / passer à une nouvelle cible / paralléliser d'autres propriétés » ; n'ajoutez pas toutes les animations de manière systématique ou ne les arrêtez pas toutes non plus. Ne remplacez que les propriétés réellement en conflit (GSAP utilise overwrite: "auto", ne faites pas de kill() aléatoire ni de overwrite: true global).

5.5 Accessibilité et performances

• Respectez prefers-reduced-motion: reduce, proposez une solution réduite en effets dynamiques ; en cas de réduction des animations, l'information et la fonctionnalité doivent rester complètes.
• N'utilisez pas d'animations pour masquer un contenu essentiel ou pour retarder des informations que l'utilisateur doit obtenir immédiatement.
• Évitez les scintillements à haute fréquence, les zooms rapides et de grande amplitude, et les effets de parallaxe susceptibles de provoquer un inconfort.
• Les animations liées au défilement ne doivent pas perturber le défilement normal, les opérations au clavier et les opérations tactiles.
• Lorsque vous quittez une page ou détruisez un composant, nettoyez correctement les écouteurs d'événements, les ScrollTrigger et les instances d'animation qui ne sont plus nécessaires.
• Le contenu important de l'écran d'accueil ne doit pas dépendre du chargement complet de la bibliothèque d'animations pour s'afficher.

Références :

• GSAP Documentation
• GSAP Timeline
• GSAP Tween / overwrite
• Apple HIG Motion
• Material Motion

6. Ressources

Utilisez systématiquement tools/resource-getter/get.py pour obtenir les ressources, ne construisez pas manuellement des URL de sites, et ne dispersez pas une multitude de liens externes de sources diverses dans la page. La matrice complète des sources, des licences et du dépannage se trouve dans tools/resource-getter/README.md.

Priorité de sélection

1. Illustration vectorielle transparente : unDraw / Storyset / DiceBear / Doodle Ipsum
2. Images détourées PNG : Pixabay (--transparent) / pngimg
3. Photographies : Pixabay / Picsum / Unsplash / Pexels
4. SVG dessinés à la main (géométriques, décoratifs, graphiques)
5. Images générées par IA (en dernier recours, règles ci-dessous)

Par défaut, lien direct ; si lent, enregistrement local. Le mode auto de get mesure le TTFB : si > 0,9 s ou si la lecture > 2,5 s, il est considéré comme lent et doit être téléchargé dans ui/<page>/assets/ ; même si rapide, n'accumulez pas vingt grandes images distantes dans l'écran d'accueil.

...