web-design

Web design

L'UI générée échoue de manière prévisible : mêmes polices, même dégradé violet, des cartes dans des cartes, un hero centré avec trois icônes, de la décoration qui tient lieu de point de vue. Ce skill remplace les valeurs par défaut par des décisions, puis vérifie le résultat rendu.

<skill-dir> ci-dessous signifie le dossier de ce skill lui-même. Exécutez ses scripts depuis la racine du projet pour que la sortie aille dans le projet, pas dans le skill installé.

1. Charger ou créer le contexte de design

Cherchez DESIGN.md (aussi docs/DESIGN.md, BRAND.md). S'il existe, lisez-le avant de toucher à l'interface ; ses règles et tokens l'emportent sur votre goût. S'il n'existe pas et que le travail est plus qu'une petite correction, créez-en un à partir du modèle en lisant le code : les vrais tokens depuis la config CSS/Tailwind, les vraies polices, les vrais composants. Marquez comme inféré tout ce que vous avez déduit.

Mettez à jour DESIGN.md lorsqu'une session prend une décision durable (un nouveau token, une direction rejetée et pourquoi). C'est ainsi que la session suivante évite de régresser vers les valeurs par défaut.

2. Décider de la direction

Nommez d'abord le mode. Il définit le niveau d'audace que la surface mérite :

• Persuader (pages de vente, tarifs, lancement) : le design est le produit ; engagez un point de vue.
• Opérer (UI d'application, tableaux de bord, paramètres, formulaires) : précision et retenue ; les motifs familiers gagnent leur place ; la marque vit dans les détails.
• Lire (docs, articles, journaux de modifications) : structurez pour la compréhension, puis rendez la lecture agréable.
• Expérience (portfolios, vitrines, jeux) : le travail prime ; l'interface s'efface.

Vous affinez ou vous refaites ? Affiner conserve l'identité actuelle, le contenu et le comportement et améliore à l'intérieur. Refondre conserve les faits et la fonction du produit mais remplace entièrement l'apparence. Ne faites jamais la moitié du chemin en peaufinant un look que vous comptez jeter.

Ensuite planifiez en deux passes avant d'écrire du code.

Première passe, le plan :

• Tâche : qui est présent, ce dont il a besoin en premier, l'action suivante.
• Palette : quatre à six valeurs hexadécimales nommées, avec l'endroit où l'accent est autorisé.
• Typographie : polices et leurs rôles, l'échelle, les chiffres.
• Mise en page : une phrase et un wireframe ASCII approximatif ; alignement explicité.
• L'élément audacieux : l'unique élément mémorable. Tout autour reste discret.

Deuxième passe, le test générique : auriez-vous produit ce plan pour n'importe quel brief similaire ? Vérifiez-le par rapport aux apparences par défaut de l'IA actuelles, qui changent avec le temps. Fond crème avec une police à empattement et un accent terre cuite, presque noir avec un accent acide, et les traits fins de journal sont les clusters d'aujourd'hui, comme les dégradés violets l'étaient l'année dernière. Si une partie du plan correspond à un défaut que le brief n'a pas demandé, remplacez-la et notez ce que vous avez changé et pourquoi. Les propres mots du brief l'emportent toujours, y compris quand il demande un de ces looks.

Choisissez dans l'univers du sujet : ses matériaux, lieux, artefacts et vocabulaire. Le site d'un promeneur de chiens et le tableau de bord d'un analyste ne doivent pas pouvoir échanger leurs palettes.

Quand l'utilisateur fournit des références, étudiez-les correctement : étude de référence extrait les styles calculés des sites en direct pour que vous empruntiez les relations (échelle, rythme, densité), pas la décoration de surface.

3. Construire dans le système du produit

• Utilisez les tokens, primitives et composants existants. Ajoutez un token avant d'ajouter une valeur ponctuelle.
• Contenu réel uniquement : vrais noms, longs noms, vrais nombres, données vides. Jamais de lorem ipsum, jamais de métriques inventées pour remplir une mise en page.
• Concevez les états avec l'écran : chargement, vide, erreur, succès, désactivé, débordement. Un état vide qui ressemble à un bug est un bug.
• Masquez ce qui n'a rien à dire. Zéro lignes, zéro soldes et graphiques vides deviennent un état vide honnête ou disparaissent ; pas de murs de zéros.
• Les en-têtes sont des libellés. Un sous-titre qui réexplique l'en-tête est supprimé.
• Le mobile est sa propre mise en page : réorganisez par priorité, utilisez des rails horizontaux de défilement là où le bureau utilise des grilles, dvh/svh pas 100vh, des inputs en 16px ou plus grand, des cibles tactiles de 44px.

Tenez la ligne sur la base de qualité en construisant, pas comme une passe finale. Pour toute animation ou transition, lisez d'abord motion : un moment orchestré, un petit système de temporisation, sans coupure, avec gestion du mouvement réduit, et visionné comme un film image par image.

4. Regardez-la

node <skill-dir>/scripts/shoot.mjs http://localhost:3000/page --full          # 390 + 1440, clair + sombre
node <skill-dir>/scripts/shoot.mjs http://localhost:3000/page --widths 320,390,768,1440 --themes light
node <skill-dir>/scripts/shoot.mjs http://localhost:3000/page --click '[aria-controls=menu]' --widths 390

Ouvrez chaque capture d'écran et lisez-la vraiment. Ensuite parcourez, dans cet ordre :

1. Première lecture : plissez les yeux. La chose la plus importante est-elle la plus proéminente ? Pouvez-vous dire ce que c'est et quoi faire en trois secondes ?
2. Cassé : débordement, texte coupé, calques qui se chevauchent, mots isolés, focus invisible, contraste en mode sombre. shoot.mjs signale plusieurs de ces problèmes ; vérifiez sa sortie.
3. Hiérarchie et rythme : plus d'espace au-dessus d'un titre qu'en dessous ; espacements cohérents dans les groupes, plus grands entre les groupes ; une action primaire par vue.
4. Générique : lancez l'analyse de deslop ou vérifiez les anti-patrons. Un étranger devinerait-il ce produit à partir d'une capture d'écran avec le logo retiré ?
5. Qualité : alignement au pixel près en 2x, équilibre optique des icônes et du texte, chiffres tabulaires dans les colonnes.

Corrigez le pire problème, reprenez la capture, répétez. Comparez avec les références à la même largeur et au même état. Deux ou trois cycles complets est normal pour un nouveau travail.

5. Terminer

Rapportez les captures et les états que vous avez inspectés (largeurs, thèmes), les décisions que vous avez prises, et tout ce qui n'a pas été inspecté (états authentifiés que vous n'avez pas pu atteindre, données réelles que vous n'aviez pas). Validez les modifications de DESIGN.md avec l'interface.

Règles

• Le brief de l'utilisateur et DESIGN.md priment sur ce skill. Si la marque est des dégradés violets, ce sont des dégradés violets.
• Pas de nouvelle bibliothèque UI, jeu d'icônes ou police pour un changement local.
• N'inventez pas de preuve sociale, témoignages, logos, nombres d'utilisateurs ou "approuvé par".
• Ne simulez pas de vivacité : pas de points "Live" pulsants, de tickers ou d'activité sauf si des données réelles les justifient à cette cadence ("Mise à jour toutes les 10s" quand c'est vrai).
• Ne fusionnez jamais des états distincts (soumis, accepté, confirmé) en une seule coche de succès.