Le Design System chez PrestaShop : le challenge de l’Open Source

TL;DR :

• Le design system peut être un outil de gestion de la dette design.
• Le design system peut être complexe à mettre en place dans une entreprise.
• Le design system fédère les équipes Product/Tech/Brand

Dans un contexte de très forte accélération de sa croissance et d’expansion internationale suite au rachat par le groupe italien MBE Worldwide en 2022, PrestaShop opère en 2023 un repositionnement de la marque.
Qui dit repositionnement dit nouvelle identité, et donc intégration de celle-ci dans nos parcours et dans nos produits. Ce besoin identifié nous a permis de passer plus de temps sur une problématique connue mais à l’époque seulement effleurée : la dette design.
PrestaShop étant une solution Open Source créée par et pour une communauté de développeurs, l’expérience utilisateur, l’UI ainsi que la documentation des contributions n’étaient pas la principale priorité. De plus, notre entreprise a connu une croissance rapide, avec des équipes produit grandissantes et devant s’intégrer rapidement.
Dans ce contexte, une question était au coeur de nos réflexions, comment intégrer une nouvelle identité de marque dans un environnement technologique mixte et basé sur une solution Open Source ? L’arrivée de cette nouvelle identité était pour nous une opportunité de réactualiser la question de la dette design puisqu’elle permettait d’aligner les composants produits sur une même base et d’en faire un enjeu commun à toute l’entreprise.

Le Design System comme outil d’alignement

Le design system est considéré comme le cœur visuel du produit. Il centralise et documente tous les éléments visuels (couleurs, boutons, icônes, checkbox, etc.) en un seul endroit. Alors que les développeurs commentent, ordonnent et structurent leur code, pourquoi le design ne s’inspirerait-il pas d’une telle organisation ?

Un design system est réellement utile :

• Une vélocité augmentée de 50% du design au développement pour une économie annuelle de 250K pour une équipe de 10 designers.*
• Il réduit considérablement, voire élimine la dette design, source d’incohérences, de problèmes d’accessibilité et d’expériences utilisateur inadaptées.

Le design system est un outil efficace pour scaler un business.

Dans le monde de l’entreprise, la création d’un design system peut être un sujet épineux, quels que soient sa taille ou son niveau de maturité. Les arguments contre abondent : le manque de temps, l’apparente inutilité à court terme, le manque de ressources etc. Pourtant, mettre en place un design system est aussi impactant stratégiquement que choisir la bonne technologie pour lancer un MVP.

Les premiers pas vers un projet d’entreprise

En 2022, les équipes design de PrestaShop ont considérablement augmenté, passant de 4 à 16 Product/Content Designers, chacun ayant son propre périmètre.

Les designers travaillaient sur un Design System depuis plusieurs mois. Le projet était encore jeune, voire embryonnaire, peu (re)connu au sein de l’entreprise, ne permettant pas de mobiliser suffisamment les ressources tech notamment. Aussi, il s’apparentait plus à un UIKit qu’à un DS en tant que tel. Ce manque de mobilisation autour du sujet ne permettait pas d’adresser les questions structurantes nécessaires à sa bonne réalisation, comme le choix de la technologie, et la stratégie de mise en oeuvre. Les discussions ont longtemps stagné et n’ont pas permis d’avancer de manière constructive.

La nécessaire déclinaison de la nouvelle identité de PrestaShop, tant sur les outils de communication externes, que sur notre logiciel, a servi de catalyseur. Dès lors, les expertises nécessaires ont pu s’emparer officiellement du sujet Design System.

C’est ainsi que Fabien (VP Engineering), Aubin (Front Developer) et moi-même, Lead Product Designer, avons pris les commandes du sujet Design System. Quelques semaines plus tard, nous avons été rejoints par deux Product Designers pour assurer la communication, suivis d’un Tech Manager, d’une Lead Product Manager et d’un Lead Agile.

Petit à petit, le projet attire l’attention. Nous sommes désormais une équipe de 9 personnes, accompagnée de notre armée de designers et de développeurs motivés à contribuer à ce projet d’entreprise qui fait de plus en plus de bruit.

L’initiative étant nouvelle, nous n’avons pas d’équipe entièrement dédiée à 100% sur le projet. Il a été convenu que chaque contributeur consacrera un pourcentage de son temps à une tâche liée au Design System. Ainsi, nous pouvons avancer dans la mise en place du projet sans créer une équipe dédiée.

Négociations, argumentaires, décisions et politique

Le lancement du projet Design System a permis de mettre en place des phases exploratoires sous formes de deux chantiers simultanés :

Côté développeurs, des recherches ont été effectuées pour décider du framework CSS à utiliser (Bootstrap, Tailwind, Element…) et une réflexion a été entamée sur la migration.

Côté design, il s’agit de définir les besoins (thème, mobile, desktop), l’UX et de commencer à créer les premiers atomes (UI).

Les designers travaillent alors sur un challenge d’entreprise. Comment décliner la nouvelle identité de marque de PrestaShop sur le logiciel ? Tout ça en imaginant une version du produit à 5 ans, sans contrainte. Un article sera dédié à ce challenge tant il a été stimulant pour les designers, mais également pour l’entreprise.

Ces deux tâches ont été menées simultanément et ont pris environ un trimestre pour être finalisées. De nombreux débats entre les ingénieurs ont eu lieu, principalement à propos des technologies à utiliser. Il aura fallu plusieurs réunions et répondre individuellement aux craintes pour s’entendre sur l’utilisation du framework Tailwind.

Voici quelques unes des questions qui ont fait jaser le Slack :

• Pourquoi tout refaire alors qu’on a déjà Bootstrap ?
• Tailwind est mobile first, vous y avez pensé ?
• Comment on migre les 143 pages de notre produit ?
• Comment faire cohabiter les deux ?
• Comment utiliser Tailwind si je n’utilise pas VueJS ?
• La librairie actuelle ne répond pas à mon besoin, comment je fais ?

Un exercice fastidieux mais qui a fini par payer.

Token ou pas Token ?

Un autre débat, celui du Token Design. Étant au début du projet et ne voulant pas rater un virage majeur dans le domaine nous avons fait des tests et des recherches sur l’utilisation du token.

A l’heure ou j’écris ces lignes, Figma propose les Variables pour défendre le sujet. D’autres plugins comme Figma Token permettent de pousser automatiquement sur GitHub des mises à jour design de token. On pourrait imaginer que les Product Designers ou même nos contributeurs de l’Open Source puissent modifier le design system sans toucher une ligne de code.

La complexité réside dans les création elle même de ces tokens. Sur quel composants, atomes, valeurs devons nous créer un Token.

Que souhaitons-nous rendre modulable ?

Nous avons pris la décision d’y intégrer les tokens de bases (couleurs, typographie) et de surveiller l’arrivée d’un prochain outil qui pourrait nous aider à automatiser la création de tokens sur une large palettes de composants. Une chose est sûre, nous ne souhaitons pas louper négliger cet aspect.

Edit : Entre temps Adobe a lancé son outil que nous nous empressons de prendre en main.

Ces phases d’assise du projet nous ont permis d’établir une entente commune sur les objectifs et les enjeux. Suite à ces discussions, nous avons pu entamer les ateliers initiaux permettant de créer une base commune au Design System, tant d’un point de vue technologique que design

• Voici deux très bons articles pour étayer ces chiffres :
  https://zeroheight.com/blog/what-is-the-value-of-a-design-system/
  https://www.smashingmagazine.com/2022/09/formula-roi-design-system/