Qu’est-ce qui va pousser René, porteur d’un pacemaker, à télécharger une application mobile de télésurveillance cardiaque ? Ou Paul, médecin de la douleur, à prescrire à ses patients un suivi dans la durée via une montre connectée ? C’est à ces questions que les interviews utilisateurs, et, plus largement, la recherche utilisateur, tentent d’apporter des réponses.
La recherche utilisateur (ou User/UX research) consiste à collecter des données quantitatives et qualitatives afin de cerner et comprendre les besoins des utilisateurs. Elle fournit aux Product Managers le carburant pour concevoir des produits que les utilisateurs vont (vraiment) utiliser.
Dans cet article, nous allons proposer une méthode pour réussir vos interviews utilisateurs.
🏥 Et la recherche utilisateur en e-santé ?
Chez Hokla, on développe des produits en e-santé. La particularité de ce type de produit est qu’il est très réglementé. Pour être commercialisé, il doit obtenir le marquage CE dans l’Union Européenne et le FDA approval aux Etats-Unis, attestant qu’il satisfait des exigences de sécurité et de performance. Or, cette phase s’anticipe dès la conception du produit avec la rédaction d’un dossier technique, qui rassemble (entre autres) les User Requirements Specifications (URS) qui spécifient les besoins des utilisateurs du logiciel. La recherche utilisateur est donc une étape indispensable pour obtenir le marquage CE en vue d'une mise sur le marché et d'un éventuel accès au remboursement.
Les 3 biais à éviter en interview utilisateur
Réaliser une interview utilisateur est une action délicate qui s’apparente à un travail d'excavation archéologique : un mouvement brusque et tout s’effondre. Si on s’y prend mal, on risque de biaiser la qualité des réponses et tous les choix de conception qui s’en suivront.
Pour commencer, comment ne PAS s’y prendre ?
1. Le biais de confirmation
Imaginons : tu as recruté un patient que tu ne connais pas et qui correspond parfaitement à la persona du produit. Tu es avec lui dans son environnement quotidien. Tout commence bien jusqu’à ce que là, d’un coup, tu lui demandes “et toi t’aimerais bien suivre ta glycémie sur ton portable ?”.
Patatra. En posant cette question, tu ne cherches pas à comprendre quelles sont les motivations profondes, sociales et émotionnelles de l’être humain en face de toi, tu viens chercher une conformation à une conviction que tu as déjà.
Il s'agit du biais cognitif appelé "biais de confirmation" c’est-à-dire la tendance à privilégier des informations d'une manière qui confirme ses croyances ou hypothèses préexistantes. Le risque devient alors d’influencer les réponses de la personne interviewée, le souvenir qu’on a de ses réponses, ou l’interprétation qu’on en tire et mettre en péril la pertinence des fonctionnalités imaginées. Ce biais peut aussi être transféré sur la personne interviewée : si on lui demande “comment est organisé ton suivi médical au quotidien ?”, elle aura tendance à répondre en projetant son suivi idéal puis à chercher des faits pour confirmer sa projection. Au contraire, il faudrait plutôt poser la question “comment s’est déroulé ton suivi médical la semaine dernière ?” qui va lui permettre de répondre factuellement avec des exemples vécus.
2. Le biais de disponibilité
“C’est l’histoire d’un mec qui cherche ses clés sous un lampadaire. Pourquoi sous un lampadaire ? parce que c’est le seul endroit éclairé de la rue” (Coluche)
Par facilité, il peut être tentant de puiser l’information là où elle est immédiatement disponible. Par exemple sur un Produit mature, on peut être tenté de n’interroger que les “power users” déjà fans du produit.
Toutefois, cette solution de facilité risque de fausser la recherche au risque de passer à côté d'éléments cruciaux simplement parce qu’ils demandent plus d'effort pour être explorées.
Alors que faire pour élargir sa perception quand on a déjà interrogé son réseau ou les power users de son produit ? On peut toujours être créatif et intégrer les groupes Facebook des patients atteints d’une pathologie ou les associations de patients, faire jouer son entourage en demandant du referral à des professionnels de santé (pour éviter d’interroger quelqu’un de trop proche), voire recourir à un organisme payant spécialisé comme Hack Your Care.
3. Le biais de post hoc fallacy
Dans ce graphique, les dépenses des États-Unis dans “la Science, l’Espace et la Technologie” et le nombre de “suicides par pendaison, strangulation” semblent suivre une corrélation parfaite sur 10 ans, et pourraient faire voir un lien de causalité dans cet amusant hasard. De même en conception produit, il faut suspendre son jugement le temps de la user research pour ne pas s’accrocher trop vite à de mauvaises intuitions.
Par exemple chez Hokla, un test d’usabilité avec des patients nous a appris à ne pas aller trop vite vers ce qui semblait le plus évident : après plusieurs tests auprès de patients équipés d’un pacemaker Bluetooth, nous avons compris que le faible taux de succès du jumelage de leur implant avec leur smartphone n’était pas lié à la complexité du parcours, mais plutôt à la taille des caractères trop petite pour ces patients âgés en moyenne de plus de 75 ans.
La bonne méthode à adopter pour vos interviews utilisateur
Une bonne méthode est donc une méthode qui 1) ne cherche pas à confirmer des croyances préexistantes (baume à ego) 2) élargit le champs des interviews au maximum et 3) ne saute pas trop hâtivement sur des conclusions.
Comment procéder ?
Préparer l’interview en amont
- Écrire de façon la plus claire possible un “research statement”, c’est-à-dire un ensemble d’hypothèses à vérifier. Cela permet de s'assurer de poser les bonnes questions, voire d’embarquer les stakeholders en leur partageant le document. Exemple : (1) le médecin n’a pas plus de 30 secondes par consultation pour regarder un Dashboard. (2) le suivi en temps réel du patient a moins de valeur qu’une alerte lorsque sa santé se dégrade. Etc
- Préparer une trame d’interview avec des questions, mais il ne faudra pas hésiter à s’en écarter. Une bonne interview suit rarement la trame prévue. Commencer par les questions les plus larges pour comprendre qui est la personne, son contexte, ses préférences, avant de se concentrer sur la problématique en question selon un schéma bien connu d’entonnoir.
- Dans une phase exploratoire, il faut plutôt chercher à comprendre le problème de la personne qu’évaluer le potentiel de sa solution (ça c’est plutôt l’objet d’un test d’usabilité sur une maquette basse-définition par exemple). Pour ça, on peut poser des questions ouvertes tournées sur l’expérience passée (plutôt qu’une projection idéale). Par exemple, ne pas demander « et toi à quel point tu pourrais suivre ton diabète sur une application » car cela ne renseigne pas sur une vraie préférence. Le patient risque plutôt de répondre par une projection sans fondement ou par une flatterie (« bien sûr que ton app est géniale puisque c’est la tienne ») mais dire plutôt « raconte moi comment tu as suivi ta glycémie la semaine dernière ».
Pendant l’interview : parler peu, écouter beaucoup
- Écouter vraiment. Une bonne interview c’est 20% de temps de parole pour l’interviewer maximum. Bien sûr, tout en maîtrisant le rythme de la discussion pour continuer à apprendre de nouvelles choses et éviter les « tunnels » sur un seul sujet.
- Lorsque la personne interviewée développe une idée qui manque de concret, ne pas hésiter à lui demander un exemple. On peut aussi employer la technique du miroir qui consiste à répéter ses derniers mots pour obtenir des précisons. Par exemple : je n’arrive jamais à me connecter c’est pénible pour moi. - pénible pour vous? - bah oui pénible parce que je dois aller dans mes mails chercher un code de sécurité (…) .
- En pratique, on peut se répartir la conduite de l’interview et la prise de notes à deux.
- À la fin de l’interview, remercier la personne et en profiter pour lui proposer de la recontacter plus tard pour lui demander son avis sur le résultat, elle sera flattée et vous avez sécurisé une recrue pour un test d’usabilité / formatif / sommatif.
Après l'interview
Restituer (tout de suite après quand c’est encore frais) fidèlement le transcript de l’interview sans l’interpréter, avec d’éventuelles observations sur l’attitude corporelle ou le ton de la personne. Puis retravailler ce rendu brut pour en extraire :
- les émotions positives (”j’apprécie les codes couleurs clairs qui me permettent de traiter en premier les patients le plus en détresse”) pour identifier ce qu’il faut renforcer,
- les émotions négatives (”c’est pénible pour moi de devoir emmener mon boitier électronique associé à mon pacemaker quand je voyage car il est très encombrant”), pour identifier le potentiel d’amélioration de la vie de la personne,
- les alternatives et les critères de choix (”avant j’utilisais un bout de papier que je perdais, désormais j’utilise une l’application bidulechouette.app”), pour identifier ce qu’il faut privilégier,
- les “jobs to be done” où la personne idéale que l’interviewé veut devenir (« je veux atténuer ma douleur (fonctionnel), être rassuré (émotionnel) et partager avec d’autres patients ce que je ressens (social) »)
Enfin après relecture, se replonger dans sa research statement pour faire évoluer ses hypothèses initiales. On apprend des choses quand on casse des idées reçues.
Pour aller plus loin, 3 ouvrages de références :
Public visé : Entrepreneurs & Product Managers
Key learnings : On apprend comment poser des questions de telles sorte que les réponses ne soient pas biaisées. Très court. Très facile. Très riche.
Public visé : Product Managers
Key learnings : Un framework de Discovery en 7 étapes pour scander cette phase souvent pauvre en livrables concrets.
Public visé : Product Managers
Key learnings : La théorie des Jobs to be Done (= process que l’utilisateur / client essaie d’atteindre auquel le produit devra répondre). Elle permet d’enrichir l’analyse concurrentielle et de comprendre par exemple pourquoi Facebook peut concurrencer Marlboro dans la satisfaction d’un besoin émotionnel (un petit shot de dopamine) et social (discuter avec ses proches) lors d’une pause au boulot.
Quand est-il de la GenAI pour vos interviews utilisateur ?
Demain, tous des prompt-researchers ? Si les réponses statistiques des LLM peuvent fournir des hypothèses interessantes à (in)valider ensuite sur le terrain, il convient pourtant parler à de vrais êtres humains, dans la mesure où c’est eux qui, en définitive, décideront d’utiliser le produit.