Il existe beaucoup d’idées fausses à propos du cadre de validité d’un test avec 5 utilisateurs. Aucune raison ne saurait justifier un point de vue extrême sur cette question, qui consisterait à penser que ce nombre de participants n’est jamais approprié, ou bien que c’est toujours le bon. Pour ne pas avoir une opinion aussi tranchée, il faut comprendre ce qui peut être apporté et ce qui ne peut pas l’être par un test avec un faible nombre d’utilisateurs.

1. 5 utilisateurs détecteront des problèmes les plus visibles

Si un problème d’utilisabilité touche plus de 31 % des utilisateurs de votre application ou site web, il est très probable que vos tests permettent de le détecter. Il est très important de se rappeler que vous ne serez limité qu’à une détection de problèmes affectant de nombreux utilisateurs – c’est-à-dire 1 utilisateur sur 3, ce qui représente une occurrence importante. Avec seulement 5 utilisateurs, il est également possible de détecter des problèmes moins évidents – rencontrés par un utilisateur sur 10 - mais ce n’est pas du tout assuré.

2. Vous pouvez faire 5 tests en un seul jour dans le cas où vous décidez de réaliser des tests physiques

Avec la popularité de la méthode agile et du Lean UX, il est souvent impératif d’avoir des retours très rapides ce qui explique en partie l’essor rapide des tests utilisateurs distants. Les emplois du temps sont difficiles à coordonner, et la réalisation d’applications stables et accessibles est un vrai challenge. Si vous décidez de les réaliser vous même physiquement, prévoyez donc au minimum 1 jour de tests, de préférence répartis à intervalles réguliers. Dans une journée de 8 heures comprenant une session de tests d’une heure, quelques pauses toilette, quelques utilisateurs lents, des problèmes techniques et un débriefing avec l’équipe, 5 utilisateurs est le maximum que votre emploi du temps et votre cerveau d’animateur vous permettront de gérer.

3. Vous pourrez identifier les problèmes fréquents

Si vous constatez que chacun de vos 5 utilisateurs rencontre une difficulté avec un élément d’une interface, il est très probable que ce soit le cas pour plus de 71% de l’ensemble des utilisateurs. C’est une preuve statistique convaincante, même à très petit échantillon, que l’interface nécessite d’être modifiée. Cette valeur est obtenue en considérant la limite inférieure de l’intervalle de confiance binomiale.

4. Un meilleur moyen d’identifier les problèmes et les régler

Si vous avez un budget permettant de faire participer 10 ou 15 utilisateurs dans les phases de tests de début du développement, il est préférable de répartir ces participants en 2 ou 3 groupes de 5 utilisateurs. Quand vous observez des problèmes rencontrés par la plupart de ces 5 utilisateurs, ou rencontrés par un seul participant mais qui peuvent être réglés facilement, essayez de tous les traiter avant le prochain groupe de tests. Le recrutement des participants, la rédaction des protocoles et la mise en place d’un environnement stable prennent beaucoup de temps. Observer les mêmes utilisateurs se confronter encore et encore aux mêmes problèmes est une perte de temps, si vous savez qu’ils devraient être réglés. Pire encore, certains problèmes d’utilisabilité peuvent en fait être masqués par d’autres problèmes qui empêchent les utilisateurs d’avancer dans leurs tâches. 5 utilisateurs donnent un bon point de départ, vous permettant de faire les ajustements nécessaires avant la prochaine session de tests.

5. Si les 5 utilisateurs réussissent une tâche, au moins 70 % des utilisateurs la réussiront également

Bien qu’il soit difficile de montrer avec peu de tests qu’une application ou un site est très facilement utilisable, dans certains cas nous avons suffisamment de preuves pour montrer une utilisabilité suffisamment bonne. Dans le cas où les 5 utilisateurs réussissent une tâche, il y a 90 % de chance que le pourcentage des utilisateurs (dans la même cible d’utilisateurs) qui réussissent cette tâche soit compris entre 71 % et 100 %. L’approche mathématique est la même que pour l’estimation de la fréquence des problèmes d’utilisabilité – l’intervalle de confiance.Bien que cela ne se produise pas pour toutes les tâches d’un test, cet intervalle de confiance est atteint pour au moins une tâche dans la plupart des tests utilisateurs. A partir de là, nous avons suffisamment de preuves que cette tâche peut être réalisée sans difficulté, et il est plus utile de faire s’essayer les participants à une autre tâche, ou d’explorer une autre partie de l’interface lors de la prochaine phase de tests.

