Client
Corum est une entreprise française de gestion d'actifs, spécialisée dans les solutions d'épargne et d'investissement, principalement à travers des fonds immobiliers et obligataires. Elle propose aux investisseurs individuels des produits financiers accessibles et performants, les aidant à faire croître leur patrimoine à long terme. Corum offre des solutions adaptées à divers profils d'investisseurs, avec des options dans les fonds de placement immobilier (SCPI) et les obligations d'entreprises à travers l'Europe.
Produit
J'ai travaillé sur l'espace destinés aux clients B2B, tels que les Conseiller en Gestion de Patrimoine (CGP), qui gèrent à la fois des clients individuels et des entreprises et j'ai également travaillé sur l'espaces B2C pour les clients individuels qui peuvent, ou non, être gérés par un CGP. Grâce à ces plateformes, les utilisateurs peuvent suivre leurs investissements et en faire d'autres, soit de manière indépendante, soit avec l'aide de leur CGP. Les clients peuvent accéder à leurs espaces via le web et une application mobile, bien que la vaste majorité de mon travail (hors design system) soit concentrée sur la plateforme web B2B.
Brief
Réduire les coûts de développement et accélérer le délai de mise sur le marché.
Améliorer l'évolutivité pour mieux anticiper les prochaines initiatives.
Flux de travail agile.
Améliorer la cohérence visuelle.
Faciliter l'onboarding et la collaboration entre designers/développeurs.
Rôle et Contribution
En tant que designer produit freelance au sein de l’équipe produit, j’ai été missionné pour renforcer le développement du design system. J’ai approché les problèmes identifiés sous plusieurs angles :
Workflow designer-développeur
Je me suis concentré sur l’amélioration de la collaboration via Figma et Supernova en établissant un système de documentation robuste pour combler les écarts entre les équipes.Design tokens
J’ai adressé les problèmes de modularité de plusieurs composants, puis j’ai intégré des design tokens afin de résoudre des problématiques telles que la cohérence visuelle et la scalabilité. Par la même occasion, j’ai créé un langage commun entre le design et le développement, pour favoriser davantage de collaboration.
Les design tokens nous ont ensuite servi à assurer la transition vers la refonte visuelle réalisée par les agences BETC et Extreme.
Audit & Challenges
Avec la demande croissante de nouvelles fonctionnalités et l'évolution du produit, des écarts significatifs ont commencé à apparaître entre les maquettes et le produit final développé. En outre, offrir une expérience utilisateur cohérente est devenu de plus en plus difficile pour les designers, tant en termes d'exécution que de temps, à mesure que le nombre de changements augmentait.
Pour résoudre ces problèmes, j'ai mené un audit approfondi à la fois du produit et du design system. Cela a été suivi d'une série d'ateliers impliquant les différentes parties et nous avons découvert plusieurs causes aux problèmes rencontrés.
Faible réutilisabilité des composants
La plupart des composants manquaient de modularité, ce qui limitait leur réutilisabilité et leur évolutivité. Ne disposant pas de plus petits éléments flexibles, ils étaient difficiles à adapter à différents contextes.
Redondance des composants
Le manque de modularité a engendré une redondance dans la bibliothèque de composants. Ne pouvant être facilement réutilisés, les designers devaient souvent recréer des variantes similaires pour chaque cas d’usage. Résultat : plusieurs composants quasi identiques coexistaient, compliquant les décisions de conception et encombrant la bibliothèque. Cette redondance augmentait la charge de maintenance, affectait la cohérence visuelle et rendait plus difficile l’identification des composants adéquats.
Manque de communication entre les équipes
Deux équipes de développement distinctes travaillaient sur des aspects différents du même produit (espaces privés et tunnels), fragmentant les efforts. Chacune gérait sa propre bibliothèque de composants, faisait face à des contraintes spécifiques et appliquait des workflows différents, générant des incohérences dans le produit. De plus, très souvent, certains composants présents n’étaient jamais développés par l'autre équipe.
Absence de documentation
L’absence de documentation a creusé le fossé entre designers et développeurs. Sans directives claires, la communication s’est fragmentée, entraînant des incohérences dans l’utilisation et l’implémentation. Elle a aussi compliqué l’alignement d’équipes déjà fragilisées par la redondance des composants et freiné l’intégration des nouveaux membres.
Optimiser le workflow Figma
Plusieurs bonnes pratiques manquaient et devaient être mises en place dans Figma. De nombreux composants étaient dispersés dans divers fichiers, tandis que d’autres avaient été détachés de la plupart des maquettes. Les styles, quant à eux, étaient parfois appliqués de façon incohérente.
Pour y remédier, la première étape a consisté à définir une méthodologie de design cohérente. Nous avons regroupé tous les éléments fondamentaux (couleurs, typographie, règles d’espacement, grilles) dans un unique fichier nommé « Fondation » afin de faciliter l’accès aux bons éléments pour les designers et les développeurs.
Nous nous sommes ensuite concentrés sur les composants. Ils étaient souvent conçus pour des cas très spécifiques et créés directement dans les maquettes, ce qui les dispersait dans différents fichiers. À l’aide de Figma Analytics, nous avons tout regroupé dans un seul fichier, nommé « Component library ». Nous avons aussi analysé leurs taux d’insertion et de détachement, afin de déterminer lesquels étaient obsolètes ou nécessitaient une refonte.
Bien que cela ait rendu la bibliothèque plus simple à maintenir, le processus fut très chronophage et a exigé de nombreuses réunions avec les développeurs des deux équipes pour comprendre leur gestion des composants.
La dernière étape pour simplifier Figma a consisté à renommer les pages de la « Component library » en familles logiques (navigation, overlay, champs, sélection, communication, formulaires, tableaux, etc.). Ce changement simple a rendu la bibliothèque plus intuitive et facile à parcourir.
En organisant les composants en familles claires, nous avons :
Clarifié la fonction de chaque groupe, aidant à repérer les redondances et les éléments manquants.
Renforcé la cohérence du design system, en encourageant le choix du composant le plus adapté.
Réduit le temps de recherche, en évitant de fouiller dans une longue liste d’éléments sans lien.
Facilité l’onboarding des nouveaux membres, qui comprennent plus vite la structure de la bibliothèque.
Documenter le design system
Après avoir éliminé les redondances et rendu certains composants plus modulaires en les décomposant en plus petits éléments, nous avons poursuivi la création d’un design system cohérent en mettant en place des standards et des directives avec Supernova, afin d’en faire notre source de vérité.
Nous avons passé en revue chaque composant, en commençant par les plus utilisés (boutons, champs, onglets, bascules, tableaux). Ces analyses avaient lieu lors de réunions hebdomadaires entre designers et développeurs front-end, où nous examinions leurs propriétés visuelles, variantes, états, libellés, etc., afin de garantir la cohérence et corriger toute divergence entre le design et l’implémentation.
Nous avons commencé par des étapes incrémentales pour la documentation, en ayant bien tête que c'était un projet continu.
J'ai établi une architecture de l'information, décrivant toutes les sections que nous souhaitions inclure comme une section 'Fondation' pour présenter notre système de couleurs, typographie, espacements, visualisation des données comme les graphiques ou tableaux et plus encore, ainsi que d'autres sections dédiées aux composants, aux patterns et au contenu (UX writing).
Intégrer les design tokens
Pour corriger les incohérences visuelles (couleurs, textes, unités d’espacement…) et faciliter la montée en charge de notre design system, nous avons adopté les design tokens. Pour rappel, ces derniers sont des variables qui stockent les décisions de design (couleurs, typographies, espacements, etc.).
J’ai présenté leurs avantages aux parties prenantes à travers une présentation détaillée, en montrant comment ils pouvaient résoudre nos problèmes actuels et améliorer nos processus. Après un test en environnement contrôlé, nous avons décidé de les implémenter progressivement, notamment en raison des avantages suivants :
Consistance visuelle
Les design tokens nous permettent de centraliser les décisions de design et d’assurer l’uniformité entre les plateformes et les composants. Les mises à jour des éléments majeurs (couleurs, typographie, etc.) se reflètent ainsi de manière cohérente dans l’ensemble du produit.
Évolutivité
Les design tokens facilitent la mise à jour des composants modulaires, surtout pendant une refonte. Les changements de style se répercutent uniformément, réduisant le temps de développement et permettant une montée en charge efficace.
Meilleure collaboration
Les design tokens instaurent un langage commun entre designers et développeurs, limitant les malentendus et assurant une mise en œuvre précise.
Gestion de thèmes et du contexte
Les design tokens accélèrent les ajustements de thèmes, de branding, de contexte. Modifier un seul token suffit à propager les changements dans tout le système, offrant une adaptation rapide aux évolutions de marque et besoins de personnalisation.
J’ai également pris le temps, dès le début, de documenter le concept des tokens pour l’équipe sur Supernova :
La taxonomie des tokens
J’ai animé des ateliers (dont certains s’inspiraient du travail de Nathan Curtis) réunissant designers et développeurs de toutes les équipes. Nous avons élaboré une structure de tokens claire, facile à adopter et évolutive. Pour cela, nous avons passé en revue toutes les caractéristiques de nos composants et modèles, en nous inspirant également de systèmes de design comme Primer et Polaris.
Nos tokens suivaient un format structuré comme --cds.button.color.surface.primary, où chaque segment du nom donne une information spécifique dans un ordre défini. Cette structure garantit la cohérence et l'évolutivité, car l'ordre spécifique de chaque segment joue un rôle crucial pour permettre une extension et une adaptation faciles des tokens pour des besoins futurs.
C'était peut-être l'un des aspects les plus difficile du travail avec des tokens, car nous avons été confrontés à la difficulté de rendre les tokens à la fois concis et descriptifs, en veillant à ce qu'ils restent clairs tout en gardant leurs noms suffisamment courts.
Voici quelques exemples des différentes parties de notre taxonomie de tokens qui peuvent être décomposées comme suit :
Object
Component
Element
button
form
left-icon
right-icon
Base
Category
Concept
Property
color
font
spacing
size
shadow
breakpoint
communication
vizualisation
action
text
size
surface
weight
border
letter-spacing
Modifier
Variant
State
Scale
Context
primary
secondary
tertiary
default
success
danger
breakpoint
enabled
hover
active
pressed
selected
disabled
50
100
150
small
medium
large
muted
subdued
bold
b2b
b2c
Le système de design tokens
Nos tokens sont organisés en trois groupes principaux pour couvrir différents niveaux d’abstraction et garantir un design system adaptable et évolutif.
Primitives tokens (ou global tokens)
Ils contiennent des valeurs brutes, sans contexte spécifique. Par exemple, le token blue.800 correspond à #0E5E77, mais ce code hexadécimal ne précise pas où ni quand l’appliquer. Ces tokens servent de base à toutes les autres décisions de design et ne sont jamais référencés directement dans nos composants.
Semantic tokens
Contrairement aux tokens primitifs, les tokens sémantiques n’utilisent pas de valeurs brutes : ils renvoient plutôt à des tokens primitifs (ex : --cds.color.brand.primary = blue.800). Cela garantit la cohérence et ajoute du contexte (par exemple, --cds.color.text.danger pour un message d’erreur), rendant l’utilisation de chaque valeur plus claire.
L’un des principaux défis avec les styles Figma et l’absence de documentation était l’absence de consignes claires : quelle nuance de vert choisir pour un état “success” ? Certains designers utilisaient “green 500”, d’autres “green 600” ou même “green 700”. Il fallait s’en souvenir par cœur. Les design tokens résolvent ce problème en mettant en place un système de référence qui offre un contrôle supplémentaire et crée une couche systématique pour gérer les décisions de design.
Token components
Nous avions aussi envisagé une troisième couche appelée “token components” pour offrir un contexte supplémentaire aux composants spécifiques. Ainsi, un même composant de formulaire pourrait avoir une version simplifiée pour le B2C et une plus détaillée pour le B2B, ou encore un composant de tableau de bord qui adapterait ses métriques selon qu’il s’adresse à un client ou à un conseiller en gestion de patrimoine. Cette approche garantissait flexibilité et personnalisation.
La gestion des tokens
Pour assurer une transition fluide lors du rebranding, j’ai créé un nouveau thème appelé « rebrand » à l’aide de design tokens, comme on le ferait pour un mode sombre. Ce thème reprend directement les couleurs et la direction artistique établies par BETC et Extreme, ce qui permet un déploiement précis et une cohérence visuelle optimale.
L’un des principaux atouts de cette approche est sa flexibilité : nous pouvons intégrer progressivement les nouveaux éléments de la marque sans tout bouleverser d’un coup. Cela nous permet également d’effectuer des A/B tests pour recueillir des retours avant une mise en œuvre complète.
Une fois la transition achevée et tous les tokens passés en mode « rebrand », il suffit de déprécier l’ancien mode pour conserver un système à jour.
Gestion visuelle des tokens
Pour faciliter la transition, j’ai créé une documentation et des cartes visuelles dans Figma, présentant les caractéristiques de chaque type de token. Ce format permet d’identifier rapidement les éventuels problèmes et les différences entre la nouvelle conception et la version initiale (par exemple, certaines couleurs trop vives ou insuffisamment prononcées) et de faire des ajustements précis. Il offre aussi une vue claire de ce qui est déjà intégré ou toujours en attente, ainsi que l’impact potentiel d’un token sur l’ensemble du système : modifier un token peut affecter tous ceux qui en dépendent.
"—cds" est le préfixe du token qui indique le nom du design system, ici "Corum Design System". "sys" indique qu’il s’agit d’un composant sémantique ; nous aurions également pu utiliser "sem" à la place.
Un inconvénient majeur de ces cartes visuelles était la maintenance nécessaire pour les garder à jour et le risque accru d’erreurs, faute d’automatisation. Pour y remédier, nous avons envisagé de créer une base de données Airtable afin d’automatiser certains points, ou de n’utiliser que Supernova pour gérer les tokens — une solution robuste, mais qui ne proposait pas la vue d’ensemble visuelle dont nous avions besoin. Nous recherchions un outil similaire au "Token Visualization Tool" du design system Spectrum d’Adobe.
Gestion de nos tokens sur Supernova
Gestion des tokens de Adobe
Pour ce faire, nous avons exporté des collections de tokens depuis Figma au format .json à l’aide d’un plugin Figma, ce qui présentait plusieurs avantages. Le format JSON facilite la gestion et le partage des données, tout en étant indépendant de la plateforme. Nous avons ensuite importé nos fichiers .json dans JSON Crack, qui nous a permis de visualiser efficacement les dépendances entre les tokens et d’en cartographier les relations.
Gestion visuelle de nos tokens avec JSON Crack
Résultats final, Impact et enseignements
Mesurer le succès global
Bien que ma mission se soit terminée, il était évident que le projet avait besoin d’un suivi continu pour réussir sur le long terme. Pour que le design system continue d’apporter de la valeur, j’ai mis en place plusieurs KPI pour en mesurer l’efficacité.
J’ai notamment utilisé Figma Analytics pour suivre la réutilisabilité des composants à travers différents projets. En étudiant les taux d’insertion et l’usage des variantes, nous pouvions déterminer quels composants étaient peu exploités et cibler les améliorations nécessaires. Nous avons aussi recueilli régulièrement les retours de l’équipe design et développement, et je suis heureux de dire que le ressenti global était positif. Les développeurs ont immédiatement perçu l’utilité de ces actions et se sont pleinement investis dans les discussions.
Impact global
L’introduction des tokens a considérablement amélioré la cohérence de notre langage de design, réduisant les écarts entre équipes et facilitant la collaboration transversale. Designers et développeurs pouvaient ainsi se référer à une source unique de vérité, limitant confusion et malentendus. La documentation a également joué un rôle majeur : des lignes directrices claires et accessibles ont réduit la courbe d’apprentissage, allégé la charge cognitive des designers et rendu l’intégration plus rapide.
Leçons clés
En réfléchissant à cette expérience, j'ai appris que construire un design system efficace va au-delà de l'établissement des bons composants ou des design tokens. L'importance de la communication entre les équipes ne peut être surestimée. Dès que chacun avait une compréhension claire de la façon et des raisons pour lesquelles nous utilisons des tokens et des composants, les choses se sont bien déroulées.
J’ai aussi appris l’importance de l’itération. J’ai tendance à vouloir tout structurer parfaitement dès le départ, mais les retours continus et les ajustements progressifs, accompagnés d’une bonne dose de patience, sont inestimables.
À suivre
Tout commence par une conversation
Phone number