Les 3 piliers d’un Design System, Saint Graal de tout produit digital

Toute entité concevant des produits digitaux ne peut se passer d’une telle approche pour tenir bon face à la concurrence.

Lisa serait-elle à l'origine de ce diagramme ?

Diagramme de Venn à la rescousse !

Quoi de mieux qu’un diagramme de Venn pour représenter trois grands principes interconnectés ? Il rend les choses plus compréhensibles, et si l’on parvient à donner un rôle tangible aux liens qui les unissent, alors la mission d’évangélisation est accomplie. On retrouve parfois un peu de post-rationalisation dans un diagramme de Venn. Après tout, un diagramme de Venn sans post-rationalisation est presque ennuyeux !

Les trois grandes disciplines concernées par un Design System. Nous verrons par la suite quels sont les liens qui les unissent.

Pilier n°1 : le matériel graphique

C’est la partie la plus facile à appréhender. Comme dans toute charte graphique, on décrit la forme visuelle que les éléments prendront. En plus des composants (détaillés plus loin), on y inclut les gammes de couleurs et les typographies à utiliser, mais également les ressources iconographiques et une bibliothèque de visuels s’il y en a.

Pilier n°2 : le code

Afin d’accélérer le développement et la production, la réutilisation du code est fondamentale. Une librairie de codes doit donc faire partie d’un Design System pour le rendre efficace. Selon la structure de la plateforme technique, on pourra a minima y trouver du code HTML et CSS. On peut aussi y trouver des templates de pages, du javascript, en particulier des composants React ou Angular… Le seul pré-requis étant que cela permette de développer tous les supports nécessaires au produit et ses déclinaisons.

Pilier n°3 : les guidelines

C’est certainement ce pilier qui donne à un Design System tout son intérêt ! Comme pour les LEGO, vous avez besoin d’un plan de construction qui vous donne toutes les clés pour concevoir une interface qui respectera le besoin utilisateur, les valeurs de la marque, et les bonnes pratiques de conception.

Les guidelines peuvent par ailleurs aller bien plus loin qu’un simple plan de construction. On pourrait y trouver notamment :

• Les guidelines de design (détaillées plus bas)
• Les valeurs de marque
• Des bonnes pratiques de conception UX
• Des guidelines Social media, et plus généralement de communication
• La charte éditoriale (ou Tone of voice)
• Des guidelines iconographiques (quel type de visuel pour quel message)

Quels sont alors les liens entre ces 3 piliers ?

En plus d’être très pédagogique, un diagramme de Venn fait toujours son petit effet dans une présentation il faut l’avouer !

Graphisme + code = des composants

Selon Wikipedia, dans sa définition générique, «Un composant est un élément de base d’un ensemble plus complexe, lequel est un assemblage de composants souvent différents ».

Appliqué à notre Design System, un composant se traduit par tout élément graphique réutilisable et pouvant être intégré dans une interface graphique. L’organisation et la hiérarchisation de composants est souvent inspirée de celle de l’atomic design proposée par maître Brad Frost. Certains préfèrent toutefois choisir des modèles plus proches de leur métier et catégoriser les éléments en fonction de leur usage plutôt que de leur forme.

De cette façon d’organiser les éléments nous pouvons facilement imaginer qu’il sera facile d’intégrer une version HTML/CSS de chacun de ces composants. Et ce d’autant plus avec l’utilisation croissante de librairies component-based telles que React ou Angular.

Graphisme + guidelines = des design guidelines

Cette partie se concentre sur les consignes visuelles de conception. Elle concerne entre autres l’utilisation d’une couleur dans un contexte donné, les règles d’utilisation typographiques, les consignes pour la création de nouveaux composants et l’utilisation de la grille de composition. Bref, tout ce qui touche au visuel et qui n’est pas “visible”.

Guidelines + code = des spécifications techniques

De la même manière que les design guidelines, les spécifications techniques décrivent tout ce qui est à prévoir “autour” du code. Les environnements de développement, de test, de production, les normes d’accessibilité, les conventions d’écriture du code, les modèles de données… Il n’y a pas vraiment de limite. Le but est que n’importe quel développeur puisse être opérationnel en se documentant sur ces spécifications, et que chaque codeur puisse intervenir sur le code d’un autre sans s’arracher les cheveux !

Le pilier invisible (dit “le divin“) : L’HUMAIN

Il est présent dans chacun des trois autres piliers et il est d’autant plus indispensable qu’un Design System fait appel à un nombre conséquent d’expertises (design, technique, communication, branding…) souvent divisées en pôles bien distincts et dont le partage est parfois perfectible. Le succès d’un Design System ne tient que si toutes ces expertises travaillent en concertation et en respectent les consignes. Avant même de commencer un Design System, il faut s’assurer que toutes les parties prenantes ont bien compris l’intérêt et les enjeux d’une telle approche. Et pour cela il faut COMMUNIQUER !

En conclusion…

Cette façon de présenter un Design System est une bonne première approche pour toute personne étrangère à ce concept. Il existe un grand nombre de façons de l’organiser ; cela doit avant tout se faire dans l’intérêt du projet. Le but est de gagner du temps de production !

Note : le visuel de titre a été réalisé avec la boîte LEGO n°10698 (https://www.instagram.com/p/BqRiknlBKss/)