Évaluer une interface : évaluation heuristique, test utilisateur et SUS

Évaluer une interface, c'est vérifier qu'elle permet à ses utilisateurs d'atteindre leurs buts avec efficacité, efficience et satisfaction, et repérer ce qui les en empêche. On dispose de deux familles de méthodes : l'inspection, où des évaluateurs examinent l'interface à l'aide d'une grille (l'évaluation heuristique), et le test utilisateur, où l'on observe de vrais utilisateurs réaliser des tâches ; un questionnaire standard, le SUS, mesure en plus la satisfaction par un score sur 100. Ce chapitre détaille ces trois méthodes, avec le test du prototype de Prêt'Matos, et dit laquelle choisir à quel moment.

Inspecter ou observer : deux familles de méthodes

Les deux se complètent. L'inspection élimine les défauts évidents à moindre coût ; le test révèle ce qu'aucune grille ne prévoit, comme Mathis qui cherche le filtre par date en haut de l'écran.

L'évaluation heuristique pas à pas

L'évaluation heuristique consiste à faire examiner l'interface par quelques évaluateurs, chacun de son côté, à l'aide d'une grille connue : les critères de Bastien et Scapin (chapitre 2) ou les heuristiques de Nielsen (chapitre 3). Nielsen a montré qu'un évaluateur seul ne trouve qu'une partie des problèmes, de l'ordre d'un tiers, et recommande trois à cinq évaluateurs : leurs listes se recouvrent peu, et leur réunion couvre la majorité des problèmes.

1. Définir le périmètre : les écrans et les tâches à examiner (« réserver un matériel », « annuler une réservation »), les personas concernés, la grille utilisée.
2. Inspecter seul : chaque évaluateur parcourt l'interface au moins deux fois, une première pour comprendre le parcours, une seconde pour examiner chaque écran critère par critère. Il note chaque problème avec l'écran, la description, le critère enfreint.
3. Consolider : les évaluateurs mettent leurs listes en commun, fusionnent les doublons.
4. Coter la gravité de chaque problème.
5. Recommander une correction pour chacun, et classer par priorité.

