Design System et Atomic Design, interfacer designers et développeurs

Dans cette partie je vais parler design system, ce qui a déjà été évoqué dans l’intervention de Thuan Nguyen et Romane Borgeais - principalement sur le sujet de Doctolib. J’y ajouterais ici la notion corollaire d’atomic design et proposerais un petit cas pratique sur Figma. Ce sont, encore une fois, des notions que j’ai déjà eu l’occasion d'aborder avant le Master, en spécialité web design en DUT notamment.

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 pas être aussi clair, net et précis que tout un tas de gens beaucoup plus malins que je ne le suis dans l’immédiat, je conseillerais dans un premier temps la lecture de “Atomic Design” de Brad Frost. Une excellente introduction - si ce n’est la meilleure - au sujet des concepts et outils complémentaires de design system et d’atomic design. Vous trouverez un accès numérique au document à cette adresse : atomicdesign.bradfrost.com/table-of-contents/

En support 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, je pense, 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, 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 :

• Design System Orange
• Design System Doctolib
• Revamp design System Spotify
• On trouve même un filtre de recherche dédié sur la plateforme communautaire de Figma

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 canva 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.

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 le 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 ou d’une API).

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.