Skill Design Lab

Ce skill implémente un workflow complet d'exploration de conception : entretien, génération de variations, collecte de retours, affinage, aperçu et finalisation.

Déclencheurs

design lab
prototype
mockup
wireframe
variation
design interview
ui exploration
design options
design feedback
compare designs

CRITIQUE : Comportement de nettoyage

Tous les fichiers temporaires DOIVENT être supprimés quand le processus se termine, que ce soit par :

L'utilisateur confirme le design final → nettoyage, puis génération du plan
L'utilisateur abandonne/annule → nettoyage immédiat, aucun plan généré

Ne jamais laisser traîner .claude-design/ ou les routes __design_lab. Si l'utilisateur dit « cancel », « abort », « stop » ou « nevermind » à un moment quelconque, confirmez puis supprimez tous les artefacts temporaires.

Phase 0 : Détection préalable

Avant de commencer l'entretien, détectez automatiquement :

Gestionnaire de paquets

Vérifiez les fichiers verrous dans la racine du projet :

pnpm-lock.yaml → utiliser pnpm
yarn.lock → utiliser yarn
package-lock.json → utiliser npm
bun.lockb → utiliser bun

Détection du framework

Vérifiez les fichiers de configuration :

next.config.js ou next.config.mjs ou next.config.ts → Next.js
- Vérifiez le répertoire app/ → App Router
- Vérifiez le répertoire pages/ → Pages Router
vite.config.js ou vite.config.ts → Vite
remix.config.js → Remix
nuxt.config.js ou nuxt.config.ts → Nuxt
astro.config.mjs → Astro

Détection du système de style

Vérifiez les dépendances package.json et les fichiers de configuration :

tailwind.config.js ou tailwind.config.ts → Tailwind CSS
@mui/material dans les dépendances → Material UI
@chakra-ui/react dans les dépendances → Chakra UI
antd dans les dépendances → Ant Design
styled-components dans les dépendances → styled-components
@emotion/react dans les dépendances → Emotion
Fichiers .css ou .module.css → CSS Modules

Vérification de la mémoire de conception

Cherchez un fichier Design Memory existant :

docs/design-memory.md
DESIGN_MEMORY.md
.claude-design/design-memory.md

S'il existe, lisez-le et utilisez-le pour préremplir les valeurs par défaut et sauter les questions redondantes.

Inférence de style visuel (CRITIQUE)

N'UTILISEZ PAS de styles génériques/prédéfinis. Extrayez le langage visuel du projet :

Si Tailwind détecté, lisez tailwind.config.js ou tailwind.config.ts:

// Extraire et utiliser :
theme.colors      // Palette de couleurs
theme.spacing     // Échelle d'espacement
theme.borderRadius // Valeurs de rayon
theme.fontFamily  // Typographie
theme.boxShadow   // Système d'élévation

Si les variables CSS existent, lisez globals.css, variables.css ou définitions :root:

:root {
  --color-*     /* Jetons de couleur */
  --spacing-*   /* Jetons d'espacement */
  --font-*      /* Jetons de typographie */
  --radius-*    /* Jetons de rayon de bordure */
}

Si une bibliothèque UI est détectée (MUI, Chakra, Ant), lisez la configuration de thème :

MUI : theme.ts ou appel createTheme()
Chakra : theme/index.ts ou appel extendTheme()
Ant : prop theme du ConfigProvider

Scannez toujours les composants existants pour comprendre les motifs :

Trouvez 2-3 boutons existants → notez leurs motifs de style
Trouvez 2-3 cartes existantes → notez le remplissage, les bordures, les ombres
Trouvez des formulaires existants → notez les styles d'entrée, le placement des labels
Trouvez de la typographie existante → notez les tailles de titre, le corps du texte

Stockez les styles déduits dans le Design Brief pour un usage cohérent dans toutes les variations.

Phase 1 : Entretien

Utilisez l'outil AskUserQuestion pour toutes les étapes de l'entretien. Adaptez les questions en fonction de la Design Memory si elle existe.

Étape 1.1 : Portée et cible

Posez ces questions (peuvent être combinées en une seule AskUserQuestion avec plusieurs questions) :

Question 1 : Portée

En-tête : « Portée »
Question : « Concevons-nous un composant unique ou une page complète ? »
Options :
- « Composant » - Un élément UI réutilisable (bouton, carte, formulaire, modal, etc.)
- « Page » - Une mise en page de page ou d'écran complète

Question 2 : Nouveau ou refonte

