Comment éviter le “User Washing” ?

Incipit : Les méthodologies issues du design font un tabac dans les départements innovation et transformation des grands groupes ainsi que dans un nombre croissants de PME (n’en déplaise). Néanmoins, leurs applications rencontrent plus ou moins de succès, notamment lorsqu’il convient d’impliquer les futurs utilisateurs en amont des projets. Cet article en propose une analyse issue de la pratique de la user research en agence, donc au plus près d’un large spectre d’acteurs corporate.

En novembre dernier, un article de Libération intitulé Pôle emploi : méthodes agiles, agences fragiles attire mon attention. Les journalistes donnent la parole à plusieurs syndicalistes qui décrient d’un seul bloc “agilité”, “design thinking” et “atelier de créativité” : infantilisant, amenant les salariés à élaborer des solutions allant contre leur propre intérêt, pratiques d’entreprises faussement libérées, véritable mascarade…

Je ne suis pas en mesure d’évaluer la pertinence des propos tenus par les personnes citées dans l’article, n’ayant pas eu l’occasion de travailler avec Pôle Emploi. Ce que je comprends néanmoins est que ce qui est reproché à ces méthodes (à tort ou à raison) est d’impliquer des salariées dans la construction de solutions qui : a) ne leur seraient pas profitables, b) ne seraient jamais appliquées/applicables. En tant que user researcher je m’interroge : dès lors que des utilisateurs (ici les agents de Pôle Emploi) sont impliqués dans la conception des outils ou des services qu’ils utiliseront demain, comment s’assurer de la pertinence des solutions qui sortiront de ce processus pour eux ? Plus largement, comment développer des solutions qui sont réellement centrée utilisateur ?

“User centric” = “User washing” ?

Passer ses utilisateurs à la machine…

Il ne suffit pas en effet de saupoudrer un peu d’utilisateur par ci, un peu d’utilisateur par là pour que — miracle — notre projet réponde à de vrais besoins, résolve réellement les problèmes des utilisateurs. Entre “User centric” and “User washing”, il semble n’y avoir qu’un pas.

Ce que je vous propose de désigner sous le terme User Washing recouvre à mon sens deux types de situations que je crois déjà bien réelles.

La première, c’est lorsque le top management d’une entreprise décide d’impliquer des utilisateurs (qui peuvent être ses propres salariés dans le cas de conception de services/organisations internes) afin de post-rationaliser et légitimer des décisions prises unilatéralement et en amont. Une phrase entendue dans ce genre de cas est : “ne leur donnez pas trop d’espoir” — comme si faire une étude utilisateur revenait à tenir un cahier de doléances ! Je crois cette phrase tout à fait symptomatique d’une asymétrie entre la volonté d’impliquer des utilisateurs et la capacité du top management à changer la façon dont il prend des décisions — à savoir : à tenir compte non pas seulement des enjeux business, mais également des enjeux utilisateurs. Conduire un projet centré utilisateur c’est avant tout, et cela peut paraître contre-intuitif, insuffler un changement au sein du management d’une entreprise.

La deuxième, plus répandue, c’est lorsqu’une étude utilisateur ou des tests sont conduits, des utilisateurs invités à co-construire des solutions… mais la façon dont les retours sont récoltés ou dont les utilisateurs sont impliqués manque de méthode (si ce n’est de rigueur), rendant l’opération caduque. Cela tient souvent à de petites choses toutes bêtes (mais nombreuses) : bien se poser la question des profils pertinents à rencontrer, adopter une méthode de retraitement des insights collectés rigoureuse et “traçable”… — je ne ferai pas la liste ici de tout ce qu’il faut faire pour qu’une étude fonctionne bien, il existe pléthore d’articles sur ce qu’est la user research et comment bien la faire (un débutant pourrait fouiller là, ici, à cet endroit, ou encore par là). Conduire une user research n’est pas inaccessible mais requiert néanmoins de la technique, de la rigueur, un esprit analytique et pas mal de pratique (pour commencer, la technique du shadowing est particulièrement appropriée).

Good research > …

… Nuit gravement à la création de valeur

Impliquer des utilisateurs dans le processus de développement de nouveaux produits ou services n’est pas neutre : c’est une exposition. Ignorer la voix des utilisateurs, changer de cap ou abandonner un projet sans explication s’avère d’autant plus problématique que ces derniers ont investit leur temps et leur attention dans le projet.

De telles situations sont à proscrire :

