Qu’est-ce qu’un design system ?

Design sys… quoi ?

Design system. Un ensemble de mots dont l’élégance n’a d’égal aujourd’hui que sa nécessité… et sa méconnaissance.

S’il continue de faire ses preuves au sein des équipes les plus averties, il arrive néanmoins que son rôle s’entache d’une ombre légère mais récalcitrante chez des profils plus juniors, ou tout simplement chez les collaborateurs peu familiers aux process de conception.

Si son existence tend à rendre obsolètes certaines méthodes pour le moins ancestrales, il est paradoxalement amusant de remarquer que son étymologie constitue à elle seule les prémices d’évangélisation du sujet.

Ouvrons donc le temps de l’anecdote nos vieux livres de latin :

• Design, du latin designare, soit « marquer d’un signe, dessiner, indiquer » Plus généralement, le mot « design » implique un projet, et donc une intention.
• Système, du latin systema, soit « combinaison, assemblage, organisation »

Mis bout-à-bout, nous sommes donc sur une organisation d’un projet. Toute organisation devient légitime dès lors qu’elle est encadrée par une structure, en vue d’un but collectif. Ça ne vous rappelle rien ? Toute société est régie par un système, véritable guide de bonne conduite et de vivre ensemble, structuré de lois indiquant ce qu’il est possible de faire, mais aussi ce qui est proscris.

Cette organisation du design viendrait donc chapeauter l’ensemble du processus créatif, petit protégé des designers soucieux de stabiliser les trois piliers suivants :

• cohérence de l’identité
  → le produit doit être homogène et reconnaissable
• accessibilité du produit
  → tout le monde doit pouvoir le comprendre et l’utiliser
• rapidité de conception
  → optimiser le temps de création et fluidifier les process entre les équipes

Trois objectifs de taille pour un but unique et en somme essentiel : porter un langage commun entre les différents métiers et les équipes d’un même produit. L’union fait la force !

Différencier un “Design System” d’un “UI Kit”

Mais comme dans de nombreux cas, la meilleure volonté du monde ne peut être seule partisane des plus grands succès. Enlevez ou sabotez au pâtissier ses ingrédients (design system), ses compétences (intentions) deviennent vaines, et le gâteau (l’objectif, la maquette) susceptible d’être raté.

Sur cette nouvelle analogie, attardons-nous sur un élément capital et bien souvent incompris :

Une librairie de composants n’est pas un design system.

Dans une librairie de composants (ou UI kit), nous trouvons des éléments d’interface prêts à l’emploi, comme des boutons, des search bars, ou encore un header, mais aussi des éléments plus sommaires, comme des fonts, des icônes, et des couleurs.

Si elle constitue une partie intégrante du design system, elle ne peut en aucun cas se suffire à elle-même dans cette initiative. Si cette bibliothèque d’éléments graphiques (font, couleurs, icônes, search bar, etc.) demeure des plus essentielles, une organisation du design et l’élaboration de son système nécessite un cadre bien plus solide qu’un simple fichier Sketch. Les compétences d’une équipe et la performance de leurs outils ne seront d’aucune valeur notable sans l’existence d’un bon mode d’emploi.

L’importance des guidelines

Ce mode d’emploi, ce sont les guidelines. Elles déterminent et indiquent ce qu’il est possible ou non de faire avec les composants de la librairie dans le cadre d’un design process. La couleur d’un bouton est-elle libre ? La taille d’un titre est-elle la même partout ? Une search bar peut-elle être placée n’importe où ? Sur le modèle d’une charte graphique d’un logo, ces indications nécessaires à l’élaboration du produit vont déterminer l’existence des éléments ainsi que leur mise en pratique.

Combien d’entre nous ont, par ego ou impatience, délibérément délaissé le mode d’emploi d’un meuble, et perdu un temps monstre dans sa construction aléatoire — solvée, le plus souvent, par un échec ? Expérience tristement triviale que d’envisager en dernier recours, la notice et son impitoyable première consigne : nécessite deux personnes.

Cet exemple démontre bien que sans marche à suivre, le chemin risque d’être douloureux, plus long que nécessaire, voire semé d’embûches. Si le designer est le protagoniste de son intention, le design system endosse quant à lui son rôle d’adjuvant à toute épreuve.

Atomic design, ou le design modulaire

Maintenant que les grands axes ont été tracés, de quoi avons-nous besoin ?

Si nous avons certes mentionné qu’une librairie de composants n’était pas un design system à part entière, elle en constitue cependant le noyau solide et nécessaire à son développement.

Pensée comme une base déclinable dans laquelle l’on va venir puiser, cette librairie tend à être mise à jour en parallèle avec le produit auquel elle appartient. De cette manière, le designer pourra alors construire, décliner, et retravailler ses écrans en toute sérénité (comme on vérifie d’avoir des ingrédients frais et non périmés avant de faire un gâteau.) De leur côté, les développeurs mettront également en place ce système au sein du code afin de faciliter l’intégration du design.

