(Cet article est extrait d'un mémoire de master UXD à l'UTC. Il fait suite à un cycle de conférences sur une large gamme de sujets pas nécessairement attachés à son sujet.)
Dans cette partie, je vais parler du design system, dans la continuité de l'intervention de Thuan Nguyen et Romane Borgeais. J'apporterai à la discussion la notion indissociable d'atomic design pour comprendre la logique d'un design system et proposerai un petit cas pratique sur Figma. J'aborderai ces notions avec ma lorgnette de web design, étant donné qu'il s'agit de ma formation de base (DUT).
C’est quoi un Design system, comment ça se met en place et à quoi ça sert ? Et à partir de là, quel rôle pour l’atomic design ? C’est globalement ce sur quoi j'essaierais d'apporter un éclairage.
D’abord, Parce que je ne pourrais être aussi clair, net et précis que tout un tas de gens beaucoup plus malins que moi dans l’immédiat, je conseillerais la lecture de “Atomic Design” de Brad Frost. Une excellente introduction - si ce n’est la meilleure - sur les concepts et outils complémentaires du design system et de l’atomic design. Vous trouverez un accès numérique au document à cette adresse : atomicdesign.bradfrost.com/table-of-contents/
En support également, vous trouverez un document Figma. Figma est sans doute un des outils de prototypage no code les plus répandus, la principale raison étant sa capacité à gérer les composants dynamiques et son aspect collaboratif très bien implémenté. Sinon, pour des outils plus puissants, il faut se tourner vers des choses comme WebFlow, beaucoup plus technique, Figma propose un équilibre qui en fait, en l’état, le meilleur outil de prototypage pour des applications web et mobile.
C’est en tout cas ce que j’utilise au quotidien et son architecture encourage la création d’un design system ou a minima de logique systémique pour rationaliser, d’où mon choix privilégié de solution pour cette démo.
Donc d’abord, c’est quoi un design system ?
Basiquement, un design system fait la synthèse du design - généralement numérique - d’une entité, de ce qui a été produit et comment tout complément doit être produit. Il se présente sous la forme d’une documentation. Comme le remontait Romane Borgeais en parlant de Doctolib, une grosse partie de la charge de ce genre d’outils est d’abord de mettre à plat, de normaliser l'existant.
Quelques exemples :
Un design system adresse les problèmes en normalisant l’évolution d’un design, en agrégeant dans une seule et unique documentation ce qu’il y a à savoir pour les designers, les développeurs et l’ensemble des personnes concernées.
On pourrait imaginer la charte graphique comme un embryon de ce que serait un design system. Une fraction du design system, qui lui couvrirait tous les autres aspects, comme le nécessaire pour produire des applications web et mobile, des templates, des UI kits, etc. On voit même que chez certains (comme chez Orange) le design system est compartimenté par média et plateforme.
Plus encore que ce qui compose un design system (puisque chacun y met un peu ce qu’il veut), c’est la démarche qui prévaut : il est l’inscription de la norme d’un design, il est une sorte de constitution de celui-ci.
Cette norme a avant tout pour but de faciliter le partage et le travail sur les projets l’exploitant, il est avant tout un outil de collaboration - j’y reviendrai. Je ne me risquerais pas à dire que c’est comme ça que l’on procède et pas autrement.
Un design system se “design”, il s'agit avec de designer le processus de design lui-même, de définir l'environnement de design et surtout comment doivent se faire les intégrations et les modifications de l’existant. Il organise la collaboration. Il est un canevas pour rationaliser non seulement de UI, mais la fabrication de l’UI.
Comme une bonne documentation, un bon design system n’est pas qu’une liste bête et méchante, il améliore l’expérience de design pour les concernés.
Et l’atomic design dans tout ça ?
Pour résumer brièvement, l’atomic design, comme son nom l’indique, se propose d’atomiser les éléments qui composent une interface et de graduellement construire à partir de ces briques élémentaires des composants plus complexes.
Atomic Design ©Brad Frost
L’atomic design rationnalise et organise la conception de composants au service de la création d’un design system, lui-même outil de norme. Nous allons y venir, mais cette façon de penser le design trouve pour moi sa source dans la logique de développement de ces applications.
L’atomic design prend appui sur des composants dynamiques et responsives, nécessaires pour le web. Il n’y a pas “des boutons”, mais un nombre restreint de “composants” ayant des “instances”, et même parfois, comme cela sera présenté sur Figma, un seul composant, mais avec des “variantes” pour limiter un maximum les répétitions.
Il suffit de modifier ce modèle, ce composant, pour actualiser toutes les instances, et de cette façon on peut facilement itérer et intervenir sur le design system.
Ces composants sont également dynamiques, et ont pour cela des données de positionnement et de taille (x et y, width et height) relative. Exemplairement, la taille d’un bouton peut-être relative à la taille du texte qu’il contient. Si je veux changer le texte, je n’interviens que sur celui-ci, le bouton gardera les mêmes proportions.
Ces composants dynamiques, robustes, sont eux même injectés dans des “containers” ayant eux aussi des règles de dispositions relatives sur le modèle de CSS flex. Des boîtes dans des boîtes, auxquelles on donne donc des instructions leur permettant de régir le contenu interne.
L’idée à retenir c’est que modifier un composant n’oblige pas à faire plus de modifications, et que de cette façon beaucoup d'informations sont centralisées. D’où l’intérêt d’avoir des atomes : il facilite la fabrication d'éléments complexes ainsi que leur maintenance.
Cette logique, d’une certaine façon, émule le comportement de l'environnement de développement en plus de la logique de travail. Elle facilite la “traduction” du design vers un dispositif interprétable par les navigateurs (dans le cas d’un site web).
De l’Atomique au système
L’atomic design fait référence au design de composants, de briques, en cela il peut être compris comme une logique sous-jacente et interne à intégrer dans un design system. Il est préférable de penser un Design System de façon atomique, puisque cela en amplifie sa logique normative et permet de plus facilement s'interfacer avec le développement qui lui fonctionne déjà sur cette logique.
Notez, qu’il s’agit d’un document spécifique imaginé pour ce mémoire et qu’il n’est pas représentatif de l'organisation classique d’un design system. Cependant, il me permettra de donner de la concrétude à mes explications en mettant en évidence les différentes graduations de l'atomic design et comment cela se corrèle au travail de développement. Le contenu du document est extrait de mes propres test de design system.
Comme évoqué plusieurs fois au-dessus, le design system ne s'adresse pas qu'au designer, une partie de son rôle est en outre de faire le pont entre l’outil de prototypage et la version de développement. Il est ici accompagné d’extraits de code imaginés comme une librairie “à la boostrap” en HTML/CSS.