Design System de Consoneo

Durée

1re version : 6 mois
Rôle

Lead Product Designer
Équipe

2 autres designers, 1 développeur full-stack 1 Product Manager

Contexte

Pour être en cohérence avec la nouvelle stratégie mise en place dans l’entreprise en début d’année 2022, la direction a décidé de moderniser son image en repensant entièrement son identité visuelle.

Le besoin d’établir une harmonie entre les différents produits est donc rapidement devenu une nécessité et une des priorités numéro un. Tandis que j’encadrais mon équipe dans ce rebranding, j’avais en parallèle pour mission de concevoir, seule dans un premier temps, le tout premier Design System de Consoneo, sur lequel reposerait nos produits existants ainsi que les prochains.

Exemples d'incohérences

Objectifs du Design System

Établir une consistance pour renforcer l’identité de marque et montrer son engagement envers la qualité, la cohérence et l’attention aux détails dans les produits et services.
Améliorer l’expérience utilisateur pour que les utilisateurs apprennent plus rapidement à utiliser les produits, et que ces derniers deviennent plus intuitifs.
Augmenter la productivité en utilisant des composants réutilisables, ce qui permet d’accélérer le processus de développement des produits et de faciliter les mises à jour.
Favoriser la scalabilité

Contraintes

Temps et ressources : la date de livraison de la première version étant proche et le fait que je sois, au lancement du projet, seule, nous obligeait à être pragmatique dans la mise en place de ce DS.

Nous devions accepter l’imperfection et préparer les prochaines itérations dès le départ. Par exemple, dans un premier temps, la documentation du DS serait exclusivement dans Figma pour les designers et dans Storybook pour les développeurs.

Processus de création (aka le plan d'attaque)

Le maître mot en matière de DS est la collaboration. Les développeurs ont été très impliqués et nous ont beaucoup conseillé tout au long de ce processus, autant dans le choix des outils que dans les méthodes de travail à envisager.

Découpage du projet dans Figma

Composer (et recomposer) les palettes de couleurs :

Gagner du temps en s’aidant de générateur de palettes performants
- Utiliser un découpage de palette clair et efficace
- Couleurs primaires et secondaires + couleur de soutien issus du branding
- Couleurs neutres : gris chauds et gris froids
- Couleurs sémantiques réservées au produit : info, success, warning, danger, focus
Réadapter les couleurs de branding établies pour une utilisation produit (soin porté à l’accessibilité et à une homogénéité globale)
Anticiper les besoins futurs en préparant une couleur neutre de marque blanche (tertiaire)
Anticiper les besoins en testant une version dark mode des palettes
Challenger en équipe les parti-pris

Choix des méthodologies à adopter et du système de nommage des composants

Un fichier “Components” comprenant :

Les règles à suivre pour utiliser et maintenir correctement le DS
Les changelogs détaillant avec précisions les mises à jour effectuées
Chaque composant expliqué et contextualisé dans une page dédiée

Prévenir les développeurs des mises à jour

En utilisant un plugin pour versionner les mises à jour et en établissant un rapport détaillé des changements effectués, autant dans le fichier “Assets” que dans “Components”

Template de documentation

Afin de clarifier le contexte d’utilisation des composants et de rendre leur lecture plus agréable. Ce template comprend : un encart dédié aux règles générales à suivre pour maintenir le DS de manière cohérente, un encart pour les composants “master” et leurs composants enfants (souvent non publiés), un encart pour contextualiser les composants et les prototyper, un encart pour les composants prêts à être utilisés et un encart pour les cas particuliers concernant les composants utilisant des variables spécifiques.
Pour faciliter l’apprentissage des méthodes de travail par les nouveaux designers
Pour disposer d’une source de vérité disponible à tout moment en cas de doute.

Nommer un composant

Les composants disposent de noms standards et donc cohérents et facilement identifiable. A l’aide de component.gallery, nous avons sélectionné ceux qui nous convenaient le mieux. Quelques exemples : Button, Calendar, Modal…
Le système mis en place fonctionne comme suit :
- Utilisation des chevrons pour les “core” composants. Ex : <Accordion>
- Les composants “enfants” et imbriqués (props) sont signalés à l’aide du mot “Assets”, un emoji losange orange et non publiés.
- Comme les props, les composants “slots” sont également signalés et différenciés par un emoji losange bleu.
- Le système de classification des composants natif de Figma peut être exploité en utilisant les slashs dans le nom des composants pour faciliter leur recherche dans un projet.

Contextualiser un composant

Chaque composant est présenté, décrit et légendé à l’aide du template de documentation. Ce dernier permet notamment de préciser les animations liées aux interactions avec le composant et d’apporter toutes les informations nécessaires à la bonne utilisation du composant.

Construire un composant

Les composants les plus complexes comprennent toutes les propriétés qui leurs sont utiles en évitant la multiplication inutile de variants. Les différentes déclinaisons possibles sont ainsi mis en lumière dans la partie dédiée à la contextualisation du composant.

Utiliser les emojis – avec parcimonie – dans le nom des propriétés permet de les repérer en un coup d’œil. L’utilisation des slots accorde une flexibilité et une modularité parfois primordiale.

Proposer des composants stratégiques

Ces composants ne sont pas à développer car ils ne sont pas de “vrais” composants à proprement parler. Ils ne sont utiles que dans Figma car ils permettent de gagner un temps considérable dans la conception de produit et d’optimiser les mises à jour des maquettes. Ex : “Textfield”.

D’autres composants utilisés comme “props” prennent quant à eux tout leur sens une fois imbriqué dans un autre. Ex : “Label” dans “Textfield” ou “Paragraph” dans “Accordion”

Variabiliser le DS

Avant les récentes mises à jour Figma, un travail de nommage et de classement des variables a été effectué au préalable grâce à Figma Tokens.
Nous avons ensuite chirurgicalement remplacé les styles utilisés dans les palettes de couleur par des variables et déterminé des variables spécifiques pour les composants pour lesquels cela était requis.
L’équipe en a profité pour compléter et corriger certaines couleurs.

Enfin, nous les avons testé en simulant des marques blanches sur des projets réels.

Résultats

Une implémentation des composants 2 fois plus rapide côté développement depuis l’utilisation du nouveau Design System.

Un maquettage également 2 à 3 fois plus rapide côté design grâce aux différents templates de page créés.

Une adaptation des interfaces en marque blanche en un temps record : seulement 2 jours pour modifier les variables nécessaires, faire une review des maquettes et les tester.

Conclusion

Enfin, nous les avons testé en simulant des marques blanches sur des projets réels.Le fait que chaque projet soit développé avec des langages différents nous oblige à opérer un monitoring constant – et à avoir un œil particulièrement aguerri lors des tests avant les mises en production – afin de veiller à la bonne mise à jour des composants et ainsi à la cohérence globale de chaque interface.

Toutefois, au cours des 2 dernières années, l’équipe design a acquis une réelle expertise en design system, tant sur sa conception minutieuse que sur sa gestion stratégique et a su implémenter les nouvelles méthodes de travail relatives aux mises à jour de Figma à chaque fois, et surtout, savoir les transmettre.

Notre souhait à long terme serait que le DS devienne la source de vérité pour tous les projets de Consoneo, qu’ils soient “brandés” Consoneo ou en marque blanche, et qu’une page dédiée au DS et détaillée existe sur consoneo.com.