Design — Interfaces distinctives, zéro AI slop

Les LLMs sont des machines à moyennes statistiques. Leur corpus d'entraînement (2019–2024) est saturé de tutoriels Tailwind, démos Shadcn et clones SaaS. Le résultat par défaut est toujours le même : boutons bg-indigo-500, Inter partout, hero en dégradé violet-bleu, trois cartes icônes en ligne, glassmorphism comme "premium". Ce n'est pas du design — c'est de la moyenne statistique. Ce skill existe pour l'éviter.

Pré-requis

• Consulter DESIGN_SYSTEM.md s'il existe — les choix du projet priment sur les recommandations de ce skill

Chargement des références

Avant de générer du code UI, lire avec Read les guides pertinents selon le type de travail :

Type de travail	Références à lire
Landing page / site web	reference/spatial.md, reference/typography.md, reference/color.md, reference/personality.md
App / dashboard	reference/spatial.md (section dashboards), reference/interaction.md, reference/typography.md
Composants UI / formulaires	reference/interaction.md, reference/accessibility.md
Animations / transitions	reference/motion.md, reference/motion-recipes.md
Responsive / mobile	reference/responsive.md
Texte / microcopy / copywriting	reference/copywriting.md, reference/personality.md, reference/ux-writing.md
Refonte / changement de design	reference/blacklist.md + les guides du type de travail concerné
SEO / metadata / partage social	reference/metadata.md

Ne pas tout lire — lire ce qui est pertinent pour la tâche en cours. 2-3 Read ciblés suffisent.

---

Step 0 — Avant d'écrire une seule ligne

