Design & UX

Créer et maintenir un design system

10 min de lecture

Ce que vous saurez faire à la fin

  1. Définir le périmètre d’un design system (composants, tokens, patterns, voix).
  2. Construire les fondations : couleurs, typographie, espacement, grille.
  3. Créer une bibliothèque de composants Figma versionnée.
  4. Documenter via Storybook ou Zeroheight.
  5. Maintenir et faire vivre le design system dans le temps.

Durée : 4-8 semaines pour la v1, puis itérations continues. Pré-requis : Figma équipe, Storybook OU Zeroheight (~30-100 $/mois), 1 designer + 1 dev front référents, soutien direction (sinon abandon en 6 mois).

Étape 1 — Définir les 5 guide général de votre design system

guide général Contenu
Tokens Couleurs, typo, spacing, radius, ombres, animations
Composants Bouton, Input, Card, Modal, Tooltip, Tabs…
Patterns Formulaires, navigations, listings, dashboards
Voix & ton Vocabulaire produit, micro-copie, messages d’erreur
Brand Logo, identité, illustrations, photographie

Étape 2 — Définir vos design tokens

Tokens = variables design qui pilotent tout. Format JSON standard :

{
  "color": {
    "brand": { "primary": "#2563EB", "secondary": "#0EA5E9" },
    "neutral": { "50": "#F9FAFB", "900": "#111827" },
    "semantic": { "success": "#10B981", "danger": "#EF4444" }
  },
  "spacing": { "xs": "4px", "sm": "8px", "md": "16px", "lg": "24px", "xl": "32px" },
  "radius": { "sm": "4px", "md": "8px", "lg": "16px", "full": "9999px" },
  "fontSize": { "xs": "12px", "sm": "14px", "base": "16px", "lg": "20px", "xl": "32px" }
}

Étape 3 — Choisir une échelle typographique

Échelle modulaire (ratio 1.25 ou 1.333). Définissez 6-7 tailles :

Display 2 : 56 / 64 / Bold     (titres landing)
Display 1 : 40 / 48 / Bold     (titres section)
Heading 1 : 32 / 40 / Semibold
Heading 2 : 24 / 32 / Semibold
Heading 3 : 20 / 28 / Semibold
Body L    : 18 / 28 / Regular
Body      : 16 / 24 / Regular
Body S    : 14 / 20 / Regular
Caption   : 12 / 16 / Medium
Format : taille / line-height / poids

Étape 4 — Définir l’échelle d’espacement (4 ou 8 px base)

Choisissez une grille 4 px ou 8 px. Tous les paddings, marges, gaps suivent cette grille.

Échelle 4 px : 4, 8, 12, 16, 24, 32, 48, 64, 96
Échelle 8 px : 8, 16, 24, 32, 48, 64, 96, 128
Outil pour vérifier : Figma plugin "Design Lint"

Étape 5 — Construire les composants Atom (Atomic Design)

Méthode Brad Frost. Atoms = briques indivisibles : Bouton, Input, Label, Icon, Avatar. Pour chaque : définissez 3-5 variants (primary, secondary, ghost, danger × default, hover, focused, disabled). Utilisez les Variants Figma : 1 composant master, propriétés (Type, État, Taille).

Étape 6 — Construire les composants Molecules

Molecules = combinaisons d’atoms : Form Field (Label + Input + Helper), Search Bar (Input + Button), Card Header (Avatar + Title + Action), Pagination, Tabs. Auto-layout obligatoire. Définissez 2-3 tailles si pertinent. Documentez l’usage : « Card Header utilisé en haut de toute Card listing ».

Étape 7 — Construire les composants Organisms

Organisms = sections complètes : Header navigation, Footer, Modal complète, Table avec en-tête + rows + pagination, Hero section. Plus complexes mais composables des molecules. Limitez à 15-20 organisms : au-delà, vous reconstruisez votre app dans Figma.

Étape 8 — Construire la library Figma partagée

Créez un fichier « DS / Components ». Structure pages : Cover, Tokens, Foundations, Atoms, Molecules, Organisms, Templates. Publiez en Library : Menu Assets > Library > Publish. Tout fichier de votre équipe peut maintenant utiliser les composants. Versions : « Save to version history » à chaque release majeure.

Étape 9 — Coder les composants en parallèle

Stack moderne : React + Tailwind CSS + shadcn/ui + Radix UI. Pour Vue : PrimeVue ou Vuetify. Pour Angular : Angular Material. Code chaque composant en miroir de Figma. Fichier tokens.css à la racine, importé par toute l’app :

:root {
  --color-brand-primary: #2563EB;
  --color-neutral-900: #111827;
  --spacing-md: 1rem;
  --radius-md: 0.5rem;
  --font-size-base: 1rem;
}
.btn-primary {
  background: var(--color-brand-primary);
  padding: var(--spacing-sm) var(--spacing-md);
  border-radius: var(--radius-md);
}

Étape 10 — Documenter avec Storybook

