Le Design Ops est en plein essor, au point de se présenter comme un levier incontournable pour maximiser l'impact du design au sein des organisations. Mais à quel moment faire appel à un Design Ops ? Je vous livre ici les 5 signaux qui vous indiquent qu’il faut passer à l’action !
👶 L’essor du Design Ops
Du plus loin que je me souvienne, c’est depuis la publication du livre d’Invision DesignOps Handbook en 2018 que cette discipline prend de l’ampleur et se démocratise, notamment outre-Atlantique. Une étude de 2020 menée auprès de plus de 500 designers par le Nielsen Norman Group, avance le fait que 20% des interrogés travaillaient dans des entreprises ayant au moins une personne dédiée au Design Ops… Pour environ 40% qui indiquent être entourés de personnes ayant des responsabilités DesignOps (des Design managers par exemple) sans pour autant en avoir la fonction officielle.
Depuis, et en France notamment, deux indicateurs laissent à penser que cette discipline est en plein essor :
- Les grandes entreprises de la tech outre-Atlantique possèdent des équipes dédiées au Design Ops : Atlassian, SalesForce, Figma, Intel,… Un exemple avec Meta où plus de 200 Designers sont chargés de l’Ops pour des milliers de Designers.
- Des scale-up françaises (Doctolib, Payfit, Agicap) et des grands groupes (Decathlon, Renault) s’entourent progressivement de Design Ops.
Avant de s’intéresser à ce qui peut pousser une organisation à recruter son premier Design Ops, il me semble important de clarifier ce qu’est cette discipline :
Le Design Ops a pour objectif de faciliter les activités liées au design au sein d'une organisation, afin d'en tirer un maximum d'impact avec un minimum de friction. Pour maximiser cet impact, son périmètre d’intervention peut donc être très large. En s’inspirant du “Design Ops Landscape” du Nielsen Norman Group, on peut décrire les domaines sur lesquels il intervient.
- L’organisation de l’équipe
S'assurer que l'organisation design est correctement structurée, que l'environnement est propice à la collaboration et au développement des designers.
Exemples : S’assurer que les rôles et responsabilités sont clairs, que la communauté de pratiques est bien animée, que les Designers peuvent se projeter dans un parcours de carrière,...
- Les processus et outils
S'assurer que les pratiques sont harmonisées, que les outils sont les bons et que les sujets adressés soient priorisés.
Exemples : Les principes de design existent et guident la conception, les processus de discovery et de delivery sont établis et fluides, les sujets design sont correctement priorisés,... - L’impact du Design
S'assurer que l'impact du design est mesurable, valorisé et que le reste de l'organisation gagne en maturité
Exemples : Définir des design metrics, évangéliser autour de l'impact du design, permettre la montée en compétence,...
⛈️ Les 5 signaux qui montrent que vous avez besoin d'un Design Ops
- Le nombre de Designers augmente rapidement.
Passer de 5 à 30 Designers en plusieurs mois implique de nombreux challenges, que ça soit en termes d’onboarding, d’organisation de l’équipe, des processus etc...
C’est encore plus vrai lorsque les équipes s'internationalisent ! Toutes les organisations confrontées à cette internationalisation découvrent de nouveaux challenges (Decathlon, Doctolib, Le Bon Coin,…) : Comment favoriser la collaboration ? Aussi la cohérence dans le produit & dans les pratiques ? Enfin, comment maintenir une culture design unifiée quand on passe de 30 Designers français à 100 Designers répartis dans le monde entier ?
Difficile pour moi de vous donner un chiffre précis à partir duquel une organisation devrait recruter un Design Ops tant cela dépend de l’organisation et de ce qu’elle attend de son Design Ops . Je trouve cependant la récente étude (2022) menée par Design Ops Assembly intéressante : elle conclut à la présence d’1 Design Ops pour 25 Designers en moyenne.
- Votre équipe se spécialise et peine à s’organiser.
Lorsque votre organisation atteint un certain niveau de maturité en design, il devient presque indispensable de se renforcer avec des profils spécialisés : User Researchers, UX Writers, UI Designers, Design Managers,…
La structuration de l’équipe ainsi que la définition des rôles et responsabilités devient donc un enjeu important.
De nouveaux challenges émergent : Comment faire collaborer ces expertises avec les Product Designers déjà en place ? Comment structurer ces pôles d'expertise ? Comment industrialiser cette collaboration ? Ce sont des challenges auxquels Virginie Coux, consultante Design Ops chez Decathlon, a plusieurs fois été confrontée :
“Quand on commence à parler de recruter des profils spécialisés, on peut observer différentes réactions de la part des équipes design. D’un côté, il y a ceux qui vont attendre l’arrivée d’un User Research ou d’un Content Designer comme le messie, car ils perçoivent rapidement leur valeur ajoutée et ce qu'ils vont apporter. De l’autre, il y a ceux qui appréhendent et ont peur de “se faire piquer une partie de leur job”. C’est notamment le cas lorsque les Product Designers sont eux-mêmes très attachés à la research ou au content. Il faut comprendre et composer avec ces craintes, y répondre et mettre en place les outils et process qui permettent à la collaboration d'être la plus fluide et efficace possible.”
- Des Designers qui travaillent en silos.
De nombreux problèmes découlent de ce constat, autant dans les pratiques que sur le produit en lui-même. Ce manque de collaboration et d’alignement peut créer des problèmes de cohérence et une perte d’efficacité : composants créés plusieurs fois, expériences différentes d’une équipe à une autre, enseignements issus de la user research non partagés, ... Ça arrive d’autant plus depuis l’arrivée massive du télétravail. En effet, la distance amplifie tout ce qui ne fonctionne pas bien en présentiel.
Une autre conséquence de cet isolement est la difficulté pour les Heads of Design de maintenir une culture design commune. Comment faire pour remplacer la communication (par définition non scalable) par les bons outils et les bonnes pratiques : design system, principes de design, vision commune, process communs…?
- Des initiatives lancées qui ne voient pas le jour.
Souvent très motivés à l’idée d’améliorer les pratiques et l’impact du design au sein de leurs organisations, les Designers peuvent être amenés à lancer des initiatives par eux-mêmes. Si ces initiatives sont louables et peuvent contribuer à l’amélioration des pratiques, la réalité du terrain vient souvent les tuer.
- Difficulté à se libérer du temps pour faire avancer les sujets. C’est encore plus le cas lorsque les fiches de poste ne prévoient pas de temps dédié pour travailler sur de l’Ops.
- Souci à embarquer les équipes, par manque d’alignement ou parce que “pas le mandat”.
- L’équipe s’éparpille et le manque de focus génère un manque d’impact.
Donner la responsabilité de porter ces initiatives transverses à un profil dédié permet donc de s’assurer qu’elles sont priorisées, bien exécutées et portées jusqu’au bout.
“J’ai plusieurs fois observé des Designers se plaindre d’un manque d’organisation dans leurs fichiers de travail, sans que personne ne prenne l’initiative de résoudre ce problème de manière transverse...”
- Plusieurs équipes rencontrent le même problème sans prendre le temps de le résoudre.
La remontée et/ou l’observation de problèmes récurrents venant de Designers travaillant dans des équipes différentes est évidemment un indicateur que le problème devrait être adressé de manière transverse. C’était notamment le cas chez e.Voyageurs SNCF. Emilie Larose, anciennement Head of Design Ops chez e.Voyageurs , expliquait au travers du podcast Design MasterClass que ses équipes remontaient régulièrement le fait qu’elles passaient trop de temps en réunion. Certaines semaines, le temps effectif passé par ses Designers sur des activités purement liées au design (production, réflexion,…) ne représentait que 35%.
Autre exemple côté outillage : j’ai plusieurs fois observé des Designers se plaindre d’un manque d’organisation dans leurs fichiers de travail, sans que personne ne prenne l’initiative de résoudre ce problème de manière transverse.
Un dernier grand classique est la difficulté de s’interfacer correctement avec le Produit et la tech : difficulté à choisir les bons outils de suivi, s’accorder sur les “definition of ready” et definition of done” par exemple.
🤔 Résoudre ces problèmes sans Design Ops dédié, est-ce possible ?
Selon moi, plus que des activités et un rôle, le Design Ops est avant tout un état d’esprit reposant sur le “problem solving” que chaque Designer se doit d’avoir. Se pose donc légitimement la question de résoudre ces problèmes de manière collaborative, sans un profil dédié. On peut également se tourner vers les Design managers en se demandant si, finalement, ce n’était pas leur responsabilité de résoudre ces problèmes et de garantir collaboration, qualité et impact au sein des équipes.
Le retour d’’expérience de Rémi Guyot, ex-CPO de Blablacar et Partner chez Thiga :
“Chez BlaBlaCar, on s'était sérieusement penché sur cette question. Baignant dans une culture très lean, notre crainte était de créer un rôle qui finisse par s'attaquer à des problèmes internes mineurs juste pour avoir des nouveaux process à implémenter, au détriment de problèmes utilisateurs ou business autrement plus importants ! Notre choix de l'époque a été de ne pas créer de rôle de Design Ops fourre-tout.
Du coup, pour régler les problèmes qui survenaient, on alternait entre :
- - (souvent) Ajouter ça à la longue liste de responsabilités des managers. Exemple : harmonisation des process, grille d'évaluation et d'évolution, gestion des embauches, etc.
- - (parfois) Demander à un Designer de prendre un problème en charge sur l'année. Exemple : gérer les outils de l'équipe, aussi bien la négo, le contrat que les licences ou l'exploration d'alternatives.
- - (rarement) Créer un rôle dédié qui ne ferait que ça. Exemple : Design System, Prototypage, User Research
Avec le recul, je me demande si cette approche n'a pas mis trop de pression sur les épaules des managers. Certaines personnes, y compris parmi les profils managers, adorent pouvoir se concentrer sur les défis utilisateurs et business à régler, et sont ravis de s'appuyer sur des process et outils bien huilés définis par d'autres. Est-ce que ces profils-là sont les meilleures personnes pour définir, implémenter et faire respecter ces process et outils ? Probablement pas. Des balles tombaient tout le temps, à force d'être noyés dans trop de sujets à la fois. On s'est parfois retrouvé à gérer beaucoup de chaos au quotidien, ce qui peut être usant sur le long terme.
Parmi les choix dont je doute le moins, je suis très content de notre approche de la user research. On a testé beaucoup de modèles différents, et le meilleur a clairement été celui où le rôle de User Researcher était 100% un rôle de Research Ops, au service des Product Managers et Product Designers."
Mon avis sur ce modèle est qu’il est intéressant lorsqu’on décide de commencer à structurer les activités liées au Design Ops, lorsqu’il n’y a pas le budget ou encore lorsque l’organisation n’a pas le niveau de maturité design suffisant pour comprendre l’apport que pourrait avoir un rôle dédié à temps plein.
L’augmentation du nombre de sujets design et l’augmentation des effectifs rend cependant cette multiplication des casquettes difficile à maintenir dans le temps. Le risque est de surcharger le ou les Design Manager(s). L’objectif n’est pas non plus de les faire perdre en impact ou de créer des burn-out. Une autre limite au modèle : la difficulté à garantir l’alignement entre les différents managers dans le temps. L’équipe grandit, les managers se concentrent sur leurs équipes et garantir la cohérence devient complexe.
Pour conclure, si je devais donner une réponse simple à la question “Le Design Ops : Oui mais quand ?”, je dirais “dès que vous n’arrivez plus à régler des problématiques transverses liées à votre équipe design et que votre produit commence à en pâtir”. Aucune raison donc de ne pas prendre le train en marche si besoin et de ne pas structurer ses activités liées à l’Ops. À minima, en commençant par responsabiliser les managers, en faisant monter un Designer déjà présent dans l’équipe ou alors en recrutant son premier Design Ops !
Comment structurer sa démarche Design Ops et s’assurer qu’elle est bien adaptée au contexte de son équipe ? C’est un autre sujet, qu’on abordera dans une prochaine publication… Stay tuned ;)
Merci à Virginie, Rémi, Julien et Thomas pour leur aide précieuse dans la rédaction de ce papier.
Pour en savoir plus sur le Product Design : télécharger notre livre Le Product Design dans une organisation Produit
