Comment construire un Design System de A à Z ?

Vous avez très certainement entendu parler de design system récemment, puisque ces derniers fleurissent un peu partout depuis quelques années.

Souvent rendu accessible au grand public par les sociétés à l’origine de leur conception, certains sont devenus de véritables références, comme celui d’IBM avec

ou encore

pour Google.

Et pour cause, l’utilisation d’un design system apporte plusieurs bénéfices :

1. Améliorer l'expérience utilisateur : en utilisant des composants et des guidelines, vous pouvez garantir que tous vos produits et services répondent à des standards de qualité élevées en termes de fonctionnalités, de performance et d’accessibilité.
2. Faciliter la collaboration : un design system facilite les échanges entre les différentes équipes de l'entreprise en standardisant les processus de design et en fournissant un langage et des références communes.
3. Adaptabilité et évolution : un design system peut être facilement mis à jour et adapté aux besoins changeants de l’entreprise et des utilisateurs.

Dans un premier temps, nous allons nous intéresser à la mise en place de l’espace de travail. Définir quels sont les fichiers essentiels pour disposer de fondations pertinentes, avant de s’intéresser à leurs contenus.

Dans un second temps, nous verrons comment établir une documentation complète pour les utilisateurs du design system.

Les fondations du design system

Celui-ci est divisé en deux sections.

Au cœur se trouve la partie design ; elle contient les éléments intervenants dans la composition des produits digitaux.

Ces derniers sont ensuite récupérés dans la partie documentation, afin d’y définir un cadre d’utilisation et les comportements liés aux différents types d’interactions. C’est là l’une des différences majeures avec un UI kit. La notion de documentation est ici extrêmement importante et doit être intégrée au produit dès son lancement.

S’il est possible de faire cohabiter ces deux sections sur un logiciel dédié au design, il est toutefois recommandé d’adopter des outils spécifiques plus appropriés. Cela permet d’optimiser votre productivité, mais également d’avoir une meilleure gestion des accès.

💡 Figma, récemment racheté par Adobe, est à ce jour l’outil de conception le plus adapté à la création d’un Design System et s’accorde parfaitement avec Zeroheight et Storybook pour la partie documentation.

Avant d’entrer dans le vif du sujet, il est primordial de s’attarder un instant sur la notion de design moléculaire sur laquelle repose le design system.

Cette méthodologie largement adoptée depuis la publication en 2016, du livre Atomic Design de Brad Frost remet en question l’approche traditionnelle de conception écran par écran, en inversant le processus établi. Partir des éléments fondamentaux appelés “atomes”, avant de les combiner à d’autres éléments pour former des molécules, organismes ou encore templates, afin d’atteindre l’objectif de création d’une interface.

L'idée sous-jacente est qu’en travaillant à partir des éléments de base, il est possible de créer des designs plus flexibles qui évoluent avec les besoins du produit. En utilisant ce système de conception modulaire, les équipes peuvent gagner en agilité et en efficacité.

Design Workplace

Encore un peu de patience, ne faites pas l’erreur de vous lancer tête baissée dans la création de vos composants !

Un design system reste avant tout un produit, il est donc indispensable de définir les besoins à satisfaire. L’un des objectifs du design system est de rationaliser et de mutualiser les ressources.

Une fois ce cadre défini, il est important d’organiser au mieux son espace de travail. Anticiper tant que possible le développement du produit et par conséquent sa segmentation. L’intérêt est d’offrir une structure efficace et de vous prémunir de potentiels ralentissements causés par des fichiers trop volumineux.

1. Setup de la design workplace

Structurer et harmoniser les fichiers grâce à la boîte à outil.

La première brique du design system ! Cette section, à ne pas négliger, contient les fondations communes à l’ensemble des fichiers. Il s’agit d’une librairie de composants destinés à harmoniser la structure des fichiers et à guider l’utilisateur. On y retrouve fréquemment les templates Getting started, Overview, Release patch note, ainsi que des illustrations dédiées à la documentation.

