Contexte

Chez Alan, on est tous ingénieurs FullStack. Pour autant, on n'a pas tous les mêmes expériences avec le front, que ce soit en terme de bonnes pratiques, que d'appétence pour le design.

Comment faire alors, pour toujours continuer à livrer la meilleure qualité de software et sublimer le travail des designers, dans une entreprise aussi vivante et dynamique qu'Alan ? Le Design System bien sûr ;)

La Mission

Partant d'une librairie de composants complète mais techniquement endettée (incohérences graphiques, bugs, doubles usages), nous avons, en collaboration avec l'équipe Design mis en place la stratégie suivante:

• Définition du Design System dans son ensemble: principes, composants, atomes, fondations, core components, design tokens

• Refactoring de la librairie de composants:

  • Partage des interfaces (Typescript) entre les libraires React et React Native pour assurer une pratique similaire sur mobile et web

  • Tri des composants et migration de la code base pour définir une relation unitaire entre un usage UX et un composant

• Mise en place d'une documentation avec Storybook

• Création et mise en place design tokens (couleurs, tailles) pour assurer une cohérence maximale dans la gestion des tailles et des marges

• Mise en place de règles de linting (ESLint) pour guider les 80 développeurs vers les bonnes pratiques

• Mise en place de grands principes d'implémentation du design (UI Engineering Principles)

• Mise en place et animation d'une équipe de développeurs volontaires pour faire évoluer le Design System sur le temps long

• Etude et mise en place de la meilleure solution de styling pour nos besoins

La difficulté majeure d'un chantier comme celui-ci est qu'il était nécessaire d'effectuer tous ces changements, sans impacter le travail des 80 développeurs travaillant sur le même repository.

Nous avons donc établi un plan d'action précis pour éviter que l'impact des différentes migrations ne perturbe les autres équipes, notamment grâce à la création de règles de linting "progressives":

• Si une ligne de code ne respecte pas la règle, mais n'a jamais été touchée, le linter se tait

• Si un développeur touche à la ligne en question, alors il doit corriger l'erreur du linter

Nous avons ainsi réussi à apporter de la cohérence graphique en un temps record, en faisant contribuer l'ensemble des développeurs par des micro-changements, sur plusieurs mois.

Aujourd'hui le Design System d'Alan est une pièce maîtresse de son identité visuelle, mais aussi de l'efficacité de ses équipes.