Romain Delgrange — 2- Culture de feedback & pensée systémique

Product Design : du Discovery au Delivery, comment concilier UX et agilité ?

Episode 2 avec Romain Delgrange : culture de feedback et pensée systémique.

Romain Chabbal : Bienvenue dans notre série d’interviews qui vise à explorer les métiers de l’expérience utilisateur (UX, ergonomie, design d’interfaces) et de l’agilité, en creusant plus particulièrement le rôle combiné de PO et UX. Nous recevons aujourd’hui Romain Delgrange, UX et Product Designer indépendant.

Bonjour Romain, pourrais-tu te présenter, qui es-tu et que fais-tu ?

Romain Delgrange : Oui, je suis designer à la base depuis 2012. J’ai fait de l’espace, du produit et du design thinking et je me suis spécialisé en UX en 2017. Pas mal de rôles en UX et expérience plutôt récente sur un rôle croisé UX/PO l’année dernière dans une boîte qui s’appelle Easypara. De là j’ai découvert plus profondément le monde de l’agilité. J’avais déjà eu une expérience de UX en Scrum avant mais là j’ai pu expérimenter les deux rôles, et c’était riche en émotions [rires].

RC : Merci pour cette introduction. On entend souvent parler d’UX : qu’est-ce que c’est pour toi être “UX Designer” ?

RD : Je pense que c’est particulier à chaque région du globe. J’ai eu une formation design, sur la “pensée design”, avec des bases comme Alexandra Midal qui retrace l’histoire du design, croisée avec les arts décoratifs.
Quand j’ai commencé à chercher du travail, j’ai eu du mal à en trouver parce qu’on a la technopole Sophia Antipolis qui est à côté, et je trouve qu’ils ont un background ergonomie. Et en fait pour moi, de ma conception, c’est que le métier d’ergonome est venu s’imbriquer (avec différents outils des sciences humaines) dans les process de Design. Et du coup ça a fait un espèce de petit consensus qui a créé la UX.

Concevoir pour l’homme

RC : Intéressant. Et pour toi, si on devait expliquer à quelqu’un la valeur que cela apporte dans un projet, qu’est-ce que tu dirais ?

RD : Alors ça dépend si je prends ma casquette “business” ou “philosophique”.

Avec ma casquette “business”, ce serait un retour sur investissement et de faire un bon product/market fit. Que ce soit utilisable par les utilisateurs, c’est un petit peu la base. Et après, il y a toutes les notions d’expérience qui viennent en surcouche par dessus, de diversité des utilisateurs etc.

Et avec ma casquette “philosophique”, si on peut appeler ça comme ça, ce serait plus de concevoir des outils pour l’homme. En fait, on ne conçoit pas un produit, mais on conçoit un moyen pour l’homme de s’améliorer. Donc la valeur réside dans ce que l’usager, l’être humain, va pouvoir en tirer, et non pas dans le produit en lui-même.

Anticiper, Vivre le moment présent, se souvenir

D’accord. Comment tu fais le lien entre cette valeur et la notion de “design d’expérience” ?

L’expérience au sens large c’est un peu galvaudé parce qu’on parle plus d’interface généralement. Pour moi, une expérience ce serait quelque chose de mémorable. Si je ressort mes bouquins d’UX il y a les trois phases de l’expérience : anticiper, le moment présent, et ce dont on se souvient. Donc c’est pas vraiment la cerise sur le gâteau, c’est juste de faire en sorte d’accompagner le fait qu’on est des “êtres d’expérience”.

Faire sa part

Quels sont les obstacles que tu rencontres dans la mise en œuvre de cette philosophie UX, de ces méthodologies UX ?

Alors dans ma version utopique, il y en a énormément. Et en fait c’est marrant parce que de base on a toujours été perçus comme des “pseudo graphistes”, moyennant toutes les règles d’utilisabilité, les heuristiques qu’on met en place, etc. Ça a été très difficile lors de ma première expérience, je me suis usé à la tâche. Le type d’obstacle, c’est tout simplement la culture de l’entreprise en fait. C’est “le joli, on fera après” ou encore “on sait ce que veulent les utilisateurs”.

On a les mêmes problématiques dans l’agilité : le point clé, c’est que seul, on n’y arrive pas

Culture de feedback

Tu fais référence aux problématiques qu’on rencontre dans l’agilité…

Cela rejoint le thème de fond de l’interview, la Discovery.

