J’aime les gens qui doutent… de l’intégration des utilisateurs dans les projets.

Vous êtes à la tête d’un nouveau produit et souhaitez mener une démarche centrée utilisateur (User Centric comme on dit aux States).
Quoi de mieux, même, que d’avoir des utilisateurs sur le projet venus apporter leur expertise métier au plus près de la construction et ainsi itérer extrêmement rapidement sur le design du logiciel. Que la personne soit utilisatrice ou cliente, l’important est de l’intégrer pour bénéficier de ses lumières et en faire un ambassadeur, une ambassadrice.

Mais je vous le dis, vos utilisateurs n’ont rien à faire dans l’équipe de conception.

Les avantages (quand même)

Avoir, sur son projet, des utilisateurs ou des représentants représentatifs – oui, mieux vaut s’assurer qu’ils et elles le sont bien – amène un bon gros paquet d’avantages :

• Une voix métier terrain au plus près de la construction du produit pour s’assurer de parfaitement comprendre les enjeux du terrain et les usagers
• Une capacité de co-design évitant d’être hors sol car pensé en chambre
• Un rôle majeur dans l’accompagnement au changement et l’adhésion au produit car le produit est estampillé “créé par les utilisateurs pour les utilisateurs ”

Mais…

Il y a quelques années, un projet que j’accompagnais a vu apparaître une crise.
Une démotivation grandissante de l’équipe opérationnelle – Dev, PO, UX – du fait de se sentir simples exécutants. Une perte d’espace de décision, de créativité et donc d’engagement dans le produit.

Ce projet avait, en son cœur, un groupe d’utilisateurs clefs présents dans toutes les instances opérationnelles pour co-cadrer les sujets avec la Product Owner, suivre l’avancement et répondre aux questions en direct, tester les sujets et mener des présentations auprès de leurs collègues utilisateurs.

Le souci était que ces utilisateurs clefs avaient une très belle capacité à proposer des idées de design, donner rapidement du feedback sur les maquettes et finalement verrouiller des décisions fonctionnelles avant même d’avoir eu un échange avec les développeurs et développeuses.

Ce n’était en rien une démarche dictatoriale, une posture de client roi, rien de cela. Juste la mise en place progressive d’un cadre de fonctionnement à la dérive avec des personnes pleines de bonnes intentions.

Au final, des développeurs frustrés, une Product Owner dépassée et sous tutelle, des UXs qui tentent de suivre et des tensions progressives, des ressentiments, des doigts accusateurs.

Que s’était-il passé ?

Étude d’une dynamique

Les différentes zones de design

Dans le design produit, il existe plusieurs zones qui permettent de passer d’un problème à un livrable.

Zone du problème ou zone de friction

Ce qui est, ce qui manque, ce qui ne va pas, ce qu’il faudrait améliorer.

Travailler la zone du problème permet de s’assurer une parfaite compréhension du contexte, de son fonctionnement et mesurer l’ampleur d’un manque, d’une difficulté, des frictions qui viennent ralentir la capacité de l’utilisateur final d’atteindre son objectif.

Exemples :

• La recherche dans ma base client est trop lente
• Envoyer un document contractuel me demande beaucoup d’actions différentes
• Je suis incapable d’ajouter certains détails sur mes produits pour les rendre plus attractifs

Zone du besoin

C’est la traduction du problème, du manque, en défi. Face à ce manque, quel est le besoin ?

Exemples :

• La recherche dans la base est trop lente
  • Trouver très simplement mes clients
• Envoyer un document contractuel me demande beaucoup d’effort
  • Envoyer un document sans effort
• Je suis incapable d’ajouter des détails sur mes produits
  • Rendre les produits plus attractifs

Attention, la zone du besoin est piégeuse car elle se mélange souvent (voir systématiquement) en zone de solution fonctionnelle voir fonctionnelle.

Zone de solution fonctionnelle ou technico-fonctionnelle

Ce que nous devons construire, la proposition de service ou les fonctionnalités.

Cette zone est la plus facile à comprendre, elle consiste à imaginer des écrans, des formulaires, des tableaux, des graphiques…

Exemples :

• Trouver très simplement des clients
  • Mettre en place une recherche assistée, mémoriser mes critères de recherche
• Envoyer un document sans effort
  • Lier un envoi de document automatisé avec des états du client

Zone de solution technique

Ce que nous devons coder. C’est l’espace de l’équipe de développement qui étudie la bonne architecture, la bonne conception technique pour soutenir la solution fonctionnelle.