Installation : npx storybook@latest init. Créez un fichier .stories.tsx par composant :

import { Button } from './Button';
export default { title: 'Atoms/Button', component: Button };
export const Primary = { args: { variant: 'primary', label: 'Click me' } };
export const Secondary = { args: { variant: 'secondary', label: 'Click me' } };
export const Disabled = { args: { variant: 'primary', label: 'Disabled', disabled: true } };

Storybook tourne en local : explorez tous les composants en isolation, testez les états, copiez le code.

Étape 11 — Documenter avec Zeroheight (alternative no-code)

Sur zeroheight.com (~50-150 $/mois) : connectez Figma + Storybook (sync auto). Vous obtenez un site web de doc par composant : aperçu Figma + code React + guidelines d’usage + accessibilité + exemples Do/Don’t. URL publique pour designers, devs, PM. Idéal si pas de team front-end pour maintenir Storybook.

Étape 12 — Définir les règles d’accessibilité

Standard : WCAG 2.1 niveau AA. Règles non négociables : (1) contraste texte / fond > 4,5:1 (testez avec contrastchecker.com), (2) tous interactifs accessibles au clavier (Tab, Enter, Space), (3) labels pour tous les inputs (jamais placeholder seul), (4) focus visible (outline 2px), (5) tailles cibles tactiles > 44 × 44 px. Auditez avec axe DevTools.

Étape 13 — Versionner et communiquer les releases

Versioning sémantique : v1.0.0 (release majeure), v1.1.0 (nouveau composant), v1.1.1 (bug fix). Publiez un Changelog par release :

v1.2.0 — 2026-04-15
✨ NEW : Composant DataTable avec tri, filtre, pagination
🔧 IMPROVED : Bouton avec icône leading et trailing
🐛 FIXED : Modal qui ne se fermait pas au Esc
⚠️ BREAKING : Renommage InputText → TextField (migration: replace all)

Étape 14 — Faire vivre le DS dans le temps

Rituels :

  • Hebdo : office hours 1h pour répondre aux questions des équipes
  • Mensuel : revue d’utilisation (composants les plus / moins utilisés)
  • Trimestriel : roadmap des nouveaux composants à construire
  • Semestriel : audit cohérence sur les apps en production

Sans owner dédié et rituels, un DS meurt en 12 mois.

Erreurs classiques en design system

  • Construire le DS en isolation : impliquez 2-3 designers + 2-3 devs dès le début.
  • Tout construire avant de l’utiliser : commencez par 5 composants, dogfoodez, itérez.
  • Pas de tokens, juste des composants : rebrand impossible, cohérence cassée.
  • Pas de version code : Figma sans implémentation = beauté sans usage.
  • Documenter trop tard : personne ne sait l’utiliser correctement = forks anarchiques.

Checklist design system

✓ 5 guide général définis (tokens, composants, patterns, voix, brand)
✓ Tokens JSON ou CSS variables documentés
✓ Échelle typo (6-7 tailles) figée
✓ Échelle spacing 4 ou 8 px base
✓ Library Figma publiée et versionnée
✓ 5-10 atoms, 10-15 molecules, 15-20 organisms
✓ Composants codés (React/Vue/Angular)
✓ Storybook ou Zeroheight live
✓ Accessibilité WCAG AA validée par audit
✓ Versioning sémantique + Changelog
✓ Rituels (office hours, revue, roadmap, audit)
✓ Owner DS désigné (designer + dev référents)
✓ Adoption mesurée (% de composants DS dans les apps)

Étape 1 : auditer l’existant avant d’inventer

Avant la moindre ligne de design system, photographiez l’existant. Capturez 30 écrans représentatifs du produit, listez chaque bouton, champ, carte, modale. Vous découvrirez souvent 7 variantes du « bouton principal » dont 4 sont accidentelles.

Cet inventaire révèle les redondances et les incohérences. Il est aussi votre argument auprès du management pour justifier l’effort : sans audit, le design system passe pour une lubie de designers.

Étape 2 : définir les tokens fondamentaux

Trois familles de tokens à poser en premier : couleurs (12 à 20 valeurs nommées sémantiquement, type color-primary-500), typographie (4 à 6 tailles avec line-height associée), espacement (échelle base 4 px : 4, 8, 12, 16, 24, 32, 48, 64).

:root {
  --color-primary-500: #2563EB;
  --space-md: 16px;
  --font-size-body: 16px;
  --line-height-body: 1.5;
}

Sortie attendue : ces variables CSS sont accessibles partout dans le produit. Si getComputedStyle retourne undefined, vérifiez que le fichier de tokens est importé en premier dans la cascade.

Étape 3 : structurer la bibliothèque Figma en 3 niveaux

Niveau 1 : primitives (couleurs, typo, espacements). Niveau 2 : composants atomiques (Button, Input, Avatar). Niveau 3 : patterns (formulaire de connexion, carte produit). Cette pyramide évite que les designers réinventent un bouton à chaque écran.

