Analyser les résultats et améliorer le prototype

1. Objectifs

   • Rassembler et dédoublonner les problèmes relevés pendant les tests
   • Croiser les mesures (réussite, temps, égarement, SUS) et les observations
   • Noter la gravité et la fréquence de chaque problème pour le prioriser
   • Rédiger des recommandations précises et vérifiables
   • Corriger le prototype et retester pour valider les corrections
   • Présenter les résultats d'un test de façon claire et argumentée

1. Présentation

   • Après les sessions, l'équipe a des dizaines de notes, des chiffres, des phrases de participants. Ce matériau ne sert à rien tant qu'il n'est pas transformé en décisions : quoi corriger, dans quel ordre, et comment savoir si la correction a marché.
   • Cette leçon clôt la phase de test : elle montre comment passer des résultats bruts à un prototype amélioré, puis vérifié par un nouveau test.

• Nous terminons avec BiblioCampus et les résultats de ses cinq sessions. Pour les activités, créez le dossier 09-6-analyse/ dans votre dépôt GitHub ui-ux-design-bts.

1. Rassembler les résultats

   • On commence par un tableau de bord: les indicateurs principaux, puis les résultats tâche par tâche, chacun relié aux observations qui l'expliquent :

• On rassemble ensuite tous les problèmes relevés (compréhension, vocabulaire, navigation, composants) et on les dédoublonne: un même problème observé sous plusieurs angles ne compte qu'une fois, avec sa cause principale.
• On note aussi ce qui fonctionne: une tâche réussie par tous, un mot compris de tous. Le rapport le dit, pour que les corrections ne le cassent pas.

1. Prioriser : gravité et fréquence

   • Chaque problème reçoit une gravité de 1 (mineur) à 4 (bloquant), selon son effet sur la tâche, et une fréquence: le nombre de participants concernés. Leur produit donne la priorité :

• Un problème bloquant se corrige toujours en premier, même s'il ne touche qu'un participant : c'est souvent le cas des problèmes d'accessibilité, qui empêchent complètement certaines personnes d'utiliser le service.
• La gravité juge l'effet sur l'usager, pas l'agacement de l'équipe : une couleur qui déplaît n'est pas un problème grave.

1. Rédiger des recommandations

   • Une recommandation transforme un problème en action. Elle contient le problème, sa preuve, sa priorité, la correction précise, le critère concerné et l'effet attendu, mesurable au prochain test :

1. Corriger, puis retester

   • Les corrections sont appliquées au prototype, en commençant par les priorités les plus hautes. Puis on reteste les tâches concernées, avec de nouvelles personnes : une correction n'est validée qu'après ce nouveau test :

• Le retest peut être court : trois participants, seulement les tâches touchées. Ce qui compte est de comparer les mêmes mesures avant et après.
• Chaque version du prototype est marquée d'une étiquette Git (test-v1, test-v2…) : on peut toujours retrouver la version testée.

1. Présenter les résultats

   • Le commanditaire n'a pas le temps de lire tout le classeur. Une présentation de cinq minutes suffit : ce qui marche, les trois problèmes les plus graves avec leurs preuves, une correction avant / après et les chiffres du retest.
   • Montrez des faits (« 4 participants sur 5 ne voient pas la confirmation ») et des paroles d'usagers, jamais des opinions de l'équipe.

1. Exemple 1 : les priorités de BiblioCampus

   • Après dédoublonnage, l'équipe a retenu 14 problèmes. Deux arrivent en tête avec une priorité de 12 : « Transactions » non compris (gravité 4, 3 participants) et la confirmation non vue (gravité 3, 4 participants).
   • Le filtre illisible au lecteur d'écran ne touche qu'un participant, mais il est bloquant : il passe aussi en première ligne.
   • Les sept recommandations prioritaires ont été rédigées en une heure ; le libellé un peu long de « Ajouter à ma bibliographie » est reporté à plus tard.

1. Exemple 2 : une correction qui n'a rien changé

   • Pour la tâche « annuler une réservation », l'équipe avait renommé « Révoquer » en « Annuler ». Au retest, la réussite est restée à 60 %.
   • En relisant les observations, elle a compris que le problème n'était pas le mot, mais le menu « … » où l'action était cachée : personne ne l'ouvrait.
   • La deuxième correction a placé un bouton « Annuler ma réservation » visible sur la fiche de la réservation : 80 % de réussite au troisième test. Un retest sans amélioration est une information, pas un échec.