Je ne m’égarerai pas à donner des exemples de solutions techniques sous peine de passer soit pour un has been ou un moldu.

Attirance pour la zone de solution

Nous autres, êtres humains, apprécions de faire travailler notre cerveau pour imaginer des solutions. Dynamique créative, plaisir d’ingénier, brainstormer en collectif… quel bonheur.

De fait, comme n’importe quel être humain, l’utilisateur que nous avons intégré à l’opérationnel a aussi très envie de participer à l’effort créatif et va avoir tendance à aller dans la zone de solution fonctionnelle. Dis comme ça, cela peut paraître intéressant car qui de mieux que l’utilisateur pour savoir ce qu’il aimerait utiliser.

Sauf qu’il y a un bémol, si l’utilisateur est compétent dans son domaine métier, l’est-il dans le domaine du software design, de la conception logiciel ? Pas sûr.

Une aura d’expert, en dehors de sa zone d’expertise

L’utilisateur que nous avons intégré au plus près de “là où ça se passe” pour bénéficier de son expertise, a entendu comme message : “Aide-nous à construire le logiciel avec tes bonnes idées” ou “Aide nous à imaginer des fonctionnalités”.

Sauf que cela, c’est le travail des PMs, des POs, des UX Designer… de personnes qui ont une compétence particulière en construction de produits numériques, capables de comprendre les problèmes, en identifier des problématiques, poser des solutions innovantes (nouvelles) pour trouver des finalités à la croisée de la réponse au besoin et la faisabilité technique.

Et ça, l’utilisateur ne l’a pas, même le meilleur. Il connaît bien son contexte, il connaît bien ses problèmes, il connaît bien les règles qui régissent son métier et qui peuvent être traduites en règles de gestion.

Mais il peut avoir des difficultés à imaginer des usages nouveaux, hors de ses usages habituels, à trouver des solutions techniquement faisables et accepter de faire autrement. Car parfois, il est impossible de faire techniquement pareil. Ou dans le cadre d’une refonte  à dépasser l’utilisation des outils historiques (“Nous sommes habitués à faire comme ça”).

Mais comme cet utilisateur est pertinent grâce à sa connaissance du terrain – plus que le PM et le PO, sinon il ne serait pas là – sa parole devient prépondérante. Et dans l’opérationnel, elle devient prépondérante sur les solutions. Jusqu’à écraser les idées, les propositions du reste de l’équipe opérationnelle.

Mais quelle est la valeur de cette parole ? En écrasant celle des autres, qu’est-ce qu’elle empêche ?

Qu’une chose soit claire, le problème n’est pas dans la personne qui propose, mais dans la dynamique (ou le contexte) générale, dans le système qui lui accorde une attention au-delà de son rôle. Elle n’a pas forcément envie d’écraser, elle souhaite simplement apporter ce qu’il y a de plus pertinent aux autres utilisateurs dont elle connaît si bien le contexte. Par envie de bien faire.

Du User un peu trop Centric

Depuis plusieurs années, ce terme de User Centric ou de démarches Centrées Utilisateur est devenu omniprésent. Comme je le disais en introduction : pour de très très bonnes raisons.

Mais il y a eu une confusion : mélanger l’espace problème et l’espace solution. Avoir demandé aux utilisateurs ce qu’ils voulaient, d’avoir écouté et pris pour argent comptant leurs demandes car qui de mieux que l’utilisateur pour savoir ce qu’il veut… et bien, sûrement pas lui.

La parole d’un utilisateur concepteur est emplit de biais :

• L’utilisateur n’a pas les clefs du design logiciel et imagine des solutions à partir des outils qu’il utilise déjà (“Si j’avais demandé aux gens ce qu’ils veulent, ils m’auraient demandé des chevaux plus rapides” H. Ford)
• L’utilisateur clef est investi d’une mission, créer l’outil idéal. Il peut avoir tendance au tout ou rien, tant que nous n’aurons pas la fonctionnalité finie, les utilisateurs ne voudront pas l’utiliser (alors que bien souvent, les utilisateurs finaux acceptent des solutions dégradées temporairement)
• L’utilisateur clef, dans la dérive de l’utilisateur représentant, peut projeter son expérience personnelle comme étant l’expérience de tous les autres utilisateurs
• L’utilisateur clef  dès lors qu’il bascule du côté conception n’a plus le regard vierge de l’utilisateur final. Ce que comprend l’utilisateur clef peut ne pas être compris de l’utilisateur final.

Dès lors deux options s’offrent à nous :

