WithZeng/design-skills

Conception de site web

Leçons tirées de la refonte du site Scientify (2026-10) : la conception n'a été réussie qu'après la présentation et la validation des brouillons, qu'un système de page unique a été imposé à chaque section, et que la vérification a détecté des problèmes de contraste et de balisage que les bibliothèques d'animation introduisent.

Flux de travail et jalons

1. Brief. Recueillir le produit, le public, les sections, des exemples de données réelles, et 1 à 2 sites de référence que l'utilisateur aime. S'il n'en a aucun, en choisir 2 à 3 adaptés au type de site parmi references/ui-references.md (galeries, bibliothèques d'interface de produits réels, sources de composants) et les montrer pour approbation. Copier les références sous forme d'images (--ref) ; lorsque l'utilisateur demande des recommandations, montrer des captures numérotées ainsi que 2 à 3 combinaisons à choisir (méthode : ui-references, « Capturing references »).
2. Brouillons avant le code. Ne jamais éditer le code pour une modification visuelle avant que l'utilisateur n'approuve un brouillon. Utiliser le skill image-gen. Ordre :
   1. Si la direction est ouverte, une image d'ensemble par direction (généralement 2) ; l'utilisateur en choisit une avant tout travail détaillé. Ensuite une image pleine page longue (1024x1536) pour fixer le système de page.
   2. Une image détaillée par section/panneau en pleine résolution.
   3. Sous-pages, puis storyboards d'interaction (3 à 4 images par interaction) pour le mouvement. Montrer chaque lot, recueillir les retours, itérer. Modèles de prompts : references/draft-prompts.md.
3. Construire uniquement les brouillons approuvés, derrière un itinéraire de prévisualisation jusqu'à ce que l'utilisateur demande de remplacer la page en ligne. Modèles : references/build-patterns.md.
4. Vérifier avant tout commit/PR : references/verification.md.
5. Conserver les brouillons et captures d'écran dans le dossier scratch ignoré par git du projet (par exemple tmp/design/vN/), un dossier par itération, les prompts sauvegardés à côté des images.

Système de page (ce qui a supprimé la « 割裂感 »)

Une page semble tenir d'un seul tenant lorsque chaque section réutilise le même système. Déterminer les valeurs du système à partir des brouillons approuvés, puis les intégrer dans chaque prompt et dans les tokens du code :

• Un fond identique traité pour toute la page ; éviter les sections qui inventent chacune leurs propres bandes ou dégradés.
• Un module de section (conteneur, rayon, remplissage, bordure, padding, largeur) et un petit ensemble de mises en page à l'intérieur, réutilisé section après section.
• Une échelle typographique : la même taille et graisse pour chaque titre de section, un style de corps, un espacement cohérent.
• Un élément signature qui porte la direction artistique (généralement dans le héros) ; tout le reste reste plus discret dans la mise en page mais répond toujours à l'interaction. Ce qu'est cet élément vient du brief, pas d'un modèle : voir « Direction artistique » ci-dessous.
• Toute l'interface produit montrée est la MÊME application (même navigation, thème, données), pour que la page soit lue comme un seul produit.
• Une palette suffisamment restreinte pour maintenir la cohérence du système (un site a utilisé du pur monochrome) ; le logo conserve ses couleurs d'origine. Utiliser le vrai logo de la marque partout, jamais un placeholder lettre-dans-un-carré.
• Contenu : des données réalistes issues du domaine du produit (noms, nombres et durées plausibles) et une convention de nommage pour les fichiers et objets, décidée par projet ; pas de lorem, pas de faux témoignages ou statistiques, pas de slogans vides.

Interface applicative et pages d'authentification

Les mêmes jalons s'appliquent à l'intérieur d'un produit, avec des références et tokens différents :

