Construire un design system avant une refonte
Axeo devait passer par une refonte complète de son interface. Plutôt que de foncer directement dans le redesign, l'équipe a fait un choix structurant : poser d'abord un design system commun entre design et dev. Cette case study revient sur ce chantier préparatoire et sur la manière dont il a été construit.
Problème
Avant la refonte du produit, chaque écran avait développé sa propre logique. Les designers redessinaient régulièrement les mêmes boutons, les mêmes cards, avec des variations mineures qui n'avaient pas de raison d'être. Côté développement, ça se traduisait par des questions récurrentes sur des points jamais formalisés : le comportement au survol, l'affichage sur mobile, la gestion des états désactivés.
Cette dette avait un coût direct : du temps perdu en allers-retours, une expérience produit peu homogène, et un risque réel de reproduire ces mêmes incohérences dans la nouvelle version de l'app si rien ne changeait en amont. Il fallait d'abord établir un langage commun entre design et développement, avant même de penser aux nouveaux écrans.
Mon rôle
Designer au sein de l'équipe produit, j'ai contribué à la construction du design system aux côtés des développeurs, designer, product owner et product managers, avec qui la collaboration a été particulièrement étroite tout au long du projet.
Travailler ensemble
La réussite de ce projet tenait moins aux composants eux-mêmes qu'à la façon dont design et dev ont travaillé ensemble pour les définir. Deux pratiques ont structuré cette collaboration :
Des sessions de travail communes : Plutôt que de transmettre des specs figées par Slack ou Figma, designers et développeurs se retrouvaient directement pour caler ensemble le comportement attendu côté design et ce que la technique permettait de faire. Ce format a évité une bonne partie des allers-retours habituels, et surtout, a permis d'anticiper les contraintes techniques en amont plutôt que de les découvrir en cours de développement.
Un Storybook documenté par les designers eux-mêmes : À l'initiative de l'équipe, les designers ont pris en charge la rédaction de la documentation des composants dans Storybook. Pas uniquement les specs visuelles, mais aussi les états, les comportements et les cas limites. Cette responsabilité, généralement laissée aux développeurs, a rapproché les deux équipes sur un référentiel commun et a nettement réduit l'ambiguïté au moment de l'intégration.
Résultat
Le design system a posé les bases sur lesquelles la refonte d'Axeo a pu s'appuyer, avec un référentiel commun, cohérent et documenté.
Les retours des deux équipes ont confirmé la pertinence de cette approche collaborative :
- Côté design, la documentation Storybook est devenue une référence réellement utilisée au quotidien, à l'opposé d'un fichier Figma qui aurait fini par se déconnecter du produit réel.
- Côté développement, le design system a été perçu comme clair et simple à intégrer. Moins de questions, moins d'ambiguïté sur les comportements attendus.