Quand je rejoins Maisons du Monde, les équipes produit, design et tech travaillent déjà à plein régime :

• évolution des parcours e-commerce,
• refonte progressive du site,
• nouvelles fonctionnalités sur les différentes apps,
• montée en puissance des usages mobile et appshop.

Mais, comme dans beaucoup d’organisations, l’interface est construite au fil de l’eau, par besoin, par feature, par sprint :

• des composants développés “à la demande”,
• peu de mutualisation,
• pas de référentiel unique,
• et des écarts croissants entre ce qui est dessiné et ce qui est réellement en production.

Conséquences :

• dette UX/UI difficile à maîtriser,
• incohérences visuelles et fonctionnelles,
• difficulté à réutiliser / factoriser,
• onboarding designers & devs coûteux,
• temps perdu à “retrouver” ou “recréer” des composants existants.

Ma mission, poser les fondations d’un Design System global, capable de :

• aligner les équipes design & dev,
• structurer la production (Design Ops),
• accélérer la delivery sur tous les produits digitaux,
• tout en restant pragmatique, soutenable et co-construit avec le terrain.

Avant de produire des composants, nous avons commencé par quelque chose de moins visible, mais fondamental : le langage.

Chaque équipe avait déjà :

• ses habitudes de nommage,
• ses conventions internes,
• ses façons de décrire l’interface.

Résultat :
Un même concept pouvait être nommé 3 ou 4 façons différentes, selon que l’on s’adresse à un designer, un développeur ou un PO.

Ce que nous avons mis en place :

• Ateliers et échanges croisés Design / Dev
• Identification des divergences de vocabulaire
• Définition d’une terminologie commune
• Création d’un glossaire vivant, intégré à la documentation

Ce glossaire est devenu la base d’une grille de lecture commune pour tous les composants. Avant de parler pixel, on s’est alignés sur les mots.

Le Design System Maisons du Monde regroupe aujourd’hui :

• 44 composants Design System (socle UI, avec tokens et styles),
• utilisés par environ 150 composants Front sur les apps e-commerce, mobile et appshop.

Avant : classification atomique

La première version du DS était structurée selon l’Atomic Design (Atomes / Molécules / Organismes).

Sur le papier, la logique est claire.

Dans la pratique :

• les développeurs ne cherchent pas un “Organisme”,
• ils cherchent “le composant du carousel pour la navigation”,
• ou “la liste d’options de livraison après le panier”.

Résultat :
Une arborescence peu intuitive,
une recherche compliquée,
et donc une adoptabilité limitée.

Après : classification par fonction

Nous avons donc tout repris avec les développeurs et :

• abandonné la classification uniquement par taille / granularité,
• adopté une logique par fonction / usage.

Exemple :
Un Carousel est désormais rangé dans Navigation et non plus dans une catégorie fourre-tout de type “Organismes”.

Cette arborescence est miroir :

• côté design : Figma,
• côté dev : bibliothèque Vue exposée dans Histoire.

Le Design System devient cohérent, trouvable, utilisable.

Une fois langage et structure alignées, nous avons consolidé un double référentiel unique :

• Figma → pour les designers (UI, variantes, tokens, guidelines)
• Histoire → pour les développeurs (composants Vue, playground, props)

Côté Histoire

Chaque composant est exposé avec :

• un playground interactif pour jouer avec les props (variant, level, size, etc...),
• des exemples d’usage,
• une visualisation directe des états.

Cela permet :

• aux développeurs de valider l’implémentation,
• aux designers de challenger les détails,
• aux QA / PO de comprendre les possibilités réelles du composant.

Côté Figma

Les mêmes composants sont :

• modélisés avec toutes les variantes (états, tailles, niveaux),
• nommés selon la même nomenclature,
• reliés à la documentation (props, usages, do/don’t).

Un principe fort : un composant n’est “terminé” que lorsqu’il est aligné et documenté dans Figma et dans Histoire.

Le Design System n’est pas qu’un livrable :
il a servi de socle au Design Ops.

Nous avons mis en place :

• des Design System Reviews hebdomadaires avec les développeurs,
• un Design System Board hebdomadaire avec les designers,
• un workflow de contribution :
• proposition d’évolution,
• conception / implémentation,
• documentation,
• validation,
• diffusion,
• une logique stricte de single source of truth : pas de composant “off” ou “caché” dans un coin.

Impact Design Ops

✔ Meilleure synchronisation Design / Tech
✔ Beaucoup moins de doublons
✔ Onboarding designers et développeurs accéléré
✔ Alignement fort sur les comportements et états
✔ Diminution des retours tardifs en sprint
✔ Un référentiel consultable par tous (Design, Dev, PO, QA)