Afin de s’assurer d’avoir des composants cohérents et réutilisables, nous allons les penser de manière atomique.

Cette méthode, connue sous le nom d’Atomic design, puise ses origines dans la chimie et le design modulaire (Modular Design), avant d’être évangélisée par Brad Frost en 2013 dans son livre du même nom.

Cette technique consiste donc à penser le design à l’image des atomes et des molécules chimiques : les éléments de l’interface doivent être vivants et évolutifs.

Les atomes

Un atome est un élément isolé qui à lui seul n’a pas de but fonctionnel. Irréductible, il ne peut pas être scindé en plusieurs parties, dans la mesure où il constitue la base de tout autre élément graphique de l’interface.

Exemple : une couleur, une font, une icône, un logo, un champ de saisie…

Les molécules

Une molécule est un ensemble de plusieurs atomes, qui va constituer un élément simple de l’interface. Sur du projet web, une molécule doit être pensée de manière responsive, de sorte qu’elle s’adapte facilement à toutes les résolutions.

Exemple : icône + font + champ de saisie = un champ de recherche

Les organismes

Un organisme est une combinaison plus complexe de plusieurs molécules, ou de plusieurs molécules et d’atomes, pour venir former un élément graphique important de l’interface.

Exemple : logo + nav + champ de recherche = un header

Les pages

Si cette dernière étape n’est à proprement parler plus directement liée à notre analogie scientifique, elle est cependant très utile. Une page se rapproche le plus de l’écran final, avec en son sein du vrai contenu. L’étape intermédiaire constituerait à mettre en place dans le code des templates de ces pages avec du contenu aléatoire, essentiellement dans le but de vérifier l’ergonomie et la hiérarchisation des informations.

Côté design, les pages sont très utiles lors de l’élaboration de parcours dans le cadre d’une nouvelle feature : tous les écrans ne sont ainsi pas à refaire de A à Z, et seront automatiquement mis à jour si le design d’un élément isolé (couleur, taille de font…) venait à être modifié.

Un gain de temps des plus astucieux pour tout designer qui se respecte !

Et avant, on faisait comment ?

Lors d’une sombre époque pas si lointaine, le design process était le suivant : on élaborait des écrans en entier, puis on venait en extraire les composants pour les transmettre aux développeurs front, et ainsi faciliter l’intégration du design.

Sur le papier, ce procédé longtemps généralisé avait les meilleures intentions du monde. Mais dans les faits, cette dynamique de travail a par la suite généré une importante problématique :

Les composants ne sont pas pensés de manière générique, mais bien pour un contexte et une demande précise. En conséquence, le système est bien souvent non réutilisable et donc rapidement obsolète.

Dans les faits, voici quelques situations bien fâcheuses que tout designer aura malgré lui maintes et maintes fois vécues :

• chercher un composant ou une page pendant des heures parmi les fichiers, sans être convaincu qu’ils soient à jour
• devoir recréer indéfiniment un composant à partir d’une capture d’écran du produit en production
• perdre plus de temps qu’il n’en faut sur les retours en modifiant les écrans un par un
• laisser libre cours à sa création au détriment de la cohérence de l’identité et de l’expérience

Si l’absurdité de ces douloureux exemples manquerait encore d’évidence à vos yeux, calquons donc ces exemples sur notre analogie pâtissière :

Sans les ingrédients ni les étapes de sa recette, voici à quoi devrait se risquer le pâtissier :

• Tenter d’extraire d’un dessert A prêt à consommer (une capture d’écran du site) les ingrédients communs pour un dessert B à concevoir (maquette à créer.) Autrement dit : tenter à l’oeil ou à l’intuition de reconnaître si un gâteau contient du beurre, des oeufs, ou du lait… Compliqué !
• Partir cueillir et moudre lui-même du blé dès lors qu’il a besoin de farine. En clair : nécessite beaucoup de temps et de volonté pour un résultat tout à fait incertain.
• Jouer les artistes culinaires en progressant à l’aveugle en terrain inconnu. Une ambition dangereuse et très risquée, pour un résultat très certainement raté.

Chacune de ces trois alternatives est évidemment trop coûteuse et très fastidieuse. Le temps investi ne justifie pas nécessairement le coût de production ; ce qui peut s’avérer fâcheux en cas d’erreur, voire même fatal en cas d’échec.

C’est pourquoi travailler avec un design system tend à éviter au maximum ce genre de situations propres aux frustrations et aux embûches.

Élaborer les composants en amont des écrans à l’aide de guidelines précises est donc une méthodologie qui assure la cohérence de l’évolution du produit ainsi que la communication entre ses différentes équipes.