Le coeur du design system

La pièce maîtresse ! C’est ici que l’ensemble des composants seront répertoriés.

Cette section contient également les guidelines, qui définissent les principes graphiques appliqués aux différents produits (couleurs, grilles, espacements, iconographie, ombre, flou, typographie, etc)

Ces règles sont essentielles pour cadrer le travail des designers et conserver un écosystème harmonieux tout au long du cycle de vie des produits.

Souvent réduites à une notion purement esthétique, les guidelines représentent bien plus. Puisqu’une mauvaise exécution de ce document entraînera à coup sûr une dette design conséquente, ralentira la production et la collaboration des équipes.

Enfin ! Il est temps de concevoir les premiers composant du design system. Les plus fins observateurs auront sans doute remarqué le fichier Master. Celui-ci comporte les composants “sources”, qui seront employés dans Component pour décliner les différentes variantes.

L’objectif des composants master est de paramétrer les caractéristiques communes aux variantes du composant, comme par exemple les propriétés de l’auto-layout. L’intérêt de cette pratique est de pouvoir opérer des changements rapides sur des composants disposant d’un grand nombre de variants. Ainsi, un changement de radius sur l’élément master se répercutera automatique sur l’ensemble des composants issus de ce dernier.

Le composant master finalisé, il est dupliqué et de nouveau déclaré comme étant un composant (instance “Primary”). Ainsi, l’ensemble des variants issus de cette instance seront affectés par les changements effectués sur le master.

Donnez vie à vos composants

Il est temps de donner vie à vos composants. Les prototypes permettent d’en évaluer la pertinence via des tests utilisateurs, mais également de faciliter la compréhension des comportements et des interactions attendues auprès des équipes de développement.

Il est important de décrire les différents états d’un composant et de définir les interactions pour les atteindre. C’est l’objectif du fichier Component, décrire l’ensemble des comportements pour chacun des composant du design system.

Il n’est pas rare d’avoir des éléments qui sont amenés à évoluer au sein d’un ensemble pour être pertinent. Le fichier Flow permet de contextualiser et d’illustrer des cas d’usage concret en détaillant le comportement d’un organisme ou d’une page.

Aller plus loin

S’ils constituent l’essentiel des fichiers de votre Workplace et comblent la majeure partie de vos besoins, il est possible d’enrichir cet espace avec d’autres fichiers :

• Contributions : selon votre organisation et la structure de vos équipes, un fichier de contributions peut s’avérer particulièrement utile pour récolter des feedbacks et impliquer vos utilisateurs dans la conception des composants. Je vous invite à consulter l’un de nos articles qui traite de ce sujet sur notre blog :
• Playground : établir un espace dédié à l’expérimentation, permet d’explorer des pistes de design en éliminant tout risque de porter atteinte au design system.
• Archives : puisque le design system est un produit qui est amené à évoluer, il est conseillé de conserver une trace des travaux réalisés dans un fichier d’archives, pour anticiper tout incidents et garder de la visibilité sur les précédentes releases.

💡 Dupliquez certains de ces projets pour mieux gérer les accès entre les différents parties prenantes. Effectuez régulièrement des releases sur la base du fichier source en documentant tous les changements réalisés.

2. Organisation des composants

Une fois votre espace de travail organisé, attardons-nous sur la structure des fichiers.

La mise en place d’un design system prend du temps, il est donc recommandé d’introduire chaque fichier par quelques pages d’onboarding (référencer les templates utilisés dans la toolbox permet d’effectuer des changements rapides sur l’ensemble du design system et d’harmoniser les fichiers), pour faciliter la prise en main du produit par de nouveaux intervenants.

Chaque page correspond à un composant. Cependant certaines exception comme les tableaux peuvent nécessiter d’être diviser en plusieurs pages pour préserver les performances.

