Design system ? C’est quoi ? Pourquoi chez Mindbaz ?

Mai 19, 2021

Avant tout, un design system, qu’est-ce que c’est ?

 

C’est une bibliothèque de composants et d’éléments graphiques basée sur le principe du code réutilisable. L’idée est d’externaliser les récurrences fonctionnelles et graphiques de multiples projets dans un unique projet et d’en faire un outil référentiel UI/UX

 

Il faut voir ça comme une sorte de bibliothèque de legos triés et ordonnés.

Design System - Component Storage

Image par diogenes_3 de Pixabay

Design System - Collaboratif

Photo by krakenimages on Unsplash

Cet outil présente de nombreux avantages et sera à destination à la fois des développeurs, des designers ou des product owners et testeurs.

Pour les développeurs, il facilitera le travail collaboratif (un seul composant pour les différents besoins métiers des projets), la maintenance (une seule codebase à maintenir avec un système de versionning) et l’évolution technique (moins de dépendances et donc moins soumis à la dette technique).

Pour les designers, il leur permettra de mettre en place une véritable cohérence graphique et interactive dans les projets de l’entreprise. On y retrouvera les mêmes règles d’interaction et la même charte graphique. De manière à pouvoir garantir la qualité et l’ergonomie souhaitée du produit.

Et enfin, pour les autres intervenants des projets comme les product owners ou les testeurs, il leur facilitera tout le travail de vérification et de concordance par rapport à la demande initiale.

En isolant chaque composant de manière indépendante et dépourvue de métier, il est bien plus simple de tester et garantir que le résultat corresponde aux règles de gestion et aux tests d’acceptances établis en amont.

Design System - Example

Cool ! Pourquoi ce besoin chez Mindbaz ?

 

Chez Mindbaz, on a pas mal de projets et certains ont un historique plus ou moins important. Sur ces différents projets, on y retrouve différents fronts construits avec plus ou moins de similitudes (mais surtout plus ou moins de différences). 

Design System - Difference

Plus on avance dans les projets et plus ça devient compliqué de conserver et maintenir cette similitude. Que ce soit du point de vue interactif (UX), graphique (UI) ou de maintenabilité (qualité du code). 

Quand on se met à travailler sur de plus en plus de projets simultanément, il y a un moment où ça finit par devenir compliqué.

Design System - Headache

La dette technique peut s’accumuler, les phases de run peuvent s’allonger et ça peut devenir un véritable casse-tête d’avancer et de tout synchroniser (c’est du vécu !).

Il a donc fallu qu’on se pose la question de comment répondre à ces problématiques: pouvoir continuer à développer nos projets tout en garantissant la qualité et la résilience de l’existant. 

La mise en place d’un design sytem s’est avéré être une bonne solution !

Ah ok. Mais du coup, comment ça se met en place ?

Alors ici, il n’y a pas une méthode unique. Ça dépendra de l’environnement sur lequel on travaille. 

En faisant quelques recherches, on remarque très vite qu’il y a une multitude de tutos sur une multitude de technos.

 

Chez Mindbaz, les fronts sont réalisés en Reactjs et couplés à du Material UI pour le rendu des interfaces.

On a voulu partir de cette base pour construire notre design system.

Nos ressources pour notre Design System

Il n’y a pas besoin d’énormément de ressources pour commencer: 

  • notre stack front préférée (React / Typescript / Ecmascript*)
  • une techno permettant d’exposer nos composants dans notre librairie (Storybook*)
  • une techno de gestion de packages pour héberger et versionner nos composants (Verdaccio*)

 

Et si on veut aller plus loin:

  • un framework UI pour gagner du temps et éviter de maintenir trop de choses (Material UI*)
  • une interface pour designer nos composants (Zeplin*)
  • et une techno pour tester nos composants (Jest*)

 

*: ce que nous utilisons

À partir de cela, il suffira ensuite de créer un nouveau projet avec une architecture la plus simple possible.

Ce qui nous intéresse, c’est d’y retrouver un répertoire contenant l’ensemble de nos composants classés par utilisation. Des composants légers et lisibles.

Design System - Files Architecture
Design System - Multi Composants

Photo by Sahand Babali on Unsplash

Il ne faut pas hésiter à créer plusieurs fichiers pour isoler les différentes couches comme le rendu, le style ou les interfaces de typage.

Plus le composant sera léger et plus il sera simple de le maintenir et le faire évoluer sans provoquer de bugs ou régressions (surtout que certains plus gros composants peuvent eux-même se composer d’autres plus petits composants (comme des legos oui)).

L’utilisation de tests (unitaires et snapshots) est vivement conseillée si on veut s’épargner des frayeurs après quelques modifications hasardeuses !

 

Peut-être un dernier petit conseil: procéder par étapes et commencer par les plus petits éléments en priorité.

 

Le mieux étant, avant de démarrer le développement de plus gros composants, de définir les styles via un thème perso (fonts, couleurs, espacements, …) et de se pencher sur les composants natifs de base (boutons, champs texte, formulaires, …).

Ça évitera pas mal d’aller-retours pour les futurs développements et il suffira d’aller piocher ce qu’il nous faut dans notre librairie.

 

Et voilà 🙂