Implémenter un Design System

Figma définit un Design System comme "un ensemble de blocs de construction et de normes qui aident à préserver la cohérence visuelle des produits et des expériences". Cela va du ton employé, reflet des valeurs et de la personnalité de la marque, à la définition du moindre espacement. Dit autrement, c'est un guide de styles qui introduit un systématisme, une grammaire visuelle dont l'utilisateur n'a pas nécessairement conscience, mais qui amoindrit très effectivement l'apprentissage nécessaire lorsqu'il aborde un nouveau produit, une nouvelle interface. L'interaction étant facilitée, l'utilisateur et l'organisation atteignent plus certainement leurs objectifs et tout le monde est content.

Concevoir un Design System est un investissement important pour toute organisation, mais un investissement qui porte rapidement ses fruits : une fois en place, il diminue le nombre de décisions à prendre en phase de conception, permettant aux designers d'accéder à des considérations de plus haut niveau. Son implémentation au travers d'une bibliothèque de composants implique également des gains de productivité évidents en phase de développement, en plus de promouvoir l'état de l'art en matière d'accessibilité et de compatibilité mobile.

Le Design System d'Atlassian en est un parfait exemple. Sa structuration ("Brand", "Foundations", "Tokens", "Components"…) reflète bien le chemin de pensée et la logique de construction pyramidale issue de l'atomic design.

Notez en passant la notion de design token : un jeton est une valeur nommée désignant une couleur, un espacement, une typographie etc. Par exemple : color.background.danger, qui correspondra à une nuance bien précise de rouge. Pour nos amis designers, épris de rigueur, qui ressentent de manière intime ce que signifie "une UI tirée au cordeau", les design tokens ont quelque chose de… oddly satisfying. On les comprend.

Une question demeure : comment traduire cela en code ? En la matière, le maître-mot est "encapsulation", ce que je traduis par 4 recommandations.

1. Au risque d'enfoncer des portes ouvertes, rappelons la nécessité de constituer une librairie de composants (React, Vue, Angular, Web Components, ce que vous voulez), importée par tous les actifs informatiques. De la sorte, si changement il doit y avoir, il n'a lieu qu'en un seul endroit ; ce changement peut concerner la valeur d'un token ou bien le framework CSS lui-même. Le corollaire, c'est que vous ne voulez pas la moindre classe CSS en dehors du Design System, pas le moindre text-red-500 (Tailwind CSS, à titre d'exemple) qui, pourtant, vous arrangerait bien. Facile à dire, compliqué à mettre en œuvre.

2. Ce text-red-500 qui, pourtant, vous arrangerait bien, il ne s'agit pas de le rajouter tel quel au Design System : il faut lui donner du sens. C'est peut-être un composant Danger, à moins que le rouge ne soit la couleur primaire de votre Design System, auquel cas ça n'a rien à voir. Le plus probable restant que ce text-red-500 sorte de nulle part et n'ait en fait rien à faire dans le Design System 😉 En bref : pas de place pour la contingence, tout a du sens, tout doit être pensé.

3. Limitez impérativement le nombre de tokens pour une même propriété. Vous n'allez pas utiliser les 34 valeurs de padding que Tailwind CSS propose par défaut : 34, c'est l'infini, cela va à l'encontre de l'idée-même de Design System. Vous devez donc restreindre les valeurs possibles, en définissant vous-même les 2 ou 3 que votre composant accepte en paramètre.

4. Concrètement, les tokens peuvent se traduire par l'appel à une fonction depuis un composant du Design System, par exemple token('color.background.danger'), ladite fonction n'étant rien d'autre qu'un gros switch. Alternativement, vous pouvez customiser votre thème Tailwind CSS en définissant par exemple une couleur background_danger.

En clair, bossez vos tokens, bien en amont du développement. Et donc, pour prendre un peu plus de hauteur, ne mettez pas la charrue avant les bœufs : dans la mise en place d'un Design System, le développement intervient presque en toute fin. La démarche part du design, pas du développement. Si vous êtes au clair là-dessus, vous réalisez que les conseils précédents sont le reflet d'une démarche de rationalisation "ex-post", c'est-à-dire partant d'un existant de code.

Pour finir, signalons le pattern Compound Component, qui se révèle très utile pour créer des composants de haut niveau tel que le PageLayout de cette capture d'écran (à gauche, le Design System, à droite son utilisation dans un produit).