Le point de départ
Après Expert et Karto, je documentais déjà les composants de chaque outil sur Confluence, mais chaque projet avait ses propres fichiers Adobe XD, ses propres composants. Avec l’arrivée de nouveaux outils, j’ai décidé de centraliser tout ça dans une bibliothèque partagée.
C’était aussi l’occasion de repartir sur une base visuelle plus solide, sans les contraintes de couleur qui avaient guidé Expert. J’en ai profité pour repenser la charte, introduire le double thème sombre et clair, et poser des fondations qui pourraient servir à l’ensemble des produits de l’écosystème.
Les objectifs
Ce design system répondait à plusieurs besoins simultanément, avec un principe commun : mutualiser pour aller plus vite et mieux.
Pour la conception : capitaliser sur les composants existants et se concentrer sur ce qui est spécifique à chaque produit plutôt que sur les éléments récurrents.
Pour les équipes de développement : une base commune et documentée, pour aligner les implémentations. Plusieurs équipes travaillaient sur des outils différents, leur donner les mêmes fondations garantissait la cohérence entre les projets.
Pour les utilisateurs : une expérience fluide d’un outil à l’autre. Quelqu’un qui passe de Peekr à Karto retrouve ses repères immédiatement.
Sur le long terme : une maintenance centralisée mettre à jour un composant à un endroit suffit pour l’ensemble de l’écosystème.
Ma démarche
La démarche a été pragmatique, j’ai commencé par Peekr, construisant les composants au fur et à mesure des besoins réels. Rapidement, j’ai aussi décidé de rafraîchir Expert : trois ans de développement, de nouveaux besoins, et cette fois sans les contraintes de couleur du départ. C’était l’occasion de faire mieux.
C’est en travaillant ces deux projets en parallèle que le design system s’est construit élément par élément, centré sur les besoins réels plutôt que sur une vision théorique.
Au-delà du visuel, j’ai défini les comportements de chaque composant de façon centralisée : états de survol, sélection, ouvert/fermé, focus, connecté/déconnecté pour garantir cohérence et réutilisabilité d’un outil à l’autre.
Pour le responsive, j’ai observé comment les équipes utilisaient réellement ces outils sous Windows : souvent en demi-écran, parfois en quart d’écran…. J’ai donc prévu trois comportements principaux desktop, demi-écran avec des versions intermédiaires là où c’était nécessaire.
Le travail UI
J’ai structuré le design system autour de tokens : couleurs partagées, couleurs de thème, couleurs de graphiques… et d’une typographie cohérente. Sur cette base, j’ai construit une bibliothèque de composants ancrée dans les besoins réels des outils : datepicker, tags, notifications à plusieurs niveaux et tous les éléments qui revenaient d’un projet à l’autre.
Pour l’iconographie, j’ai conçu une bibliothèque sur mesure couvrant l’ensemble des cas d’usage, transformée en font-icône en trois graisses : Regular, Medium et Bold, pour plus de nuance selon le contexte et une intégration légère côté développement.
J’ai également créé les Andrew une série de personnages expressifs utilisés dans les messages et états de l’interface : confirmation, erreur, surprise, réflexion… Une façon d’humaniser les moments de friction ou de vide, sans alourdir l’interface avec du texte explicatif.
Couleurs
Les décisions de conception
Le système d’icônes repose sur deux approches distinctes selon l’usage. Les grandes thématiques visuelles : celles qui nécessitent des ombres et des dégradés sont en SVG. Le reste fonctionne en font-icône : plus léger, plus flexible côté développement.
Les trois graisses (Regular, Medium, Bold) permettent de couvrir tous les besoins selon le contexte, un peu comme une police typographique. Pour accélérer la production, j’ai mis en place une grille de conception qui permettait de créer les icônes de façon rapide et cohérente : une approche industrielle qui garantissait l’homogénéité de l’ensemble.
Sur le thème sombre et clair, la décision principale était de maintenir un bon niveau de contraste dans les deux modes pas juste inverser les couleurs, mais s’assurer que chaque combinaison reste lisible et accessible.
Trois principes d’accessibilité ont guidé l’ensemble du système :
- La couleur ne porte jamais seule une information : un statut, un état ou une mise en avant est toujours accompagné d’un texte ou d’une icône. Une personne ayant une déficience visuelle liée aux couleurs peut toujours comprendre l’interface sans s’appuyer uniquement sur la teinte.
- Les icônes utilisées seules sont systématiquement accompagnées d’une tooltip pour garantir que leur signification reste accessible à tous, même sans contexte visuel immédiat.
- Un message d’erreur, par exemple, n’est jamais signalé uniquement par une couleur rouge : il est toujours doublé d’un symbole et d’un texte explicatif.
Travail d’équipe
L’adoption s’est faite naturellement parce que le design system a été appliqué directement sur Peekr, un outil en cours de développement : pas de migration, pas de dette à gérer.
J’ai eu la chance de travailler avec des développeurs front qui non seulement comprenaient l’intérêt de la démarche, mais la poussaient eux-mêmes. Une développeuse en particulier était particulièrement engagée au niveau de l’implémentation, de l’accessibilité, de la rigueur. Le genre de collaboration qui donne envie de faire mieux. Des gens qui voulaient que le travail soit bien fait, en partie parce que certains d’entre nous connaissaient personnellement des utilisateurs qui allaient se servir de ces interfaces au quotidien.
Les résultats
Le design system a été utilisé sur l’ensemble des outils qui ont suivi. Sur chacun, la base existante permettait de démarrer directement sur ce qui était spécifique au produit, sans redessiner les fondations. Kdata en est le meilleur exemple : la déclinaison a été rapide parce que tout l’essentiel était déjà là.
Pour les équipes de développement, la base commune a également réduit les allers-retours et les incohérences d’implémentation entre les projets.
Les enseignements
Ce projet a confirmé quelque chose que je crois vraiment : un design system n’est pas une fin en soi, c’est un outil au service des gens qui l’utilisent : designers, développeurs, utilisateurs. Sa valeur se mesure à ce qu’il permet de faire, pas à ce qu’il contient. Et dans ce cas précis, c’est autant la rigueur collective de l’équipe que le système lui-même qui a fait la différence.
Font-icones
La bibliothèque complète : Regular, Medium et Bold. Chaque icône dessinée sous Illustrator, intégrée via IcoMoon. Les Andrew et les icônes WYSIWYG font partie des éléments invariables, communs à tous les outils.
J’ai créé une iconographie sur mesure pour l’ensemble des projets. Les icônes sont dessinées sous Illustrator, puis intégrées dans une font-icône personnalisée.
