« 5 utilisateurs suffisent pour trouver 85 % des problèmes » Cette affirmation, de Jakob Nielsen, est souvent citée dans des présentations, sur les tests utilisateurs, en oubliant de préciser le contexte théorique sous-jacent. Le message est bien passé, créant un mythe, une légende urbaine, repris à droite et à gauche par des « experts » de tous poils. En regardant de plus près, cette affirmation n’est pas fausse mais sous certaines conditions très précises.

Nous allons donc revenir aux origines du mythe, voir quelles sont les études qui ont été faites depuis et comment bien dimensionner ses tests utilisateurs.

Les origines du mythe.

Jakob Nielsen et Thomas Landauer ont écrit en 1993 un long article intitulé « A mathematical model of the finding of usability problème ». Cet article a, entre autre, pour but de répondre à la question « Combien faut-il d’utilisateurs pour faire un test utilisateurs avec le meilleur rapport qualité/prix ? ».

Comment détermine-t-on les 85% pour 5 utilisateurs ?

Nielsen se base sur une formule mathématique pour établir cela.

Problèmes trouvés P (i) =  N(1-(1-L)ⁱ)

En français, le nombre de problèmes trouvés P par i utilisateurs est égale au nombre N total de problèmes, multiplié par une fonction inférieure à 1. Plus le nombre d’utilisateur est grand plus cette fonction tend vers 1 et donc le nombre de problèmes trouvés est proche du nombre total.

La valeur L (λ lambda dans certain article) correspond à la proportion de problèmes rencontrés par un utilisateur. Un utilisateur qui rencontre 10 problèmes sur les 20 connus aura une valeur L de 0,5, et un utilisateur qui rencontre 16 problèmes, une valeur de 0,80. Le test pour les deux utilisateurs aura une valeur L de 0,65.

Donc cette valeur L varie d’un test à l’autre. Dans l’article, les valeurs L des tests varient de 0,12 à 0,32 pour les tests utilisateurs et de 0,22 à 0,58 pour les évaluations heuristiques. La moyenne du L des 12 évaluations est de 0,31. Par la suite, Nielsen retiendra cette valeur type L de 0,31 (Alertbox, 2000).

Donc par exemple, pour

• N = 20 problèmes au total.
• i = 5 utilisateurs,
• L = 0,31

P(5) = 20 (1-(1-0,31)⁵) = 16,87 problèmes trouvés sur 20 au total soit 85%

La question subsidiaire c’est comment trouver N le nombre total de problèmes ? Vu qu’on ne peut le connaître qu’a posteriori ? Il peut être estimé avec un modèle statistique à partir du moment ou vous avez plusieurs utilisateurs qui ont réalisé le test. Nous y reviendrons.

Et le retour sur investissements.

Un point important de cet article est aussi l’aspect financier des méthodes d’évaluations (test ou évaluation heuristique). Les auteurs comparent le coût de plusieurs techniques en fonction du nombre de participants et du taux d’erreurs trouver. Sur la base des calculs précédents, avec un L = 0,31, ils montrent que les tests ont un retour sur investissement optimal pour 5 utilisateurs, les évaluations heuristiques pour 3 ou 4 évaluateurs.

5 utilisateurs, ça ne suffit pas !

Une première étude de Jared Spool et Will Schroeder (2001) montre qu’un test 5 utilisateurs ne donne pas 85 % des problèmes. L’étude propose d’observer 49 utilisateurs sur 4 sites Web.

Le taux de découverte d’un nouveau problème d’utilisabilité est mesuré sur les 6 premiers utilisateurs, puis les auteurs estiment le nombre total de problèmes par sites et déterminent le nombre d’utilisateurs nécessaires pour les découvrir tous. Sur les deux premiers sites testés, après 5 utilisateurs seulement 35% des problèmes sont trouvés. La valeur L pour ces sites est de 0,1.

Une deuxième étude d’Alan Woolrych et Gilbert Cockton remettent en cause aussi la valeur L de 0,31. Ils précisent que cette variable pourrait être remplacée une fonction de densité de probabilité plus réaliste. Point important aussi la gravité des problèmes, n’est pas pris en compte dans le modèle de Nielsen et Landauer.

Que sait-on des méthodes d’évaluations ?

Je vais résumer ici une série d’études « Comparative usability évaluation » réalisée notamment par Rolf Molich qui compare donc les différentes méthodes d’évaluations des IHM. Le but des études est d’apporter des réponses aux questions suivantes :

