5 faux prétextes pour ne pas faire de User Research

Marine Antunes Dias
Demain sera bien. Par Haigo.
6 min readSep 28, 2017

Être user centric ne s’improvise pas et n’est pas un effet de mode éphémère. C’est ce qu’on vous expliquait déjà dans cet article sur la User Research.

Rappel définition : la User Research

Fait de récolter et d’analyser des données qualitatives et quantitatives auprès des utilisateurs afin de garantir que le développement d’un produit, ou plus généralement d’un projet, se fasse en faisant converger les enjeux business et les besoins des utilisateurs réels.

Faire de l’UX sans User Research, c’est comme faire de l’astrophysique sans donnée corroborée par l’observation.

Mais force est de constater que malgré un nombre croissant d’articles et de cas concrets réussis en entreprise*, les acteurs français restent encore frileux et très en reste sur la mise en place de cette démarche.

Si on vous demande de bosser sur un projet de…

  • Refonte d’un écosystème — Tiens Lucien, il faudrait refaire cet espace client en ligne !”
  • Création d’un nouveau produit — Dites donc Ninon, il faudrait lancer une nouvelle offre de service à destination des 18–25 ans”
  • Ou de transformation organisationnelle — Alors Hector, on a eu une mauvaise perf’, le service et l’expérience collaborateur doivent évoluer”

… Et que vous ne savez pas par quel bout le prendre, on vous comprend, et on pense à vous.

La bonne nouvelle ? C’est exactement le genre de situations dans lesquelles une User Research peut vous apporter des réponses.

Alors voici ce qu’il faut dire à votre boss quand il vous dira que…

1. “Faire une User Research, ça coûte trop cher”

Pourquoi ce n’est pas un bon argument

Oui, faire une première phase de recherche avec de VRAIS utilisateurs, pour qu’ils parlent de leurs VRAIS problèmes, ça a un coût.

Néanmoins, cela coûtera moins cher que d’investir dans une fonctionnalité qui ne servira à rien ou dans une refonte qui ne fera que déplacer des problèmes, ou en créer de nouveaux.

Pour éviter de mener des projets inutiles, qu’il faudra bientôt refaire ou faire pivoter en cours de route, comprendre les usages et les attentes de nos utilisateurs finaux est une option sûre (et rentable).

Le cas concret

Lors d’une User Research avec des personnes souffrant de handicaps portant sur leur parcours dans les transports en commun, nous nous sommes rendus compte que beaucoup d’entre elles n’utilisaient pas leur smartphone en déplacement — souvent à cause d’un sentiment de vulnérabilité.

Grâce à la User Research, nous avons ainsi évité à notre client de développer une application mobile coûteuse… pour rien.

2. “On n’a pas de temps à perdre avec des entretiens utilisateurs”

Pourquoi ce n’est pas un bon argument

Premièrement, une phase de recherche auprès des utilisateurs peut se conclure très rapidement, tout dépend du scope de l’étude — et de la bonne définition du scope. Par exemple, il nous faut environ 2 à 3 semaines pour donner les orientations de la refonte d’un dispositif digital interne d’une entreprise de +250 personnes, répartie sur 3 continents.

On peut faire de la User Research et être Lean.

Ensuite, c’est un temps gagné sur les éventuels pivots ou projets qui n’aboutissent pas, faute de vrais problèmes à résoudre (cf 1.).

En phase de développement, cela permet de prioriser sur des bases rationnels un backlog, de s’éviter la fonctionnalité de trop non plébicité par les utilisateurs, et de trancher rapidement des conflits en cas de divergence de vue dans la meilleure façon de donner corps à une fonctionnalité.

Le cas concret

Lorsque nos PO (Product Owners) s’interrogent sur le développement de telle et telle fonctionnalité, lorsque que les équipes de développement et les designers sont en désaccord, le moyen le plus rapide et le plus efficace pour trancher et prendre une décision est de descendre à la cantine un midi avec un protocole de test rapide à mettre en place et deux prototypes.

A la fin du repas, l’une des deux options est validée, l’autre éliminée.

On a dit LEAN.

Grâce à la User Research, nous pouvons faire rapidement et pacifiquement des choix du quotidien.

3. “Je ne vois pas la valeur ajoutée, à la fin, ce n’est qu’une étude”

Pourquoi ce n’est pas un bon argument

A la fin d’une User Research, qui constitue la première brique d’un projet centré utilisateur on sait ce qui ne va pas, où sont les vrais problèmes, comment ils sont liés les uns aux autres, quel outil ou service les cristallisent et comment les utilisateurs de notre futur produit/service traitent actuellement le problème que l’on veut résoudre. Nous créons généralement des “parcours utilisateurs” clefs pour replacer les problèmes documenter sur le terrain et nous utilisons très souvent les personae pour humaniser ces parcours. Enfin, la User Research nous donne les axes autour desquels construire la vision produit.