1. Activité 1 : dédoublonner

   • Ces quatre notes viennent de sessions différentes. Combien de problèmes contiennent-elles ?
     • a) « P1 ne comprend pas le mot “Révoquer” » ;
     • b) « P3 n'ouvre jamais le menu “…” et abandonne l'annulation » ;
     • c) « P4 : “Annuler, c'est où ?” » ;
     • d) « P2 annule par erreur : aucune confirmation ».
   • Vérifier : deux ou trois problèmes selon votre analyse. a, b et c relèvent de « l'annulation est introuvable » (mot et emplacement) ; d est un problème distinct, l'absence de confirmation.

1. Activité 2 : le tableau de bord

   • À partir de vos résultats du TP 6, construisez le tableau de bord de CantineCampus : six indicateurs, puis une ligne par tâche avec ce qui l'explique.
   • Vérifier : chaque chiffre de tâche est accompagné d'au moins une observation qui l'explique.

1. Activité 3 : noter la gravité

   • Notez la gravité (1 à 4) de ces problèmes et justifiez : « le bouton d'ajout semble désactivé » ; « l'icône ⚙ n'est pas comprise, le filtre des allergènes n'est pas trouvé » ; « l'accroche contient un anglicisme » ; « l'annulation se fait sans confirmation ».
   • Vérifier : le filtre introuvable pour une personne allergique est bloquant (4) ; l'anglicisme de l'accroche est mineur (1 ou 2) ; chaque note est justifiée par l'effet sur la tâche.

1. Activité 4 : prioriser

   • Reportez tous vos problèmes avec leur gravité et leur fréquence, calculez la priorité et classez-les.
   • Vérifier : les problèmes bloquants sont en tête même s'ils sont rares ; aucun problème n'est compté deux fois.

1. Activité 5 : rédiger les recommandations

   • Rédigez une recommandation complète pour les cinq problèmes prioritaires : problème, preuve, priorité, correction, critère, effet attendu. Enregistrez-les dans projet-cantinecampus/05-tester/recommandations.md.
   • Vérifier : chaque correction dit exactement quoi changer et où ; chaque effet attendu est mesurable au retest.

1. Activité 6 : corriger et retester

   • Appliquez au moins trois corrections à votre prototype Figma, puis retestez les tâches concernées avec trois nouvelles personnes.
   • Vérifier : les mesures avant et après sont comparées dans un tableau ; toute correction sans effet est analysée.

1. Activité 7 : la présentation de cinq minutes

   • Préparez cinq diapositives pour le directeur du restaurant : ce qui marche, les trois problèmes les plus graves, une correction avant / après, les chiffres du retest, la suite proposée.
   • Vérifier : chaque diapositive contient au moins un fait chiffré ou une parole de participant ; aucune ne repose sur un avis de l'équipe.

1. Activité 8 : déposer votre travail sur GitHub

   • Regroupez vos réponses dans 09-6-analyse/README.md, puis envoyez le tout et marquez la version testée :

git add 09-6-analyse projet-cantinecampus/05-tester projet-cantinecampus/04-prototyper
git commit -m "Ajoute l'analyse des tests et les corrections de CantineCampus"
git push
git tag -a test-v2 -m "Prototype corrigé après le retest"
git push origin test-v2

• Vérifier : recommandations.md s'affiche sur GitHub et l'étiquette test-v2 apparaît dans l'onglet Tags.

1. Erreurs fréquentes

1. À retenir

   • On rassemble et on dédoublonne: un problème par ligne, avec sa cause principale.
   • Les chiffres disent où et combien ; les observations disent pourquoi.
   • La priorité = gravité × fréquence; un problème bloquant passe toujours en premier.
   • Une recommandation précise : problème, preuve, correction, critère, effet attendu.
   • Une correction n'est validée qu'après un retest.
   • On présente des faits et des paroles d'usagers, jamais des opinions.

Tester sans corriger ne sert à rien ; corriger sans retester, c'est espérer. L'amélioration naît de l'aller-retour entre les deux.