DesignOps : ce que c’est, et par où commencer

Une définition simple

Quand une équipe design passe de trois à trente personnes, les problèmes changent de nature. On ne manque plus de talent, on manque de cohérence : trois façons de faire un bouton, des fichiers que personne ne retrouve, des développeurs qui réinventent ce qui existe déjà. Le DesignOps s’occupe de ces frictions.

Concrètement, c’est l’ensemble des pratiques qui rendent le design reproductible : un design system tenu à jour, des rituels de revue, un outillage partagé, une façon claire de contribuer, et des gens qui savent que tout ça existe.

Ce que le DesignOps n’est pas

• Un poste de gestion de projet rebaptisé. Le DesignOps produit des choses : des composants, de la documentation, des outils, des formations.
• Un design system à lui seul. Le design system est souvent le premier livrable, mais sans adoption, c’est une bibliothèque Figma de plus.
• Une affaire de grandes entreprises. Une équipe de cinq personnes a déjà besoin de conventions de nommage, d’une source de vérité et d’un rituel de revue.

Les trois chantiers

Le travail se répartit en trois blocs, qu’on mène en parallèle.

• Les outils et le système : le design system (tokens, composants, documentation), l’organisation des fichiers Figma, le lien avec le code, les gabarits.
• Les process : comment une demande arrive, comment un composant est proposé, revu, publié et versionné, qui décide quoi.
• La communauté et l’adoption : l’onboarding des nouveaux, les points d’échange réguliers, les relais dans chaque équipe, le support au quotidien.

Le troisième chantier est le plus souvent oublié, et c’est pourtant celui qui fait la différence. Sur le design system d’ENGIE, ce sont les événements réguliers, le contenu d’onboarding et un réseau de relais dans les entités qui ont fait passer le système d’un outil à une pratique partagée.

Mesurer l’adoption

Un design system qui n’est pas mesuré finit par être jugé sur des impressions. Quelques indicateurs suffisent, à suivre chaque trimestre.

• Couverture : la part des écrans ou des projets qui utilisent les composants du système.
• Adoption : le nombre de projets, d’équipes ou d’entités actifs, et sa progression.
• Écarts : le nombre de composants recréés à la main, de couleurs codées en dur.
• Satisfaction : un questionnaire court aux utilisateurs du système, designers et développeurs.
• Contributions : le nombre de propositions venues d’autres équipes que l’équipe cœur.

La communauté, le levier sous-estimé

Un système s’adopte quand les gens le connaissent, le comprennent et peuvent l’influencer. Trois leviers marchent à toutes les échelles.

1. Des relais : une personne par équipe ou par entité qui fait remonter les besoins et redescendre les nouveautés.
2. Un rendez-vous régulier, court et utile : ce qui est sorti, ce qui arrive, une démo, une question ouverte.
3. Un onboarding de trente minutes, que n’importe quel nouveau peut suivre seul.

Par où commencer : un plan sur 90 jours

1. Semaines 1 à 3 : écouter. Entretiens avec designers, développeurs et responsables produit, inventaire des fichiers, des composants et des irritants.
2. Semaines 4 à 6 : poser les fondations. Tokens, conventions de nommage, organisation des fichiers, un premier composant de bout en bout.
3. Semaines 7 à 9 : outiller la contribution. Un process écrit pour proposer, revoir et publier un composant, et un journal des versions.
4. Semaines 10 à 12 : lancer la communauté. Les premiers relais, le premier rendez-vous, l’onboarding, et une première mesure de l’adoption.

Les signaux qu’il est temps

• La même question revient chaque semaine sur le canal design.
• Deux équipes livrent deux versions différentes du même composant.
• L’onboarding d’un nouveau designer prend plus de deux semaines.
• Personne ne sait quelle bibliothèque Figma fait foi.

Je mène ce travail avec les équipes, de la startup au grand groupe : design system, gouvernance, communauté. Le design system de ce site, documenté et versionné, en est un petit exemple.