Le tri des pages n’est pas soumis à une règle d’optimisation particulière. Libre à chacun de trier comme bon lui semble, la plupart des design system adoptent un simple tri alphabétique.

En revanche, l’attribution d’un code couleur permet d’avoir de la visibilité sur le statut de production des composants :

• ⚫ = En attente de traitement
• 🔴 = Modification nécessaire
• 🟡 = En attente de validation
• 🟢 = Composant à jour

💡 En pratique, la meilleure façon d’opérer un changement est de l’isoler via le système de branch de Figma. Cela permet de garantir l’intégrité des éléments existants pendant toute la durée de l’intervention. Attention toutefois à ne pas effectuer un trop grand nombre de modification sur une seule et même branch, ou de tarder à publier cette dernière, au risque d’être confronté aux limitations techniques de l’outil.

S’il est préférable d’adopter des outils spécifiques, avoir une copie de la documentation sur le fichier de design permet de centraliser l’information, mais également de conserver une source en cas de changement du support de documentation.

Parlons documentation à présent

Il y a plusieurs avantages à utiliser une documentation.

Tout d'abord, elle permet une meilleure collaboration entre les différents départements de l'entreprise en fournissant un cadre commun de référence. De plus, elle assure la cohérence de la marque en s'assurant que tous les produits respectent les standards établis.

Pour ce faire, il est possible de combiner différents types de documentation, chacun ayant son propre objectif et son public cible. Les deux outils les plus courants sont Zeroheight et Storybook.

Zeroheight est une plateforme de documentation qui fournit une vue d'ensemble de tous les composants de design utilisés dans un système de design. Cette documentation est souvent utilisée pour fournir une référence visuelle des différents éléments de design. Elle permet également aux designers de voir comment ces éléments s'assemblent pour former des pages et des écrans complets.

Storybook, quant à lui, est un outil de documentation et d'affichage interactif pour les composants. Il permet aux développeurs de visualiser les différents états et interactions dans un environnement de développement isolé. Cela permet aux développeurs de s'assurer que les composants fonctionnent comme prévu et de tester rapidement sans besoin d’intégration.

La documentation constitue donc d’un élément crucial pour une entreprise ou une organisation soucieuse de l'expérience utilisateur et de la cohérence de la marque en étant accessible à un large éventail d'utilisateurs.

1. Zeroheight

Il est courant d’introduire la documentation par les fondations sur lesquels reposent votre design system. Ils définissent les valeurs et la démarche de l’entreprise en matière de design. Il peut y être décrit l’organisation du design system, les différents produits impactés, l’équipe mise à contribution et les objectifs à plus ou moins longs termes.

Adopter la vision de l’utilisateur

L’intérêt de Zeroheight est de disposer d’un environnement dissocié de l’outil de conception pour approfondir les notions relatives à l’usage. Il faut savoir adopter le point de vue d’un utilisateur dont la mission est de concevoir une interface et qui ne possède aucune connaissance en matière de design system. L’objectif est donc de contextualiser au maximum (en utilisant le fichier illustration pour représenter différents cas d’usage).

La fiche technique des composant

Il s’agit des règles qui définissent la façon dont les composants doivent être utilisés, construits et personnalisés. Il est courant d’introduire la fiche d’un composant par une courte description et de référencer les acronymes qui lui sont associés. Les éléments qui composent le composant ou les différentes variantes de ce dernier sont ensuite détaillés pour donner les premières indications aux utilisateurs.

1. Bouton avec label, 2. bouton avec label et icone, 3. bouton avec icon

Les différents variants du composant sont ensuite listés et accompagné d’une description, de façon à ce que l’utilisateur puisse facilement déterminer le variant le plus adapté à son cas d’usage.

Le bouton étant l'un des éléments les plus couramment utilisés dans les interfaces, voici un exemple de ce que pourrait donner la description des variants les plus communs :

