Rapport de test d’utilisabilité : relier les problèmes à l’enregistrement

Le rapport commence par les observations

« Le participant n’a pas aimé la navigation » ne dit pas ce qu’il faut corriger. L’enregistrement peut montrer que la personne a ouvert trois fois la rubrique Paiement pour chercher comment faire un retour, puis qu’elle a demandé de l’aide. L’équipe dispose alors d’un problème reproductible dans une tâche précise.

Consignez les conditions du test : version de l’interface, appareil, scénario, critère de réussite et aide du modérateur. Sans ces éléments, l’équipe peut prendre une difficulté rencontrée dans un prototype pour un défaut du produit en service, ou compter une réussite après un indice comme un succès en autonomie.

Transformez les sessions en constats vérifiables

1. Repérez les épisodes importants

   Pour chaque session, marquez le début de la tâche, les difficultés, la reprise et le résultat. Comparez la transcription à l’enregistrement de l’écran. « J’ai cliqué » ne décrit pas toujours un clic réel. Gardez les repères temporels avant et après l’action pour préserver le contexte.

2. Distinguez l’observation de l’explication

   Notez l’action et le résultat dans le champ d’observation. Réservez un autre champ à la cause supposée. « A cherché le retour dans Paiement » est une observation. « Le nom de la rubrique est peu clair » est une hypothèse à tester dans une autre version de l’interface.

3. Comparez les cas semblables

   Regroupez les épisodes uniquement s’ils présentent le même problème dans des scénarios comparables. Indiquez le nombre de participants concernés et le nombre de personnes qui ont effectué la tâche. Évitez d’extrapoler la proportion observée dans un petit groupe à l’ensemble du public du produit.

4. Définissez une action et sa vérification

   Évaluez la conséquence : tâche interrompue, aide nécessaire ou étapes supplémentaires. Convenez de la priorité en tenant compte du contexte du produit. Pour le changement proposé, précisez quel résultat observable du prochain test montrera s’il a aidé.

Un utilisateur cherche à retourner une commande

L’exemple pédagogique ci-dessous est fictif. Les noms, les conditions et les résultats servent uniquement à expliquer la méthode.

Une seule remarque ne suffit pas à savoir ce qui s’est passé à l’écran. Dans l’exemple, l’enregistrement montre deux passages dans Paiement, puis l’arrêt de la tâche jusqu’à l’indice donné par le modérateur. Inscrivez-le sur la fiche avec la version du prototype.

Ajouter un lien dans le détail de la commande est une piste à vérifier. Le prochain test montrera si le participant trouve l’action seul et s’il comprend quelle commande il est en train de retourner.

Fiche de problème pour le rapport

Préparez d’abord les fiches, puis résumez les principaux obstacles. Les conclusions resteront liées au matériau du test.

Titre court du problème :
Version / appareil / tâche :
Participant et repère temporel :
Action observée :
Conséquence sur la tâche :
Aide du modérateur :
Répétitions dans des sessions comparables :
Cause supposée :
Priorité et justification :
Changement proposé :
Comment vérifier le résultat :

Vérifiez que le rapport permet d’agir

• Les constats importants sont repérables dans l’enregistrement.
• On sait si la tâche a été réalisée en autonomie.
• La cause est présentée comme une hypothèse.
• La proposition a un critère pour le prochain test.