• Elles s’accompagnent d’une défiance de la part des utilisateurs — là ou ces méthodes sont sensées apporter de la confiance.
• Elles ne limitent en rien le risque de produire des solutions non pertinentes et des utilisateurs mécontents — là ou les besoins utilisateurs sont sensés être couverts grâce à une récolte d’insights régulière et qualitative.
• Elles font perdre 2X plus de temps et d’argent : impliquer des utilisateurs prend du temps et de l’énergie, réparer/changer/abandonner le fruit de leur mauvaise collaboration également — là ou elles devraient accélérer le développement de produits/services en les rendant plus pertinents plus vite.

“User centric” = éthique ?

Bien sur, on se trouve rarement dans une situation aussi manichéenne. Par exemple, ce n’est pas parce qu’un projet vient du top management qu’il est nécessairement “mauvais” — et heureusement, car c’est encore souvent le cas. Cela pose tout de même une question : Peut-on tout co-concevoir ? N’est-ce pas problématique d’inclure des “utilisateurs” dans le processus de conception d’une solution qui ne vise pas à répondre à un de leur besoin ? Voire qui y contrevient ?

Par exemple, peut-on co-concevoir un plan de licenciement avec les collaborateurs ? Ce qui est une démarche bienveillante et commune de création s’apparente alors rapidement à une approche un peu tordue (pour ne pas dire perverse) opérant un transfert de responsabilité de décisions difficiles du top management vers les collaborateurs — à leurs dépends.

Une démarche centré utilisateur doit avoir sa propre éthique. Cette éthique impose par exemple que les utilisateurs participent à construire des solutions qui répondent réellement à leur besoin.

5 questions à se poser pour un projet vraiment centré utilisateur

Voici 5 piliers sur lesquels s’appuyer pour un projet centré utilisateur. 5 questions à se poser avant, pendant ou après — pour faire le bilan et ne plus jamais recommencer — un projet qui vous semble se présenter de façon peu honnête.

✅ Contexte : D’où vient le projet ?

Un projet doit répondre à un besoin utilisateurs aussi, pas uniquement à des enjeux business. Pour les identifier vous pouvez vous appuyer sur plusieurs éléments : le résultat d’une recherche utilisateur (bien sûr), mais aussi des analytics qui rendent compte de l’usage d’un site ou un logiciel, ou encore des retours qualitatifs récoltés par les sales ou le support. (à chaque produit son étude, pour vous aider à faire un choix de méthode Nielsen Norman Group est comme toujours très utile…).

✅ Qualité : Comment je garantis une collecte de retours utilisateurs pertinents et non-biaisés ?

Pour cela il existe plusieurs méthodes, dont le choix va dépendre du contexte. De nombreux articles (souvent en anglais, j’en conviens) de user researchers ou ux designers partagent retours d’expériences et astuces. Le plus complet (déjà mentionné dans un précédent article) est l’article de Buster Benson : ici.

✅ Traçabilité : D’ou viennent les feedbacks utilisateurs que j’ai récolté ?

Il est important de savoir d’ou vient une info, tout d’abord parce qu’une info hors contexte perd sa pertinence — savoir qui a dit quoi est capital pour imaginer une solution adaptée à chacun. C’est également clef car cela permet d’être transparent vis-à-vis du reste de votre équipe (tout en conservant néanmoins l’anonymat de vos utilisateurs !) avec le double avantage de vous contraindre à adopter une démarche explicable et de les embarquer / convaincre plus facilement.

✅ Priorisation : Selon quels critères sont prises les décisions relatives au développement produit ?

Centré utilisateur, ça ne s’arrête pas à la récolte de feedbacks. C’est aussi réussir à transformer ces retours concrètement pour dessiner la bonne solution. Il convient de porter la voix de l’utilisateur jusque dans les choix qui vont orienter le développement — au même titre que celle du business. Au moment de prioriser telle ou telle fonctionnalité ou service, demandez-vous : dans quelle mesure cela crée-t-il de la valeur pour mes utilisateurs ?

✅ Robustesse : Dans quelle mesure ai-je un produit qui répond à de vrais besoins et respectueux de mes utilisateurs ?

Une “bonne” solution est une solution qui fonctionne, qui améliore sensiblement l’expérience de ses utilisateurs tout en répondant aux objectifs fixé par le business. Pour mesurer cela, dans un premier temps il y a les tests, dans un second temps il y a le suivi de KPIs mesurables (notamment pour objectiver les choix réalisés par l’équipe de conception de manière significative). Mais il n’y a pas que cela. La performance mise à part, il convient de se demander : dans quelle mesure répond-on correctement au besoin ? Sans aller jusqu’au “dark pattern”, répondre à un besoin utilisateur tout en cherchant à faire faire à l’utilisateur ce qu’il ne veut pas faire ne convient pas à une approche “centrée utilisateur”.

De la à dire qu’une démarche centrée utilisateur est éthique, il n’y a qu’un pas…