• Quelles méthodes sont actuellement utilisées par les professionnels ? Est ce que certaines méthodes sont abandonnées par les professionnels ?
• Les résultats des évaluations sont ils reproductibles ?
• Comment estimer qu’un problème est sérieux ou critique ?
• Quel est l’ordre de grandeur du nombre de problèmes d’utilisabilité sur un site Web ?
• Combien de participants sont nécessaires pour trouver le plus de problèmes critiques ?
• Est ce qu’il y a des différences de qualités entre les résultats obtenus par les différentes équipes ?
• Quel est le retour sur investissements ?
• Comment comparer tests utilisateurs et les analyses d’expert ?

CUE 4

Pour cette étude dix-sept équipes mesurent l’utilisabilité du site Web d’un hôtel. Neuf équipes basent leurs évolutions sur des tests utilisateurs. Les huit autres utilisent des analyses d’experts. Les équipes relèvent 340 problèmes d’ergonomie. Seuls neufs de ces problèmes sont relevés par plus de la moitié des équipes, alors que 205 problèmes (60 %) ne sont relevés qu’une fois. 61 de ces problèmes étant jugés comme sérieux ou critiques. Seuls deux problèmes ont été reportés par 15 des équipes. L’étude montre aussi qu’il n’y a pas de différence notable entre les tests utilisateurs et les revues d’experts.

Pour l’étude, chaque équipe doit reporter au maximum 50 problèmes. Ces problèmes sont classifiés sur une grille allant de la remarque positive au bug technique en passant par les problèmes mineurs ou critiques. Cela permet de comparer les résultats avec les études précédentes.

• Problème mineur : L’utilisateur hésite quelques secondes.
• Problème sérieux : L’utilisateur perd une à cinq minutes, mais il peut continuer. Occasionnellement, cela peut causer une « catastrophe ».
• Problème critique : Cause de fréquentes « catastrophes ». Une catastrophe est une situation où le site Web met en échec l’utilisateur. L’utilisateur ne peut pas réaliser la tâche ou le site Web énerve considérablement les utilisateurs.

Les résultats sont donc comparés aux études précédentes. Il est intéressant de remarquer qu’une proportion élevée (60 % et plus) de problèmes dont certains sérieux ou critiques ne sont relevés que par une seule équipe.

CUE 8

Pour cette étude, quinze équipes différentes mesurent indépendamment l’utilisabilité d’un site de location de voiture (budget.com) avec différentes techniques. Il est demandé à chaque équipe de mesurer 5 tâches, et pour chacune de mesurer le temps par tâche, la réussite de la tâche et la satisfaction.

Les méthodologies employées sont assez diversifiées, avec ou sans la présence d’un expérimentateur, de 9 à 313 utilisateurs, des approches hybrides, avec ou sans vidéos…

Exemple de résultats pour l’étude CUE 8

Les résultats entre les différentes équipes sont aussi assez variables, soit parce que les méthodes ne mesurent pas les mêmes choses (par exemple le temps d’une tâche avec ou sans la lecture du scénario), soit les différences observées non pas été mise en évidence.

Ces mesures d’utilisabilité révèlent les faiblesses des méthodes de tests. CUE8 confirme donc la nécessité de respecter un certain nombre de règles pour une bonne méthodologie de mesure. Le résultat le plus intéressant de cette étude est que même les équipes professionnelles ne respectent pas toujours ces règles.

Conclusions

On voit que dans la réalité, établir la liste exhaustive des problèmes d’ergonomie est mission impossible. Même pour des objectifs identiques, des équipes différentes trouvent des résultats différents.

Les auteurs concluent de manière pragmatique :

• Les tests utilisateurs ne sont pas le standard de référence, c’est juste une méthode aussi valable que les autres.
• Passer moins de temps à trouver tous les problèmes, il y a peu de chances que vous y arriviez même avec 50 utilisateurs. Le mot d’ordre ne doit pas être « 5 utilisateurs suffisent à trouver 70% des problèmes d’ergonomie » mais « 5 utilisateurs suffisent pour conduire un processus itératif pertinent ».
• Les analyses d’experts sont aussi efficaces que les tests utilisateurs.
• Il faut concentrer les ressources dont on dispose sur ce qui est pertinent. Même avec des moyens faibles, il est possible d’alimenter le processus de conception.