Alors oui, dans l’absolu, il n’y a pas de fichier sketch, pas de design d’interface, pas de ligne de code dans GitHub.

Mais il y a néanmoins l’essentiel.

Ce qui va vous permettre de définir vos fonctionnalités, déterminer vos types de contenus, dessiner vos écrans et préparer votre premier sprint de développement.

En plus d’être facilement activable, une User Research fournit la matière première de l’opérationnel, pour construire un projet cohérent et intelligent.

Une User Research, c’est un outil de :

  • Management d’équipe : pour communiquer une vision et la faire cascader.
  • Orientation de roadmap : pour se concentrer produit sur les familles d’utilisateurs stratégiques.
  • Priorisation de backlog : pour traiter les tickets les plus douloureux en premier.

Bien utilisée, c’est également un outil de communication, d’implication des équipes et de change management redoutable.

Le cas concret

Après avoir conduit une User Research, plusieurs collaborateurs sont venus nous voir pour savoir où en était le projet, continuer de nous donner des feedbacks et nous proposer leur aide pour de futurs ateliers ou tests d’implémentation. En quelques semaines, nous avons créé tellement d’engouement que nous avons rassemblé une communauté de 300 ambassadeurs pour le projet.

Sans la User Research, la communication et l’adoption du projet aurait été plus longue et plus compliquée.

4. “Mais enfin, on les connaît déjà nos clients/nos collaborateurs”

Pourquoi ce n’est pas un bon argument

Non.

Ce n’est pas vrai.

Enfin, si peut être un peu. Mais il y a aussi tout ce que vos clients ne disent pas, il y a les habitudes de contournement que certains collaborateurs ont pu développer à force d’utiliser un service non optimisé… Sans compter sur l’évolution permanente des usages de chacun dans le temps ! Tout le monde n’a pas le même rapport à un produit ou à un service en fonction de sa maturité à utiliser telle ou telle technologie, son intérêt à le faire, le moment ou il l’utilise,….

En plus, vos collègues vous mentent. Ou ils ont peur de vous dire la vérité. Et pas forcément par malveillance, souvent pour vous faire plaisir ou vous éviter de porter une information désagréable.

Développer votre empathie envers vos clients/collaborateurs ne consiste pas à se mettre à leur place. Il s’agit plutôt d’être à leur écoute et capable de comprendre leur point de vue en les observant.

N’imaginez pas, fondez vos décisions sur des feedbacks pertinents et des observations concrètes.

Le cas concret

Pour répondre à de forts besoins de sécurité, un de nos clients avaient mis à disposition de ses collaborateurs tout un tas de dispositifs très sophistiqués pour protéger leurs échanges d’information. Ainsi, en dehors des échanges officiels, une grande partie d’entre eux avait développé des pratiques de contournement de ces dispositifs pour échanger plus facilement,… rendant l’ensemble des dispositifs de sécurité caduque.

Sans la User Research, nous n’aurions pas eu connaissance de ces pratiques de contournements, nous n’aurions donc pas pu rectifier le tir.

5. “Ce n’est pas à nos clients de nous dire comment faire notre travail, ce ne sont pas des pros”

Pourquoi ce n’est pas un bon argument

En effet, ce ne sont pas des pros.

C’est pour ça qu’il faut leur demander s’ils comprennent bien le fonctionnement du service que vous leur proposez ou de la fonctionnalité que vous leur poussez.

Parce qu’au fond, à la fin, pro ou pas, c’est eux qui jugeront de l’utilité de votre produit.

Bien souvent, ce sont vos utilisateurs qui savent le mieux ce dont ils ont besoin, et ont donc les meilleurs tips pour améliorer votre produit ou votre service.

Le cas concret

Après le développement de son site, un de nos clients, qui avait omis de consulter ses commerciaux, s’est aperçu que le taux de conversion était très bas. Après une rapide étude auprès de ces derniers, nous nous sommes rapidement rendus compte que bon nombre des arguments principaux qu’ils utilisaient pour mettre en valeur les produits sur leurs plaquettes de présentation (!) n’avait pas été repris.

De plus, la façon dont ils faisaient leur démonstration ont donné des idées de fonctionnalités supplémentaires, décisives pour la V2 du site.

Sans la User Research, nous n’aurions jamais eu les inputs précieux des commerciaux pour l’élaboration des fonctionnalités de la V2 du site.

Si on vous donne d’autres contre-arguments ou que vous avez d’autres façon de convaincre votre boss, je suis curieuse d’en savoir plus : n’hésitez pas à nous en faire part.

* Pour plus d’info sur les “use cases” réussis de projets user centric/design thinking, vous pouvez regarder un premier aperçu de nos réalisations sur haigo.fr ou m’envoyer un mail à marine@haigo.fr .

--

--