Déconstruire (ce que ce n'est PAS)

1. Qu'est-ce que ce n'est PAS ? Lister 5 clichés UI que l'IA produirait par défaut pour ce brief. Les bannir explicitement.
2. Qui n'est PAS l'audience ? Le slop IA cible "des devs qui veulent du moderne". Designer pour un humain réel avec un goût, un contexte et un état émotionnel spécifiques.

Construire (ce que c'est)

3. Visual thesis : Une phrase qui décrit le mood, la matière et l'énergie. Ex: "Éditorial austère, papier chaud, énergie lente".
4. Content plan : La séquence des sections — Hero → Support → Detail → CTA final. Chaque section a un seul but, un seul visuel dominant, une seule action.
5. Interaction thesis : 2-3 concepts de mouvement qui définissent l'atmosphère. Ex: "reveal au scroll des sections, parallaxe subtile sur le hero, hover lift sur les éléments actionnables".
6. Le UN truc mémorable : Une signature visuelle qui rendrait une capture d'écran instantanément reconnaissable. L'exécuter sans compromis.

---

Blacklist — Ne jamais utiliser par défaut

Détails complets et alternatives dans reference/blacklist.md.

Couleurs

indigo-500 / violet-600 / purple-* comme primaire. Dégradé bleu-violet en hero. Gradients aurora/mesh. Teal ou cyan comme accent "tech" sur fond sombre. Fond blanc + texte gris + bouton indigo. Noir pur (#000) ou blanc pur (#fff).

A la place : Couleurs qui portent un sens pour CE projet. Chercher dans la mode, le print, la nature — pas Dribbble. Max 3 couleurs actives. Voir reference/color.md.

Typographie

Inter, Roboto, Poppins, Space Grotesk — bannis. Arial/system-ui comme choix de design — jamais comme statement.

A la place : Polices qui méritent leur place. Display : Playfair Display, Unbounded, Cabinet Grotesk, Syne, Fraunces, Instrument Serif, Bebas Neue, Neue Haas Grotesk. Voir reference/typography.md.

Layouts

Grille 3 colonnes d'icônes. Hero centré + sous-titre + 2 CTAs. Sidebar gauche + contenu + rail droit. Bento grid. Cartes pour tout. Rang de metric cards en haut de dashboard.

A la place : Asymétrie, colonnes décalées, déséquilibre intentionnel. Espace négatif généreux OU densité informationnelle — pas le milieu médiocre. Layouts éditoriaux. Voir reference/spatial.md.

Effets visuels

Glassmorphism. shadow-lg sur tout. Texte en dégradé sur les titres. Blobs animés. Bordures lumineuses. Particules/points flottants. Formes géométriques décoratives.

A la place : Ombres dures avec couleur (box-shadow: 4px 4px 0 #1C1410). Texture bruit/grain. Bordures comme éléments structurels. Texture subtile : lin, papier, béton.

Composants

rounded-xl sur tout — varier intentionnellement. Bouton CTA générique indigo. Footer 4 colonnes. État vide icône + texte gris. Modals sans nécessité. Voir reference/interaction.md.

Emojis dans les interfaces

Jamais d'emojis dans les interfaces générées : titres, boutons, labels, badges, listes, navigation, états vides, messages d'erreur. Les emojis remplacent un vrai travail d'iconographie et de hiérarchie visuelle. Utiliser de la typographie, de la couleur ou des icônes SVG.

---

Système de couleurs

Ne pas choisir des couleurs au hasard. Construire un système :

DOMINANT (60%) : La base — fonds, grandes surfaces
SECONDAIRE (30%) : Support — cartes, panneaux, éléments secondaires
ACCENT (10%) : L'impact — CTAs, highlights, interactions clés
NEUTRE : Texte, bordures, séparateurs — toujours teinté chaud ou froid

Construction :

1. Choisir l'ACCENT d'abord — spécifique au registre émotionnel du produit
2. DOMINANT = version désaturée de la température de l'accent
3. SECONDAIRE = étape entre dominant et accent en valeur
4. NEUTRE = teinte chaude ou froide, jamais gris pur

Méthodes qui fonctionnent :

• Monochrome avec contraste de valeur extrême (noir encre + blanc cassé chaud + un accent saturé)
• Tons terre : terracotta, ocre, ardoise, sauge — sous-utilisés en tech
• Primaires désaturées : rouge poudreux, denim fané, vert forêt
• Fonds sombres chauds : #1C1410, #1A1A14, #160D0D

Test : La palette fonctionne en 1-bit (noir/blanc) ? Bonne structure. Existerait dans un contexte non-tech (mode, édition, gastronomie) ? Distinctive.

Consulter reference/color.md pour OKLCH, neutres teintés et dark mode.

---

Système typographique

DISPLAY : Une police expressive pour titres, grands chiffres, texte hero
BODY : Une police lisible pour paragraphes, labels UI, descriptions
MONO : Pour code, données, contenu technique (optionnel mais distinctif)

Échelle — utiliser une vraie échelle, pas des tailles arbitraires : 12 / 14 / 16 / 20 / 24 / 30 / 36 / 48 / 60 / 72 / 96px — choisir 4-5 tailles, assigner des rôles, s'y tenir.

Type comme design :

• font-size: clamp(3rem, 8vw, 7rem) pour le type display fluide
• letter-spacing: -0.04em sur grands titres (serré = moderne)
• letter-spacing: 0.12em + uppercase pour labels et légendes
• line-height: 1.1 pour display, 1.6 pour body

Utilitaires CSS obligatoires :

• text-balance sur les headings (répartition uniforme des lignes)
• text-pretty sur le body/paragraphes (évite les orphelins)
• tabular-nums sur les données chiffrées (alignement colonnes)
• truncate ou line-clamp pour les UI denses
• Ne jamais modifier letter-spacing sans demande explicite

Consulter reference/typography.md pour rythme vertical, OpenType et chargement.

---

Mouvement — Intentionnel, pas décoratif

Un reveal d'entrée bien timé > une douzaine de micro-interactions éparpillées.

• Durée : 150ms pour le feedback UI, 300-500ms pour les reveals, 700ms max pour les transitions de page
• Easing : exponentiel (ease-out-quart/quint/expo) pour une décélération naturelle. Jamais bounce ou elastic — daté et kitsch.
• Ne jamais animer plus de 3 éléments simultanément
• prefers-reduced-motion est obligatoire, pas optionnel
• Animer uniquement transform et opacity — tout le reste cause un recalcul de layout
• Ne jamais ajouter d'animation sauf si explicitement demandé

Performance critique :

• Ne jamais intercaler lectures et écritures DOM dans le même frame (layout thrashing)
• Ne jamais piloter d'animation depuis scrollTop/scrollY/événements scroll — utiliser animation-timeline: view() ou Scroll Timelines
• Pas de boucle requestAnimationFrame sans condition d'arrêt
• will-change uniquement quand l'animation est imminente — retirer après
• Blur animé ≤ 8px, uniquement pour des effets ponctuels, jamais en continu
• Pas d'animation de CSS variables héritées — scoper localement

Consulter reference/motion.md pour courbes, stagger, FLIP et performance perçue. Consulter reference/motion-recipes.md pour les 10 patterns d'animation concrets (scroll reveal, stagger, parallax tilt, magnetic button, text scramble, SVG draw, shared layout morph...).

---

La méthode de contrainte

Quand le brief est vague, imposer UNE contrainte créative et l'exécuter à fond plutôt que de rendre chaque choix médiocre :

• Couleur : Monochromatique — une seule teinte, tout le travail par la valeur
• Typo : Une seule police, variation de graisse et taille uniquement
• Layout : Zéro border-radius — tout est anguleux
• Mouvement : Zéro animation — composition purement statique
• Composant : Zéro carte — l'information vit en lignes, colonnes ou forme libre

Un design construit autour d'une contrainte claire est 10x plus mémorable qu'un design qui utilise toutes les techniques à mi-force.

---

Accessibilité — Intégrée, pas optionnelle

L'accessibilité n'est pas une couche à ajouter après — elle fait partie du design. Les manquements d'accessibilité sont des bugs, pas des suggestions.

Règles impératives (violations = bloquant) :

• HTML sémantique avant ARIA — <button>, <nav>, <main> plutôt que des <div> avec rôles
• Labels sur chaque input, alt sur chaque image informative
• Contrastes WCAG AA : 4.5:1 texte normal, 3:1 grand texte et éléments interactifs
• Clavier : tout ce qui est cliquable est focusable, focus visible, Escape ferme les overlays
• Touch targets : 44x44px minimum
• prefers-reduced-motion respecté sur toutes les animations
• Couleur seule : ne jamais communiquer l'information uniquement par la couleur
• Composants primitifs accessibles (Radix, React Aria, Base UI) pour tout ce qui implique focus/clavier — ne jamais reconstruire le comportement clavier à la main
• aria-label sur les boutons icône-only, aria-hidden="true" sur les icônes décoratives
• Ne jamais bloquer le paste dans les <input> ou <textarea>

Détails complets, patterns ARIA par composant et outils de vérification dans reference/accessibility.md.

---

Personnalité — Intentionnelle, pas forcée

Les interfaces sans personnalité sont oubliables. La personnalité IA par défaut (confettis, "Oops!", ton "quirky") est pire. Chaque élément de personnalité sert une fonction : réduire la friction, rassurer, guider ou récompenser.

• Micro-interactions : feedback immédiat (150ms), transitions d'état (300ms), skeleton screens
• Microcopy : états vides qui guident vers l'action suivante, erreurs qui expliquent comment corriger
• Labels : décrivent ce qui va se passer, pas l'action mécanique ("Envoyer le message" > "Submit")
• Jamais : confettis systématiques, emojis dans l'UI, "Yay!", humour dans les erreurs critiques

Détails complets, anti-patterns et exemples dans reference/personality.md.

---

Checklist pré-livraison

Avant de finaliser une UI :

Anti-slop :

• Zéro bg-indigo-*, bg-violet-*, bg-purple-* sauf intention justifiée
• Zéro Inter, Roboto ou Poppins sauf exigence de marque
• Zéro glassmorphism
• Zéro texte en dégradé sur les titres
• Zéro grille 3 colonnes d'icônes
• Zéro shadow-lg/shadow-xl appliqué universellement
• Zéro emoji dans l'interface (titres, boutons, labels, badges, navigation)
• border-radius varie par type d'élément, pas rounded-xl partout
• Zéro gradient (sauf demande explicite) — jamais violet/multicolore
• Zéro glow effect comme affordance primaire

Technique :

• h-dvh au lieu de h-screen (viewport dynamique mobile)
• text-balance sur headings, text-pretty sur body
• tabular-nums sur données chiffrées
• Animations sur transform/opacity uniquement
• Pas d'animation layout (width, height, top, left, margin, padding)
• Pas de will-change hors animation active
• Pas de useEffect pour ce qui peut être du render logic
• Échelle de z-index fixe (pas de z-[9999] arbitraire)

Accessibilité :

• HTML sémantique — pas de <div> cliquables
• Contrastes WCAG AA vérifiés
• Navigation clavier fonctionnelle, focus visible
• prefers-reduced-motion géré
• Touch targets 44x44px minimum

Cohérence marque :

• Couleurs, typo et spacing conformes au DESIGN_SYSTEM.md (si existant)
• Aucune valeur hardcodée qui devrait être un token

Identité :

• UN élément qui rendrait cette capture d'écran reconnaissable

Litmus checks (répondre oui à chaque) :

• La marque/le produit est reconnaissable au premier écran ?
• Il y a un ancrage visuel fort (pas juste du texte) ?
• La page se comprend en ne lisant que les titres ?
• Chaque section a un seul job ?
• Les cards sont-elles vraiment nécessaires ? (sinon, layout)
• Le motion améliore la hiérarchie ou l'atmosphère ? (sinon, supprimer)
• Le design resterait premium si on enlevait toutes les ombres décoratives ?
• Supprimer 30% du texte améliorerait la page ? (si oui, continuer à couper)

---

Références esthétiques (étudier, ne pas copier)

Bon goût, zéro slop :

• Teenage Engineering — orange industriel, grille utilitaire, esthétique machine
• Loewe — luxe terreux, espacement éditorial, couleur retenue
• A24 — neutres sombres, texture grain-film, confiance typographique
• Linear (pré-mainstream) — l'original, pas les copies
• Vercel — retenue extrême, monochrome bien fait
• Stripe Docs — le design d'information comme esthétique
• Are.na — brut, anti-design, laideur intentionnelle
• Basecamp — chaleureux, humain, délibérément non-tech

Étudier hors tech : Style typographique international suisse. Magazines 032c, Apartamento, Garage. Architecture brutaliste en UI. Design produit japonais (Muji, Braun).

---

Comportement

• Consulter DESIGN_SYSTEM.md en priorité — les choix du projet priment. Signaler toute dérive (couleur, typo, spacing non conforme aux tokens définis)
• Signaler les anti-patterns AI slop comme des problèmes de qualité
• Signaler les manquements d'accessibilité comme des bugs, pas des suggestions
• Proposer des alternatives distinctives avec du code concret
• Ne pas bloquer — guider et signaler, sans imposer
• Varier — chaque interface doit être unique. Alterner thèmes clairs/sombres, polices, esthétiques. Ne JAMAIS converger vers les mêmes choix entre les générations

Tool Boundaries

• Changements minimaux et ciblés — ne pas réécrire le code environnant
• Ne pas migrer de librairie UI, animation ou CSS sauf demande explicite
• Ne pas refactorer du code hors du périmètre design
• Appliquer les règles dans le stack existant du projet