Pourquoi tester ses supports web avec au moins 5 testeurs ?
Pourquoi tester ses supports web avec au moins 5 testeurs ?Une question qui revient souvent est : « Est-ce que vous avez vraiment besoin de réaliser des tests avec 5 utilisateurs ou plus lors d'un test utilisateur ? »
Il y a beaucoup d'opinions bien arrêtées sur le chiffre magique de 5 tests d'utilisabilité et beaucoup d’encre a coulé à propos de ce sujet ! Comme vous pouvez l'imaginer, il n'y a pas un nombre fixe d'utilisateurs qui sera toujours le bon nombre, mais les test avec cinq utilisateurs peut être suffisant pour découvrir les problèmes dans une interface, compte tenu de certaines conditions. Le test utilisateur...
En moyenne, 5 utilisateurs seront en mesure de détecter environ 85% des problèmes dans une interface, étant donné que la probabilité qu'un utilisateur se heurte à un problème est d'environ 31%. La plupart des gens ne se soucient pas de la 2ème partie de la phrase précédente par omission ou par incompréhension. De plus, cette valeur de 31% ne s'applique pas à toutes les situations de test tels que la comparaison de deux éléments. Dans ce cas, d'où viennent ces 31% ?
Malgré l'efficacité des formules mathématiques de travail, ces dernières peuvent rappeler de mauvais souvenirs à beaucoup d'entre vous et Testapic a donc fourni des simulations ci-dessous pour vous montrer comment cela fonctionne. Test utilisateur.
Test utilisateur "pile ou face" (50% de probabilité)
Nous savons tous qu'il y a une probabilité de 50% d'obtenir pile et 50% de chances d'obtenir face quand on joue à pile ou face. Si vous avez voulu savoir combien de fois vous devez planifier le pile ou face pour voir le pile au moins une fois, en utilisant la formule du binôme, la réponse est 3. Vous pouvez répéter cet exercice et voir que la taille de l'échantillon à considérer tend vers 3.
Probabilité par du lancer de dé (16,7% de probabilité)
Il ya un 1/6 de chance d'obtenir un nombre quelconque d'un dé à 6 faces. Donc, sur n'importe quel lancer, il y a une chance 16,667% d'obtenir un 1. La formule du binôme prédit que vous aurez besoin de lancer un dé en moyenne 10 fois pour être à 85% sûr que vous allez obtenir au moins un 1.
Détection de problèmes qui affectent 31% des utilisateurs grâce au test utilisateur
Combien d'utilisateurs avez-vous d'essai à 85% sûr que vous allez voir un problème qui touche 31% des utilisateurs au moins une fois ? 5 ou moins !
Détection de problèmes qui affectent 10% des utilisateurs dans le test utilisateur.
Combien d'utilisateurs avez-vous de tester pour être à 85% sûr que vous allez voir un problème qui touche 10% des utilisateurs au moins 1 fois ? La réponse est 18 testeurs.
Détection de problèmes lors du test utilisateur qui touchent 1% des utilisateurs
Combien d'utilisateurs avez-vous de tester pour être à 85% sûr que vous allez voir un problème qui touche 1% des utilisateurs au moins 1 fois ? La réponse est 189 testeurs.
Combien d'utilisateurs ai-je donc besoin lors d'un test utilisateur ?
Tous les problèmes ne touchent pas 31% des utilisateurs. En fait, dans les logiciels publiés ou sur des sites Web, la probabilité de rencontrer un problème pourrait être plus proche de 10% ou 5%. Ainsi, moins des problèmes sont susceptibles d'être détectés par les utilisateurs, plus vous avez besoin de tester un nombre important d'utilisateurs pour avoir une chance raisonnable de les observer dans un test d'utilisabilité ou test utilisateur.
[box_info]Donc, si vous prévoyez d'effectuer des tests avec cinq utilisateurs, sachez que vous n'êtes pas susceptible de voir la totalité des problèmes. Néanmoins, vous pourrez mettre en avant la plupart des problèmes qui affectent 31% de cette population sur un ensemble de tâches.[/box_info]
Pourquoi la controverse sur le nombre optimal de testeurs ?
Il n'y a aucun problème avec la formule du binôme (ou celle de Poisson), la controverse se situe autour de la fréquence des problèmes, par exemple d'assurance, lorsque ces derniers se produisent trop fréquemment. En réalité, ils ne sont pas un pourcentage figé comme 31% ou 10%, au lieu de cela, ils représentent une fréquence moyenne d'occurrence du problème.
Le problème vient donc du fait de ne pas affecter les utilisateurs de manière totalement uniforme, ou d'affecter les utilisateurs d'une manière aisément prévisible. Bien qu'il soit difficile de connaître la fréquence à laquelle les problèmes surviennent, en règle générale, pour les premiers modèles, ce pourcentage sera plus élevé (31% ou plus) et pour les applications qui sont utilisées par de nombreux utilisateurs, ce % sera probablement inférieur à 10%. Bien sûr, vous ne savez pas quelle est la probabilité qu'un utilisateur rencontre un problème. En fait, vous ne savez souvent même pas s'il y a un problème si vous y remédiez ! Grâce aux test utilisateur, vous pourrez désormais le savoir et le mesurer.
Comme stratégie d'études, nous vous conseillons de choisir un certain % d'occurrence du problème, disons 20%, et la probabilité de la découverte, disons 85%, ce qui signifie que vous aurez besoin d'effectuer votre test sur au moins 9 utilisateurs. Après avoir testé 9 utilisateurs, vous savez que vous avez détecté la plupart des problèmes qui affectent 20% ou plus des utilisateurs. Si vous avez besoin d'être plus certain des résultats, augmentez la probabilité de la découverte, par exemple, à 95%. Cela augmentera la taille de l'échantillon nécessaire à 13 testeurs pour votre test utilisateur.
La meilleure stratégie est de tester un certain ensemble d'utilisateurs, de détecter les problèmes qu'ils ont rencontré, de régler ces problèmes, puis de concevoir une réalisation itérative de test afin de détecter des problèmes de moins en moins décelable et de plus en plus fin. Même si vous n'utilisez pas plus de 5 testeursà la fois, au total, vous aurez surement besoin de tester 15 ou 20 utilisateurs sur une série de 4 à 5 tests. En fait, c'est ce que Nielsen recommande dans son article, et non pas seulement de tester 5 utilisateurs au total.
Donc, si vous prévoyez de tester 5 utilisateurs, sachez que vous n'êtes pas susceptible de voir la plupart des problèmes, vous êtes simplement enclin à détecter la plupart des problèmes qui affectent 31% d'utilisateurs de cette population sur un ensemble de tâches. Avec un peu de chance, vous pourrez également collecter quelques-uns des problèmes qui touchent moins de 31% des utilisateurs, pas seulement 85% d'entre eux, dans votre test utilisateur.