Alors, comment faire ?

Déjà, il me paraît nécessaire de se reposer la question : « pourquoi faire des tests utilisateurs ? » Pour valider, un service avant le proposer sur le marché ? Pour détecter et éliminer tout ou une partie des problèmes d’ergonomie ? Pour se rassurer ? Pour aboutir des recommandations ? Pour comparer avec une autre version du service ?

Clairement la réponse est essentielle. Avant de choisir telle ou telle méthode d’évaluation, il est nécessaire de fixer les objectifs à atteindre, faire des hypothèses et savoir ce que vous voulez mesurer.

Brièvement, je pense que les méthodes à employer sont les suivantes, en fonction de l’avancement du projet :

• En début de projet, quand vous ne disposez que d’une maquette, une évaluation heuristique par deux ou trois personnes (pas nécessairement des experts) est un bon moyen de défricher le terrain.
• Des tests utilisateurs avec un faible nombre de participants, de l’ordre 5, peuvent en suite être pertinent en cours de développement, dès qu’un prototype existe ou que certains parcours sont fonctionnels. Le but n’étant pas d’avoir relevé x % des problèmes mais simplement d’avoir suffisamment de problèmes à corriger.
• En fin de projet, pour valider le service, une évaluation avec une méthodologie précise comme celle proposée par la norme ISO 20282, permet de s’assurer de la qualité l’ergonomie.

Des tests avec plus d’utilisateurs peuvent être aussi envisagés, par exemple, si vous « récupérez » un service en l’état et qu’il faut faire un état des lieux.

Bon, alors combien d’utilisateurs faut-il pour trouver 85 % des problèmes d’ergonomie ?

Pour répondre à cette question, il est nécessaire de faire un pré-test sur votre site, avec quelques (5 ou 6)  utilisateurs. Des vrais utilisateurs correspondant à votre population cible, même si avec 5 ça ne sera pas forcément très représentatif. Sur ce pré-test, vous relevez les problèmes d’ergonomies pour chacun des utilisateurs.

Après vous rendez sur cette page, au 2éme chapitre : « Estimate Problem Occurrence (p) then Sample Size ». Vous remplissez la matrice, et hop, c’est magique, vous obtenez la réponse, par exemple :

Given 15 total problems and 4 unique problem(s), the adjusted problem occurrence is 0.2. Which is the avg of Normalization: 0.14 and GT: 0.26. For the goal of discovering 85% of all problems available for discovery, the recommended sample size is 9 participants.

Ce n’est pas beau ça !

Voila, pour résumer, la probabilité qu’un utilisateur de rencontrer un problème d’ergonomie dépends du site, de l’utilisateur et des évaluateurs. Le sujet des tests utilisateurs est toujours un sujet sensible, sujet à polémiques, car nombre de métiers s’y intéressent et voudraient « faire dire des choses » aux utilisateurs. J’espère ne pas faire trop de malheureux en faisant descendre le mythe du « 85% pour 5 utilisateurs » de son piédestal !

Sources :

Articles

• « A mathematical model of the finding of usability problème, », Nielsen, Jakob, and Landauer, Thomas K. Proceedings of ACM INTERCHI’93 Conference (Amsterdam, The Netherlands, 24-29 April 1993), pp. 206-213.
• Why and When Five Test Users aren’t Enough, Alan Woolrych, Gilbert Cockton, IHM-HCI’2001
• testing Web sites : Five user is nowhere near enough, Jared Spool, Will Schroeder. CHI 2001
• Determining Usability Test Sample Size, Carl W. Turner*, James R. Lewis†, and Jakob Nielsen, International Encyclopedia of Ergonomics and Human Factors, 2006, Second Edition, Volume 3.
• Comparative usability evaluation (CUE-4), Rolf Molich; Joseph S. Dumas ; Behaviour & Information Technology, 1362-3001, Volume 27, Issue 3, First published 2008, Pages 263 – 281
• Rent a Car in Just 0, 60, 240 or 1,217 Seconds? (CUE-8) Rolf Molich, Tomer Sharon ; Comparative Usability Measurement, CUE-8, Journal of usability studios, 2009,

Web

• http://www.measuringusability.com/analytic-testing.php
• http://www.useit.com/alertbox/20000319.html
• http://www.dialogdesign.dk/cue.html