Autant en Delivery, je pense que ça fait des années que… Enfin tu vois, si je devais vulgariser la Delivery, pour moi on est un peu à la croisée entre tout ce que les devs ont fait depuis que l’ordinateur existe, et les méthodes de productivité, comme le Fordisme, le Lean et tout ce qui est venu après. Et donc ça on est bon, on comprend parce que c’est tangible. La Discovery, c’est mettre quelque chose dans les mains de l’utilisateur et le concevoir avec lui. En fait c’est une culture de feedback que, en tout cas en France, on n’a pas. Et ça, ça pèche, ça nous fait pécher dans l’agilité comme en UX.

Culture du “Quand on est au sommet, on sait”

Pourquoi tu penses qu’on n’a pas cette culture de feedback en France ?

Pourquoi ? Je ne sais pas… C’est un petit peu les modèles des entreprises depuis les années 80–90. Alors là je vais pousser une hypothèse : on a toujours eu cette espèce de vision du chef d’entreprise très patriarcale, très pyramidale qui fait que du coup quand on est au sommet, on “sait”. Et les autres exécutent dans leur périmètre d’action. Je crois qu’on ne challenge pas forcément la hiérarchie et nos supérieurs, en tout cas c’est ce qu’on faisait avant, et du coup on ne mettait pas forcément la parole du décideur en question. Et peut-être que c’est une piste pour expliquer ça.

En quoi c’est important d’avoir une culture de feedback en tant que professionnel de l’UX ?

Je l’applique maintenant à ma vie entière. Et côté UX, la culture du feedback sert à savoir si ce que l’on conçoit convient à différents niveaux : que cela satisfasse les besoins, que ce soit utilisable, que ce soit utile et qu’il y ait une expérience mémorable par dessus. Cela participe aussi à la réduction des coûts et donc à la pérennité de l’entreprise.

Qu’est-ce qu’on fait, comment on vérifie ?

Concrètement, qu’est-ce que tu mets en place pour atteindre cette culture de feedback ?

Chez un acteur des technologies du tourisme, j’ai énormément évangélisé. J’ai commencé à pousser l’UX en parlant des lois de l’UX et des différentes heuristiques. Cela donne un côté tangible.

Je dis par exemple “le bouton est trop éloigné”, “ça c’est trop gros”, “pas assez petit” etc. Je montre que le lecteur d’écran n’arrive pas à lire l’architecture parce qu’il y a un H1, un H2 mais qu’il manque les H2 suivants.

Je démarre avec quelque chose de très tangible et après on brainstorm, on discute, je creuse, et je finis par me “contredire” tout seul : je dis “oui la loi elle dit ça”, mais peut-être que l’utilisateur il va faire ça, ou en fait non, l’utilisateur, il pourrait peut-être faire plutôt ça. Du coup, qu’est ce qu’on fait ? Je les amène à aller vérifier.

C’est intéressant. Finalement tu les laisses être en proposition de comment on pourrait faire pour vérifier les hypothèses, sans pousser de méthodes préétablies.

Oui. Et on met des warning, on leur dit “écoutez, mettez les moyens que vous êtes prêt à mettre en face, Moi je vous ai donné toutes les clés”.

Lien Discovery — Delivery

Ok, on est bien au clair sur la Discovery, l’exploration, c’est une phase sur laquelle en UX on est bien outillé. Qu’est ce que tu pourrais nous dire sur le lien entre Discovery et Delivery, toi qui a été amené à travailler sur ces deux phases?

Le lien entre la Discovery et la Delivery : il doit y avoir un trait d’union entre les 2, ça doit être “collé”, c’est continu. Parce qu’à partir du moment où on met un délai entre les 2, on perd l’élan (le “momentum” comme on dirait en agilité) et donc une partie de la valeur qu’on veut créer.

Tu as vécu ce type de situation, avec un délai entre le Discovery et le Delivery qui impacte le momentum ?

Oui et ça entraîne une perte de sens pour le UX. Parce que du coup le contexte a changé, les complexités techniques ont changé, le business a potentiellement changé, le regard du designer aussi a changé.

Un exemple avec une feature de points de fidélité chez un pure player en parapharmacie. C’était super intéressant, on a commencé à travailler des premières ébauches avec des feedbacks qu’on a eu en amont. Mais une refacto des sujets connexes était nécessaire, l’investissement était conséquent et la valeur était à long terme.