• Les références proviennent de véritables interfaces de produits (par exemple Refero, captures d'écran de produits comparables sur leurs sites, documentation de composants pour les écrans de chat/agent), pas de galeries de pages d'atterrissage.
• Réutiliser les tokens et composants propres à l'application ; ne pas importer la palette du site marketing. Fixer d'abord un petit ensemble de primitives partagées (panneau, largeurs de conteneur de page, largeurs de dialogue, contrôle segmenté), puis restyler les écrans avec elles.
• Connexion/inscription avec un widget d'authentification hébergé (ex. Clerk) : le styliser via son API d'apparence et sa localisation, et vérifier les pièges dans build-patterns (« Auth pages »).

Direction artistique (dimension et mouvement)

Concevoir les parties dimensionnelles et animées à partir des propres besoins du site, puis les esquisser comme tout autre visuel. Ne pas réutiliser une recette ou des valeurs fixes d'un site précédent.

1. La dériver du brief. Quelle est l'idée unique qu'un visiteur doit retenir (le produit en action, une transformation, l'échelle, la précision, le calme) ? Quel est le public, le ton de la marque, quels appareils et budget de performance ? L'élément signature doit montrer cette idée, idéalement avec le vrai produit.
2. Explorer 2 à 3 options qui s'adaptent au système de page et au ton, par exemple une fenêtre produit en perspective, une profondeur en couches avec parallaxe, une scène animée au défilement qui raconte le flux de travail, une illustration ou un objet 3D, une métaphore visuelle/données, ou une page plate et calme avec des micro-interactions riches. Esquisser chaque option en image et, pour le mouvement, en storyboard ; l'utilisateur choisit.
3. Spécifier, puis construire. Noter pour l'option choisie : ce qui bouge, ce qui le déclenche (chargement, défilement, pointeur, temps, clic), l'état de repos, la version à mouvement réduit, et la version mobile. Ajuster les angles, les temporisations et les intensités par rapport aux brouillons approuvés dans le navigateur, pas à partir d'un modèle.
4. Vérifier le coût. Cela ne doit pas nuire à la lisibilité, au contraste, à la stabilité de la mise en page ni au temps de chargement ; cela doit se dégrader gracieusement sans JavaScript et avec mouvement réduit.

Interaction riche, à partir de bibliothèques

Les pages statiques semblent bon marché. Utiliser activement les bibliothèques de composants et d'animations pour rendre chaque interaction vivante :

• Chaque état reçoit un retour : survol, pression, focus, chargement/exécution, succès/erreur, apparition/disparition, changement de mise en page. Planifier ces retours dans les storyboards d'interaction, pas après coup.
• Préférer un composant prêt à l'emploi de qualité à un effet écrit à la main. Associer chaque interaction à un modèle, puis choisir le composant parmi les bibliothèques sélectionnées pour ce projet (references/ui-references.md, « Interaction patterns »).
• Les démos de produit bougent : des tâches réelles avancent, des résultats arrivent, des nombres changent, des scènes changent.
• Le mouvement doit être utile : il explique l'état ou attire l'œil sur ce qui a changé. Les effets décoratifs lourds appartiennent aux pages marketing, pas aux écrans de travail. Respecter le mouvement réduit partout.

Choix des bibliothèques

Choisir les bibliothèques de composants et d'animations pour le projet ; aucune n'est obligatoire.

• Projet existant : utiliser ce qu'il a déjà ; n'ajouter une bibliothèque que pour combler un manque, et jamais une qui chevauche une bibliothèque existante.
• Nouveau projet : choisir en fonction du type de projet, du framework et des besoins (critères et candidats dans references/build-patterns.md, « Choosing libraries »). Conserver un système de composants de base et une bibliothèque d'animation principale, sauf raison claire.
• Privilégier les sources qui s'installent comme code source éditable dans le projet (registre/CLI ou copie) plutôt que des paquets opaques, afin que les composants suivent les tokens du projet.

Règles durement acquises (détails dans build-patterns)

• Chaque ton de texte doit avoir un rapport de contraste d'au moins 4.5:1 sur la surface sur laquelle il repose ; vérifier le token le plus pâle sur le fond du panneau, pas seulement sur le fond de page.
• Pas d'atténuation par opacité sur les entrées au-dessus du pli, ni d'assombrissement par opacité pour les états « inactifs » — les audits Axe en cours d'animation signalent les problèmes de contraste. Utiliser des entrées uniquement par transformation et des changements de couleur.
• Les wrappers d'animation ne doivent pas se placer entre <ul>/<ol> et <li> ; animer à l'intérieur du <li>.
• Pills coulissantes : placer le label dans un span relative au-dessus d'un pill absolu ; pas de -z-10 + isolate.
• Les compteurs affichent la valeur finale sur le serveur et animent seulement lorsqu'ils sont visibles.
• Sur les sites multilingues, chaque chaîne visible passe par l'internationalisation, y compris l'interface démo dans les fenêtres fictives et les sessions rejouées.
• Les grilles ont besoin d'une colonne unique explicite / de pistes minmax(0,1fr) et la racine de la page a besoin d'un débordement horizontal masqué pour éviter le débordement mobile.