Design System @ Le Parisien — Partie 1 : Définition & Objectifs

Pourquoi créer un Design System?

Il y a 1 an, nous avons décidé de créer un Design System en interne au Parisien. Au travers de cette série d’articles, nous allons vous présenter l’histoire sa genèse, quels étaient les objectifs et comment nous l’avons développé.

1. Organisation

La direction technique du Parisien est une équipe constituée de 42 personnes divisée en 5 squads. Chaque squad est responsable d’une ou de plusieurs parties de l’écosystème numérique du Parisien et travaille sur ses propres sujets :

• Squad Audience : responsable de la publicité, des scripts externes ainsi que de la Homepage
• Squad Engagement : responsable de la partie éditoriale du site
• Squad Abo : responsable de la partie abonnement et compte utilisateur
• Squad Verticales : responsable des différentes marques gravitant autour de l’univers du Parisien : Le Guide, L’étudiant, etc…
• Squad App : responsable des applications mobiles iOS et Android

Une squad comprend généralement 1 PO (project owner), 1 PM (project manager), plusieurs développeurs front et back ainsi qu’un QA. L’équipe design intervient en transverse sur l’intégralité des squads en fonction des besoins. L’idée étant de spécialiser chaque équipe sur des features spécifiques ayant une cohérence métier, permettant une meilleure efficacité dans le run et le build des nouvelles features.

Une (petite!) partie de notre équipe dans les locaux du Parisien

Côté stack technique, nous utilisons le CMS Arc Publishing permettant de gérer facilement le contenu éditorial d’un site au sein d’une rédaction. D’un point de vue technique, Arc nous permet de développer des éléments front en React et de réaliser du serveur side rendering afin de répondre aux problématiques de performance et de SEO.

2. Problématiques

Un des challenges face à l’organisation en squads est le partage du code entre les équipes. Chaque squad réalisant ses propres développements au fur et à mesure des sprints, il est difficile d’avoir de la visibilité sur tous les composants existants. Bien que nous organisions une démo des squads toutes les 2 semaines afin que chaque équipe puisse présenter son travail, cela n’est pas suffisant pour avoir une vision globale au jour le jour des nouveaux éléments ajoutés.

Par conséquent, nous nous retrouvons avec des variations de styles pour un même composant, chaque équipe ayant développé sa propre version ou ses propres classes utilitaires (ce n’est évidemment pas toujours le cas). Cela impacte le branding du Parisien et augmente le poids total la codebase car certains éléments sont développés en plusieurs fois. De plus, nous n’avions pas d’environnement pour présenter nos composants de manière exhaustive ni de documentation claire pour les utiliser.

Le composant bouton est un des exemples les plus flagrants avec de nombreuses différences en production: hauteurs, styles de texte, largeur des bordures, majuscule vs minuscule, etc…

3. Un Design System, qu’est-ce que c’est?

Par le passé, une entreprise développant un site ou un produit avec une équipe front essayait de créer des éléments réutilisables. Les frameworks JS étant inexistants, on concentrait principalement nos efforts autour des feuilles de style CSS et notamment des classes génériques que l’on pouvait réutiliser à travers notre produit pour construire les pages. Il n’y avait pas réellement de structure modulaire permettant de monter des templates.

Le concept d’atomic design introduit par Brad Frost en 2013 dessinait les prémices de ce qu’on appellerait plus tard Design System : on a alors commencé à construire des composants indépendants (grâce aux frameworks JS tel que React) et à les regrouper par catégories : atoms, molecules, organisms, templates et pages. La classification se faisait surtout par rapport à la taille et la complexité de chaque composant. Une page était structurée autour d’un template, lui même composé de plusieurs organisms intégrant des molecules construites à l’aide de multiple atoms.

Pour avoir déjà expérimenté cette méthodologie par le passé, elle n’est pas toujours optimale : il est souvent difficile de classifier correctement un composant car chaque personne aura un avis divergent sur la question. Par exemple, la différence entre une molécule et un organisme est assez mince pour certains composants. De plus, nous n’avions pas forcément besoin d’un niveau de granularité aussi élevé pour construire notre système : un composant reste un composant, peu importe sa taille ou sa complexité.

Pour nous, un Design System doit rester simple : c’est un ensemble de resources réutilisables (styles et composants) représentant l’identité d’une marque. L’idée étant qu’il permette à chacun, aussi bien en design qu’en développement, d’utiliser des éléments existants pour construire les pages d’un site ou d’un produit sans devoir réinventer la roue en permanence.

4. Objectifs

Nous nous sommes ensuite demandés comment nous allions structurer notre système. Pour nous, il était clair que nous devions le séparer en 2 parties :

1. Une librairie Figma à destination des designers. Cette librairie allait nous permettre de designer les pages en réutilisant les mêmes éléments.
2. Un package NPM à destination des développeurs pouvant être installée dans les différents projets afin d’importer les styles et les composants à la volée.

Ces 2 parties se devaient d’intégrer aussi bien les resources intangibles (couleurs, styles de texte, espacements, etc…) que les resources tangibles (composants). Le naming des éléments dans le système serait le même entre les designers et les développeurs, aussi bien pour les styles que pour les composants. Grâce à cela, nous souhaitions répondre à 3 objectifs principaux :

1. Avoir un langage unifié pour les styles et les composants entre designers et développeurs.
2. Éviter les duplications et les différences de styles entre les composants au sein de notre écosystème.
3. Faciliter et accélérer l’intégration de nouveaux templates ou de nouvelles features grâce aux éléments existants et réutilisables.

La difficulté d’un Design System est de construire des éléments qui soient complètement agnostiques d’un contexte ou d’un contenu donné. En effet, la tentation est forte de vouloir intégrer chaque nouvel élément d’UI dans le système dès lors que l’on commence un nouveau projet. Cependant, les 2 questions principales à se poser pour chaque élément sont les suivantes :

1. Est-ce que le composant que je suis en train de développer va être utilisé plusieurs fois sur mon projet?
2. Si oui, va-t-il être réutilisé sur d’autres projets en dehors du mien?

Si la réponse est oui à ces 2 questions, alors il se peut que l’élément soit qualifiable pour être intégré au système. Dans la suite de notre série, nous allons donc voir comment nous avons pu traduire tout cela en design ainsi qu’en développement.