1. Garder l’utilisateur clef à distance du projet, le voir comme un client qui valide le produit
   Cela amène évidemment le risque historique d’un décalage entre le produit et le besoin réel, le produit et l’expérience utilisateur, le produit et ses utilisateurs finalement.
2. Cadrer en amont et en profondeur la manière dont nous souhaitons intégrer ces utilisateurs clefs.

Et pour le bien de vos projets, nous opterons pour la seconde solution.

5 clefs pour bien intégrer les utilisateurs clefs sur les projets

1 – Replacer l’utilisateur dans la zone de problème et potentiellement de problématique

Poser en amont les attendus de la part de l’utilisateur. Nous souhaitons qu’il s’exprime sur son métier, sur les difficultés vécues, sur ce qu’il aimerait faire mieux.

Son discours doit rester agnostique par rapport à un outil. Il doit éviter le champ lexical du design logiciel. L’utilisateur n’a besoin ni d’écran, ni de tableau filtré, de champs dans un formulaire, de popup ou de login. Il a besoin de retrouver ses informations, de mieux visualiser ses clients, de pouvoir calculer des montants… le vocabulaire métier.

Le reste est du ressort des PMs, POs, des UX, de Business Analysts venus du monde du logiciel.

2 – Valoriser sa connaissance dans un rôle de Business Owner ou expert métier

La connaissance des utilisateurs sur leur propre métier est un trésor qu’aucun acteur projet en chambre ne saurait inventer. Pour bénéficier de cette matière sans risquer la dérive, avoir un utilisateur en Business Owner permet de passer le message “ta connaissance nous est fondamentale et ton rôle sera toujours de nous ramener aux enjeux business”.

Le positionner en expert métier nous permettra de venir le questionner sur son domaine et de prendre ses réponses comme des sources de réflexion et pas des propositions de design.

3 – Créer une vrai culture du questionnement

Pour sécuriser la distanciation entre le projet et les utilisateurs clefs, il est nécessaire de créer une réelle culture du questionnement notamment auprès des acteurs et actrices du design produit mais aussi de l’équipe de développement.

Un des risques principaux sur les projets est de descendre trop rapidement dans la zone de solution fonctionnelle. Comme je le disais au début de cet article, le cerveau adore imaginer des solutions. A partir du moment où la totalité des interlocuteurs a basculé dans la zone de solution, il est extrêmement difficile de remonter dans les strates supérieures et ainsi avoir un design adapté.

Créer une culture du questionnement permet qu’il n’y ait pas de design en chambre et que les solutions imaginées le soient en conscience du contexte et de ses enjeux.

Utiliser des pratiques de questionnement, déplacement sur le terrain, “vis ma vie” (suivre des utilisateurs dans leur quotidien pour s’imprégner de leurs difficultés et plaisirs)

4 – Mettre en place des boucles de feedback rapide

Si l’intégration profonde des utilisateurs dans l’opérationnel comporte des risques, l’inverse également. L’éloignement des utilisateurs clefs par rapport aux solutions va créé un effet tunnel pendant la durée de la production du logiciel et au moment du lancement du produit, il y a un risque que celui-ci soit hors sujet. Risque encore plus fort si le développement est long.

Pour éviter cela, mettez en place des boucles de feedback rapide pour vérifier rapidement vos hypothèses fonctionnelles, les confronter. De cette manière vous permettrez aux utilisateurs de rester des utilisateurs, avec leur regard extérieur, prêt à challenger vos propositions et vous pourrez récolter de l’information en temps réel pour faire évoluer votre produit.

5 – Mettre en place un dispositif de change management

Une des difficultés sur les projets est de réussir à fédérer des collectifs d’utilisateurs pour valider les hypothèses ou mieux comprendre leur contexte.

Avoir une stratégie de change management qui s’appuie sur l’utilisateur clef du projet permet de fédérer les bonnes personnes afin de :

• récolter des besoins diversifiés (attention : “besoins” et pas “demandes”)
• identifier les freins et accélérateurs à l’utilisation
• Mener des tests utilisateur

En conclusion

Pour réussir à intégrer efficacement les utilisateurs clés dans vos projets, il est essentiel de les recentrer sur leur expertise métier et de les éloigner de la conception des solutions.

Leur rôle est précieux pour identifier les problèmes et orienter les décisions, mais ce sont les PMs, POs, et designers qui doivent imaginer les solutions adaptées.

En créant une culture du questionnement sur le projet, en mettant en place des boucles de feedback rapide et en cadrant l’implication des utilisateurs, vous éviterez les dérives tout en tirant le meilleur parti de leur savoir.