Primary : le bouton primaire est utilisé pour les actions principales dans l'interface. Il est conçu pour être facilement repérable et est souvent associé à la couleur principale.

Secondary : le bouton secondaire est utilisé pour les actions secondaires dans l'interface. Il est conçu pour être moins visible que le bouton primaire, mais toujours facilement repérable. Il est souvent associé à une couleur secondaire.

Tertiary : le bouton tertiaire est utilisé pour les actions mineures dans l'interface. Il est conçu pour être le moins visible des trois types de boutons, mais toujours facilement repérable. Il est souvent associé à une couleur de la marque qui n'est ni la principale ni la secondaire.

Danger : le bouton danger est utilisé pour les actions qui ont des conséquences négatives pour l'utilisateur ou l'application. Il est conçu pour être facilement repérable et est souvent associé à une couleur rouge.

Text : le bouton texte est utilisé pour les actions qui n'ont pas besoin d'un bouton aussi visible que les autres types de boutons. Il est conçu pour être le moins visible de tous les types de boutons et est souvent utilisé pour les actions telles que l'annulation ou la fermeture d'une boîte de dialogue.

Respectivement les états enable, hover, active, focus et disable du variant primary d’un bouton.

Évoqué précédemment, les usages servent à décrire le contexte dans lequel le composant va évoluer et à donner des exemples concrets d'utilisation. Par exemple, une liste de produits, un formulaire de contact, une barre de navigation, etc.

Les do and don'ts sont les règles d'utilisation des composants qui décrivent ce qui est recommandé et ce qui est à éviter. Par exemple, il peut être recommandé d'utiliser un bouton pour effectuer une action, plutôt qu'un lien, et il peut être déconseillé de modifier la couleur d'un bouton pour des raisons d'accessibilité. Les do and don'ts sont généralement basés sur les meilleures pratiques en matière de conception d'interface utilisateur et d'accessibilité.

Un exemple de do & don’ts qui recommande l’usage de texte concis dans les bouton.

Pour conclure la documentation d’un composant, il est courant de rediriger vers des composants qui sont étroitement liés ou dépendants de celui précédemment documenté (par exemple, une barre de navigation peut inclure des sous-menus).

2. Storybook

Storybook permet aux développeurs et aux designers de visualiser et de tester facilement des composants de façon indépendante sans avoir à exécuter l’application complète. L'un de ses avantages est qu'il permet aux équipes de travailler de manière plus efficace en facilitant la collaboration entre les développeurs et les designers.

De plus, cet outil permet aux équipes de documenter et de maintenir les composants de manière efficace. En utilisant Storybook, vous pouvez créer une bibliothèque de composants qui peut être utilisée comme référence par toute l'équipe.

C’est ici l’occasion d’aborder une notion liée aux guidelines, celle du Design Token.

Les tokens et les atomes sont deux concepts liés à la méthodologie de conception atomic design, qui vise à organiser les éléments visuels d'une interface utilisateur en utilisant une hiérarchie de niveaux d'abstraction.

Si les atomes décrivent les composants basiques d'une interface, les tokens sont des variables qui décrivent les propriétés visuelles d'une interface, comme la couleur, la typographie, les espacements, etc. Ils permettent de maintenir une cohérence visuelle à travers une interface en définissant des règles de style qui peuvent être utilisées dans tous les composants.

Il y a plusieurs avantages à utiliser des design tokens :

1. Uniformiser le design : les design tokens permettent de maintenir l'uniformité du design et de l'expérience utilisateur à travers les différentes plates-formes et appareils sur lesquels un produit est utilisé.
2. Faciliter la maintenance : en centralisant les définitions de style dans un fichier de configuration, les design tokens facilitent la maintenance et la mise à jour du design d'un produit. Si vous devez modifier un élément de style, vous n'avez qu'à le faire dans le fichier de configuration, ce qui mettra à jour toutes les occurrences de cet élément.
3. Simplifier la collaboration : les design tokens permettent à tous les membres de l'équipe de développement d'accéder aux définitions de style de manière centralisée et cohérente. Cela peut améliorer la collaboration et la communication entre les membres de l'équipe.

