Design system · Design Ops
Faire vivre un design system multi-scope, en croissance constante.
Au sein de l’équipe Design Operations, j’ai participé au maintien, à l’expansion et à l’optimisation du design system de Betclic, sur plusieurs scopes produit, en prenant le lead sur ceux de Payment, Account et Join. Mon travail s’est notamment porté sur les librairies de tokens et d’assets, les composants en atomic design jusqu’aux organismes et templates, et la gouvernance qui garde le tout cohérent à mesure que l’équipe grandit.
- Entreprise
- Betclic
- Rôle
- Design system designer et Design Ops
- Période
- 09/2024 – 09/2026
- Équipes impliquées
- Design Ops, Product Design, Engineering, Content Design, Creative, Product Ops, Product Owners, Product Managers, etc.
Schéma de la hiérarchie atomique du DS Betclic
01
Le contexte et le problème
Le DS Betclic est commun à plusieurs produits Betclic (paris sportifs, casino, poker, hippique), sur web et mobile, dans plusieurs marchés réglementés. Mon rôle n’est pas de le reconstruire, mais de le faire vivre : l’enrichir à mesure que les besoins produit évoluent, tout en gardant sa cohérence.
J’ai le lead sur trois scopes (Payment, Account et Join), ce qui veut dire que je valide les usages du système sur ces parcours et que je suis l’interlocutrice des Product Designers qui y travaillent.
- contrainte: système déjà en production, aucune interruption possible
- contrainte: plusieurs scopes et contributeurs simultanés
- contrainte: cohérence entre design et code à maintenir en continu
02
Comment j’ai travaillé
Le travail est continu, pas un projet avec un début et une fin : identifier les besoins des scopes, faire évoluer les bonnes ressources du système, et transmettre.
- Étape 1 - Cadrage
Comprendre les besoins, scope par scope
Recueil des besoins des Product Designers sur Payment, Account et Join, et arbitrage entre demandes ponctuelles et cohérence du système.
Livrables- Cadre de gouvernance par scope
- Backlog des demandes arbitrées
- Points réguliers avec les Product Designers
- Étape 2 - Librairies
Faire évoluer tokens, composants, organismes, templates
Enrichissement des librairies de tokens et d’assets, structuration des composants en atomic design jusqu’aux templates.
Livrables- Tokens et assets mis à jour
- Composants, organismes et templates documentés
- Étape 3 - Handoff
Assurer le passage au développement
Documentation et guidelines rédigées pour chaque évolution, échanges directs avec les équipes front-end pour garantir un handoff propre.
Livrables- Documentation à jour
- Guidelines de contribution
- Échanges réguliers avec le front-end
03
Décisions de conception
Gouvernance
Avant
Les validations de composants se faisaient au cas par cas, scope par scope.
Après
Un cadre de gouvernance commun, avec un lead identifié par scope.
Bibliothèques
Avant
Tokens, assets et composants évoluaient sans toujours suivre la même logique.
Après
Cascade de tokens et composants structurés en atomic design, jusqu’aux organismes et templates.
Outillage
Avant
Certaines tâches de production se répétaient manuellement à chaque évolution.
Après
Plugins Figma développés pour automatiser les tâches répétitives.
04
Ce que le travail a produit
- Motif 01
Gouvernance multi-scope
Trois scopes sous ma responsabilité (Payment, Account, Join), chacun avec ses propres besoins, arbitrés dans un cadre commun.
- Motif 02
Cascade de tokens
Des tokens primitifs jusqu’aux tokens de composants, une seule source de vérité déclinée par produit.
- Motif 03
Bibliothèque en atomic design
Composants, organismes et templates construits les uns sur les autres, pour ne jamais repartir de zéro.
- Motif 04
Handoff continu
Documentation, guidelines et plugins Figma pour que chaque évolution arrive proprement jusqu’au code.
05
Ce que j’en retiens
- 01
Un design system mature s’entretient, scope par scope, sans jamais perdre de vue l’ensemble.
- 02
Être lead sur un scope, c’est arbitrer en continu entre les besoins ponctuels d’une équipe et la cohérence du système pour tout le monde.
- 03
Automatiser une tâche répétitive avec un plugin fait gagner plus de temps, sur la durée, que n’importe quelle documentation.