On a donc préféré mettre en place des actions plus petites, à valeur ajoutée immédiate.

On décalait le feature des points de fidélité, on décalait de nouveau, donc perte d’appétence, tu perds un peu le fil et ça fait que le sujet sort du backlog.

Coût & valeur : à quelle échéance ?

Ce que tu décris finalement, c’est cet arbitrage constant qu’on doit avoir entre l’estimation de la valeur associée à une nouvelle fonctionnalité, et son coût, sa complexité, qu’on estime également.

Je rajouterai aussi une notion de temporalité, une 3ème facette, qui touche à la stratégie de l’entreprise.Tu vas dégager telle valeur potentiellement, mais à quelle échéance en fait ?

Tout le monde n’est pas prêt à s’engager quand il y a autant d’incertitudes et une échéance éloignée.

Créer des espaces de rencontres entre parties prenantes

Est-ce que toi en tant qu’UX, c’est quelque chose que tu rencontres fréquemment, de devoir subir des arbitrages défavorables pour des fonctionnalités que tu as imaginées, dont tu es convaincu qu’elles apporteraient de la valeur à l’utilisateur final, mais pour lesquelles il y a eu une complexité ou un risque estimé trop élevé ?

Alors avant de connaître l’agilité, oui, j’avais énormément de frustration quand j’avais des arbitrages défavorables parce que j’avais encore cette utopie-là d’être l’avocat des utilisateurs.

En fait, quand tu es UX designer, tu dois traverser toutes les couches de l’organisation pour dire “vous verrez, par l’usage, l’utilisateur va apprécier le produit, l’utiliser constamment et du coup générer du revenu à plus ou moins long terme, et apporter énormément de fidélité”. Voilà, encore une fois, une valeur incertaine et lointaine.

Tout le monde doit y croire et consacrer de l’argent pour une potentielle valeur, surtout si à la fin l’expérience est extraordinaire.

Et après en mettant ma casquette business, j’ai ajouté d’autres dimensions à cela.

A ce terme d’utilisateur, j’ai rajouté les collaborateurs. En fait, les personnes dans l’entreprise sont utilisateurs de mes prestations. Il s’agit de créer une dynamique, un espace et un moment où tout le monde se rencontre, toutes les parties prenantes. Pour moi, avec l’expérience que j’ai pour l’instant, c’est la seule manière fiable pour un designer de porter la valeur jusqu’aux utilisateurs.

Ce qui est super intéressant dans ce que tu dis, c’est qu’on est dans le “faire avec” et pas le “faire contre”. On ne cherche pas à opposer la valeur pour l’utilisateur et la valeur pour l’organisation : au contraire, on cherche à ce que ce soit gagnant-gagnant, c’est ce que je comprends de ton discours.

Je suis toujours tributaire de la communication que j’ai avec les parties prenantes. Et je t’avoue qu’il m’est parfois arrivé de sacrifier des éléments que je pensais être excellent pour l’utilisateur pour privilégier ma relation avec l’équipe. Parce que c’est eux qui vont pouvoir permettre de fabriquer cet élément en fait. Il vaut mieux un bon produit qui sort qu’un excellent produit qui ne sort pas.

Pensée systémique, design par la contrainte et “just in time”

On fait le lien avec le Delivery : le but final c’est d’amener cette valeur jusqu’à l’utilisateur final, et pour lui amener, il faut effectivement que le produit sorte.

Du coup quelles approches tu mets en œuvre pour comprendre les besoins de ces parties prenantes ?

Je ne mets pas de formalisme car j’ai toujours travaillé dans des petites structures, et le formalisme pourrait tuer la confiance.

L’idée c’est de venir à la pause café, entretenir des liens étroits et discuter de sujets anodins. A chaque échange, je vais avoir cette posture “je dois livrer de la valeur à l’utilisateur”.

Si on rapproche ça avec des méthodes UX, c’est de l’interview, du tri de cartes, du brainstorming sous toutes ses formes, appuyés par des whiteboards.

On fait pas mal de scénarios, vu que c’est assez tangible et que ça marche bien. Je travaille aussi pas mal avec des outils comme les system map, les blueprint.

C’est une pensée un peu systémique en fait : je pars tout le temps du système, je ne pars presque jamais de l’utilisateur. Ou alors je récupère des petits inputs comme ça, discrètement. Mais j’ai plus une approche systémique et produit en fait. Vraiment. C’est ma définition de Product Designer. Je pars du produit, la manière dont il est construit. Qu’est ce qui se passe si on ajoute ça, ou modifie ça ? En fait, j’ai dans la balance l’utilisateur d’un côté, et comment est ce qu’on intègre ça dans le produit de l’autre côté.

