Cas 03 · Talkspirit · Product design · UI · Design system

Un design system n'est pas une boîte à outils. C'est un langage partagé.

Construit pour faire respecter la cohérence à travers l'UI et l'UX, aligner les designers avec les développeurs, et permettre aux équipes de réinventer moins pour résoudre des problèmes plus importants. Voici comment je l'ai structuré, des échelles de couleurs accessibles à une architecture de tokens qui garde le design et le code synchronisés.

Rôle: Product Designer
Outils: Figma · Tokens Studio · Storybook
Produit: Talkspirit · Holaspirit
Périmètre: Tokens · Architecture Figma · accessibilité · handoff

Design systemDesign tokensAccessibilitéThemingDev handoff

Pourquoi un système

Un langage partagé qui permet aux équipes de réinventer moins.

Un design system est central dans le travail d'un designer : il aide à faire respecter les bonnes pratiques et à maintenir la cohérence à travers le design UI et UX. Il s'aligne aussi avec les développeurs, en leur permettant de retrouver facilement les composants qui pourraient avoir besoin d'être affinés.

Plus qu'une simple boîte à outils, il fonctionne comme un langage partagé qui réduit les frictions, aligne l'expérience utilisateur, et documente les patterns et les guidelines, permettant aux équipes de réinventer moins et de résoudre des problèmes plus importants.

Bases et accessibilité

La couleur en échelles, avec l'accessibilité en surface.

Nous avons construit la palette de couleurs en échelles (100, 200, 300, etc.), pour que chaque famille de couleur reste cohérente. Ainsi, une nuance « 100 » a toujours la même luminosité, qu'elle soit neutre, bordeaux, orange ou bleue. Cela rend les états au survol, les boutons et les arrière-plans naturels et équilibrés; en se comportant de manière cohérente à travers le système.

Les nuances désactivées indiquent ce qui n'est pas utilisé actuellement. Cela permet de voir d'un coup d'œil où se situe la marque dans le spectre de couleurs plus large.

Les familles de couleurs en échelles 100–900, avec les tags « default » et les avertissements de contraste.

La couleur construite en échelles, avec les tags « default » et les avertissements de contraste affichés sur les échantillons.

Un tag « default » marque le choix standard de chaque famille, ce qui garde la palette propre. Certaines nuances ne respectent pas pleinement les standards d'accessibilité, mais ont été conservées parce qu'elles portent de vraies décisions de marque. Plutôt que de le masquer, je les ai signalées par un avertissement et leur ratio de contraste sur fond blanc. Chacun peut voir les limites d'un coup d'œil et faire un choix réfléchi. La porte reste ouverte à une conformité WCAG 2.1 AA plus tard.

Design tokens

Trois couches qui gardent le design et le code synchronisés.

Les tokens sont ma façon de garder le design et le code synchronisés. Je les ai construits en trois couches : options → décisions → composants. Les options sont les valeurs brutes (les échelles de couleurs, les tailles de texte, les espacements). Les décisions donnent une fonction à ces valeurs : « ce rouge signifie danger ». Les composants n'utilisent jamais que des décisions, jamais des valeurs brutes. Ainsi, quand je change une option, elle se propage automatiquement dans tout le système.

Option · primitive

blue/800 · #015AD1

Une valeur brute. Ne signifie rien en soi.

Décision · sémantique

action/primary → blue/800

Donne une fonction à la valeur : « c'est l'action principale. »

Composant

Button CTA → action/primary

Utilise la décision, jamais la valeur brute.

Changez blue/800 une fois, et chaque appel à l'action à travers le produit se met à jour automatiquement.

Ce système de couches est aussi ce qui rend le theming simple. Le produit fait tourner trois thèmes de marque (bordeaux, bleu et orange) entre lesquels un client peut basculer. Seule la couleur d'accent change. Les couleurs de feedback (danger, warning, info, success) sont partagées entre les trois. Le rouge d'erreur ne bougera jamais par accident.

J'ai choisi Tokens Studio plutôt que les variables natives de Figma car il garde ces références intactes, gère les styles typographiques complets, et exporte en JSON que les développeurs utilisent directement dans leur code.

Tokens Studio : options, décisions et thèmes, exportables en JSON pour les développeurs.

Organisation

Un fichier structuré pour que rien ne se perde.

Trois sections, chacune sur ses propres pages : Foundations, Components et Patterns. Les Components contiennent les éléments comme les boutons et les champs. Les Patterns couvrent les cartes et la navigation. Les variantes liées sont regroupées dans un même frame, comme chaque bouton toggle au même endroit, pour qu'elles soient faciles à trouver. Cela garantit aussi que le système est évolutif.

Le fichier Figma : Foundations, Components et Patterns, variantes regroupées dans des frames.

Foundations · Components · Patterns : variantes regroupées dans des frames, hiérarchie atomique en dessous.

Pour les éléments plus complexes, j'ai utilisé une approche atomique (atomes, molécules, organismes), en séparant les briques de base les plus simples des structures plus grandes comme un tableau kanban. La séparation en pages, associée à la hiérarchie atomique, garde le système rapide à naviguer et suffisamment flexible pour évoluer vers des composants avancés.

Une approche atomique : des atoms et des molecules composés en organisms plus larges.

Une approche atomique sépare les briques simples des structures plus larges.

Comment ça vit à travers les équipes

La valeur d'un système tient à sa capacité à garder les équipes alignées.

La vraie valeur n'est pas le fichier, mais la compréhension partagée qui l'entoure. Cela signifiait construire deux ponts : un vers l'équipe technique, un vers le Marketing et le Support (qui disent aux utilisateurs ce qui est nouveau).

Avec les développeurs

Storybook comme miroir vivant

Chaque composant et couleur vit dans Storybook, miroir du design system, pour que les développeurs voient l'apparence et le comportement attendus avant de livrer. Un point hebdomadaire tient les deux côtés informés des ajouts, ajustements et restes à faire.

Storybook : les mêmes composants, documentés pour les techs.

Avec le marketing et le support

Dire aux utilisateurs ce qui est nouveau dans le produit

Les utilisateurs manquaient souvent les nouvelles fonctionnalités : on comptait trop sur les campagnes et le support pour faire passer le message. J'ai comblé cet écart avec une page entière dédiée aux composants de feedback pop-ins, bulles, bannières et tutoriels rapides et fermables qui montrent une nouveauté là où elle se trouve. La communication est devenue naturelle et au bon moment, plutôt que réactive.

Modales, sondages et bannières : un kit partagé pour la communication in product.

À retenir

L'accessibilité, la cohérence et l'organisation structurent bien plus que l'interface.

J'ai appris comment l'accessibilité, la cohérence et une bonne organisation peuvent structurer bien plus que l'interface. Elles changent aussi la façon dont les équipes travaillent ensemble, transformant un design system en quelque chose de vivant qui aide chacun à avancer dans la même direction.