Le digital a changé les règles du jeu. L’expérience utilisateur est le critère principal d’attraction et de rétention des utilisateurs, pas la taille de l’entreprise. Délivrer des interfaces au high-standard est un critère de survie pour les organisations.
Le Design est un activité souvent perçue comme élitiste, réservée à un nombre réduits d’acteurs agissant en chambre close. Une fois l’expérience conçue, elle est finalement dévoilée aux équipes chargées de l’implémentation.
Le DesignOps vient accélérer les cycles de prototypages d’expériences utilisateurs par une meilleure collaboration des acteurs. Il en résulte une performance accrue de l’expérience client et de l’organisation.
Émile Aublet a été Lead Designer et mis en pratique le DesignOps dans différentes organisations. Il nous partage son expérience et conseils sur cette thématique clef du DesignOps :
- Le métier de Design et d’UX
- La définition et motivations du DesignOps
- Les méthodologies du DesignOps
- La valeur ajoutée et management du DesignOps
- L’organisation et les acteurs du DesignOps
- Comment initier une démarche de DesignOps
- Les compétences du DesignOps
Rejoignez la QE Unit pour accéder à plus de contenu exclusif de la communauté.
À propos de Émile Aublet
Émile Aublet a plus de 12 années d’expériences dans le domaine du Design. Il est basé au Canada à Montréal, travaillant pour Shopify en tant qu’Engineering. Il a obtenu plusieurs prix et récompenses de design et d’interfaces utilisateurs.
Il a commencé sa carrière chez TC Media en tant que Designer Interactif avant d’évoluer chez Nurun, occupant les postes de Designer Web puis d’Art Director. Il a ensuite évolué en tant qu’Interactive Art Director chez Frank+Oak avant d’être Manager Interactions & Design chez Aldo Group. Il a plus récemment occupé les postes de Lead Interaction Design UI puis Lead Design Ops à la Banque Nationale du Canada. Il est actuellement chez Shopify en tant qu’Engineer.
Antoine : Peux-tu commencer par te présenter ?
Je vis à Montréal, je suis Designer, DesignOps et front-end Développeur. J’ai passé les 12 dernières années essentiellement sur le design et les intéractions. Aujourd’hui, je me concentre un peu plus sur la partie front-end, avec une envie d’apprendre un peu plus du côté de la technique. Je suis convaincu que c’est essentiel à mon métier et au thème de cet interview.
Antoine : En quoi consiste le métier d’UX, design? Quelles priorités addresses-tu?
Le design, l’UX et le développement front se mélangent de plus en plus. Le but est de créer des interfaces qui sont surtout des expériences utilisateurs. On parle de plus en plus de fabrication d’expériences en collaboration avec les développeurs. On cherche à créer des expériences accessibles, faciles d’utilisation, mémorables.
Le travail de design et d’interaction tourne beaucoup autour de l’humain. Que ce soit en réalisant du user-testing directement avec des utilisateurs pour tester l’interfaces, ou même dans certains cas avec une présence physique. Le métier de design évolue beaucoup. Il y a 10 ans on imprimait des maquettes; aujourd’hui on les code pour directement les tester.
Le DesignOps a un impact direct tant en interne qu’en externe, pouvant faciliter la vie, le travail et la collaboration des acteurs.
Antoine : L’acronyme DesignOps a suscité ma curiosité. On sent un parallèle avec le DevOps dans une dynamique globale d’accélération. Peux-tu nous en dire un peu plus ? Comment cela s’insère dans le Quality Engineering ?
Le DesignOps a bien des racines communes au DevOps. C’est un ensemble de pratiques qui existaient déjà en partie. Son émergence est liée à la collaboration accrue des designers avec les autres acteurs dans le processus de design. Si autrefois un designer travaillait seul avec des maquettes sous Photoshop, ce n’est aujourd’hui plus possible. Les designers ne peuvent pas tout savoir, connaître ni prévoir seuls. Ils doivent donc collaborer au plus tôt et régulièrement avec les acteurs pertinents pour pouvoir délivrer des expériences utilisateurs de qualité.
Le DesignOps permet aux designers de saisir les opportunités de l’écosystème et facilite la collaboration avec les acteurs. Comme le DevOps, cela ne se limite pas aux outils ou aux processus, la culture et les compétences sont importantes. Un designer doit savoir communiquer ses idées, la réalisation étant de plus en plus réalisée en équipe.
Antoine : En quoi le DesignOps est différent des approches traditionnelles de Design?
Nous pouvons déjà définir ce qu’est une approche traditionnelle de design. Je pense généralement à un designer travaillant en mode agile, par exemple avec des sprints. La différence principale est que le designer est très focalisé et centré sur son contexte, sa perspective et ses objectifs, comme dans un silo. Il a donc peu d’échanges avec le reste de l’écosystème au risque d’avoir des soucis d’intégration par la suite.
Une autre approche traditionnelle est de réaliser en étapes distinctes le design et l’implémentation technique. Un designer va travailler 6 mois à construire un certain nombre d’éléments qui seront ensuite pris en charge par une équipe de développement et de contenus. Dans les deux cas, il faut prendre du recul sur les aspects positifs et négatifs de ces approches.
J’ai pu mettre en place une démarche de DesignOps dans ces 2 contextes. Le DesignOps est finalement la colle entre toutes les activités du Designer pour qu’il soit capable d’avoir une meilleure visibilité, un meilleur recul et confrontation de ses idées. On évite de passer des mois à construire une boîte noire ensuite révélée comme un grand dévoilement au reste de l’équipe. Les acteurs internes et les partenaires font partie intégrante des itérations de design.
Formaliser le DesignOps permet de clarifier la structure et la gouvernance.
Antoine : Il y a donc un vrai pilier de culture et d’intéractions au sein du DesignOps. Au-delà de tester leur design plus rapidement, c’est également le mettre en musique plus tôt, le partager et avoir des retours transverses à plusieurs niveaux.
Oui exactement, surtout dans un business où l’expérience utilisateur est différenciante. C’est tellement coûteux de fabriquer un produit qu’il faut réduire les risques et développer les bonnes pistes. Ces tests et vérifications de valeur sont subtils en design ; on parle beaucoup d’émotions, d’attachement, de satisfaction. Ce sont des variables difficiles à mesurer factuellement. Pour complexifier la tâche, les interprétations dépendent du contexte.
Par exemple, il est difficile de tester l’accessibilité d’un site web. Chaque personne est dans un contexte différent, avec un équipement et des réglages différents. On veut réduire le biais au maximum. Le DesignOps permet de réduire au maximum la variabilité dans l’évaluation en testant rapidement et de manière intégrée dans le reste de l’écosystème. On doit pouvoir tester plusieurs idées par jour.
Antoine : Quelles fondations pour le DesignOps ? Quelles pratiques concrètes pour le DesignOps ?
Les principes se déclinent différemment selon les contextes. Je peux partager un cas concret où j’étais dans une banque avec une équipe de designers et de développeurs. Nous avions plusieurs produits numériques. Ces produits avaient régulièrement besoin de composants relativement standards. Une première priorité a été de créer des librairies de ces objets pour les réutiliser facilement au sein d’autres applications.
Cette première étape de bibliothèque nous a permis de mieux communiquer et de partager avec les autres équipes sur les besoins récurrents. Nous avons plus facilement convergé sur un vocabulaire commun, accélérant la collaboration entre différents acteurs. Comme tout problème humain, le nœud est souvent la communication qui nous fait perdre du temps et de l’argent.
En complément, ces librairies nous ont orienté vers une approche produit de nos composants, facilitant le versioning, maintenance et évolution. Au fil du temps, ces pratiques se sont transformées en éléments de culture de notre équipe. De gros acteurs l’ont réalisé en avance; Google avec le Material Design, Shopify avec Polaris. Les développeurs sont familiarisés avec ces composants, il est facile de les intégrer aux applications.
La culture commune a évolué par le langage commun, la bibliothèque de composants et leur documentation facilitant leur utilisation. Le gain concret est la réutilisation et l’accélération de la création de Design qui sont rapidement testés. Le niveau d’exigence a également été augmenté sur l’ensemble des composants pour atteindre cette même facilité d’utilisation. Les équipes veulent pouvoir itérer rapidement sur l’ensemble des composants.
Dans notre cas, nous nous sommes toujours focalisés à avoir des composants réels intégrés aux applications. On peut penser utiliser Framer ou à InVision pour imiter des composants avec des mockups. Le problème est que l’intégration sera compliquée, ralentie et les tests pas forcément pertinents. Il est donc important dès le départ d’avoir une approche intégrée du DesignOps sur l’ensemble de la chaîne. Cela crée également une empathie plus forte entre designers et développeurs.
Antoine : L’enjeu est bien de tester l’idée et son implémentation jusqu’au bout pour valider la capacité de réalisation et d’amélioration de l’UX par la suite.
Le Design System est un couteau à double tranchant. Il faut le voir comme une boîte à outils, pas comme des menottes. La ligne est fine, on peut vite basculer dans un extrême. Par exemple, en utilisant uniquement des composants standards, on finira par créer des expériences limitées et fades, en s’enfermant dans les choix disponibles. Le risque est d’optimiser notre processus en oubliant la perspective utilisateur, qui en fonction des contextes à des besoins différents.
Le DesignOps est en recherche continue d’un sweet spot, entre un produit suffisamment simple, malléable et évolutif pour pouvoir l’adapter, et à la fois structuré et standard pour garantir sa maintenabilité et robustesse.
Antoine : Quels apports et création de valeur as-tu vu se réaliser, ou constater tant pour le Business que l’IT ?
Le DesignOps se matérialise dans un premier par une meilleure collaboration avec les équipes. Il en résulte des temps de design et de développement réduits sur des cycles beaucoup plus courts. Un produit qui prend rapidement vie contribue à des attentes plus claires au plus tôt pour les parties prenantes. Les équipes auront vu un produit concret intégré, qui permet de valider beaucoup plus d’hypothèses.
Pour le client, la valeur est dans l’expérience. On peut regarder les grands players comme Google, Facebook, Microsoft; une fois familiarisé avec une application on sait facilement utiliser l’ensemble. C’est le cas avec Gmail et la suite collaborative, Outlook et la suite Microsoft, Safari et les applications sous Apple. Il existe une uniformité des applications, issue d’une démarche de DesignOps. À la fois, l’application est pertinente pour ses cas d’usages et a une cohérence transverse pour faciliter l’utilisation de la suite globale. Les utilisateurs qui comprennent une interface n’ont pas besoin de documentation ou d’aide. L’intuitivité est telle que les utilisateurs savent utiliser d’eux-mêmes les outils, satisfaits de leur expérience.
Une expérience utilisateur de haut niveau a un impact sur la performance de l’entreprise. Cela peut se traduire par une hausse du chiffre d’affaires, de la marge, d’indicateurs clients. La facilité et la satisfaction d’interagir avec une marque, ses produits et ses services supportent l’attraction et la rétention des clients. Les entreprises qui réussissent le mieux ont une réelle culture du Design et de l’amélioration continue.
Le design n’appartient pas qu’aux designers. On a parfois une vision trop élitiste de l’activité, comme pour les développeurs. L’ensemble de l’organisation doit être sensibilisé au design, sa valeur, ses processus et sa complexité. Les parties prenantes doivent comprendre la nécessité des investissements, des temps d’itérations et de validations nécessaires. Cette connaissance des autres métiers nous aide à créer des solutions qui nécessitent moins d’aller-retours. Les acteurs sont sensibilisés aux nécessités et difficultés, ils intègrent naturellement certaines informations par ce capital d’empathie. Chaque acteur est bien responsable pour son travail, et charge à chacun de faciliter la collaboration et la communication en transverse.
Antoine : Les parties prenantes sont importantes pour une culture du design. On a identifié le designer, le product owner, les développeurs. Quels sont les acteurs d’une démarche de DesignOps ?
Le DesignOps peut sembler difficile à vendre dans une entreprise. Cela peut être considéré comme une pure dépense, sans retour sur investissement. Or cette discipline se met déjà en place dans les équipes de design, il ne reste bien souvent qu’à la formaliser et standardiser les méthodes. Le DesignOps devient l’affaire de tous quand c’est bien en place, supporté par une gouvernance qui s’élargit au fil du temps. On a pas forcément besoin d’un “hero designer”, les compétences et les activités sont à terme transverses à l’organisation. Il faut des personnes capables de collaborer et faire accélérer l’organisation au global, pas uniquement sur leur prisme individuel.
Il faut démarrer par un petit noyau, une petite équipe dont c’est leur principale priorité. Le nombre d’acteurs doit être bien sélectionné et rester limité pour garder des itérations courtes et efficaces. On oublie trop facilement les acteurs responsables du contenu, ils se retrouvent à devoir intégrer tant bien que mal les éléments en bout de chaîne, en ayant uniquement des références de contenus. Pourtant, une expérience utilisateur qui est agréable et facile à utiliser passe énormément par le contenu. Il est donc essentiel d’intégrer ces acteurs dès le début de la démarche.
“Le DesignOps devient l’affaire de tous par une gouvernance et culture d’entreprise partagées.”
Émile Aublet
Leur contribution sera également plus pertinente avec des contenus plus adaptés, intégrés et revus au plus tôt. Par exemple, le texte d’un élément de confirmation peut être “Poursuivre”, “Continuer”, “OK”. Le fait de partager les designs, le développement et les contenus directement fera émerger ce besoin et sera clarifié bien plus tôt. La probabilité de rework et de changement est drastiquement réduite par la suite. Cet exemple semble trivial mais arrive fréquemment. Sur un plus grand nombre d’éléments, la perte de temps devient significative.
Le DesignOps étant un enjeu culturel, j’ai souvent eu à le pousser à des niveaux qui dépassent celui des équipes opérationnelles, par exemple à des VPs. L’allocation de 3 personnes pendant plusieurs mois travaillant sur cette démarche est un réel investissement pour une entreprise. Les résultats sont à moyen et long-terme, pas à court-terme, il faut des gens influencés et convaincus. Comme pour le DevOps, il faut un setup initial avant de pouvoir en capter les fruits. Au début, on peut difficilement mesurer le gain. Par la suite, on peut plus facilement mesurer le gain et également l’impact de ne plus avoir ces pratiques en place.
Antoine : Que recommandes-tu à une organisation voulant initier cette démarche? Quelles bonnes pratiques suivre ou erreurs à éviter?
C’est plus facile de mettre en place le DesignOps si on débute sur une nouvelle équipe ou un nouveau projet. La complexité est moindre, on peut graduellement créer notre bibliothèque de composants et les adapter au fur et à mesure. Les compétences et capacités de collaboration des acteurs sont en fait les plus importantes dans ce contexte.
Pour des équipes existantes qui ont déjà d’autres priorités et mécanismes, il faut qu’il y ait une problématique à résoudre. On doit commencer par faire ses preuves sur des premières victoires plus faciles à atteindre en cueillant les “low-hanging fruits”. Il y a toujours des typographies, des éléments de formulaires etc. Ce sont des éléments souvent utilisés et en prise directe avec les utilisateurs. On peut déjà les standardiser et les centraliser dans un portail documentation. C’est ici un sujet d’organisation, de structure et de processus partagés.
On doit également avoir un champion, un référent du DesignOps qui sera notre ambassadeur pour étendre la démarche. Il doit être le point de contact privilégié pour l’ensemble des acteurs pour toutes questions ou interrogations. C’est à lui de garantir les méthodes, processus et l’organisation du DesignOps. Il faut à la fois agir sur les processus, la technologie, les priorités, l’organisation et les compétences.
Par la suite, on peut commencer à étendre nos pratiques dans d’autres équipes. On a d’ailleurs pas besoin d’intégrer tout le monde à la même équipe. C’est ici que la culture, un partage des référentiels et des pratiques nous permet d’étendre plus largement dans l’organisation.
En développant rapidement des prototypes entre les différents acteurs, on centre la discussion des parties prenantes sur un objectif commun et partagé : construire une expérience utilisateurs répondant aux différents critères de qualité.
Antoine : Le DesignOps a besoin de véritables fondations, des méthodologies à l’organisation des tâches. On est pas forcément sur l’utilisation des dernières technologies. Il faut commencer par les fondamentaux et itérer sur la création de valeur.
Less is more. On peut souvent faire beaucoup de choses avec les outils dont on dispose, c’est rarement le problème. Le frein est plus souvent celui du mindset. Par exemple, on peut commencer par la bibliothèque de composants partagés et se rendre compte qu’on en a 140 à réaliser, sans savoir pas où commencer. En appliquant un 80/20, on peut certainement se focaliser sur les 10 plus importants dans un premier temps, mesurer leur valeur, les adapter et les améliorer.
Le prototypage est difficile à cause du mindset. Les designers peuvent être biaisés par ce qu’ils savent prototyper, en fonction de leurs compétences. C’est la même chose pour les développeurs, ils vont avoir tendance à limiter les possibilités d’implémentation à ce qu’ils savent faire.
“Pour atteindre le sweet spot, il faut donc que les acteurs sachent composer leur expertise et agir en dehors de leur zone de confort.”
Émile Aublet
Un prototype sera très souvent jeté et non utilisé. Le but est de rapidement valider une idée réelle que l’on peut expérimenter pour valider la création de valeur. On peut ensuite passer à l’étape d’industrialisation. On peut utiliser des images pour une grande partie de l’écran pour des prototypes. Si l’on veut uniquement tester une transition ou la fluidité des changements, inutile de perdre du temps sur le reste. C’est un exemple de DesignOps en pratique, il faut savoir utiliser des raccourcis où on n’impacte pas la mesure de valeur. C’est un réel équilibre, les designers doivent être un peu plus techniques, les développeurs beaucoup moins exigeants sur leur code.
Antoine : Pour un designer, quelles compétences identifies-tu comme principales pour aborder la DesignOps?
Les compétences techniques sont importantes. Dans ce monde des intéractions et des expériences, il faut pouvoir agir en transversalité. Je ne suis pas sûr que cet aspect soit forcément abordé dans les formations officielles et plus traditionnelles. C’est pour moi très important. Pour des designers en freelance, savoir coder permet également d’être plus lucratif.
Je fais également le parallèle avec ma mère qui étaient designer sur du print physique. Il est impossible de faire du design de print sans savoir comment il va être imprimé, comment la machine fonctionne, quelles contraintes elle a. C’est impossible. On doit connaître l’encre, le papier, le type d‘impression etc. Tant l’imprimeur que le designer doivent comprendre leurs besoins et contraintes. En design d’intéractions, c’est la même chose, il faut maximiser nos connaissances sur l’ensemble de la chaîne.
Le DesignOps requiert donc la composition d’expertises. Il faut avoir un équilibre plutôt qu’un extrême sur certaines compétences. On tombe trop facilement dans une optimisation en silo, perdant de vue les utilisateurs. L’humain et la collaboration sont des éléments essentiels du DesignOps, et de la création d’expériences utilisateurs à valeur ajoutée.
Antoine : Merci beaucoup Émile pour ce décryptage, partage d’expériences et recommandations sur le DesignOps. Un très bon exemple d’une pratique appliquant le paradigme de l’ingénierie de la qualité, contraignant son ensemble de processus à la livraison continue de logiciels de valeur. Nous avons les pistes pour démarrer et des parallèles intéressants avec d’autres pratiques. Merci beaucoup pour ta contribution et bon Design(Ops) !