TP 6 : Tester un prototype avec des utilisateurs

1. Objectifs

   • Préparer un test : objectifs, tâches, critères de réussite, recrutement de participants représentatifs, test pilote
   • Vérifier la compréhension du service avec le test des cinq secondes
   • Évaluer le vocabulaire de l'interface avec un test des mots
   • Observer des usagers réaliser des tâches à voix haute et mesurer la navigation de page en page
   • Relever les problèmes d'utilisabilité des composants et mesurer la facilité perçue (SUS)
   • Analyser les résultats, prioriser les problèmes, améliorer le prototype et retester

1. Prérequis

   • Avoir suivi les leçons du chapitre « Phase de test : évaluer avec les utilisateurs » : Préparer un test avec des utilisateurs représentatifs, Tester la compréhension du service, Évaluer le choix des mots et la qualité du vocabulaire, Tester la navigation de page en page, Évaluer l'utilisabilité des composants de l'interface, Analyser les résultats et améliorer le prototype.
   • Avoir réalisé le TP 5 : Concevoir les wireframes d'une application, ou utiliser le prototype de référence fourni dans l'archive.
   • Aucune programmation n'est demandée : on observe, on mesure, on améliore.

1. Présentation du projet

   • Le prototype de CantineCampus est prêt. Avant de lancer le développement, le directeur du restaurant veut une réponse claire : les usagers comprennent-ils le service et arrivent-ils à s'en servir seuls ?
   • Vous organisez un test avec cinq usagers représentatifs de vos personas. Vous évaluez quatre aspects, un par leçon du chapitre :
     • la compréhension du service ;
     • le vocabulaire;
     • la navigation de page en page ;
     • l'utilisabilité des composants.
   • Puis vous corrigez le prototype et vérifiez que les corrections fonctionnent.
   • Téléchargez l'archive du TP. Elle contient un prototype de référence cliquable (prototype/cantinecampus-prototype.html, à ouvrir dans un navigateur), le guide de test, les cartes de tâches et de vocabulaire, le formulaire de consentement et le questionnaire à imprimer (protocole/), ainsi que le classeur modeles/grille-test.xlsx.

• Le prototype de référence est fictif et ses défauts sont volontaires. Ne le corrigez pas avant le test : c'est aux participants de les révéler. Vous pouvez tester votre propre prototype Figma à la place, si les cinq tâches y sont réalisables.
• Pour l'observateur : sur ordinateur, la touche J affiche le journal des clics du prototype de référence (temps, écrans vus, écrans différents) et la touche R remet le chronomètre à zéro. Rechargez la page (F5) entre deux participants.

1. Organisation du TP

   • Le TP est découpé en dix parties. Chacune indique sa durée, ses notions, ses consignes, une aide, un point de contrôle et des questions.
   • Chaque partie ajoute une pièce à votre rapport de test. Le classeur modeles/grille-test.xlsx contient les tableaux à remplir ; il calcule les taux de réussite, le taux d'égarement, le score SUS et les priorités.
   • Trois règles s'appliquent : on teste l'application, pas l'usager; on observe sans aider; chaque correction vient d'un constat.
   • À la fin de chaque partie, enregistrez votre travail sur GitHub : un commit par partie permet de suivre votre progression.

1. Partie 0 : préparer le travail

⏱ 15 min

Notions mobilisées : Préparer un test avec des utilisateurs représentatifs

• Dans votre dépôt ui-ux-design-bts, créez le dossier de la phase de test :

cd ui-ux-design-bts
git pull
mkdir -p projet-cantinecampus/05-tester/protocole projet-cantinecampus/05-tester/sessions projet-cantinecampus/05-tester/analyse projet-cantinecampus/05-tester/corrections
git add projet-cantinecampus/05-tester
git commit --allow-empty -m "Démarre le TP 6"
git push

• Copiez le classeur dans 05-tester/ et complétez l'onglet « Mode d'emploi ». Choisissez le prototype à tester : le vôtre ou celui de l'archive. Ouvrez le prototype de référence et faites vous-même les cinq tâches une fois, pour connaître le chemin minimal.