Pour coter la gravité, on utilise souvent l'échelle de Nielsen, de 0 à 4. Elle combine la fréquence du problème (touche-t-il beaucoup d'utilisateurs ?), son impact (bloque-t-il la tâche ou ralentit-il seulement ?) et sa persistance (l'utilisateur le contourne-t-il une fois pour toutes, ou le subit-il à chaque fois ?).

Voici un extrait du rapport d'évaluation heuristique du prototype de Prêt'Matos, mené par Moussa Diallo, Chloé Lambert et Antoine Mercier, du service informatique, qui n'ont pas conçu les écrans, avec la grille de Bastien et Scapin :

Le test utilisateur

Un test utilisateur (test d'utilisabilité) consiste à observer des utilisateurs représentatifs pendant qu'ils réalisent des tâches réalistes avec l'interface, sans les aider, pour repérer ce qui les gêne. On ne teste pas l'utilisateur : on teste l'interface.

Préparer

L'objectif. Que veut-on apprendre ? « Les salariés réservent-ils seuls un matériel, en moins de 2 minutes ? » est un objectif ; « voir si ça plaît » n'en est pas un.

Les tâches. Chaque tâche est un scénario réaliste, qui donne un but sans dire comment l'atteindre. Elle ne contient ni le nom des menus ni celui des boutons, qui guideraient le participant :

À éviter : « Cliquez sur Catalogue, utilisez le filtre de date et réservez le vidéoprojecteur VP-01 pour jeudi. »

À préférer : « Vous présentez une offre chez un client jeudi prochain à 9 h, dans ses locaux, et il vous faut un vidéoprojecteur. Organisez-vous avec Prêt'Matos. »

Les participants. Ils doivent ressembler aux utilisateurs réels, donc aux personas : des commerciaux et des comptables pour les écrans de réservation, la logistique pour les écrans de gestion. Pas des développeurs, pas des membres de l'équipe.

Le protocole. Un document d'une page fixe le déroulement : accueil et consentement, tâches, questionnaire, questions finales, et le rôle de chacun. Un animateur donne les consignes et reste neutre ; un observateur note, de préférence sans parler.

Combien de participants ?

Nielsen et Landauer ont modélisé en 1993 la part des problèmes découverts en fonction du nombre de participants. Si un participant fait apparaître en moyenne une proportion L des problèmes (L vaut environ 31 % dans leurs études), n participants en font apparaître :

part trouvée = 1 − (1 − L)^n        avec L ≈ 0,31

n = 1 → 31 %      n = 3 → 67 %      n = 5 → 84 %      n = 10 → 98 %

D'où la règle célèbre : cinq participants par profil suffisent pour un test qualitatif. Au-delà, on revoit surtout les mêmes problèmes. Plutôt qu'un grand test de quinze personnes, mieux vaut trois tests de cinq, en corrigeant l'interface entre chaque : le deuxième test vérifie les corrections et fait apparaître les problèmes que les premiers masquaient.

Animer

• Mettre à l'aise : « Nous testons l'application, pas vous. Il n'y a pas de mauvaise réponse ; si vous bloquez, c'est l'application qui est en cause. »
• Recueillir le consentement, par écrit si tu enregistres l'écran ou la voix : dire ce qui est enregistré, pourquoi, pour combien de temps, et que la personne peut arrêter à tout moment. Un enregistrement est une donnée personnelle (RGPD) : conserve-le le temps de l'analyse, puis supprime-le.
• Demander de penser à voix haute (think aloud) : le participant dit ce qu'il cherche, ce qu'il pense, ce qui le surprend. C'est la source la plus riche du test.
• Ne pas aider, ne pas expliquer, ne pas défendre l'interface. Quand le participant demande « je clique où ? », retourne la question : « Où cliqueriez-vous ? ». Fixe une limite de temps par tâche au-delà de laquelle on note un échec et on passe à la suite.
• Observer et noter : réussite ou échec, temps, hésitations, erreurs, retours en arrière, phrases prononcées.

Un test peut se faire en salle, en visioconférence avec partage d'écran, ou de façon très légère : cinq minutes avec un collègue à la machine à café, sur un prototype papier. Un test imparfait vaut beaucoup mieux que pas de test.

Analyser

Pour chaque tâche, relève des mesures simples :

Puis liste les problèmes observés, compte combien de participants ont rencontré chacun, cote sa gravité et décide des corrections. Voici les deux tests de Prêt'Matos sur la tâche « réserver le vidéoprojecteur pour jeudi » :

L'exigence du cahier des charges, « un salarié qui n'a jamais utilisé l'application réserve un matériel en moins de 2 minutes, sans aide », n'était pas atteinte en version 1 ; en version 2, les deux salariés qui découvraient l'application l'atteignent. C'est une preuve qu'une commission ou un client comprend immédiatement. Dans une PME de 14 salariés, on ne trouve pas dix personnes qui découvrent l'application : signale cette limite (trois participants connaissaient déjà la tâche), elle fait partie d'une évaluation honnête.

Le questionnaire SUS

Le SUS (System Usability Scale), créé par John Brooke en 1986, est un questionnaire de dix affirmations qui mesure l'utilisabilité perçue par un score de 0 à 100. Il est court, gratuit, applicable à tout type d'interface, et utilisé depuis quarante ans : on peut donc comparer son score à des milliers d'autres. On le fait remplir juste après le test, avant toute discussion.

Chaque affirmation se note de 1 (« pas du tout d'accord ») à 5 (« tout à fait d'accord »). Les affirmations impaires sont positives, les paires négatives :

Calculer le score

Le calcul a trois étapes, pour chaque participant :

affirmations impaires (1, 3, 5, 7, 9) :  contribution = note − 1
affirmations paires   (2, 4, 6, 8, 10) : contribution = 5 − note
score SUS = (somme des 10 contributions) × 2,5

Chaque contribution va de 0 à 4, la somme de 0 à 40, et le score de 0 à 100. Le score d'une interface est la moyenne des scores des participants. Exemple avec le premier participant du test de la version 1 :

Somme des contributions : 3 + 3 + 3 + 3 + 2 + 2 + 3 + 3 + 3 + 3 = 28, donc score = 28 × 2,5 = 70. Les quatre autres participants ont obtenu 60, 65, 37,5 et 77,5 : la moyenne de la version 1 est (70 + 60 + 65 + 37,5 + 77,5) / 5 = 62,0. Le score de 37,5 est celui du participant qui a échoué à la tâche : le SUS reflète aussi l'efficacité.

Interpréter le score

Un score SUS n'est pas un pourcentage : 62 ne veut pas dire « 62 % de satisfaction ». On l'interprète par comparaison avec les scores observés sur des centaines d'études, recensés notamment par Jeff Sauro (MeasuringU) :

La version 1 de Prêt'Matos (62,0) est sous la moyenne ; la version 2 (83,5) est parmi les meilleures. L'usage le plus solide du SUS est d'ailleurs la comparaison : deux versions d'une même interface, ou ton application et celle qu'elle remplace. Sur cinq participants, un score moyen reste imprécis : une différence de quelques points ne prouve rien, une différence de vingt points, comme ici, est parlante.

Les autres méthodes

Quelle méthode, à quel moment ?

Exercices