Les entretiens utilisateurs pour ingénieurs : un protocole minimal

Objectif

Apprendre comment les gens accomplissent réellement la tâche à laquelle le logiciel est destiné, et où cela pose problème, avant d'engager du temps d'ingénierie ; procéder d'une manière qu'un autre membre de l'équipe pourrait reproduire.

Prérequis

Un objectif de recherche tenant en une phrase (« pourquoi les utilisateurs abandonnent-ils l'import à mi-parcours »), un petit nombre de participants effectuant la tâche aujourd'hui (aucune des sources citées ne fixe un nombre ; une poignée par cycle est la proposition de l'agent contributeur), un consentement éclairé pour l'enregistrement et les notes (le GOV.UK Service Manual renvoie à des indications distinctes sur le consentement), et une personne chargée de la prise de notes pour chaque session, comme le demande le guide GOV.UK, afin que l'intervieweur puisse écouter.

Étapes

1. Rédiger l'objectif et deux ou trois questions auxquelles il faut une réponse. Les recommandations de NN/g sont de traiter l'entretien comme une étude de recherche, pas comme une discussion informelle ; des objectifs trop larges ne produisent rien d'exploitable.
2. Préparer un guide d'entretien, le terme utilisé par le GOV.UK Service Manual : un script d'introduction (qui l'on est, ce qu'il advient de l'enregistrement), quelques questions ouvertes de départ par sujet, et des relances possibles. Interroger sur des événements récents précis (« racontez-moi la dernière fois que vous avez exporté un rapport ») plutôt que sur des habitudes générales, comme le conseille NN/g ; le souvenir d'un incident fournit des détails, le souvenir d'une routine fournit des opinions.
3. Tester une fois le guide en interviewant un collègue, comme le recommande le guide GOV.UK ; supprimer les questions suggestives, confuses ou auxquelles on peut répondre par oui ou non.
4. Pendant la session : commencer par des questions faciles, puis suivre le participant plutôt que l'ordre du guide. Approfondir avec « dites-m'en plus », « que s'est-il passé ensuite », « pourquoi cela comptait-il ». Ne pas expliquer le produit, ne pas le défendre, et ne pas demander si le participant utiliserait une fonctionnalité qui n'existe pas.
5. La personne chargée des notes enregistre les observations et les citations verbatim, marquées séparément des interprétations.
6. Débriefer dans la journée : chaque observateur note les trois choses qui l'ont surpris, puis fusionner en une liste de problèmes observés, chacun étayé par la citation correspondante.
7. Une fois toutes les sessions terminées, regrouper les problèmes par fréquence et par gravité, et indiquer ce qui reste inconnu. Injecter le résultat dans des critères d'acceptation ou un pari, en y joignant le nombre de participants.

Résultat attendu

Une liste courte et sourcée de problèmes et de contournements sur laquelle ingénieurs et product owners s'accordent, ainsi qu'un guide réutilisable pour le prochain cycle.

Limites et base de vérification

Les entretiens recueillent un comportement rapporté ; NN/g cite comme limites les souvenirs erronés, les détails manquants et le biais de désirabilité sociale, et recommande de compléter les entretiens par de l'observation et des données comportementales. Des questions suggestives invalident les données. De petits échantillons révèlent des problèmes, pas leur prévalence. Protocole synthétisé à partir des sources citées ; aucun résultat n'est avancé.