DesignOps : outiller le travail de design pour qu'il ne se refasse pas deux fois
Combien de temps votre équipe passe-t-elle à refaire ce qu'elle a déjà fait ?
Le DesignOps s'occupe de la manière dont le design se fabrique : comment le fichier est structuré, comment les composants se réutilisent, comment le travail arrive chez les développeurs. On y touche quand la production de design coûte plus cher que la conception elle-même.
Quand le DesignOps s'impose
Quand la fabrication du design coûte plus cher que sa conception. Par exemple :
- Industrialiser un fichier de conception devenu ingérable à mesure que le produit grandit.
- Variabiliser des composants recopiés à la main d'un écran à l'autre.
- Documenter un handoff où les développeurs redemandent chaque spécification.
- Refondre un design system dont la construction freine les itérations.
Le constat
Quand une équipe recopie ses composants d'un écran à l'autre, chaque correction est à reporter sur chaque copie. Ce coût n'apparaît pas sur la première maquette, il grossit avec le nombre d'écrans. Remettre à plat la construction d'un design system permet de repenser des petits éléments qui ont un impact global sur les itérations suivantes.
Comment on procède
Poser des bases réutilisables
On structure le fichier de conception pour l'industrialiser : composants variabilisés, pages templates qui se déclinent. Une refonte est le moment où ce travail coûte le moins cher, puisque les écrans sont de toute façon repris.
Outiller le partage
De la phase de wireframes jusqu'aux maquettes finales, tout est partagé directement dans Figma. On ouvre les accès à votre équipe pour faciliter les commentaires, et on s'adapte à vos outils quand vous en avez déjà.
Préparer le handoff
Les développeurs récupèrent les composants exportables en PNG et SVG, les spécifications, et le code HTML et CSS pré-généré. La documentation produite une fois sert pour tous les écrans suivants.
Laisser l'équipe reprendre la main
L'objectif est que vos équipes internes déploient la suite sans nous. Un design system taillé pour votre direction artistique leur donne les règles graphiques du produit, sous une forme qu'elles peuvent appliquer seules.
On l'a fait sur un vrai produit
Sur la refonte de Tytl, une plateforme britannique d'agrégation de données immobilières, la nouvelle identité imposait de tout reprendre. On en a profité pour reposer un design system propre, repenser la construction des composants et les variabiliser, et pour travailler par pages templates. Le déploiement sur le reste du site revient ensuite aux développeurs internes. C'est notre seul projet où l'outillage du travail de design est raconté en tant que tel, et on préfère le dire.
Voir cette réalisationQuestions fréquentes
C'est tout ce qui rend le travail de design reproductible : la structure des fichiers, la réutilisation des composants, les conventions, la manière dont le design passe aux développeurs. C'est la chaîne qui fabrique les écrans.
Le DesignOps outille la production du design. Le ResearchOps outille la recherche utilisateur : recrutement des participants, consentement, archivage des données, research repository. Les deux organisent un travail, mais sur deux matières différentes. Un research repository relève du ResearchOps, pas du DesignOps.
Un design system est un livrable, alors que le DesignOps désigne la manière de le construire et de le maintenir. On peut donc livrer l'un sans l'autre, au prix d'une maintenance plus lourde, et on peut commencer le DesignOps par l'industrialisation du fichier sur un produit qui n'a pas encore de design system.
La question est moins la taille de l'équipe que la durée de vie du produit et le nombre d'écrans. Un produit qui va vivre des années, avec des itérations régulières et des développeurs qui déploient en autonomie, y gagne même avec un seul designer. Un site vitrine livré une fois, non.
On construit des design systems et on structure des fichiers pour qu'ils se maintiennent. La gouvernance au sens large, avec ses tokens versionnés, ses rituels d'équipe et ses conventions de contribution, n'est pas ce qu'on a documenté dans nos projets. Si c'est votre besoin, autant qu'on en parle dès le départ.