Comment faciliter la création de composants et l'itération d'un Design System dans un contexte de R&D ?

2026 Design System, Guidelines, User Research
Scope Composant et guidelines
Outils Figma, Figjam, Figma AI
Timeline 6 mois
EDSO

Contexte

Après le succès de son MVP, le laboratoire de recherche JUMO du CEA souhaitait faire passer son outil de démonstrateur R&D à un produit SaaS commercialisable. Le laboratoire m'a demandé de travailler sur la refonte de son Design System marque blanche.

Following the success of its MVP, the JUMO research lab at CEA wanted to turn its R&D demonstrator tool into a commercializable SaaS product. The lab asked me to work on the redesign of its white-label Design System.

Objectifs du projet

  • Réduire drastiquement le temps de maquettage et de delivery
  • Supprimer la dette technique (zéro composant détaché)
  • Garantir un standard d'accessibilité (RGAA)
  • Moderniser l'interface en incorporant les contraintes de conception du SaaS

KPI du projet

🎯 100% Taux d'adoption
🧩 0 Taux de composants détachés
X4 Temps de production
📦 80 Nombre de composants

Étape d'accompagnement

Audit

Avant de refondre, j'ai audité le Figma de l'équipe et le design system existant en faisant l'inventaire des composants, de la structure et nomenclature.

Before redesigning, I audited the team's Figma and the existing design system by inventorying the components, structure, and nomenclature.

01
Documentation déconnectée du code
  • Manque de contexte sur la vie du composant
  • Utilisation abusive de variants Figma
02
Identité visuelle obsolète
  • Une UI datée qui ne reflète pas les standards d'un SaaS moderne
  • Manque cruellement de composants de Data-Visualization natifs
  • Utilisation des breakpoints plutôt qu'à l'échelle de densité dans ce contexte
03
Architecture chaotique
  • Brouillons de recherche et maquettes ready-to-dev mélangés
04
Gouvernance en silo
  • Changelog tenu manuellement sur une page texte
  • Manque d'alignement avec le trio produit (PM, Lead Dev, Designer)

Enquête terrain

J'ai réalisé des entretiens qualitatifs avec les développeurs front-end pour comparer leur usage réel avec le rendu attendu.

I conducted qualitative interviews with front-end developers to compare their actual usage with the expected output.

👥 4 Participants
🗣️ qualitative Type d'enquête
⏱️ 15 min Durée
5 Questions
Ce que je voulais savoir
Ce que j'ai appris
Comment agrémenter la documentation pour répondre aux besoins des développeurs
Limiter les disparités de documentation, interactives, do/don't à inclure
Comment agencer des différents éléments et fichiers ?
Séparer les fichiers par usage (delivery, composants..)
Comment faciliter la communication design/dev
Utiliser des variables sémantiques et le Figma Dev Mode à bon escient, avoir des rituels design

Benchmark

Analyse de 6 Design Systems de référence (Material, Atlassian, Primer, DSFR) pour dégager des patterns de documentation et bonnes pratiques.

Analysis of 6 reference Design Systems (Material, Atlassian, Primer, DSFR) to identify documentation patterns and best practices.

Institutionnel

Autre

Conception

Une documentation intégré

  • Création de gabarits invisibles en production pour standardiser les règles
  • Intégration de la documentation dans Figma
  • Variantes complexes remplacées par des booléens

Utilisation des Design Token

  • Paramétrage de tokens sémantiques et de densités
  • Intégration d'un Dark Mode conforme WCAGAA
  • Polissage de nombreux composants

Nouvelle architecture

  • Séparation des fichiers de travail

Versioning natif

  • Utilisation des branches Figma pour isoler les versions
  • Instauration de rituels hebdomadaires entre Designer, PM et le Lead Dev

Création des Guidelines

Pour chaque composant, le designer crée une fiche "Guideline" dédiée qui définit le composant, ses différents états (les variants) et annonce une série de règles à respecter.

For each component, the designer creates a dedicated "Guideline" sheet that defines the component, its different states (variants), and outlines a set of rules to follow.

Une fiche est composée de :

A sheet consists of:

  • Description : Une rapide présentation du composant et de son utilité (donne le cas d'usage le plus commun)
  • Structure : Les détails sur la taille du composant (et ses variants), les marges, les espacements...
  • Personnalisation : Les possibilités de personnalisation du composant et comment s'y prendre
  • Variants / Types : Le composant de base et ses différents états mis côte à côte pour avoir une vision globale
  • Do & Don't : les règles à respecter pour ce composant avec des exemples en texte et en image

De plus, pour faciliter le partage du DS au reste de l'organisation (Directions, filiales, partenaires...) et aussi au grand public, il est conseillé de passer par un outil spécifique tel que : ZeroHeight, InVision, Confluence...

Additionally, to facilitate sharing the DS with the rest of the organization (management, subsidiaries, partners…) and the general public, it is recommended to use a dedicated tool such as: ZeroHeight, InVision, Confluence…

Dans Figma

Quelques éléments

Impact

La création d'EDSO et sa nouvelle gouvernance ont permis à JUMO d'adopter les standards opérationnels d'un véritable SaaS.

The creation of EDSO and its new governance enabled JUMO to adopt the operational standards of a true SaaS product.

÷ 4
Temps de production (design → code)
→ 10 min
Temps de documentation (vs 1h)
× 5
Développeurs ayant adopté le cadre
+ 80
Composants refactorisés
90 %
Conformité WCAG AA