De l'UI Kit au Design System Produit
Construire les fondations avant la scalabilité retour de mon expérience à Bestmile
Aperçus
18 févr. 2021
UI Kit vs Design System — une clarification essentielle
Avant de parler de mon expérience, clarifions une confusion fréquente : un UI Kit n’est pas un Design System.
Un UI Kit est une bibliothèque de composants visuels réutilisables — boutons, champs, icônes, couleurs, styles typographiques.
Il permet de produire rapidement des interfaces cohérentes.
C’est un outil de production.
Un Design System, en revanche, est une infrastructure produit.
Il inclut :
les composants
des principes UX
des règles d’usage documentées
des design tokens
une implémentation en code
une gouvernance
un alignement structuré entre design et engineering
👉 Le UI Kit aide à designer vite.
👉 Le Design System aide un produit à évoluer durablement.
Et cette transition — je l’ai vécue de l’intérieur.
Le contexte — avant la scalabilité
Début 2018, Bestmile entame une refonte majeure de sa plateforme.
Une nouvelle équipe frontend se structure avec Manuel Hitz et Jean-Baptiste Cochery, pilotée côté produit par David Geretti.
L’ancien Fleet Management Tool est abandonné au profit d’un nouvel Operator Dashboard.
Lorsque je rejoins l’équipe presque un an plus tard:
Le produit est en reconstruction.
La scalabilité est en ligne de mire.
Mais il n’existe pas encore de vision UX unifiée ni de Design System structuré.
J’arrive alors comme solo UX/UI designer.
Tout reste à poser.
J’ai volontairement commencé par un UI Kit
Avant de parler Design System, soyons honnêtes :
J’ai commencé par un UI Kit.
Pourquoi ?
Parce qu’il fallait livrer vite.
Le produit avançait rapidement.
L’équipe frontend reconstruisait la plateforme.
Il fallait une cohérence immédiate.
Dans Sketch, j’ai donc structuré :
une palette de couleurs
une typographie
des composants de base
des patterns récurrents
Ce UI Kit nous a permis :
d’aligner les écrans
d’accélérer le delivery
de réduire les incohérences visuelles
Mais très vite, ses limites sont apparues.
Le vrai problème n’était pas visuel
Les interfaces semblaient cohérentes.
Mais le système était fragile.
Un même composant pouvait :
être implémenté différemment
évoluer sans mise à jour globale
diverger entre web et mobile
La dette n’était pas graphique. Elle était systémique.
Et dans une plateforme utilisée quotidiennement par des équipes opérationnelles, la cohérence est un levier de performance.
De l’UI Kit au Design System
À partir de l'UI Kit Sketch, j’ai progressivement construit un Design System petit à petit.
UX d’abord
Avant même de structurer un Design System, j’ai pris du recul pour regarder le produit tel qu’il existait réellement.
J’ai commencé par analyser nos principaux écrans opérationnels, ceux utilisés au quotidien par nos principaux utilisateurs, afin de comprendre :
Quels composants revenaient le plus souvent
Quels patterns étaient critiques dans les parcours utilisateurs
Ce qui devait vraiment être standardisé
Ce qui pouvait rester plus flexible
Plutôt que de concevoir une bibliothèque de composants “idéale”, je suis partie de l’usage réel.
Concrètement, j’ai identifié les briques essentielles :
les boutons (avec une hiérarchie claire des actions)
les champs de recherche
les tableaux de données (au cœur du produit)
les cartes (que j’ai personnellement designées et intégrées avec de Mapbox Studio)
les timelines pour visualiser les trajets des voyageurs et des chauffeurs
les états vides, loading et erreurs
les patterns de navigation
Ces composants n’ont pas été choisis parce qu’ils sont “standards”.
Ils ont été choisis parce qu’ils représentaient le travail réel de nos utilisateurs.
Les flux d'utilisateurs ont façonné le système.L’usage réel a défini les composants.
Pas l’inverse.
Ce n’est qu’après cette lecture UX du produit que j’ai commencé à structurer :
les foundations
les composants
puis les patterns.
Documentation avec InVision DSM
Pour aller au-delà de Sketch, j’ai documenté le système dans InVision Design System Manager (DSM).
À l’époque, Sketch ne proposait pas encore de prototypage collaboratif ni de gestion centralisée des commentaires.
Nous exportions donc régulièrement nos écrans Sketch vers InVision pour :
créer des prototypes interactifs
collecter les retours
partager les maquettes avec les équipes
C’est naturellement que nous avons aussi choisi InVision DSM pour :
centraliser les guidelines
documenter les composants
structurer les usages
relier design et implémentation
Cela a marqué un vrai tournant :
du design vivant localement dans Sketch
→ au design comme infrastructure partagée et documentée.
Avec le recul, si je devais refaire ce choix aujourd’hui, j’opterais probablement pour Zeroheight.
InVision a depuis décliné, et Zeroheight me semble plus robuste et pérenne pour la documentation d’un Design System.
Mais à ce moment précis, DSM correspondait à notre stack et à notre niveau de maturité.
Le frontend n’est pas un relais, c’est un partenaire
Même en étant seule côté design, le Design System n’a jamais été “mon” projet.
Il a été co-construit avec le frontend :
alignement intentions UX ↔ APIs des composants
gestion des edge cases
cohérence web / mobile
documentation comportementale
itérations continues Sketch ↔ code
Le design nourrissait le code.
Le code nourrissait le design.
C’est cette collaboration qui a rendu le système réel et utilisé.
Avant ZF : poser les fondations
Tout ce travail s’est fait avant l’acquisition par ZF.
À ce stade, le Design System n’était pas encore un programme stratégique.
C’était une nécessité pragmatique.
Mais ces fondations ont ensuite facilité :
la scalabilité
un onboarding plus fluide
une meilleure cohérence produit
une maturité organisationnelle accrue
Un Design System devient stratégique après coup.
Au départ, il répond simplement à un besoin réel.
Chaque entreprise ou produit a-t-il besoin d’un Design System ?
Réponse courte : non.
Un Design System est pertinent lorsque :
Plusieurs équipes collaborent
Le produit est multi-plateforme
La dette UX ralentit le delivery
la cohérence devient critique
Il devient contre-productif si :
l’équipe est très petite
Le produit est encore exploratoire
Personne ne peut réellement le maintenir
Il est créé “parce que tout le monde en a un”
Dans beaucoup de cas, un UI Kit bien structuré suffit largement.
Ce que cette expérience m’a appris
Commencer par un UI Kit est pragmatique
Évoluer vers un Design System est stratégique
l’UX précède les composants
La documentation est du design
La collaboration frontend est essentielle
La cohérence est une fonctionnalité utilisateur
Un Design System n’est pas un livrable.
C’est une infrastructure vivante.
Et demain, quelle place pour l’IA dans les Design Systems ?
Dernière question, plus ouverte.
À l’heure où l’IA transforme déjà nos façons de designer, prototyper et coder…
À quoi ressembleront les Design Systems demain ?
des composants générés dynamiquement ?
des tokens adaptatifs selon le contexte utilisateur ?
des guidelines pilotées par la data ?
des expériences personnalisées automatiquement ?
Peut-être évoluerons-nous vers des systèmes moins figés, plus intelligents, capables de s’adapter en temps réel aux usages.
Une chose me semble certaine :
Les Design Systems vont passer de bibliothèques statiques à de véritables écosystèmes intelligents.
Et dans ce futur-là, le rôle du designer devient encore plus stratégique.
Car si l’IA accélère l’exécution, elle ne remplace ni :
le sens produit
l’empathie utilisateur
la pensée systémique
ni le jugement humain.
Je serais ravie d’échanger sur ces sujets — Design Systems, UX, collaboration design + engineering et impact de l’IA sur nos métiers.
Au plaisir d’en discuter. 🤍
Plus à découvrir
De l'UI Kit au Design System Produit
Construire les fondations avant la scalabilité retour de mon expérience à Bestmile
Aperçus
18 févr. 2021
UI Kit vs Design System — une clarification essentielle
Avant de parler de mon expérience, clarifions une confusion fréquente : un UI Kit n’est pas un Design System.
Un UI Kit est une bibliothèque de composants visuels réutilisables — boutons, champs, icônes, couleurs, styles typographiques.
Il permet de produire rapidement des interfaces cohérentes.
C’est un outil de production.
Un Design System, en revanche, est une infrastructure produit.
Il inclut :
les composants
des principes UX
des règles d’usage documentées
des design tokens
une implémentation en code
une gouvernance
un alignement structuré entre design et engineering
👉 Le UI Kit aide à designer vite.
👉 Le Design System aide un produit à évoluer durablement.
Et cette transition — je l’ai vécue de l’intérieur.
Le contexte — avant la scalabilité
Début 2018, Bestmile entame une refonte majeure de sa plateforme.
Une nouvelle équipe frontend se structure avec Manuel Hitz et Jean-Baptiste Cochery, pilotée côté produit par David Geretti.
L’ancien Fleet Management Tool est abandonné au profit d’un nouvel Operator Dashboard.
Lorsque je rejoins l’équipe presque un an plus tard:
Le produit est en reconstruction.
La scalabilité est en ligne de mire.
Mais il n’existe pas encore de vision UX unifiée ni de Design System structuré.
J’arrive alors comme solo UX/UI designer.
Tout reste à poser.
J’ai volontairement commencé par un UI Kit
Avant de parler Design System, soyons honnêtes :
J’ai commencé par un UI Kit.
Pourquoi ?
Parce qu’il fallait livrer vite.
Le produit avançait rapidement.
L’équipe frontend reconstruisait la plateforme.
Il fallait une cohérence immédiate.
Dans Sketch, j’ai donc structuré :
une palette de couleurs
une typographie
des composants de base
des patterns récurrents
Ce UI Kit nous a permis :
d’aligner les écrans
d’accélérer le delivery
de réduire les incohérences visuelles
Mais très vite, ses limites sont apparues.
Le vrai problème n’était pas visuel
Les interfaces semblaient cohérentes.
Mais le système était fragile.
Un même composant pouvait :
être implémenté différemment
évoluer sans mise à jour globale
diverger entre web et mobile
La dette n’était pas graphique. Elle était systémique.
Et dans une plateforme utilisée quotidiennement par des équipes opérationnelles, la cohérence est un levier de performance.
De l’UI Kit au Design System
À partir de l'UI Kit Sketch, j’ai progressivement construit un Design System petit à petit.
UX d’abord
Avant même de structurer un Design System, j’ai pris du recul pour regarder le produit tel qu’il existait réellement.
J’ai commencé par analyser nos principaux écrans opérationnels, ceux utilisés au quotidien par nos principaux utilisateurs, afin de comprendre :
Quels composants revenaient le plus souvent
Quels patterns étaient critiques dans les parcours utilisateurs
Ce qui devait vraiment être standardisé
Ce qui pouvait rester plus flexible
Plutôt que de concevoir une bibliothèque de composants “idéale”, je suis partie de l’usage réel.
Concrètement, j’ai identifié les briques essentielles :
les boutons (avec une hiérarchie claire des actions)
les champs de recherche
les tableaux de données (au cœur du produit)
les cartes (que j’ai personnellement designées et intégrées avec de Mapbox Studio)
les timelines pour visualiser les trajets des voyageurs et des chauffeurs
les états vides, loading et erreurs
les patterns de navigation
Ces composants n’ont pas été choisis parce qu’ils sont “standards”.
Ils ont été choisis parce qu’ils représentaient le travail réel de nos utilisateurs.
Les flux d'utilisateurs ont façonné le système.L’usage réel a défini les composants.
Pas l’inverse.
Ce n’est qu’après cette lecture UX du produit que j’ai commencé à structurer :
les foundations
les composants
puis les patterns.
Documentation avec InVision DSM
Pour aller au-delà de Sketch, j’ai documenté le système dans InVision Design System Manager (DSM).
À l’époque, Sketch ne proposait pas encore de prototypage collaboratif ni de gestion centralisée des commentaires.
Nous exportions donc régulièrement nos écrans Sketch vers InVision pour :
créer des prototypes interactifs
collecter les retours
partager les maquettes avec les équipes
C’est naturellement que nous avons aussi choisi InVision DSM pour :
centraliser les guidelines
documenter les composants
structurer les usages
relier design et implémentation
Cela a marqué un vrai tournant :
du design vivant localement dans Sketch
→ au design comme infrastructure partagée et documentée.
Avec le recul, si je devais refaire ce choix aujourd’hui, j’opterais probablement pour Zeroheight.
InVision a depuis décliné, et Zeroheight me semble plus robuste et pérenne pour la documentation d’un Design System.
Mais à ce moment précis, DSM correspondait à notre stack et à notre niveau de maturité.
Le frontend n’est pas un relais, c’est un partenaire
Même en étant seule côté design, le Design System n’a jamais été “mon” projet.
Il a été co-construit avec le frontend :
alignement intentions UX ↔ APIs des composants
gestion des edge cases
cohérence web / mobile
documentation comportementale
itérations continues Sketch ↔ code
Le design nourrissait le code.
Le code nourrissait le design.
C’est cette collaboration qui a rendu le système réel et utilisé.
Avant ZF : poser les fondations
Tout ce travail s’est fait avant l’acquisition par ZF.
À ce stade, le Design System n’était pas encore un programme stratégique.
C’était une nécessité pragmatique.
Mais ces fondations ont ensuite facilité :
la scalabilité
un onboarding plus fluide
une meilleure cohérence produit
une maturité organisationnelle accrue
Un Design System devient stratégique après coup.
Au départ, il répond simplement à un besoin réel.
Chaque entreprise ou produit a-t-il besoin d’un Design System ?
Réponse courte : non.
Un Design System est pertinent lorsque :
Plusieurs équipes collaborent
Le produit est multi-plateforme
La dette UX ralentit le delivery
la cohérence devient critique
Il devient contre-productif si :
l’équipe est très petite
Le produit est encore exploratoire
Personne ne peut réellement le maintenir
Il est créé “parce que tout le monde en a un”
Dans beaucoup de cas, un UI Kit bien structuré suffit largement.
Ce que cette expérience m’a appris
Commencer par un UI Kit est pragmatique
Évoluer vers un Design System est stratégique
l’UX précède les composants
La documentation est du design
La collaboration frontend est essentielle
La cohérence est une fonctionnalité utilisateur
Un Design System n’est pas un livrable.
C’est une infrastructure vivante.
Et demain, quelle place pour l’IA dans les Design Systems ?
Dernière question, plus ouverte.
À l’heure où l’IA transforme déjà nos façons de designer, prototyper et coder…
À quoi ressembleront les Design Systems demain ?
des composants générés dynamiquement ?
des tokens adaptatifs selon le contexte utilisateur ?
des guidelines pilotées par la data ?
des expériences personnalisées automatiquement ?
Peut-être évoluerons-nous vers des systèmes moins figés, plus intelligents, capables de s’adapter en temps réel aux usages.
Une chose me semble certaine :
Les Design Systems vont passer de bibliothèques statiques à de véritables écosystèmes intelligents.
Et dans ce futur-là, le rôle du designer devient encore plus stratégique.
Car si l’IA accélère l’exécution, elle ne remplace ni :
le sens produit
l’empathie utilisateur
la pensée systémique
ni le jugement humain.
Je serais ravie d’échanger sur ces sujets — Design Systems, UX, collaboration design + engineering et impact de l’IA sur nos métiers.
Au plaisir d’en discuter. 🤍
Plus à découvrir
De l'UI Kit au Design System Produit
Construire les fondations avant la scalabilité retour de mon expérience à Bestmile
Aperçus
18 févr. 2021
UI Kit vs Design System — une clarification essentielle
Avant de parler de mon expérience, clarifions une confusion fréquente : un UI Kit n’est pas un Design System.
Un UI Kit est une bibliothèque de composants visuels réutilisables — boutons, champs, icônes, couleurs, styles typographiques.
Il permet de produire rapidement des interfaces cohérentes.
C’est un outil de production.
Un Design System, en revanche, est une infrastructure produit.
Il inclut :
les composants
des principes UX
des règles d’usage documentées
des design tokens
une implémentation en code
une gouvernance
un alignement structuré entre design et engineering
👉 Le UI Kit aide à designer vite.
👉 Le Design System aide un produit à évoluer durablement.
Et cette transition — je l’ai vécue de l’intérieur.
Le contexte — avant la scalabilité
Début 2018, Bestmile entame une refonte majeure de sa plateforme.
Une nouvelle équipe frontend se structure avec Manuel Hitz et Jean-Baptiste Cochery, pilotée côté produit par David Geretti.
L’ancien Fleet Management Tool est abandonné au profit d’un nouvel Operator Dashboard.
Lorsque je rejoins l’équipe presque un an plus tard:
Le produit est en reconstruction.
La scalabilité est en ligne de mire.
Mais il n’existe pas encore de vision UX unifiée ni de Design System structuré.
J’arrive alors comme solo UX/UI designer.
Tout reste à poser.
J’ai volontairement commencé par un UI Kit
Avant de parler Design System, soyons honnêtes :
J’ai commencé par un UI Kit.
Pourquoi ?
Parce qu’il fallait livrer vite.
Le produit avançait rapidement.
L’équipe frontend reconstruisait la plateforme.
Il fallait une cohérence immédiate.
Dans Sketch, j’ai donc structuré :
une palette de couleurs
une typographie
des composants de base
des patterns récurrents
Ce UI Kit nous a permis :
d’aligner les écrans
d’accélérer le delivery
de réduire les incohérences visuelles
Mais très vite, ses limites sont apparues.
Le vrai problème n’était pas visuel
Les interfaces semblaient cohérentes.
Mais le système était fragile.
Un même composant pouvait :
être implémenté différemment
évoluer sans mise à jour globale
diverger entre web et mobile
La dette n’était pas graphique. Elle était systémique.
Et dans une plateforme utilisée quotidiennement par des équipes opérationnelles, la cohérence est un levier de performance.
De l’UI Kit au Design System
À partir de l'UI Kit Sketch, j’ai progressivement construit un Design System petit à petit.
UX d’abord
Avant même de structurer un Design System, j’ai pris du recul pour regarder le produit tel qu’il existait réellement.
J’ai commencé par analyser nos principaux écrans opérationnels, ceux utilisés au quotidien par nos principaux utilisateurs, afin de comprendre :
Quels composants revenaient le plus souvent
Quels patterns étaient critiques dans les parcours utilisateurs
Ce qui devait vraiment être standardisé
Ce qui pouvait rester plus flexible
Plutôt que de concevoir une bibliothèque de composants “idéale”, je suis partie de l’usage réel.
Concrètement, j’ai identifié les briques essentielles :
les boutons (avec une hiérarchie claire des actions)
les champs de recherche
les tableaux de données (au cœur du produit)
les cartes (que j’ai personnellement designées et intégrées avec de Mapbox Studio)
les timelines pour visualiser les trajets des voyageurs et des chauffeurs
les états vides, loading et erreurs
les patterns de navigation
Ces composants n’ont pas été choisis parce qu’ils sont “standards”.
Ils ont été choisis parce qu’ils représentaient le travail réel de nos utilisateurs.
Les flux d'utilisateurs ont façonné le système.L’usage réel a défini les composants.
Pas l’inverse.
Ce n’est qu’après cette lecture UX du produit que j’ai commencé à structurer :
les foundations
les composants
puis les patterns.
Documentation avec InVision DSM
Pour aller au-delà de Sketch, j’ai documenté le système dans InVision Design System Manager (DSM).
À l’époque, Sketch ne proposait pas encore de prototypage collaboratif ni de gestion centralisée des commentaires.
Nous exportions donc régulièrement nos écrans Sketch vers InVision pour :
créer des prototypes interactifs
collecter les retours
partager les maquettes avec les équipes
C’est naturellement que nous avons aussi choisi InVision DSM pour :
centraliser les guidelines
documenter les composants
structurer les usages
relier design et implémentation
Cela a marqué un vrai tournant :
du design vivant localement dans Sketch
→ au design comme infrastructure partagée et documentée.
Avec le recul, si je devais refaire ce choix aujourd’hui, j’opterais probablement pour Zeroheight.
InVision a depuis décliné, et Zeroheight me semble plus robuste et pérenne pour la documentation d’un Design System.
Mais à ce moment précis, DSM correspondait à notre stack et à notre niveau de maturité.
Le frontend n’est pas un relais, c’est un partenaire
Même en étant seule côté design, le Design System n’a jamais été “mon” projet.
Il a été co-construit avec le frontend :
alignement intentions UX ↔ APIs des composants
gestion des edge cases
cohérence web / mobile
documentation comportementale
itérations continues Sketch ↔ code
Le design nourrissait le code.
Le code nourrissait le design.
C’est cette collaboration qui a rendu le système réel et utilisé.
Avant ZF : poser les fondations
Tout ce travail s’est fait avant l’acquisition par ZF.
À ce stade, le Design System n’était pas encore un programme stratégique.
C’était une nécessité pragmatique.
Mais ces fondations ont ensuite facilité :
la scalabilité
un onboarding plus fluide
une meilleure cohérence produit
une maturité organisationnelle accrue
Un Design System devient stratégique après coup.
Au départ, il répond simplement à un besoin réel.
Chaque entreprise ou produit a-t-il besoin d’un Design System ?
Réponse courte : non.
Un Design System est pertinent lorsque :
Plusieurs équipes collaborent
Le produit est multi-plateforme
La dette UX ralentit le delivery
la cohérence devient critique
Il devient contre-productif si :
l’équipe est très petite
Le produit est encore exploratoire
Personne ne peut réellement le maintenir
Il est créé “parce que tout le monde en a un”
Dans beaucoup de cas, un UI Kit bien structuré suffit largement.
Ce que cette expérience m’a appris
Commencer par un UI Kit est pragmatique
Évoluer vers un Design System est stratégique
l’UX précède les composants
La documentation est du design
La collaboration frontend est essentielle
La cohérence est une fonctionnalité utilisateur
Un Design System n’est pas un livrable.
C’est une infrastructure vivante.
Et demain, quelle place pour l’IA dans les Design Systems ?
Dernière question, plus ouverte.
À l’heure où l’IA transforme déjà nos façons de designer, prototyper et coder…
À quoi ressembleront les Design Systems demain ?
des composants générés dynamiquement ?
des tokens adaptatifs selon le contexte utilisateur ?
des guidelines pilotées par la data ?
des expériences personnalisées automatiquement ?
Peut-être évoluerons-nous vers des systèmes moins figés, plus intelligents, capables de s’adapter en temps réel aux usages.
Une chose me semble certaine :
Les Design Systems vont passer de bibliothèques statiques à de véritables écosystèmes intelligents.
Et dans ce futur-là, le rôle du designer devient encore plus stratégique.
Car si l’IA accélère l’exécution, elle ne remplace ni :
le sens produit
l’empathie utilisateur
la pensée systémique
ni le jugement humain.
Je serais ravie d’échanger sur ces sujets — Design Systems, UX, collaboration design + engineering et impact de l’IA sur nos métiers.
Au plaisir d’en discuter. 🤍