5 raisons pour lesquelles vous ne devriez pas faire de tests avec seulement 5 utilisateurs

1. Vous voulez détecter des problèmes moins évidents

Par définition, si un problème d’une interface n’affecte qu’une petite partie de vos utilisateurs, il sera plus difficile de le détecter lors d’un test avec peu de participants. Avec un panel de 5 utilisateurs, il n’y a que 23 % de chance d’identifier des problèmes touchant 5 % des utilisateurs totaux. De même, avec 5 utilisateurs, il n’y a que 5 % de chance de détecter des problèmes rencontrés par un utilisateur sur 100. Il n’est pas impossible de détecter ces problèmes peu fréquents, mais cela est moins probable et ce n’est pas une chose sur laquelle vous devez compter avec 5 utilisateurs. C’est l’erreur la plus commune qui est faite avec la règle des 5 utilisateurs – 5 utilisateurs ne découvriront pas 85 % des problèmes, mais 85 % des difficultés les plus évidentes, où évidentes signifie environ 1 utilisateur sur 3.

2. Vous voulez voir si un design permet un meilleur taux de réussite qu’un autre

Avec un panel de seulement 5 utilisateurs, même la plus grande différence de taux de réussite entre différents designs d’interfaces ne sera pas significative. Si vous avez besoin de comparer les taux de réussites entre différents designs, vous devriez miser sur un plus grand nombre d’utilisateurs.

3. Vous voulez des mesures à faibles marges d’erreur

Si vous souhaitez estimer le pourcentage d’utilisateurs qui réussissent une tâche ou ont un problème avec un élément du design, la marge d'erreur pour un échantillon de 5 utilisateurs est d'environ + / - 34 %. Pour un échantillon de 20 utilisateurs, vous aurez une marge d'erreur d'environ 20% et pour réduire la marge d'erreur de moitié, vous devrez environ quadrupler la taille de l'échantillon. Si vous voulez estimer le taux de réussite à + / - 10 %, vous devriez organiser des tests avec environ 80 utilisateurs.

4. Vous voulez vous assurer qu'au moins 90 % des utilisateurs pourront effectuer une tâche

Même si les cinq utilisateurs réussissent une tâche, vous ne pouvez être sûr qu’à 75% que le pourcentage d’utilisateurs total qui la réussiront également sera supérieur à 90 %. Même si ce résultat est bien meilleur qu’une chance sur 2, ce n’est pas une probabilité assez élevée pour vous assurer que la plus grande majorité des utilisateurs pourront compléter la tâche avec succès.

5. Vous voulez détecter les problèmes d'utilisation les plus graves

Un faible nombre de participants, par définition, va repérer les problèmes d'utilisabilité les plus fréquents, mais ces problèmes seront-ils les plus graves ?Il ne faut pas confondre le nombre d'utilisateurs affectés par un problème et la gravité de l’impact que celui-ci peut avoir sur l’expérience utilisateur. Notre analyse suggère que la fréquence et la gravité des problèmes sont indépendantes, et que les difficultés ayant un impact plus négatif sur l'expérience sont tout aussi susceptibles de se produire avec une fréquence faible que les autres difficultés.

Conclusion

Un mix de problèmes critiques et superficiels peut être repéré par un faible nombre d’utilisateurs, mais vous ne devez pas vous attendre à une détection fiable des problèmes les plus critiques avec seulement 5 utilisateurs. Ceci illustre le fait qu’avec un petit échantillon, il est plus difficile de montrer qu’une application ou un site est utilisable que de montrer l’inverse. Pour garantir un pourcentage plus élevé d'utilisateurs pouvant effectuer une tâche, vous aurez besoin de plus de cinq utilisateurs (une taille d'échantillon de 20-30 – sur une cible donnée - serait le minimum dont vous aurez besoin, et seulement si tous les 20-30 utilisateurs réussissent la tâche). Source

Publié par : - Classé dans : Best practices

Ces articles peuvent vous intéresser

Pas d'articles liés.