📁 Dans le dossier : le choix du prototype et les hypothèses à vérifier.

1. Partie 1 : rédiger le plan de test et recruter

⏱ 30 min

Notions mobilisées : Préparer un test avec des utilisateurs représentatifs

• Rédigez le plan de test dans l'onglet du même nom : objectifs, questions, participants, tâches, mesures, matériel, rôles, lieu et horaire.
• Pour chaque tâche, fixez dans l'onglet « Protocole » le critère de réussite, le chemin minimal (nombre d'écrans différents R) et le temps limite.
• Recrutez cinq participants représentatifs de vos personas, qui ne connaissent pas le projet, et notez leur profil dans l'onglet « Participants ». Le classeur vérifie que chaque persona est représenté.

📁 Dans le dossier : le plan de test, l'onglet « Protocole » et la liste anonymisée des participants.

1. Partie 2 : préparer le matériel et faire un test pilote

⏱ 20 min

Notions mobilisées : Préparer un test avec des utilisateurs représentatifs

• Imprimez les cartes de tâches et de vocabulaire, le questionnaire et le formulaire de consentement. Relisez le protocole/guide-de-test.md et répartissez les rôles : animateur, observateur, preneur de notes.
• Faites un test pilote complet avec une personne qui ne compte pas parmi les cinq participants. Corrigez le protocole : consignes mal comprises, durée, matériel qui manque.

📁 Dans le dossier : le protocole corrigé et le compte rendu du pilote.

1. Partie 3 : tester la compréhension du service

⏱ 25 min

Notions mobilisées : Tester la compréhension du service

• Au début de chaque session, réalisez le test des cinq secondes sur l'écran d'accueil : montrez-le cinq secondes, masquez-le, puis posez les quatre questions du guide. Notez les réponses mot pour mot dans l'onglet « Compréhension ».
• En fin de session, demandez : « Comment expliqueriez-vous ce service à un ami ? ». Codez chaque réponse : compris, partiel ou faux.

📁 Dans le dossier : l'onglet « Compréhension » et l'analyse des réponses.

1. Partie 4 : évaluer le vocabulaire

⏱ 25 min

Notions mobilisées : Évaluer le choix des mots et la qualité du vocabulaire

• Pendant chaque session, montrez les douze cartes de vocabulaire une par une : « Que signifie ce mot, selon vous ? Que se passerait-il si vous le touchiez ? ». Notez les réponses mot pour mot.
• Dans l'onglet « Vocabulaire », indiquez pour chaque participant si le mot est compris. Le classeur calcule le taux de compréhension de chaque mot. Proposez un remplacement pour chaque mot compris par moins de 4 participants sur 5, en reprenant les mots qu'ils ont eux-mêmes employés.

📁 Dans le dossier : l'onglet « Vocabulaire » et le lexique des mots retenus.

1. Partie 5 : mener les sessions de test

⏱ 55 min

Notions mobilisées : Tester la navigation de page en page · Évaluer l'utilisabilité des composants de l'interface · Préparer un test avec des utilisateurs représentatifs

• Réalisez les cinq sessions en suivant le guide. Pour chaque tâche, l'animateur lit la carte et la pose devant le participant, puis se tait. L'observateur appuie sur R au début de la tâche et note à la fin les mesures du journal.
• Dans l'onglet « Tâches », saisissez pour chaque participant et chaque tâche : le résultat, le temps, le nombre d'erreurs, si le premier clic était juste, les écrans vus (S) et les écrans différents (N).
• En fin de session, faites remplir le questionnaire SUS et saisissez les réponses dans l'onglet « SUS ». Notez les phrases marquantes dans l'onglet « Observations ».

📁 Dans le dossier : les onglets « Tâches », « SUS » et « Observations », et les notes anonymisées dans sessions/.

1. Partie 6 : analyser la navigation

⏱ 25 min

Notions mobilisées : Tester la navigation de page en page

• Le classeur calcule pour chaque tâche le taux de réussite, le temps moyen, la part de premiers clics justes et le taux d'égarement, qui compare le chemin suivi au chemin minimal.
• Pour les deux tâches les plus difficiles, reconstituez sur papier ou dans ioDraw le chemin réel de deux participants à côté du chemin minimal. Identifiez où ils ont quitté le bon chemin.