Et ça m’éclate parce que le design par la contrainte, c’est de l’excellent design. Tu as énormément de contraintes et tu vas venir mettre cette petite brique, qui est faisable pour le cycle à venir, et cette petite brique va s’implémenter parfaitement dans le produit et rajouter la valeur attendue.

Je raccroche les wagons avec le Shape Up et le Lean. Donc ta grosse feature des points de fidélité qui prend quatre cycles, tu vas la dégraisser jusqu’à pouvoir la faire entrer dans un seul cycle. Et on s’arrête là.

En fait, j’ai appris que c’était ça la clé, c’est le just in time (juste à temps) plutôt que le just in case (au cas où).

Être designer sans dessiner

Et de quelle manière tu es embarqué dans le Delivery ?

J’ai appris à être designer sans dessiner. Je suis un designer qui fait des maquettes hautes fidélités, du design system. Et j’ai aussi appris à être “designer” sans tout ça, à appliquer cette posture à travers un Jira Product Discovery ou un tableau blanc Miro.

Chez Easypara, j’avais une casquette de PO avec l’objectif de faire matcher tous les acceptance criteria. Et après, en tant qu’UX, je venais corriger les détails et faire du “no spec”, c’est-à-dire que je vais voir le développeur qui a une problématique dans son sprint, qui est bloqué, qui n’arrive pas à faire cette user story, et justement on adapte.

Travailler en côte à côte

En côte à côte, au plus près des devs.

Oui, c’est essentiel.

C’est parfois difficile si on n’a pas forcément cette culture, alors qu’en fait la communication c’est la clé.

Du coup, on était côte à côte avec les devs, et je variais le “no spec” , avec un petit schéma sur MIRO et des fois un petit bout de maquette sur FIGMA.

Ce qui est marrant c’est que ma pratique de designer a évolué : j’ai arrêté de faire des pages complètes avec “état A”, “état B”… Maintenant j’ai plein de petits bouts à droite à gauche. Mon design system est intact, mais à côté c’est pleins de composants, des petits bouts qui se baladent, et ensuite c’est embarqué, puisque ce qui compte, c’est ce qui est livré.

Co-concevoir en équipe et créer la confiance

Tu aurais d’autres critères clés de succès à partager du coup pour arriver à délivrer la valeur à l’utilisateur final ?

Le Product Owner, c’est un maximisateur de valeur. Le Product Designer, c’est celui qui va concevoir et proposer cette valeur. Ensuite c’est toute l’équipe qui la construit.

Donc le point clé, c’est de communiquer, de créer des espaces de confiance et de co-conception avec les équipes.

L’investigation est à faire en amont et tout au long de la vie du produit. Et ça, c’est des inputs permanents qui viennent de multiples sources.

Et ensuite c’est créer ces moments-là. C’est essentiel parce que s’il n’y a pas de confiance, pour moi, il n’y a pas de valeur livrée.

Si tu avais un souhait pour nos métiers de l’UX et de l’agilité, que serait-il ?

Que la structure de l’organisation permette et favorise l’expérimentation.

On a trop de boîtes qui font de la Delivery, encore de la Delivery.

Et ces micro-items qui sont découverts pendant la recherche, c’est une toute petite poignée. L’idée ce serait de pouvoir essayer de ratisser un peu plus large et d’ouvrir les horizons. Ne pas avoir d’œillères quoi, parce qu’on a des œillères.

Un mot pour la fin ?

Vive l’UX, vive le Design et vive la liberté !

Merci beaucoup à Romain Delgrange pour nos échanges.

Tip : Romain Delgrange utilise des projets Jira Product Discovery, adaptés pour servir de Atomic Research Database, afin de catégoriser les insights utilisateurs et les lier avec les user stories, dans une logique de “continuous discovery and delivery”.

En savoir sur l’Atomic UX Research (article Medium) : https://blog.prototypr.io/what-is-atomic-research-e5d9fbc1285c

En savoir plus sur Romain Delgrange : site internet Rhom Design / profil LinkedIn

Pour aller plus loin sur le sujet : prendre RDV pour échanger avec Romain (Chabbal) : https://calendly.com/romain-chabbal-uxshadow/ameliorer-ux