En-tête : « Type »
Question : « S'agit-il d'une nouvelle conception ou d'une refonte de quelque chose d'existant ? »
Options :
- « Nouveau » - Créer à partir de zéro
- « Refonte » - Améliorer un composant/page existant

Si « Refonte » sélectionné, posez : Question 3 : Chemin existant

En-tête : « Emplacement »
Question : « Quel est le chemin de fichier ou la route de l'UI existante ? »
Options : (laissez l'utilisateur fournir via « Autre »)

Si la cible n'est pas claire, proposez un nom basé sur les motifs du référentiel et confirmez.

Étape 1.2 : Points douloureux et inspiration

Question 1 : Points douloureux

En-tête : « Problèmes »
Question : « Quels sont les principaux points douloureux du design actuel (ou que devrait éviter cette nouvelle conception) ? »
Options :
- « Trop encombré/dense » - Surcharge d'informations, difficile à scanner
- « Hiérarchie peu claire » - Les actions principales ne sont pas évidentes
- « Mauvaise expérience mobile » - Ne fonctionne pas bien sur petits écrans
- « Apparence dépassée » - Semble ancien ou incohérent avec la marque
multiSelect: true

Question 2 : Inspiration visuelle

En-tête : « Style visuel »
Question : « Quels produits ou marques devrais-je référencer pour l'inspiration visuelle ? »
Options :
- « Stripe » - Épuré, minimal, fiable
- « Linear » - Dense, centré sur le clavier, orienté développeurs
- « Notion » - Flexible, centré sur le contenu, ludique
- « Apple » - Premium, spacieux, affiné
multiSelect: true

Question 3 : Inspiration fonctionnelle

En-tête : « Interactions »
Question : « Quels motifs d'interaction devrais-je émuler ? »
Options :
- « Édition inline » - Éditer sur place sans modales
- « Divulgation progressive » - Afficher plus au besoin
- « Mises à jour optimistes » - Retour instantané, synchronisation en arrière-plan
- « Raccourcis clavier » - Efficacité de l'utilisateur avancé

Étape 1.3 : Direction de marque et de style

Question 1 : Adjectifs de marque

En-tête : « Ton de marque »
Question : « Quels 3-5 adjectifs décrivent le ressenti de marque souhaité ? »
Options :
- « Minimal » - Épuré, simple, sans encombrement
- « Premium » - Haut de gamme, poli, affiné
- « Ludique » - Amusant, amical, accessible
- « Utilitaire » - Fonctionnel, efficace, pragmatique
multiSelect: true

Question 2 : Densité

En-tête : « Densité »
Question : « Quelle densité d'information préférez-vous ? »
Options :
- « Compact » - Plus d'informations visibles, espacement resserré
- « Confortable » - Espacement équilibré, scan facile
- « Spacieux » - Espace blanc généreux, attention concentrée

Question 3 : Mode sombre

En-tête : « Mode sombre »
Question : « Le mode sombre est-il obligatoire ? »
Options :
- « Oui » - Doit supporter le mode sombre
- « Non » - Mode clair uniquement
- « Souhaitable » - Support si facile, pas obligatoire

Étape 1.4 : Persona et travail à accomplir

Question 1 : Utilisateur principal

En-tête : « Utilisateur »
Question : « Qui est l'utilisateur final principal ? »
Options :
- « Développeur » - Technique, orienté clavier
- « Designer » - Visuel, orienté détails
- « Utilisateur métier » - Efficacité, moins technique
- « Consommateur final » - Grand public, compétences techniques variées

Question 2 : Contexte

En-tête : « Contexte »
Question : « Quel est le contexte d'utilisation principal ? »
Options :
- « Desktop en premier » - Principalement utilisé sur écrans plus grands
- « Mobile en premier » - Principalement utilisé sur téléphones
- « Les deux également » - Doit bien fonctionner sur tous les appareils

Question 3 : Tâches clés

En-tête : « Tâches clés »
Question : « Quelles sont les 3 tâches principales que les utilisateurs doivent accomplir ? »
(Laissez l'utilisateur fournir via « Autre » - ceci est ouvert)

Étape 1.5 : Contraintes

Question 1 : Éléments à conserver

En-tête : « Conserver »
Question : « Y a-t-il des éléments qui doivent être préservés ? »
Options :
- « Copie/labels existants » - Conserver le texte actuel
- « Champs/entrées actuels » - Conserver la structure de formulaire
- « Structure de navigation » - Conserver la navigation actuelle
- « Aucun » - Libre de tout changer

Question 2 : Contraintes techniques

En-tête : « Contraintes »
Question : « Y a-t-il des contraintes techniques ? »
Options :
- « Pas de nouvelles dépendances » - Utiliser uniquement les bibliothèques existantes
- « Utiliser les composants existants » - Construire sur le système de conception actuel
- « Doit être accessible (WCAG) » - Exigences d'accessibilité strictes
- « Aucune » - Aucune contrainte spéciale
multiSelect: true

Phase 2 : Générer le Design Brief

Après l'entretien, créez un Design Brief structuré en JSON et sauvegardez dans .claude-design/design-brief.json:

{
  "scope": "component|page",
  "isRedesign": true|false,
  "targetPath": "src/components/Example.tsx",
  "targetName": "Example",
  "painPoints": ["Trop dense", "Action principale peu claire"],
  "inspiration": {
    "visual": ["Stripe", "Linear"],
    "functional": ["Validation inline"]
  },
  "brand": {
    "adjectives": ["minimal", "fiable"],
    "density": "comfortable",
    "darkMode": true
  },
  "persona": {
    "primary": "Developer",
    "context": "desktop-first",
    "keyTasks": ["Compléter le paiement", "Vérifier la commande", "Appliquer une réduction"]
  },
  "constraints": {
    "mustKeep": ["existing fields"],
    "technical": ["no new dependencies", "WCAG accessible"]
  },
  "framework": "nextjs-app",
  "packageManager": "pnpm",
  "stylingSystem": "tailwind"
}

Affichez un résumé à l'utilisateur avant de continuer.

Phase 3 : Générer le Design Lab

Structure de répertoire

Créez tous les fichiers sous .claude-design/:

.claude-design/
├── lab/
│   ├── page.tsx                 # Page principale du lab (dépend du framework)
│   ├── variants/
│   │   ├── VariantA.tsx
│   │   ├── VariantB.tsx
│   │   ├── VariantC.tsx
│   │   ├── VariantD.tsx
│   │   └── VariantE.tsx
│   ├── components/
│   │   └── LabShell.tsx         # Wrapper de mise en page du lab
│   ├── feedback/                # Système de retour interactif
│   │   ├── types.ts             # Interfaces TypeScript
│   │   ├── selector-utils.ts    # Identification d'éléments
│   │   ├── format-utils.ts      # Formatage de retours
│   │   ├── FeedbackOverlay.tsx  # Composant de superposition principal
│   │   └── index.ts             # Exports du module
│   └── data/
│       └── fixtures.ts          # Données de test partagées
├── design-brief.json
└── run-log.md

Configuration du système de retours (CRITIQUE - NE JAMAIS SAUTER)

La FeedbackOverlay est la FONCTIONNALITÉ PRINCIPALE du Design Lab. Sans elle, les utilisateurs ne peuvent pas fournir de retours interactifs. NE JAMAIS générer un Design Lab sans la FeedbackOverlay.

Stratégie de fiabilité : Pour éviter les problèmes de chemin d'import dans différentes configurations de projet, créez la FeedbackOverlay directement dans le répertoire de route (par exemple, app/design-lab/FeedbackOverlay.tsx), PAS dans .claude-design/. Cela garantit qu'un import relatif simple (./FeedbackOverlay) fonctionne toujours.

Fichiers obligatoires dans le répertoire de route :

app/design-lab/           # ou app/__design_lab/ si les underscores fonctionnent
├── page.tsx              # Page principale du lab avec variantes
└── FeedbackOverlay.tsx   # Composant de superposition autonome (copié des modèles)

Source du modèle : design-and-refine/templates/feedback/FeedbackOverlay.tsx

Pourquoi cette approche :

Les chemins .claude-design/ peuvent échouer selon les configurations de bundler
Les imports relatifs du même répertoire fonctionnent toujours
Le répertoire de route est supprimé pendant le nettoyage de toute façon

Intégration de route

Next.js App Router : Créez app/__design_lab/page.tsx qui importe depuis .claude-design/lab/

Next.js Pages Router : Créez pages/__design_lab.tsx qui importe depuis .claude-design/lab/

Vite React :

Si React Router existe : ajouter route à /__design_lab
Si pas de routeur : créer un rendu conditionnel dans App.tsx basé sur le paramètre query ?design_lab=true

Autres frameworks : Créez la route temporaire la plus appropriée pour le framework détecté.

Directives de génération de variantes

IMPORTANT : Lisez DESIGN_PRINCIPLES.md pour les meilleures pratiques en UX, interaction et mouvement. Mais N'UTILISEZ PAS de styles visuels prédéfinis—déduisez-les du projet.

Appliquez les principes universels (depuis DESIGN_PRINCIPLES.md) :

UX : Heuristiques de Nielsen, réduction de la charge cognitive, divulgation progressive
Comportement des composants : États des boutons, anatomie des formulaires, structure des cartes
Interaction : Motifs de retour, gestion d'état, mises à jour optimistes
Mouvement : Timing (150-300ms), easing (ease-out pour les entrées, ease-in pour les sorties)
Accessibilité : États de focus, motifs ARIA, cibles tactiles (44px min)

Déduisez les styles visuels du projet :

Couleurs → depuis la config Tailwind, les variables CSS ou les composants existants
Typographie → depuis les en-têtes existants, le corps du texte dans le code
Espacement → depuis l'échelle d'espacement du projet ou les motifs existants
Rayon de bordure → depuis les cartes, boutons, entrées existants
Ombres → depuis les composants élevés existants

Chaque variante DOIT explorer un axe de conception différent. Ne créez pas de variations mineures—rendez-les significativement distinctes. Utilisez le langage visuel existant du projet pour toutes les variantes.

Variante A : Focus sur la hiérarchie des informations

Restructurer la hiérarchie de contenu (qu'est-ce qui est le plus important ?)
Appliquer la proximité Gestalt—regrouper les éléments connexes
Une action principale par vue
Utiliser l'échelle de typographie existante pour créer des niveaux clairs

Variante B : Exploration du modèle de mise en page

Essayer une approche de mise en page différente (carte vs liste vs tableau vs split-pane)
Appliquer l'anatomie des cartes ou les motifs de comportement de tableau depuis DESIGN_PRINCIPLES
Considérer le comportement réactif à chaque point de rupture
Utiliser le système de grille/mise en page existant du projet

Variante C : Variation de densité

Si le brief dit « confortable », essayez une version plus compacte
Si le brief dit « compact », essayez une version plus spacieuse
Utiliser les jetons d'espacement existants du projet—appliquez-les simplement différemment
Afficher les compromis : plus de données visibles vs scan plus facile

Variante D : Modèle d'interaction

Motif d'interaction différent (modal vs inline vs panel vs drawer)
Appliquer les motifs de retour : immédiat → progression → achèvement
Implémenter tous les états requis (chargement, erreur, vide, désactivé)
Considérer les mises à jour optimistes pour les actions non destructrices

Variante E : Direction expressive

Pousser la direction de marque décrite par l'utilisateur dans l'entretien
Explorer différents usages des jetons de conception existants du projet
Plus ou moins d'utilisation d'ombres, bordures, couleurs de fond
Appliquer le mouvement où il ajoute du sens (survol, focus, transitions)

Exigences de la page du Lab

La page du Design Lab doit inclure :

En-tête avec :
- Résumé du Design Brief (cible, portée, exigences clés)
- Instructions pour l'examen
Grille de variantes avec :
- Labels clairs (A, B, C, D, E)
- Justification brève pour chaque variante (« Pourquoi cela existe »)
- La variante réellement rendue
- Notes mettant en évidence les différences clés
- IMPORTANT : Chaque conteneur de variante doit avoir un attribut data-variant="X" (où X est A, B, C, D, E, ou F). Ceci est requis pour que le système de retours identifie à quelle variante appartiennent les commentaires.
Comportement réactif :
- Desktop : grille côte à côte (2-3 colonnes)
- Mobile : scroll horizontal ou onglets
Données partagées :
- Toutes les variantes utilisent les mêmes données de test depuis data/fixtures.ts
- Assure une comparaison équitable
Superposition de retours (CRITIQUE - JAMAIS OMETTRE) :

⚠️ CECI EST L'EXIGENCE LA PLUS IMPORTANTE ⚠️

La FeedbackOverlay permet aux utilisateurs de cliquer sur des éléments et de laisser des commentaires. Sans elle, le Design Lab est juste une page statique sans moyen de collecter des retours structurés.
- Créez FeedbackOverlay.tsx dans le MÊME répertoire que page.tsx
- Importez avec un chemin relatif : import { FeedbackOverlay } from './FeedbackOverlay'
- Rendez à la FIN de la page, après toutes les variantes
- Passez la prop targetName avec le nom du composant/page
Exemple d'intégration :

import { FeedbackOverlay } from './FeedbackOverlay';  // Import relatif - toujours fonctionne

export default function DesignLabPage() {
  return (
    <div className="min-h-screen bg-background">
      <header>...</header>

      <main>
        <div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-8">
          <div data-variant="A">
            <VariantA />
          </div>
          <div data-variant="B">
            <VariantB />
          </div>
          {/* ... plus de variantes */}
        </div>
      </main>

      {/* CRITIQUE : FeedbackOverlay doit être incluse */}
      <FeedbackOverlay targetName="ComponentName" />
    </div>
  );
}

Si vous oubliez la FeedbackOverlay, l'utilisateur NE PEUT PAS fournir de retours. Cela annule l'objectif entier du Design Lab.

Qualité du code

Conventions :

Suivez les conventions de code existantes du projet (nommage de fichiers, imports, etc.)
Utilisez le système de style détecté (Tailwind, CSS modules, etc.)
Utilisez les composants existants du projet où approprié

Accessibilité (depuis DESIGN_PRINCIPLES) :

HTML sémantique : <button> pas <div onclick>, <nav>, <main>, <section>
Navigation au clavier : tous les éléments interactifs focalisables et opérables
États de focus : :focus-visible visible avec anneau 2px et décalage
Contraste des couleurs : 4.5:1 pour le texte, 3:1 pour les éléments UI
Cibles tactiles : minimum 44x44px
ARIA uniquement quand la sémantique HTML ne suffit pas

États (chaque composant doit avoir) :

Défaut, Survol, Focus, Actif, Désactivé, Chargement, Erreur, Vide
Voir la section « State Handling » de DESIGN_PRINCIPLES

Mouvement :

Utiliser le timing approprié : 150-200ms pour micro-interactions, 200-300ms pour transitions
Utiliser ease-out pour les entrées, ease-in pour les sorties
Respecter prefers-reduced-motion

Phase 4 : Présenter le Design Lab à l'utilisateur

Après génération des fichiers du lab, immédiatement présentez le lab à l'utilisateur. NE PAS essayer de :

Démarrer le serveur de développement vous-même (cela s'exécute pour toujours et bloquera)
Vérifier si les ports sont ouverts
Ouvrir un navigateur
Attendre une réponse du serveur

Que faire

Sortez l'emplacement et l'URL du lab :

✅ Design Lab créé !

J'ai généré 5 variantes de conception dans `.claude-design/lab/`

Pour les visualiser :
1. Assurez-vous que votre serveur de développement est en cours d'exécution (exécutez `pnpm dev` sinon)
2. Ouvrez : http://localhost:3000/__design_lab

Prenez le temps d'examiner les variantes côte à côte, puis revenez et dites-moi :
- Quelle variante gagne (A-E)
- Ce que vous aimez à ce sujet
- Ce qui devrait changer

Passez immédiatement à la Phase 5 - posez les questions de retours. NE ATTENDEZ PAS que l'utilisateur dise qu'il a ouvert le navigateur. Présentez simplement les questions de retours tout de suite afin qu'elles soient prêtes quand l'utilisateur revient.

Pourquoi ne pas démarrer le serveur

Exécuter pnpm dev ou npm run dev démarre un processus long qui ne se termine jamais. Si vous l'exécutez, vous attendrez pour toujours. L'utilisateur a probablement déjà son serveur de développement en cours d'exécution, ou peut le démarrer lui-même dans un autre terminal.

Phase 5 : Collecter les retours

Après présentation de l'URL du lab, l'utilisateur peut fournir des retours de deux façons :

Retours interactifs (recommandé) : Utiliser la superposition intégrée dans le navigateur
Retours manuels : Via AskUserQuestion dans le terminal

Retours interactifs (Méthode principale)

Le Design Lab inclut une superposition de retours de type Figma. Lors de la présentation du lab, incluez ces instructions :

✅ Design Lab créé !

J'ai généré 5 variantes de conception dans `.claude-design/lab/`

Pour visualiser et fournir des retours :
1. Assurez-vous que votre serveur de développement est en cours d'exécution (exécutez `pnpm dev` sinon)
2. Ouvrez : http://localhost:3000/__design_lab

**Pour ajouter des retours :**
1. Cliquez sur le bouton « Add Feedback » (coin inférieur droit)
2. Cliquez sur n'importe quel élément que vous voulez commenter
3. Tapez votre retour et cliquez « Save »
4. Répétez pour tous les éléments que vous voulez commenter
5. Remplissez le champ « Overall Direction » (obligatoire)
6. Cliquez « Submit All Feedback »
7. Collez le texte copié ici dans le terminal

Ou décrivez simplement vos retours manuellement ci-dessous !

Quand l'utilisateur colle des retours, ils seront dans ce format :

## Design Lab Feedback

**Target:** ComponentName
**Comments:** 3

### Variante A
1. **Button** (`[data-testid='submit']`, button avec « Submit »)
   « Rendre ceci plus visible »

### Variante B
1. **Card** (`.product-card`, div avec « Product Name »)
   « J'adore cette mise en page »

### Overall Direction
Aller avec la structure de la Variante B. Appliquer le style de bouton de la Variante A.

Comment analyser et agir sur ces retours :

Lisez d'abord la Direction générale - cela guide votre synthèse
Pour chaque commentaire, localisez l'élément en utilisant :
- Primaire : le sélecteur CSS entre backticks (par exemple, [data-testid='submit'])
- Secondaire : la description de l'élément (par exemple, « bouton avec 'Submit' »)
Appliquez les retours en modifiant le fichier de variante correspondant

Fallback : Retours manuels via AskUserQuestion

Si l'utilisateur préfère ne pas utiliser la superposition interactive (ou colle des retours manuels), utilisez le flux AskUserQuestion ci-dessous :

Étape 1 : Vérifier s'il y a un gagnant

Question 1 : Prêt à choisir ?

En-tête : « Décision »
Question : « Y a-t-il une variante que vous aimez telle quelle ? »
Options :
- « Oui - j'en ai trouvé une que j'aime » - Prêt à sélectionner un gagnant et affiner
- « Non - j'aime des parties de différentes » - Besoin de synthétiser une nouvelle variante

Étape 2A : Si l'utilisateur a trouvé un gagnant

Si l'utilisateur a dit « Oui », posez :

Question 2a : Laquelle ?

En-tête : « Gagnant »
Question : « Quelle variante voulez-vous garder ? »
Options :
- « Variante A » - [description brève de A]
- « Variante B » - [description brève de B]
- « Variante C » - [description brève de C]
- « Variante D » - [description brève de D]
- « Variante E » - [description brève de E]

Question 3a : Des ajustements ?

En-tête : « Ajustements »
Question : « Y a-t-il de petits changements nécessaires, ou c'est bon tel quel ? »
Options :
- « Bon tel quel » - Aucun changement nécessaire, passez à l'aperçu final
- « Petits ajustements nécessaires » - Je vais décrire ce qu'il faut ajuster

Si « Petits ajustements nécessaires », demandez à l'utilisateur de décrire les changements via une saisie de texte.

Ensuite, passez à la Phase 7 : Aperçu final.

Étape 2B : Si l'utilisateur veut synthétiser

Si l'utilisateur a dit « Non - j'aime des parties de différentes », posez :

Question 2b : Qu'aimez-vous de chacune ?

En-tête : « Retours »
Question : « Qu'aimez-vous de chaque variante ? (mentionnez des éléments spécifiques de A, B, C, D, E) »
(Laissez l'utilisateur fournir des retours détaillés via saisie de texte « Autre »)

Format de réponse d'exemple pour guider l'utilisateur :

- A : J'adore la mise en page et l'espacement des cartes
- B : La palette de couleurs semble appropriée
- C : L'interaction au survol est géniale
- D : Rien ne ressort
- E : La hiérarchie de typographie est la plus claire

Ensuite, passez à la Phase 6 : Synthétiser une nouvelle variante.

Phase 6 : Synthétiser une nouvelle variante

Basé sur les retours de l'utilisateur sur ce qu'il aimait de chaque variante :

Créez une nouvelle variante hybride (Variante F) qui combine :
- Les éléments spécifiques que l'utilisateur a relevés de chacune
- Les meilleures décisions structurelles parmi toutes les variantes
- Tous les motifs qui sont apparus dans plusieurs variantes
Remplacez le Design Lab par une vue de comparaison :
- Affichchez la nouvelle Variante F synthétisée en évidence
- Gardez 1-2 des variantes originales qui étaient les plus proches pour comparaison
- Supprimez les variantes qui n'avaient rien que l'utilisateur aimait
Mettez à jour la route /__design_lab pour afficher le nouveau arrangement
Posez à nouveau des questions de retours :

Question : Comment la nouvelle variante ?

En-tête : « Examen »
Question : « Comment semble la variante synthétisée (F) ? »
Options :
- « C'est celle-ci ! » - Passez à l'aperçu final
- « On s'en rapproche » - Besoin d'une autre itération
- « Mauvaise direction » - Laissez-moi clarifier ce que je veux

Si « On s'en rapproche » ou « Mauvaise direction », collectez plus de retours spécifiques et itérez. Supportez plusieurs passes de synthèse jusqu'à ce que l'utilisateur soit satisfait.

Puis passez à la Phase 7 : Aperçu final.

Phase 7 : Aperçu final

Une fois l'utilisateur satisfait :

Créez le répertoire .claude-design/preview/:

.claude-design/preview/
├── page.tsx                    # Page d'aperçu
└── FinalDesign.tsx             # La conception gagnante

Créez une route à /__design_preview
Pour les refonte, incluez une comparaison avant/après :
- Switch de basculement ou split-view
- Afficher l'original à côté du proposé
Posez pour confirmation finale :

Question : Confirmer la conception finale ?

En-tête : « Confirmer »
Question : « Prêt à finaliser cette conception ? »
Options :
- « Oui, finalisez » - Passez au nettoyage et génération du plan d'implémentation
- « Non, elle a besoin de changements » - Dites-moi ce à ajuster
- « Abandon - annuler tout » - Supprimer tous les fichiers temporaires, aucun plan généré

Si « Non, elle a besoin de changements » : collectez des retours et itérez. Si « Abandon » : passez à Gestion de l'abandon ci-dessous.

Gestion de l'abandon

Si l'utilisateur veut annuler/abandonner À N'IMPORTE QUEL MOMENT du processus (pas seulement confirmation finale), il peut dire :

« cancel »
« abort »
« stop »
« nevermind »
« forget it »
« I changed my mind »

Quand l'abandon est détecté :

Confirmez l'abandon :
- « Êtes-vous sûr de vouloir annuler ? Cela supprimera tous les fichiers du design lab que j'ai créés. »
Si confirmé, nettoyez immédiatement :
- Supprimer le répertoire .claude-design/ entièrement
- Supprimer les fichiers de route temporaires (app/__design_lab/, etc.)
- NE PAS générer de plan d'implémentation
- NE PAS mettre à jour la Design Memory
Accusez réception :
- « Exploration de conception annulée. Tous les fichiers temporaires ont été supprimés. Faites-le-moi savoir si vous voulez recommencer depuis zéro plus tard. »

Phase 8 : Finaliser

Quand l'utilisateur confirme (a sélectionné « Oui, finalisez ») :

8.1 : Nettoyage

Supprimer tous les fichiers temporaires :

Supprimer le répertoire .claude-design/ entièrement
Supprimer les fichiers de route temporaires :
- app/__design_lab/ (Next.js App Router)
- pages/__design_lab.tsx (Next.js Pages Router)
- app/__design_preview/
- pages/__design_preview.tsx
- Revenir toute modification App.tsx (Vite)

Règles de sécurité :

SUPPRIMER UNIQUEMENT les fichiers dans .claude-design/
SUPPRIMER UNIQUEMENT les fichiers de route que le plugin a créés
NE JAMAIS supprimer les fichiers créés par l'utilisateur
Vérifier les chemins de fichiers avant suppression

8.2 : Générer le plan d'implémentation

Créez DESIGN_PLAN.md dans la racine du projet :

# Plan d'implémentation de conception : [TargetName]

## Résumé
- **Portée :** [composant/page]
- **Cible :** [chemin de fichier]
- **Variante gagnante :** [A-E]
- **Améliorations clés :** [depuis les retours]

## Fichiers à changer
- [ ] `src/components/Example.tsx` - Refactorisation du composant principal
- [ ] `src/styles/example.css` - Mises à jour de style
- [ ] ... (lister tous les fichiers affectés)

## Étapes d'implémentation
1. [Étape spécifique avec guidance du code]
2. [Étape suivante]
3. ...

## API du composant
- **Props :**
  - `prop1: type` - description
  - ...
- **État :**
  - Exigences d'état interne
- **Événements :**
  - Callbacks et gestionnaires

## États UI requis
- **Chargement :** [description]
- **Vide :** [description]
- **Erreur :** [description]
- **Désactivé :** [description]
- **Validation :** [description]

## Checklist d'accessibilité
- [ ] Navigation au clavier fonctionne
- [ ] États de focus visibles
- [ ] Labels et attributs aria-* corrects
- [ ] Contraste des couleurs conforme WCAG AA
- [ ] Lecteur d'écran testé

## Checklist de test
- [ ] Tests unitaires pour la logique
- [ ] Tests de composant pour le rendu
- [ ] Tests de régression visuelle (si applicable)
- [ ] Test de fumée E2E (si applicable)

## Jetons de conception
- [Tous les nouveaux jetons à ajouter]
- [Jetons existants à utiliser]

---

*Généré par le plugin Design Variations*

8.3 : Mettre à jour la Design Memory

Créez ou mettez à jour DESIGN_MEMORY.md:

Si nouveau fichier :

# Design Memory

## Ton de marque
- **Adjectifs :** [depuis l'entretien]
- **À éviter :** [anti-motifs découverts]

## Mise en page et espacement
- **Densité :** [préférence]
- **Grille :** [si établie]
- **Rayon de coin :** [si cohérent]
- **Ombres :** [si cohérent]

## Typographie
- **En-têtes :** [police, poids utilisés]
- **Corps :** [police, taille]
- **Emphase :** [motifs]

## Couleur
- **Primaire :** [jetons de couleur]
- **Secondaire :** [jetons de couleur]
- **Stratégie neutre :** [approche]
- **Couleurs sémantiques :** [erreur, succès, avertissement]

## Motifs d'interaction
- **Formulaires :** [approche de validation, mise en page]
- **Modales/Drawers :** [quand utiliser quoi]
- **Tableaux/Listes :** [motifs préférés]
- **Retours :** [toast, inline, etc.]

## Règles d'accessibilité
- **Focus :** [approche de focus visible]
- **Labels :** [conventions d'étiquetage]
- **Mouvement :** [support du mouvement réduit]

## Conventions du référentiel
- **Structure des composants :** [organisation des fichiers]
- **Approche de style :** [classes Tailwind, CSS modules, etc.]
- **Primitives existantes :** [Button, Input, Card, etc.]

---

*Mise à jour par le plugin Design Variations*

Si mise à jour du fichier existant :

Ajouter les nouveaux motifs découverts
Mettre à jour toute guidance conflictuelle avec les dernières décisions
Garder le fichier concis et actionnable

Gestion d'erreurs

Framework non détecté

Si le framework ne peut pas être déterminé :

Posez : « Je n'ai pas pu détecter votre framework. Qu'utilisez-vous ? »
Fournissez les options courantes : Next.js, Vite, Create React App, Vue, etc.

Le serveur de développement échoue

Si le serveur de développement ne démarre pas :

Vérifiez les conflits de port
Fournissez les instructions manuelles
Suggérez à l'utilisateur de démarrer le serveur lui-même

L'intégration de route échoue

Si impossible de créer une route temporaire :

Retombez sur la création d'un fichier HTML autonome
Fournissez les instructions pour l'aperçu manuel

Le nettoyage est interrompu

Si le nettoyage est interrompu :

Enregistrez ce qui a été supprimé vs ce qui reste
Fournissez les instructions de nettoyage manuel
Ne jamais laisser l'état partiel sans informer l'utilisateur

Options de configuration

Le plugin supporte ces configurations optionnelles (via environment ou config de projet) :

DESIGN_AUTO_IMPLEMENT : Si true, implémenter le plan immédiatement après confirmation
DESIGN_KEEP_LAB : Si true, ne pas supprimer le lab jusqu'à une commande de nettoyage explicite
DESIGN_MEMORY_PATH : Chemin personnalisé pour le fichier Design Memory

Exemple de flux de session

Utilisateur : /design-variations:design CheckoutSummary
Plugin détecte : Next.js App Router, Tailwind, pnpm
Plugin trouve : Aucune Design Memory existante
Plugin pose : Questions d'entretien (5 étapes)
Plugin génère : Résumé du Design Brief
Plugin crée : .claude-design/lab/ avec 5 variantes
Plugin crée : app/__design_lab/page.tsx
Plugin démarre : pnpm dev
Plugin sort : « Ouvrir http://localhost:3000/__design_lab »
Utilisateur examine les variantes dans le navigateur
Plugin pose : « Quelle variante gagne ? »
Utilisateur : « Variante C, mais change X et Y »
Plugin affine : Met à jour la Variante C
Utilisateur : « Semble bon »
Plugin crée : Aperçu final à /__design_preview
Utilisateur : « Confirmé »
Plugin : Supprime tous les fichiers temporaires
Plugin : Génère DESIGN_PLAN.md
Plugin : Crée DESIGN_MEMORY.md
Plugin : « Fait ! Voir DESIGN_PLAN.md pour les étapes d'implémentation »

Vérifier

Le changement a été rendu dans un navigateur/simulateur et une capture d'écran ou un snapshot DOM a été capturé, pas seulement une relecture du code
La mise en page a été vérifiée aux points de rupture que le guide du design-lab met en avant (mobile + desktop minimum) ; la preuve de chacun est attachée
Les valeurs de couleur, typographie et espacement utilisées proviennent des jetons de conception/thème du projet, pas des valeurs ad-hoc codées en dur
La navigation au clavier et l'ordre de focus ont été exercés sur chaque élément interactif introduit
Les variantes de mouvement réduit/mode sombre (si supporté) ont été vérifiées, pas supposées hériter
Aucune erreur console ni avertissements d'hydratation n'ont été émis pendant le rendu de vérification