📁 Dans le dossier : l'onglet « Tâches » analysé et les chemins dessinés.

1. Partie 7 : évaluer les composants

⏱ 25 min

Notions mobilisées : Évaluer l'utilisabilité des composants de l'interface

• À partir de vos notes, relevez dans l'onglet « Composants » chaque problème lié à un composant : bouton, champ, liste, filtre, message, onglet, menu. Indiquez l'écran, le constat observé, le nombre de participants concernés et le critère ergonomique.
• Lisez le score SUS calculé par le classeur et comparez-le aux résultats des tâches.

📁 Dans le dossier : l'onglet « Composants » et le commentaire du score SUS.

1. Partie 8 : analyser et prioriser les problèmes

⏱ 40 min

Notions mobilisées : Analyser les résultats et améliorer le prototype

• Regroupez dans l'onglet « Problèmes » tous les problèmes relevés (compréhension, vocabulaire, navigation, composants) en supprimant les doublons. Pour chacun, indiquez la gravité de 1 à 4 et la fréquence (nombre de participants). Le classeur calcule la priorité.
• Pour chaque problème prioritaire, rédigez une correction précise et vérifiable, et l'effet attendu.

📁 Dans le dossier : l'onglet « Problèmes » et la liste des corrections.

1. Partie 9 : corriger, retester et présenter

⏱ 40 min

Notions mobilisées : Analyser les résultats et améliorer le prototype

• Appliquez les corrections prioritaires à votre prototype Figma (ou, si vous avez testé le prototype de référence, réalisez dans Figma les wireframes corrigés des écrans concernés). Faites des captures avant / après.
• Faites un retest rapide des tâches concernées avec deux ou trois nouvelles personnes, et notez les résultats dans l'onglet « Retest ». Le classeur compare les taux de réussite avant et après.
• Assemblez le rapport selon le plan ci-dessous et préparez une présentation de 5 minutes pour le directeur : ce qui marche, les trois problèmes les plus graves, une correction avant / après et les chiffres du retest.

git add projet-cantinecampus/05-tester projet-cantinecampus/04-prototyper
git commit -m "Ajoute le rapport de test et le prototype corrigé du TP 6"
git tag -a test-v1 -m "Prototype testé et corrigé"
git push
git push origin test-v1

• Variantes pour les binômes en avance : tester le prototype corrigé avec un usager du persona le moins représenté ; mesurer le score SUS du prototype corrigé ; ou réaliser un test à distance par visioconférence avec partage d'écran.
• Relisez votre rapport : chaque problème a un constat et une fréquence, chaque correction renvoie à un problème, et aucun participant n'est reconnaissable.

1. Grille d'évaluation (sur 20)

1. Livrables

   • Le lien du dépôt GitHub, avec au moins un commit par partie et l'étiquette test-v1.
   • Le rapport de test (PDF), avec vos noms, 10 à 14 pages.
   • Le classeur grille-test.xlsx complété.
   • Le prototype corrigé (lien Figma), les captures avant / après, les notes anonymisées et le support de présentation.

1. Erreurs fréquentes

1. Pour aller plus loin

   • Refaire le test complet sur le prototype corrigé et comparer les deux versions sur tous les indicateurs.
   • Mener un test de préférence entre deux versions d'un même écran (test A/B sur papier).
   • Préparer la maquette en couleurs des écrans validés, puis la tester à son tour.

1. Bilan

   • Un test se prépare: objectifs, tâches réalistes, critères de réussite, participants représentatifs et test pilote.
   • Quatre angles se complètent : la compréhension, le vocabulaire, la navigation et les composants.
   • Les mesures (réussite, temps, égarement, SUS) disent combien ; les observations disent pourquoi.
   • On priorise les problèmes selon leur gravité et leur fréquence, puis on rédige des corrections précises.
   • Une correction n'est validée qu'après un retest.

Quand un usager se trompe, ce n'est pas lui qui échoue : c'est le prototype qui vient de vous apprendre quelque chose.