Préparer la mise en place de son Design System : le cas OS de PrestaShop
Cet article est le second d’une série dédiée à la création d’un Design System chez PrestaShop. Retrouvez le premier article ici — lien
[Résumé article 1] Le design system centralise et documente tous les éléments visuels (couleurs, boutons, icônes, logos, etc.) en un seul endroit. Nous avons décidé de créer un Design System pour faire suite à notre rebranding et intégrer au mieux la nouvelle identité de notre marque au sein de nos produits.
Après de nombreuses discussions entre équipes tech et produit afin de clarifier les enjeux et objectifs du Design System, nous avons pu lancer les ateliers initiaux, gages de sa réussite.
TL;DR :
Réaliser un audit avant de commencer le Design System
Estimer la dette design
Collaborer avec les devs pour s’entendre sur le meme language
Analyser l’état actuel du produit
Créer et déployer un Design System implique un retravail de l’existant. Pour ce faire, il est essentiel de parcourir le produit dans son ensemble afin d’établir la base de notre champ d’intervention.
Examen du code
Nous avons entrepris un examen complet de notre produit pour identifier les parties du code qui ont été créées manuellement et celles qui utilisent des composants. Nous avons constaté que de nombreuses parties de l’Open Source utilisaient une ancienne version de Bootstrap et deux autres librairies: Element+ et Tailwinds
Examen de la documentation
Nous avons procédé à un audit interne afin d’évaluer les incohérences au niveau de l’expérience utilisateur (UX) et de l’interface utilisateur (UI) entre nos différentes pages. Nous avons identifié que les erreurs étaient souvent causées par une utilisation incorrecte ou incohérente de nos bibliothèques de composants. Par conséquent, nous avons décidé d’entreprendre un audit de la documentation afin de garantir que toutes les informations concernant l’utilisation de nos bibliothèques soient claires et précises.
Examen du Figma
Puis, nous avons effectué une revue approfondie de notre librairie Figma, utilisée pour la création de nos maquettes. Il en ressort que certains composants sont absents, mal conçus, ou incohérents.
Comment évaluer la dette design ?
L’examen de la dette design est l’élément le plus important avant de procéder à la création et au développement d’un Design System. Cela nous donne des arguments pour justifier un tel chantier et également fédérer des équipes autour de ce sujet.
Sous forme d’atelier, nous avons répertorié l’ensemble — une bonne partie– des écrans de nos produits dans un Miro. Toutes les équipes ont relevé les incohérences.
Puis, on tag, on trie, on enlève les doublons ! Et enfin on regroupe chaque post it par composant ! Un super travail réalisé qui nous permet d’analyser l’ampleur du chantier.
En deuxième partie d’atelier nous avons fait du card sorting pour prioriser les composants à forte valeur utilisateur avec un effort design et tech modéré. Nous avons fait participer les développeurs et les designers.
Pour résumer, 4 étapes pour un workshop réussi :
- Répertorier les écrans du produit
- Identifier les incohérences
- Tagger, trier et regrouper les incohérences par composant
- Prioriser les composants à forte valeur utilisateur
On se retrouve alors avec un backlog design des premiers composants à créer et implémenter. On note par exemple : uniformiser le header, uniformiser les boutons primary et secondary, uniformiser les espacements… On notera que naturellement les premières actions concernent des éléments basiques du design system.
Maintenant que nous avons réalisé un bilan complet de notre produit, nous pouvons définir une roadmap des premières actions basées sur des éléments concrets et commencer à réduire la dette design.
D’abord, parlons la même langue.
La communication entre les développeurs et les designers est un des éléments clé pour réussir la création d’un design system. Nous avons eu plusieurs échanges sur la sémantique des composants afin d’appeler un chat un chat. Ou du moins, de nous mettre d’accord sur le prénom du chat !
Nous avons créé un grand tableau avec tous les éléments atomiques de notre design system actuel. Ainsi, chaque couleur, police, espacement et border-radius a été listé. Les corrections ont été appliquées sur Figma et la documentation pour garantir une concordance parfaite.
Certaines couleurs et typographies, trop proches ou inutiles, ont été modifiées ou supprimées. Pour faciliter l’implémentation, nous créons un tableau de conversion comme celui-ci :
Puis nous détaillons les fondamentaux (spacing, sizing, radius, shadows, typography, colors, opacity)
Et maintenant ?
Le projet Design System est bien lancé, il commence à faire du bruit dans l’entreprise. Nous avons réalisé plusieurs présentations pour expliquer le projet et ses grandes étapes. Certaines squads l’attendent avec impatience, d’autres sont encore sceptiques. Pour bien cadrer les processus de contribution, de migration et mettre à disposition le kit avec un minimum de composants, nous décidons de prendre le temps de retarder le lancer de 3–4 semaines.
La prochaine étape sera la création des premiers composants, de la documentation technique de migration (Storybook), la documentation design (Zeroheight) et la création des composants principaux (Figma).
Les 2 prochains challenges :
Il est indéniable que la migration représente le 1er défi technique où trouver l’équilibre entre priorité et gestion des ressources est essentiel.
Le second, se porte sur la contribution et l’adoption du design system auprès des équipes et du public (contributeurs Open Source). Mettre en place un processus de contribution, de validation et de mise à jour. A la fois pour l’interne mais aussi pour la communauté.
Nous aspirons à maintenir la cohérence du système tout en préservant une certaine liberté afin de ne pas entraver la vélocité de nos équipes et partenaires.
Nous n’abordons pour l’instant le Design System que dans ses problématiques internes, mais tâcherons de vous raconter nos choix et problématiques autour de son application dans le contexte de notre environnement Open Source dans de futurs articles.
Une chose est sûre, il a déjà permis de rapprocher les développeurs et les designers sur un sujet commun et s’inscrit parfaitement dans la vision d’entreprise et ses objectifs de stabilité et personnalisation du produit. Ce rapprochement a été entre autre possible grâce à la création de nos 5 librairies visant non seulement à faciliter la prise en main interne mais aussi à faciliter l’utilisation externe du Design System par notre communauté Open Source.
