Mettre en place un design system ne doit pas être une usine à gaz. Après plusieurs projets où l'UX et le dev se heurtaient à des incohérences visuelles et des composants dupliqués, j'ai adopté une approche pragmatique : démarrez petit, mais avec des fondations solides. Ici je partage comment je construis un design system accessible en cinq composants réutilisables et un workflow Figma → React qui tient la route, sans sacrifier l'accessibilité ni la maintenabilité.
Pourquoi partir de cinq composants seulement ?
Un design system peut vite devenir massif. Pour qu'il soit utile et adopté, il faut qu'il résolve des problèmes réels rapidement. En me concentrant sur cinq composants clefs — Theme (tokens), Button, Input, Card, Layout Grid — j'obtiens :
- un noyau facile à comprendre et documenter;
- une base accessible à partir de laquelle composer des interfaces plus complexes;
- une itération rapide entre design et dev (moins d'éléments à synchroniser).
Les cinq composants et pourquoi ils comptent
Voici comment je définis ces composants et quels problèmes ils résolvent.
- Theme / Design Tokens — Couleurs, typographie, espaces, rayons, ombres. C'est la source de vérité. Je les expose en CSS variables et JSON pour une compatibilité Figma → build toolchain.
- Button — État, variant, accessibilité (focus visible, labels). Les boutons sont le point d'interaction le plus critique : vous devez maîtriser couleurs accessibles, tailles et focus.
- Input — Champ texte, textarea, select minimal. Gestion des erreurs et des attributs ARIA pour l'accessibilité.
- Card — Conteneur atomique pour des combinaisons d'éléments (titre, image, CTA). Permet d'homogénéiser ombres, paddings, et responsive behavior.
- Layout Grid — Grille responsive qui définit les breakpoints et l'espacement. Plutôt que des helpers dispersés, une implémentation cohérente évite les micro-décalages.
Accessibilité : exigences non négociables
Quand je parle d'accessibilité, je parle de petites règles pratiques que je mets en place dès le départ :
- Contraste couleurs respectant AA minimum (et idéalement certains tokens AAA pour textes importants).
- Focus styles visibles et personnalisés (pas seulement outline par défaut).
- Attributs aria et rôles explicites sur Button et Input.
- Gestion des messages d'erreur accessible (aria-live pour les feedbacks, association label/for).
- Taille tactile minimale : 44x44px pour les éléments interactifs.
Workflow Figma → React : étapes concrètes
Voici le workflow que j'utilise pour que le design et le code restent synchronisés sans friction.
- 1. Tokens en Source de Vérité — Je définis les tokens (couleurs, typographie, espacements) dans Figma via Figma Tokens ou un fichier JSON importé. Chaque token porte un nom explicite (ex :
color-bg-primary,space-8). - 2. Export des Tokens — J'utilise le plugin Figma Tokens pour exporter en JSON. Ce JSON sert de base pour générer des CSS variables et des fichiers JS/TS via Style Dictionary ou Token Transform.
- 3. Composants Figma avec Variants — Pour Button et Input, je crée des composants avec variants (size, intent, state). Les variants aident les développeurs à comprendre les options et servent parfois d'input automatique pour des storybooks.
- 4. Génération et Intégration — Le pipeline transforme les tokens en : CSS variables, map JS (pour styled-components / emotion / tailwind config), et SCSS si nécessaire. Les composants React consomment ces tokens.
- 5. Documentation et Stories — J'expose chaque composant dans Storybook (ou Chromatic). Les stories couvrent les variantes et les cas d'accessibilité (focus, erreurs, contraste).
- 6. Sync continu — À chaque changement de tokens dans Figma, je relance le build (idéalement via CI) pour régénérer les variables et détecter les régressions via visual tests.
Exemples rapides : structure de tokens et button en React
Voici un aperçu minimal pour illustrer le transfert des tokens et l'implémentation d'un Button accessible.
| Token | Exemple |
|---|---|
| color-bg-primary | #0B5FFF |
| color-text-on-primary | #FFFFFF |
| space-8 | 8px |
| radius-4 | 4px |
CSS variables générées :
:root { --color-bg-primary: #0B5FFF; --color-text-on-primary: #FFFFFF; --space-8: 8px; --radius-4: 4px;}Exemple simplifié d'un Button en React (avec style inline pour clarifier) :
function Button({ children, variant = 'primary', onClick, ariaLabel }) { return ( <button onClick={onClick} aria-label={ariaLabel} style={{ background: 'var(--color-bg-primary)', color: 'var(--color-text-on-primary)', padding: 'var(--space-8)', borderRadius: 'var(--radius-4)', minHeight: '44px' }} > {children} </button> )}Points à vérifier : focus visible (outline), gestion du disabled, label explicite ou aria-label.
Outils que j'utilise et pourquoi
- Figma — pour les tokens, composants et variants. Ses plugins (Figma Tokens) sont indispensables pour lier design → code.
- Style Dictionary ou Tokens Studio — pour transformer et exporter les tokens vers différents formats.
- Storybook — documentation interactive et tests visuels.
- React + styled-components / emotion ou Tailwind selon le projet — l’important est d’avoir un mapping clair entre tokens et classes/props.
- axe-core ou ESLint-plugin-jsx-a11y — pour l'audit automatique d'accessibilité.
Bonnes pratiques pour garder le système vivant
- Versionnez les tokens (changelog) : chaque modification de couleur ou breakpoint doit être justifiée et reversable.
- Règles de contribution simples : PR templates, checklist (accessibilité, documentation, tests visuels).
- Priorisez les usages réels : observez les pages et priorisez l'ajout de composants basés sur l'usage plutôt que sur la beauté conceptuelle.
- Intégrez les designers aux revues de PR : cela évite les divergences et améliore l'adhésion.
En travaillant ainsi, j'ai constaté une baisse nette des divergences visuelles entre design et prod, une onboarding plus rapide des nouveaux devs et une meilleure conformité accessible des interfaces. Le secret n'est pas d'avoir 200 composants parfaits, mais 5 robustes, accessibles et bien connectés au processus Figma → code.