Xboxygen — reconstruction du design system
Média Gaming
Accélérer la conception et fluidifier le handoff grâce à un nouveau Design System
- Audit
- Fondations
- Composants
- Variables
- Documentation
- Rôle
- Design System Designer
- Plateforme
- 1er site français dédié à l’actualité Xbox
- Équipe
- 4 personnes PO, développeur, graphiste et moi
- Période
- Mars – Avril 2025
- Statut
- En production
Problème
Perte de temps en conception et en handoff, due à un Design System peu adopté, incohérent et sans règles d’usage claires.
Solution
Reconstruction du Design System autour de fondations communes, composants rationalisés et règles d’usage explicites pour concevoir plus vite et faciliter le handoff.
Impact
−40 %
de temps de conception sur 3 écrans comparables
Mon rôle
J’ai piloté la reconstruction du Design System, de l’audit de l’existant jusqu’à son déploiement dans les interfaces.
Mon intervention :
- identification des doublons et composants manquants
- redesign des icônes, boutons et tableaux
- refonte des fondations et composants
- création de variables et règles communes
- définition des cas d’usage
- migration vers la nouvelle bibliothèque
L’enjeu dépassait la cohérence visuelle : rendre le système suffisamment clair pour accélérer les choix tout au long de la conception.
3 décisions clés
-
Rebâtir le Design System
La demande initiale portait sur le nettoyage du fichier Figma. L’audit a révélé des problèmes plus profonds : composants redondants, mal connectés ou absents de la bibliothèque. J’ai donc proposé de reconstruire le Design System plutôt que de corriger l’existant.
Un investissement initial plus important, pour gagner durablement en conception et en handoff.
-
Prioriser, sélectionner, supprimer
En respectant au maximum la direction artistique existante, il a fallu faire des choix pour simplifier le design. Trop de cas particuliers existaient d’un écran à l’autre et j’ai donc proposé une simplification accompagnée de règles claires pour chaque cas d’usage.
-
Reconstruire en Atomic Design
Dans un produit en évolution fréquente, j’ai reconstruit les composants à partir d’éléments atomiques communs. Modifier un élément partagé permet ainsi de mettre à jour les composants associés et de réduire la maintenance côté design comme développement.
Avant
- Plusieurs composants pour un même usage
- Valeurs répétées sans logique commune
- Composants parfois détachés de la bibliothèque
- Choix ambigus lors de la conception
- Écrans construits avec des règles différentes
Après
- Un composant de référence par usage
- Valeurs centralisées via variables et tokens
- Bibliothèque commune et structurée
- Règles d’usage explicites
- Écrans alignés sur les mêmes standards
Résultats
−40 %
temps de conception par écran
Mesure indicative réalisée par mes soins sur trois écrans : temps de conception avec ancien DS vs nouveau DS
| Écran | Ancien DS | Nouveau DS | Gain |
|---|---|---|---|
| Homepage | 56 min | 31 min | −45 % |
| Article | 40 min | 26 min | −35 % |
| Game Pass | 66 min | 39 min | −41 % |
| Moyenne | 54 min | 32 min | −40 % |
62 % à 91 %
adhérence globale au Design System
+29 points
Mesuré avec Design System Auditor sur un même périmètre d’analyse.
34 % à 98 %
adhérence au DS sur des écrans critiques
Sans l’intervention de Xavier, le projet aurait pu durer encore des mois.
Ce que je referais autrement
Les objectifs de gain de temps en conception et de simplification du handoff ont été atteints.
Mais je n’ai pas quantifié les gains côté développement. Avec du recul, j’aurais défini dès le départ des KPI comme le taux de réutilisation des composants (Component Reuse Rate), le temps d’intégration UI (UI Implementation Time) ou le taux d’anomalies UI (UI Defect Rate).
Cela aurait permis de mesurer les bénéfices du Design System sur l’ensemble de la chaîne de production, du design au développement.