Dans Figma : créez un fichier « DS-Foundations », un fichier « DS-Components », un fichier « DS-Patterns ». Activez « Publish as library » sur les 3, vos équipes consomment via « Assets ».

Étape 4 : coder les composants en parallèle du design

Un composant Figma sans équivalent code reste un dessin. Pour chaque composant publié, livrez le code (React, Vue ou Web Components) avec les mêmes props et variantes. Storybook est l’outil de référence pour exposer la bibliothèque code.

npm install --save-dev @storybook/react-vite
npx storybook init

Sortie attendue : un dossier .storybook/ et un script npm run storybook qui ouvre l’UI sur http://localhost:6006. Si le port est occupé, lancez avec -p 6007.

Étape 5 : mettre en place une convention de nommage stable

Adoptez une convention type Composant/Variante/État : Button/Primary/Default, Button/Primary/Hover. Cette syntaxe se retrouve dans Figma comme dans le code, et permet à un nouveau designer de retrouver un composant en 10 secondes.

Évitez les noms métier (BoutonAchatTabaski) : ils dateront. Préférez des noms sémantiques (Button/Primary/Large) qui survivent aux campagnes saisonnières.

Étape 6 : documenter chaque composant en 4 sections

Pour chaque composant : à quoi il sert (1 phrase), exemples d’usage (3 captures), props ou variantes (tableau), règles d’accessibilité (focus, ratio, taille de cible). Une page de doc tient en 1 écran et se lit en 90 secondes.

Hébergez la doc sur un Notion partagé ou un site Storybook publié sur Vercel. La doc dans un PDF est morte dès la première mise à jour, ne tombez pas dans ce piège.

Étape 7 : versionner avec semver

Chaque release du design system suit le semver : MAJOR.MINOR.PATCH. Une couleur renommée = MAJOR (cassant), un nouveau composant = MINOR, une correction de focus = PATCH. Les équipes savent immédiatement si elles peuvent monter sans douleur.

npm version minor && git push --follow-tags

Sortie attendue : un nouveau tag git v1.3.0 publié sur le dépôt et un changelog mis à jour. Si follow-tags n’envoie rien, vérifiez que push.followTags est à true dans la config.

Étape 8 : gouverner avec un comité léger

Un comité de 3 à 5 personnes (1 lead designer, 1 lead front, 1 product owner, optionnellement 1 accessibility expert) se réunit 30 minutes par semaine. Il valide les ajouts, arbitre les conflits, refuse les composants qui dupliquent l’existant.

Sans gouvernance, le design system se transforme en cimetière de composants en 6 mois. Avec gouvernance, il reste vivant et utile à 24 mois.

Étape 9 : mesurer l’adoption en chiffres

Trois métriques : pourcentage d’écrans utilisant des composants DS (audit Figma trimestriel), pourcentage de composants UI du code importés depuis la lib DS (script de scan), nombre de tickets « j’ai dû recréer » par sprint. Si l’adoption stagne sous 60 %, le DS ne répond pas aux besoins.

Pour explorer plus loin sur la base graphique, voyez les bases de la composition visuelle. Pour valoriser le travail livré, lisez comment créer un portfolio design.

Étape 10 : maintenir avec un rituel mensuel

Un mardi par mois, l’équipe DS passe une demi-journée sur 3 chantiers : nettoyer les composants obsolètes, fusionner les variantes en doublon, mettre à jour la doc qui a dérivé. Sans ce rituel, la dette de design grossit à bas bruit jusqu’à rendre le système inutilisable.

Ce rituel est la différence entre un design system qui dure 5 ans et un projet abandonné après 18 mois. Mettez-le au calendrier comme une cérémonie agile non négociable.

Étape 11 : embarquer les nouveaux contributeurs en 1 heure

Préparez un parcours d’onboarding de 60 minutes : 15 minutes de présentation (philosophie, périmètre), 15 minutes de tour Figma + Storybook, 30 minutes d’exercice pratique (refaire un écran existant avec les composants DS). Ce format embarque designer comme développeur, junior ou senior.

Sans onboarding structuré, chaque nouvelle recrue passe 2 à 3 semaines à comprendre par tâtonnements ce qu’une heure cadrée règle. Sur une équipe de 8 personnes avec turnover annuel, l’économie atteint vite 100 jours-homme.

Étape 12 : prévoir une stratégie de migration pour les anciens écrans

Le design system arrive rarement sur un produit vierge. Pour les écrans hérités, fixez un calendrier : audit en mois 1, refactor des composants critiques en mois 2-4, migration complète en 6-12 mois selon la taille du produit. Sans calendrier, la migration s’enlise et le DS coexiste indéfiniment avec l’ancien code.

Communiquez ce calendrier à toute l’équipe produit, pas seulement aux designers et développeurs. Les product managers doivent intégrer la dette de migration dans la roadmap, sinon les nouvelles features prennent toujours le pas et la migration ne sort jamais.

Partager
#Tutoriel

Articles Similaires