Design System
Cross-platform
2022 - 2025
Industrialiser un design system dans un grand groupe
Aligner design, produit et engineering, en plein changement de stack, avec des équipes peu habituées à travailler ensemble.
Rôle
Lead Product Designer
Equipe
11 Flutter dev ⸱ 3 designers ⸱ 2 PO
Organisation
Grand groupe
Type de produit
Produit interne
Le contexte et les enjeux
The what
UN ENVIRONNEMENT COMPLEXE
Enphase est un acteur majeur du solaire et du stockage d’énergie.
Son écosystème s’appuie sur de nombreux outils internes, des plateformes métiers et une application mobile pour les utilisateurs finaux.
The when
UNE VOLONTÉ DE CHANGEMENTS
Deux événements ont servi de déclic :
La refonte de l’app mobile, enfin guidée par des données utilisateurs
Un changement technologique, de React vers Flutter
C’était le bon moment pour repenser le système, pas juste les écrans.
the why
DES PROCESS D'UN AUTRE TEMPS
Chaîne produit très manuelle, sans base commune entre design et dev
Écrans bricolés, handoff quasi inexistant, validations à la volée
Beaucoup d’itérations, avec des écarts constants entre l’intention et le rendu
Incohérences entre pages et produits, dépendance aux individus plutôt qu’au système
Concrètement, chaque équipe avançait vite… mais dans son coin.
Les designers livraient des écrans, les devs les réinterprétaient, et le produit passait son temps à arbitrer des détails UI au lieu de décisions produit.
the who
DES ÉQUIPES DÉPASSÉES
Les premiers impactés n’étaient pas les utilisateurs finaux, mais les équipes elles-mêmes.
Designers, développeurs front-end et product owners travaillaient en silos, avec peu de collaboration réelle.
Ce n’était pas un problème d’outils, mais surtout de langage commun et de confiance entre équipes.
TL;DR
Produits multiples, équipes en silo
Process manuels et peu industrialisés
Qualité et vitesse en tension permanente
Refonte mobile et changement de stack comme déclencheur
Les décisions clés
Prouver la valeur du design system
Avant …
Le design system n’était pas une priorité.
Le focus était sur le changement de techno (Flutter) et la refonte UX.
Décision stratégique
Prouver sa valeur avec un PoC concret, pas avec des slides.
Convaincre d’abord le Head of Design, puis le VP Digital Products.
… Après
Le design system est devenu un sujet stratégique.
Il a été intégré officiellement à la roadmap produit.
Prouver la valeur du design system
Avant …
Le design system n’était pas une priorité.
Le focus était sur le changement de techno (Flutter) et la refonte UX.
Décision stratégique
Prouver sa valeur avec un PoC concret, pas avec des slides.
Convaincre d’abord le Head of Design, puis le VP Digital Products.
Le design system est devenu un sujet stratégique.
Il a été intégré officiellement à la roadmap produit.
… Après
Prouver la valeur du design system
Avant …
Le design system n’était pas une priorité.
Le focus était sur le changement de techno (Flutter) et la refonte UX.
Décision stratégique
Prouver sa valeur avec un PoC concret, pas avec des slides.
Convaincre d’abord le Head of Design, puis le VP Digital Products.
Le design system est devenu un sujet stratégique.
Il a été intégré officiellement à la roadmap produit.
… Après
Traiter le design system comme un produit
Avant …
Le design system risquait de devenir un simple kit Figma.
Le risque: Un outil figé, peu adopté et difficile à maintenir.
Décision stratégique
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
… Après
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
Traiter le design system comme un produit
Avant …
Le design system risquait de devenir un simple kit Figma.
Le risque: Un outil figé, peu adopté et difficile à maintenir.
Décision stratégique
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
… Après
Traiter le design system comme un produit
Avant …
Le design system risquait de devenir un simple kit Figma.
Le risque: Un outil figé, peu adopté et difficile à maintenir.
Décision stratégique
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
… Après
Évangéliser plutôt que livrer
Avant …
Les équipes travaillaient en silos.
Peu de culture système côté design comme côté tech.
Décision stratégique
De former les équipes au mindset design system, pas seulement aux outils.
De mettre en place des workshops hebdomadaires avec les designers et les développeurs.
… Après
Un langage commun entre design et engineering.
Une adoption progressive mais durable du système.
Évangéliser plutôt que livrer
Avant …
Les équipes travaillaient en silos.
Peu de culture système côté design comme côté tech.
Décision stratégique
De former les équipes au mindset design system, pas seulement aux outils.
De mettre en place des workshops hebdomadaires avec les designers et les développeurs.
Un langage commun entre design et engineering.
Une adoption progressive mais durable du système.
… Après
Évangéliser plutôt que livrer
Avant …
Les équipes travaillaient en silos.
Peu de culture système côté design comme côté tech.
Décision stratégique
De former les équipes au mindset design system, pas seulement aux outils.
De mettre en place des workshops hebdomadaires avec les designers et les développeurs.
Un langage commun entre design et engineering.
Une adoption progressive mais durable du système.
… Après
TL;DR
PoC > Discours
Convaincre par un PoC, pas par des slides
Système > Écrans
Concevoir un système, pas juste des écrans
Adoption > Livraison
Former les équipes, sans forcer la livraison
Ce que ça a réellement changé
IMPACTS MAJEURS
Avant | Après |
|---|---|
Écrans conçus au cas par cas | Écrans assemblés à partir d’un système |
Mockups ≠ rendu final | Parité Figma / Flutter |
Décisions dépendantes des individus | Décisions portées par le système |
Screenshots bricolés pour communiquer | Composants comme langage commun |
Chaque écran est un “one-shot” | Chaque écran fait grandir le système |
Avant | Après |
|---|---|
Écrans conçus au cas par cas | Écrans assemblés à partir d’un système |
Mockups ≠ rendu final | Parité Figma / Flutter |
Décisions dépendantes des individus | Décisions portées par le système |
Screenshots bricolés pour communiquer | Composants comme langage commun |
Chaque écran est un “one-shot” | Chaque écran fait grandir le système |
Avant | Après |
|---|---|
Écrans conçus au cas par cas | Écrans assemblés à partir d’un système |
Mockups ≠ rendu final | Parité Figma / Flutter |
Décisions dépendantes des individus | Décisions portées par le système |
Screenshots bricolés pour communiquer | Composants comme langage commun |
Chaque écran est un “one-shot” | Chaque écran fait grandir le système |
x0
x0
Rapidité du prototypage figma
x0
x0
Rapidité du développement UI
Impacts Organisationnels
Sur les équipes :
Designers : plus rapides, moins de compromis
Développeurs : moins d’allers-retours, plus d’autonomie
Product : décisions plus claires, moins de friction
Mais surtout :
Le système remplace les débats subjectifs
Les discussions se déplacent du “comment” vers le “pourquoi”
Rétrospective
Avec le recul, je ne lancerais plus jamais un design system sans contrainte produit ou technique claire.
Sans enjeu réel, il n’y a pas d’adoption durable.
TL;DR
Un système unique, partagé par design, produit et front
Prototypage ×8 · Dév UI ×24
Moins de dépendance aux individus, plus au système
La refonte Flutter est devenue soutenable
PLUS DE PROJETS
Design System
Cross-platform
2022 - 2025
Industrialiser un design system dans un grand groupe
Aligner design, produit et engineering, en plein changement de stack, avec des équipes peu habituées à travailler ensemble.
Rôle
Lead Product Designer
Equipe
11 Flutter dev ⸱ 3 designers ⸱ 2 PO
Organisation
Grand groupe
Type de produit
Produit interne
Le contexte et les enjeux
The what
UN ENVIRONNEMENT COMPLEXE
Enphase est un acteur majeur du solaire et du stockage d’énergie.
Son écosystème s’appuie sur de nombreux outils internes, des plateformes métiers et une application mobile pour les utilisateurs finaux.
The when
UNE VOLONTÉ DE CHANGEMENTS
Deux événements ont servi de déclic :
La refonte de l’app mobile, enfin guidée par des données utilisateurs
Un changement technologique, de React vers Flutter
C’était le bon moment pour repenser le système, pas juste les écrans.
the why
DES PROCESS D'UN AUTRE TEMPS
Chaîne produit très manuelle, sans base commune entre design et dev
Écrans bricolés, handoff quasi inexistant, validations à la volée
Beaucoup d’itérations, avec des écarts constants entre l’intention et le rendu
Incohérences entre pages et produits, dépendance aux individus plutôt qu’au système
Concrètement, chaque équipe avançait vite… mais dans son coin.
Les designers livraient des écrans, les devs les réinterprétaient, et le produit passait son temps à arbitrer des détails UI au lieu de décisions produit.
the who
DES ÉQUIPES DÉPASSÉES
Les premiers impactés n’étaient pas les utilisateurs finaux, mais les équipes elles-mêmes.
Designers, développeurs front-end et product owners travaillaient en silos, avec peu de collaboration réelle.
Ce n’était pas un problème d’outils, mais surtout de langage commun et de confiance entre équipes.
TL;DR
Produits multiples, équipes en silo
Process manuels et peu industrialisés
Qualité et vitesse en tension permanente
Refonte mobile et changement de stack comme déclencheur
Les décisions clés
Prouver la valeur du design system
Avant …
Le design system n’était pas une priorité.
Le focus était sur le changement de techno (Flutter) et la refonte UX.
Décision stratégique
Prouver sa valeur avec un PoC concret, pas avec des slides.
Convaincre d’abord le Head of Design, puis le VP Digital Products.
… Après
Le design system est devenu un sujet stratégique.
Il a été intégré officiellement à la roadmap produit.
Prouver la valeur du design system
Avant …
Le design system n’était pas une priorité.
Le focus était sur le changement de techno (Flutter) et la refonte UX.
Décision stratégique
Prouver sa valeur avec un PoC concret, pas avec des slides.
Convaincre d’abord le Head of Design, puis le VP Digital Products.
Le design system est devenu un sujet stratégique.
Il a été intégré officiellement à la roadmap produit.
… Après
Prouver la valeur du design system
Avant …
Le design system n’était pas une priorité.
Le focus était sur le changement de techno (Flutter) et la refonte UX.
Décision stratégique
Prouver sa valeur avec un PoC concret, pas avec des slides.
Convaincre d’abord le Head of Design, puis le VP Digital Products.
Le design system est devenu un sujet stratégique.
Il a été intégré officiellement à la roadmap produit.
… Après
Traiter le design system comme un produit
Avant …
Le design system risquait de devenir un simple kit Figma.
Le risque: Un outil figé, peu adopté et difficile à maintenir.
Décision stratégique
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
… Après
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
Traiter le design system comme un produit
Avant …
Le design system risquait de devenir un simple kit Figma.
Le risque: Un outil figé, peu adopté et difficile à maintenir.
Décision stratégique
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
… Après
Traiter le design system comme un produit
Avant …
Le design system risquait de devenir un simple kit Figma.
Le risque: Un outil figé, peu adopté et difficile à maintenir.
Décision stratégique
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
… Après
Évangéliser plutôt que livrer
Avant …
Les équipes travaillaient en silos.
Peu de culture système côté design comme côté tech.
Décision stratégique
De former les équipes au mindset design system, pas seulement aux outils.
De mettre en place des workshops hebdomadaires avec les designers et les développeurs.
… Après
Un langage commun entre design et engineering.
Une adoption progressive mais durable du système.
Évangéliser plutôt que livrer
Avant …
Les équipes travaillaient en silos.
Peu de culture système côté design comme côté tech.
Décision stratégique
De former les équipes au mindset design system, pas seulement aux outils.
De mettre en place des workshops hebdomadaires avec les designers et les développeurs.
Un langage commun entre design et engineering.
Une adoption progressive mais durable du système.
… Après
Évangéliser plutôt que livrer
Avant …
Les équipes travaillaient en silos.
Peu de culture système côté design comme côté tech.
Décision stratégique
De former les équipes au mindset design system, pas seulement aux outils.
De mettre en place des workshops hebdomadaires avec les designers et les développeurs.
Un langage commun entre design et engineering.
Une adoption progressive mais durable du système.
… Après
TL;DR
PoC > Discours
Convaincre par un PoC, pas par des slides
Système > Écrans
Concevoir un système, pas juste des écrans
Adoption > Livraison
Former les équipes, sans forcer la livraison
Ce que ça a réellement changé
IMPACTS MAJEURS
Avant | Après |
|---|---|
Écrans conçus au cas par cas | Écrans assemblés à partir d’un système |
Mockups ≠ rendu final | Parité Figma / Flutter |
Décisions dépendantes des individus | Décisions portées par le système |
Screenshots bricolés pour communiquer | Composants comme langage commun |
Chaque écran est un “one-shot” | Chaque écran fait grandir le système |
Avant | Après |
|---|---|
Écrans conçus au cas par cas | Écrans assemblés à partir d’un système |
Mockups ≠ rendu final | Parité Figma / Flutter |
Décisions dépendantes des individus | Décisions portées par le système |
Screenshots bricolés pour communiquer | Composants comme langage commun |
Chaque écran est un “one-shot” | Chaque écran fait grandir le système |
Avant | Après |
|---|---|
Écrans conçus au cas par cas | Écrans assemblés à partir d’un système |
Mockups ≠ rendu final | Parité Figma / Flutter |
Décisions dépendantes des individus | Décisions portées par le système |
Screenshots bricolés pour communiquer | Composants comme langage commun |
Chaque écran est un “one-shot” | Chaque écran fait grandir le système |
x0
x0
Rapidité du prototypage figma
x0
x0
Rapidité du développement UI
Impacts Organisationnels
Sur les équipes :
Designers : plus rapides, moins de compromis
Développeurs : moins d’allers-retours, plus d’autonomie
Product : décisions plus claires, moins de friction
Mais surtout :
Le système remplace les débats subjectifs
Les discussions se déplacent du “comment” vers le “pourquoi”
Rétrospective
Avec le recul, je ne lancerais plus jamais un design system sans contrainte produit ou technique claire.
Sans enjeu réel, il n’y a pas d’adoption durable.
TL;DR
Un système unique, partagé par design, produit et front
Prototypage ×8 · Dév UI ×24
Moins de dépendance aux individus, plus au système
La refonte Flutter est devenue soutenable
PLUS DE PROJETS
Design System
Cross-platform
2022 - 2025
Industrialiser un design system dans un grand groupe
Aligner design, produit et engineering, en plein changement de stack, avec des équipes peu habituées à travailler ensemble.
Rôle
Lead Product Designer
Equipe
11 Flutter dev ⸱ 3 designers ⸱ 2 PO
Organisation
Grand groupe
Type de produit
Produit interne
Le contexte et les enjeux
The what
UN ENVIRONNEMENT COMPLEXE
Enphase est un acteur majeur du solaire et du stockage d’énergie.
Son écosystème s’appuie sur de nombreux outils internes, des plateformes métiers et une application mobile pour les utilisateurs finaux.
The when
UNE VOLONTÉ DE CHANGEMENTS
Deux événements ont servi de déclic :
La refonte de l’app mobile, enfin guidée par des données utilisateurs
Un changement technologique, de React vers Flutter
C’était le bon moment pour repenser le système, pas juste les écrans.
the why
DES PROCESS D'UN AUTRE TEMPS
Chaîne produit très manuelle, sans base commune entre design et dev
Écrans bricolés, handoff quasi inexistant, validations à la volée
Beaucoup d’itérations, avec des écarts constants entre l’intention et le rendu
Incohérences entre pages et produits, dépendance aux individus plutôt qu’au système
Concrètement, chaque équipe avançait vite… mais dans son coin.
Les designers livraient des écrans, les devs les réinterprétaient, et le produit passait son temps à arbitrer des détails UI au lieu de décisions produit.
the who
DES ÉQUIPES DÉPASSÉES
Les premiers impactés n’étaient pas les utilisateurs finaux, mais les équipes elles-mêmes.
Designers, développeurs front-end et product owners travaillaient en silos, avec peu de collaboration réelle.
Ce n’était pas un problème d’outils, mais surtout de langage commun et de confiance entre équipes.
TL;DR
Produits multiples, équipes en silo
Process manuels et peu industrialisés
Qualité et vitesse en tension permanente
Refonte mobile et changement de stack comme déclencheur
Les décisions clés
Prouver la valeur du design system
Avant …
Le design system n’était pas une priorité.
Le focus était sur le changement de techno (Flutter) et la refonte UX.
Décision stratégique
Prouver sa valeur avec un PoC concret, pas avec des slides.
Convaincre d’abord le Head of Design, puis le VP Digital Products.
… Après
Le design system est devenu un sujet stratégique.
Il a été intégré officiellement à la roadmap produit.
Prouver la valeur du design system
Avant …
Le design system n’était pas une priorité.
Le focus était sur le changement de techno (Flutter) et la refonte UX.
Décision stratégique
Prouver sa valeur avec un PoC concret, pas avec des slides.
Convaincre d’abord le Head of Design, puis le VP Digital Products.
Le design system est devenu un sujet stratégique.
Il a été intégré officiellement à la roadmap produit.
… Après
Prouver la valeur du design system
Avant …
Le design system n’était pas une priorité.
Le focus était sur le changement de techno (Flutter) et la refonte UX.
Décision stratégique
Prouver sa valeur avec un PoC concret, pas avec des slides.
Convaincre d’abord le Head of Design, puis le VP Digital Products.
Le design system est devenu un sujet stratégique.
Il a été intégré officiellement à la roadmap produit.
… Après
Traiter le design system comme un produit
Avant …
Le design system risquait de devenir un simple kit Figma.
Le risque: Un outil figé, peu adopté et difficile à maintenir.
Décision stratégique
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
… Après
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
Traiter le design system comme un produit
Avant …
Le design system risquait de devenir un simple kit Figma.
Le risque: Un outil figé, peu adopté et difficile à maintenir.
Décision stratégique
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
… Après
Traiter le design system comme un produit
Avant …
Le design system risquait de devenir un simple kit Figma.
Le risque: Un outil figé, peu adopté et difficile à maintenir.
Décision stratégique
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
Le concevoir comme un produit transversal, pensé pour évoluer.
Anticiper dès le départ thèmes, devices, versioning et maintenance.
Impliquer le Lead Engineer Flutter très tôt.
… Après
Évangéliser plutôt que livrer
Avant …
Les équipes travaillaient en silos.
Peu de culture système côté design comme côté tech.
Décision stratégique
De former les équipes au mindset design system, pas seulement aux outils.
De mettre en place des workshops hebdomadaires avec les designers et les développeurs.
… Après
Un langage commun entre design et engineering.
Une adoption progressive mais durable du système.
Évangéliser plutôt que livrer
Avant …
Les équipes travaillaient en silos.
Peu de culture système côté design comme côté tech.
Décision stratégique
De former les équipes au mindset design system, pas seulement aux outils.
De mettre en place des workshops hebdomadaires avec les designers et les développeurs.
Un langage commun entre design et engineering.
Une adoption progressive mais durable du système.
… Après
Évangéliser plutôt que livrer
Avant …
Les équipes travaillaient en silos.
Peu de culture système côté design comme côté tech.
Décision stratégique
De former les équipes au mindset design system, pas seulement aux outils.
De mettre en place des workshops hebdomadaires avec les designers et les développeurs.
Un langage commun entre design et engineering.
Une adoption progressive mais durable du système.
… Après
TL;DR
PoC > Discours
Convaincre par un PoC, pas par des slides
Système > Écrans
Concevoir un système, pas juste des écrans
Adoption > Livraison
Former les équipes, sans forcer la livraison
Ce que ça a réellement changé
IMPACTS MAJEURS
Avant | Après |
|---|---|
Écrans conçus au cas par cas | Écrans assemblés à partir d’un système |
Mockups ≠ rendu final | Parité Figma / Flutter |
Décisions dépendantes des individus | Décisions portées par le système |
Screenshots bricolés pour communiquer | Composants comme langage commun |
Chaque écran est un “one-shot” | Chaque écran fait grandir le système |
Avant | Après |
|---|---|
Écrans conçus au cas par cas | Écrans assemblés à partir d’un système |
Mockups ≠ rendu final | Parité Figma / Flutter |
Décisions dépendantes des individus | Décisions portées par le système |
Screenshots bricolés pour communiquer | Composants comme langage commun |
Chaque écran est un “one-shot” | Chaque écran fait grandir le système |
Avant | Après |
|---|---|
Écrans conçus au cas par cas | Écrans assemblés à partir d’un système |
Mockups ≠ rendu final | Parité Figma / Flutter |
Décisions dépendantes des individus | Décisions portées par le système |
Screenshots bricolés pour communiquer | Composants comme langage commun |
Chaque écran est un “one-shot” | Chaque écran fait grandir le système |
x0
x0
Rapidité du prototypage figma
x0
x0
Rapidité du développement UI
Impacts Organisationnels
Sur les équipes :
Designers : plus rapides, moins de compromis
Développeurs : moins d’allers-retours, plus d’autonomie
Product : décisions plus claires, moins de friction
Mais surtout :
Le système remplace les débats subjectifs
Les discussions se déplacent du “comment” vers le “pourquoi”
Rétrospective
Avec le recul, je ne lancerais plus jamais un design system sans contrainte produit ou technique claire.
Sans enjeu réel, il n’y a pas d’adoption durable.
TL;DR
Un système unique, partagé par design, produit et front
Prototypage ×8 · Dév UI ×24
Moins de dépendance aux individus, plus au système
La refonte Flutter est devenue soutenable