Reprendre le lead d'un Design System : par où commencer ?

Début 2026, j'ai rejoint GRDF comme Designer UX/UI et experte en accessibilité numérique. Après 6 mois à proposer des évolutions et probablement un peu trop parler de ma vision pour le Design System (😅), on a fini par m'en confier le lead.

Pour cette première entrée du carnet Lead Design System chez GRDF, je reviens sur les difficultés rencontrées en utilisant le Design System de GRDF et sur mes premières décisions en tant que Lead.

Ma démarche : comprendre avant de faire évoluer

Avant de me lancer dans la refonte d'une application, je commence toujours par identifier les points de friction et échanger avec les utilisateurs. Ces échanges m'aident à repérer des opportunités d'amélioration et à définir une vision pour la suite.

J'ai appliqué la même démarche au Design System de GRDF.

J'utilise le Design System au quotidien dans les projets GRDF. Cette double casquette me permet de garder un regard concret sur les difficultés rencontrées par les Designers et les améliorations à apporter.

Certaines tâches me prenaient plus de temps que prévu : identifier les propriétés et variantes disponibles pour un composant, retrouver une règle d'utilisation ou personnaliser une instance Figma sans la détacher.

En version 5, le Design System comptait déjà 44 composants, 5 thèmes de couleur et près de 1 000 tokens primitifs. Une bibliothèque bien établie, construite au fil des contributions de l'équipe.

Ma première ambition pour la version 7 était de consolider cet existant : une bibliothèque Figma alignée avec le code et une documentation pour chaque composant, même imparfaite ou incomplète.

En croisant mes observations avec les retours de l'équipe, j'ai regroupé les difficultés rencontrées en 5 grandes catégories de problèmes.

Problème n°1 : des différences entre Figma et le code

Certaines propriétés, variantes ou structures des composants n'étaient pas parfaitement alignées entre Figma et le code.

Pour connaître les propriétés et variantes disponibles, il fallait parfois comparer les 2 environnements ou échanger avec les développeurs.

En l'absence de slots sur certains composants Figma, les Designers pouvaient créer leurs propres composants pour remplacer les placeholders, ou détacher les instances pour adapter leur contenu.

Ces solutions répondaient aux besoins des projets, mais compliquaient la maintenance des fichiers et la propagation des mises à jour.

L'enjeu : permettre de personnaliser les composants sans perdre la cohérence entre Figma et le code.

Problème n°2 : l'absence de tokens sémantiques

Le Design System disposait d'une palette de couleurs organisée autour de 5 thèmes, mais les règles associant les couleurs à leurs usages n'étaient pas toujours explicites.

Prenons la couleur de fond d'un composant désactivé.

Plusieurs nuances de gris étaient disponibles, du neutral-50 au neutral-950. Sans token sémantique correspondant à cet usage, chaque Designer devait choisir la nuance à utiliser.

Certains tokens de composants existaient également dans Figma, mais pas dans le code, ou inversement.

L'enjeu : définir des tokens sémantiques communs à Figma et au code, avec des usages explicites.

Problème n°3 : une documentation à enrichir

Certaines documentations restaient à compléter ou à actualiser, notamment sur les cas d'usage, les comportements attendus et les recommandations d'accessibilité.

Pour trouver ces informations, les Designers devaient parfois solliciter directement leurs collègues.

La première enquête auprès des équipes, réalisée au 1er trimestre 2026, avait également fait ressortir un manque de documentation et d'exemples.

L'enjeu : disposer d'une documentation accessible et suffisamment complète pour utiliser les composants sans devoir systématiquement demander de l'aide.

Problème n°4 : un processus de contribution à clarifier

Les demandes d'évolution, les priorités et la roadmap étaient réparties entre plusieurs outils. Pour avoir une vision d'ensemble, il fallait consulter différents espaces et recouper les informations.

Les étapes de contribution soulevaient aussi des questions : où proposer une évolution ? Quand créer une branche Figma ? Qui solliciter pour une revue ? Comment suivre l'intégration côté développement ?

Ces pratiques existaient au sein de l'équipe, mais elles n'étaient pas toujours formalisées dans un parcours facile à retrouver.

L'enjeu : clarifier les étapes de contribution et centraliser les informations nécessaires aux contributeurs.

Problème n°5 : des écarts d'accessibilité dans les composants

Certains composants nécessitaient des ajustements concernant la navigation au clavier, les états de focus ou les informations transmises aux technologies d'assistance.

Ces points méritaient une attention particulière : les composants du Design System sont réutilisés dans plusieurs applications.

Une correction apportée à un composant partagé peut bénéficier à toutes les interfaces qui l'utilisent. À l'inverse, un problème non corrigé peut se retrouver dans plusieurs projets.

L'enjeu : intégrer les exigences d'accessibilité dans les composants et leur documentation.

Et maintenant ?

Identifier ce qui devait être amélioré ne suffisait pas. Mon rôle était aussi de donner une direction au Design System pour faire des choix cohérents.

À suivre dans l'entrée 02 : Définir une vision pour faire évoluer le Design System.