Comment définir les tokens ?

Il existe plusieurs façons de définir les tokens dans un projet.

Voici quelques étapes couramment suivies pour les définir et les gérer :

1. Identifiez les éléments qui doivent être définis en tant que tokens. Ces éléments peuvent inclure des couleurs, des polices, des tailles de texte, des bordures, des ombres, des animations, etc.
2. Décidez comment vous allez organiser et nommer vos design tokens. Cette phase de “naming” consiste à attribuer des noms à l’ensemble des tokens dans le fichier de configuration. Il est recommandé de regrouper les tokens similaires dans des catégories, pour une meilleure organisation et une meilleure lisibilité. Par exemple, vous pouvez définir une catégorie "colors" pour regrouper tous les tokens de couleur, une catégorie "fonts" pour regrouper tous les tokens de police, etc. Le naming est extrêmement important, cela peut avoir un impact sur la manière dont les tokens sont utilisés dans le code et sur la facilité avec laquelle ils peuvent être maintenus et mis à jour. Il est recommandé de choisir des noms explicites et de suivre une convention de nommage cohérente pour faciliter la compréhension et l'utilisation des tokens. Par exemple, si vous utilisez une couleur en tant que token, vous pouvez nommer ce token "color-primary" ou "color-secondary" selon sa couleur et son rôle dans le design. Si vous utilisez une police en tant que design token, vous pouvez nommer ce token "font-header" ou "font-body" selon son usage.

1. Créez un fichier de configuration pour stocker vos tokens. Ce fichier peut être au format JSON, YAML, SCSS, etc., selon les outils et technologies que vous utilisez dans votre projet.
2. Définissez chaque token dans le fichier de configuration en utilisant la syntaxe appropriée. Par exemple, si vous utilisez un fichier JSON, chaque token peut être défini comme une clé-valeur, avec la clé représentant le nom du token et la valeur représentant sa valeur de style.
3. Utilisez une API ou une bibliothèque de style pour accéder aux tokens dans votre code HTML, CSS et JavaScript. Cela permet de centraliser la définition des tokens et de les rendre accessibles à tous les membres de l'équipe de développement.

La documentation du design system est essentielle pour garantir que tous les membres de l'équipe comprennent et appliquent la convention de nommage. Celle-ci doit être mise à jour régulièrement pour refléter les évolutions du design system.

Conclusion

En conclusion, l'organisation d'un design system est cruciale pour garantir une expérience utilisateur cohérente et une mise en œuvre efficace des produits.

L'organisation de l'espace de travail aide à maintenir la qualité et les performances, notamment en mettant en place une segmentation claire et efficace des fichiers. La documentation complète et cohérente des différents composants du design system est également essentielle pour permettre une collaboration efficace entre les différents départements de l'entreprise et pour garantir la conformité aux standards de conception.

Investir du temps pour organiser correctement le design system aura des répercussions positives à long terme sur l'efficacité du développement de produits et leur cohérence. En fin de compte, une organisation bien conçue peut aider à accélérer davantage le processus de développement, à améliorer la qualité des produits et éviter tant que possible la création de dette design.

Une dernière chose ! Pour conclure cet article, il est essentiel de mettre en avant l'importance de suivre et de mesurer les performances de votre design system en définissant des indicateurs de performance clés (KPI), comme par exemple le temps de production. Mettre en place un processus de tracking sur l’utilisation des composants et d'autres métriques clés vous permettront d’évaluer son efficacité afin de prendre des décisions informées pour l'améliorer.

—

Tu souhaites lire plus d'articles sur le Design ?

Retrouve tous nos articles de Product Design sur notre blog !