03 Janvier 2004

Recette de test utilisateur, Partie 1

Introduction

Cet article propose une recette de test utilisateur. On peut parler de recette parce que mettre en place un test nécessite de passer par plusieurs étapes. Chacune de ces étapes exige des ingrédients spécifiques. Il est important de savoir où se procurer ces ingrédients et comment les mêler.

Comme pour les recettes de cuisine, la dextérité vient avec l'expérience. Sauf qu'en ergonomie, le contexte est toujours différent. Les projets sont différents, les interfaces et les gens aussi. On doit donc adapter la recette à ce contexte pour ne pas rigidifier la démarche.

Comprendre l'importance des tests utilisateurs n'implique pas de pouvoir les conduire. Il faudra avoir saisi les enjeux du test, les méthodes à appliquer, les données à recueillir, la manière de présenter les résultats…

La façon de conduire un test utilisateur dépend en grande partie du budget accordé à l'ergonomie dans le projet. L'important est de ne pas négliger certaines étapes et de se faire aider par des supports organisationnels (notes, grilles, check-lists, programmes…). Suivre les conseils des gens qui ont de l'expérience est enfin la meilleure façon de comprendre les points-clés de la démarche et ses pièges.


» Pré-requis

Notre présentation part du principe que l'on a pris connaissance de l'interface et identifié les objectifs du projet.

Le choix de la méthode du test suppose que le projet soit d'ampleur suffisante pour l'avoir fait précéder d'autres analyses (consultation libre des utilisateurs, tri de cartes, analyse des tâches, analyses concurrentielles, inspection experte d'une interface existante…).

S'il s'agit d'un projet de refonte, on aura auparavant conduit une évaluation experte sur la base des normes et critères existant en ergonomie des interfaces (lire à ce propos l'article sur les critères ergonomiques de Bastien & Scapin). Cette évaluation sera la base du test et permettra de se concentrer sur des points déterminés.


Nous détaillons dans cet article les étapes sous-jacentes à la conduite d'un test utilisateur classique. La conception de tests à distance est plus spécifique et nécessite certains aménagements.

De façon globale, conduire un test utilisateur, c'est :

- Préparer le test
- Tester
- Analyser les tests et en tirer quelque chose

Ces 3 grands objectifs peuvent être détaillés selon les activités requises pour les atteindre. On peut définir 10 étapes pour conduire un test utilisateur :

1. Identifier la cible utilisateur et ses caractéristiques

La nature des tests utilisateur diffère selon le projet pour lequel est conduit l'évaluation. L'élément qui différencie le plus ces tests sont les participants.

Avant toute chose, il est donc indispensable de se renseigner sur la population cible de l'interface. Cette étape se base sur l'analyse de la demande.

On doit définir précisément les caractéristiques des utilisateurs cibles (catégorie socio professionnelle, âge, expérience Internet ou avec l'outil informatique…). Si la cible présente des caractéristiques particulières, on devra les décrire précisément.

S'il s'agit d'un projet de refonte, on doit savoir s'il existe des utilisateurs experts, une communauté d'utilisateurs que l'on pourrait contacter, des réclamations, commentaires d'utilisateurs sur l'application existante. Si c'est le cas, on devra les analyser.

2. Identifier les objectifs des utilisateurs. Identifier les tâches des utilisateurs et leur importance respective dans la réalisation de chacun des objectifs. Choisir les tâches que l'on va évaluer.

Cette phase est indispensable puisque c'est à partir de ces données que l'on pourra concevoir des scénarios de test adaptés.

Il est en effet essentiel d'identifier les objectifs des utilisateurs afin de pouvoir concevoir le plan de test. Cette identification sert de base pour définir les tâches des utilisateurs et leur importance respective dans la réalisation de chacun des objectifs. Cela permet de choisir les tâches que l'on va évaluer.

Si on prend pour exemple un site d'e-commerce, on peut déterminer comme tâches critiques à tester la commande d'un produit précis, la recherche du prix d'un produit, la recherche des coordonnées du service après-vente…

3. Recruter et prendre rendez-vous avec les utilisateurs

» Echantillonnage

Lorsqu'il s'agit de recruter les participants, on doit le faire en fonction de l'analyse de la population cible. C'est cette analyse qui va conditionner l'échantillonnage des participants.

Les critères de recrutement sont classiquement la catégorie socio professionnelle, l'âge, l'expérience Internet ou avec l'outil informatique. Ces critères sont différents en fonction du type de cible (grand public ou professionnelle).

Sauf si la population à laquelle s'adresse l'interface est très ciblée, on doit veiller à recruter des utilisateurs de niveaux variés, de différentes tranches d'âges et de genres.

On peut s'adresser à des sociétés de recrutement spécialisées, passer une annonce en ligne ou dans un journal papier ou faire appel à son réseau de connaissances. Pour des applications professionnelles, on doit recruter des utilisateurs dans le domaine cible.


» Le recrutement dans le processus du test utilisateur

L'étape de recrutement des participants est souvent placée bien plus tard dans une recette de test utilisateur. Cependant, la courtoisie veut que l'on contacte les participants au moins 15 jours avant le début des tests. Logiquement, c'est donc l'une des premières choses à effectuer. Lorsque l'agenda des tests sera planifié, on pourra procéder à leur mise en place.

Lors de sa présentation aux participants potentiels, le test doit être dédramatisé : ce n'est pas une expérience sordide mais plutôt une sorte de jeu, un essai d'un site.


» Combien de participants ?

Une question récurrente concerne le nombre d'utilisateurs idéal pour obtenir des résultats optimaux.

Nielsen & Landauer avaient proposé en 1993 que 5 utilisateurs permettraient de cerner 80% des problèmes principaux d'utilisabilité. Depuis, plusieurs études ont pondéré ces résultats (voir notamment dans les lectures complémentaires Spool & Schroeder et Woolrych & Cockton).

Le problème qui se pose dans ces évaluations d'un nombre "idéal" d'utilisateurs vient de la nature même des expérimentations. L'hétérogénéité des résultats obtenus peut en partie être expliquée par le fait que le type d'interface de travail est différent et que les tâches de l'utilisateur sont différentes.

Il paraît difficile de poser de façon péremptoire un nombre d'utilisateurs nécessaire et suffisant. On peut uniquement essayer de trouver un compromis entre les exigences financières, temporelles et d'interface. Le plus important sera de faire appel à des utilisateurs qui sont les utilisateurs finaux de l'application ou pourraient l'être.

Dans la pratique des tests utilisateurs, un consensus semble se faire autour de 8 à 10 utilisateurs. On considère que c'est la plupart du temps un compromis raisonnable entre coût de l'intervention et résultats obtenus.


» Une démarche cyclique

De plus, on peut choisir de procéder à plusieurs "petits" tests (avec moins d'utilisateurs), plutôt que conduire un seul test avec un nombre plus important de participants.

Cette démarche itérative paraît apporter des résultats très intéressants et permet d'intégrer de nouvelles données dans les sessions de test. Elle permet aussi de ne pas être confronté à un problème réccurent avec tous les participants. Si tous les participants d'un premier test butent sur le même problème, on essaiera de le résoudre et de tester la solution dans un second test.





Procédure de test linéaire : une session de test avec 12 participants VERSUS Procédure de test itérative : deux sessions de test avec 6 participants.

Deux types de procédures de test : procédure linéaire vs procédure itérative.
Lors d'un fonctionnement itératif, les résultats du premier test sont le support des phases suivantes.




4. Préparer le plan de test en fonction des objectifs d'utilisabilité

» Les objectifs d'utilisabilité

Un plan de test doit se baser sur des objectifs d'utilisabilité qualitatifs et quantitatifs. (Si on prend de nouveau pour exemple un site d'e-commerce, on pourrait énoncer comme objectif : "100% des utilisateurs doivent réussir à trouver le prix de l'article machin en moins de 4 clics et sans l'ajouter au panier").

Le but du test est de trouver ce qui va et ce qui ne va pas dans l'interface. On peut évaluer les critères suivants :

- Réussite à la tâche,
- Temps de réalisation de la tâche
- Nombre de clics nécessaires pour réussir la tâche
- Nombre d'erreurs
- Nature des erreurs (clic sur une mauvaise rubrique du menu, sur un lien inadapté, oubli d'effectuer une action…)
- Compréhension de la terminologie …

À chacun de ces critères doivent être affectés des échelles d'acceptabilité. Exemples :

- Quel est le nombre d'erreurs au-delà duquel on considère que la tâche est trop complexe ?
- Quel est le nombre de clics maximal acceptable pour trouver le prix de n'importe quel produit ?
- Quel pourcentage d'utilisateurs ne réussissant pas à commander un produit peut-on accepter ?

Les objectifs d'utilisabilité peuvent être de deux types :
- absolus ("90% des participants doivent pouvoir trouver l'adresse e-mail du service éditorial en moins de 15 secondes")
- relatifs ("90% des participants doivent pouvoir trouver l'adresse e-mail du service éditorial plus rapidement que sur l'ancien site")

Ces objectifs permettent de concevoir les scénarios de navigation évaluant les tâches critiques.


» Le plan de test

Le plan de test est constitué d'une liste de questions, scénarios, et points-clés que l'on doit explorer pendant le test.

Un plan de test consiste donc à décrire de façon détaillée les scénarios de navigation permettant d'évaluer les tâches-clés, ou de délimiter la partie de l'application / du site web pour laquelle on prévoit une navigation libre.

Le scénario peut être rendu plus crédible lorsqu'il réunit plusieurs questions, afin de simuler une véritable activité de l'utilisateur sur le site.

Il est essentiel d'inclure dans le plan de test des étapes de recueil de descriptions subjectives de l'expérience (concernant la réalisation d'une tâche en particulier ou de la navigation globale dans le site). La satisfaction utilisateur est en effet une des composantes de l'utilisabilité d'une application.


» Type de protocole

Le scénario peut être présenté à l'utilisateur de façon écrite ou orale. On peut aussi concevoir des protocoles combinant des présentations orales et écrites. Chacun de ces protocoles présente des avantages et des inconvénients.

Un protocole écrit permet de conserver une distance à l'utilisateur, mais présente le risque d'être mal interprété. De plus, la rigueur qu'il introduit dans le test peut mettre l'utilisateur mal à l'aise. Enfin, il éloigne le participant d'une situation potentiellement réelle d'utilisation.

A l'inverse, un protocole oral permet d'orienter le test vers une dimension plus réaliste et humaine. Il nécessite cependant une grande rigueur de la part de l'ergonome puisque les scénarios doivent toujours être proposés de la même manière. En outre, la présentation orale est plus susceptible d'entraîner des questions de la part de l'utilisateur. Les réponses à ces questions sont encore un risque d'influencer l'utilisateur dans ses réponses.

Le choix d'un protocole écrit ou oral est souvent lié aux préférences individuelles de l'ergonome et à ses convictions concernant les façons "idéales" de conduire un test.


» Durée du test

On évitera de faire durer le test plus d'une heure. Cela semble le maximum acceptable compte tenu de ce que l'on sait du fonctionnement attentionnel. On peut envisager de conduire des tests plus longs si on introduit une pause.

5. Préparer pré et post questionnaires

» Le pré-questionnaire

Le pré-questionnaire peut se présenter comme une entrée en matière. Il permet d'introduire l'utilisateur au test et de recueillir des informations de base. C'est aussi le moment d'obtenir l'accord du participant si l'on envisage de le filmer.

Ce pré-questionnaire peut être administré avant même de recruter les utilisateurs, puisque les réponses permettront de sélectionner des participants représentatifs de la cible finale.

Il inclut notamment des questions liées au niveau d'expertise de l'utilisateur (expertise informatique ou de la navigation sur internet). On peut poser des questions plus
précises sur les durée et fréquence des utilisations.

Le questionnaire sera conçu en fonction de l'interface à évaluer. S'il s'agit d'un projet de refonte, il peut servir à recueillir des informations liées à l'expérience de l'application, ou à l'expertise concernant la tâche principale supportée par l'application (exemple pour un site d'e-commerce, expérience de l'achat en ligne).

Dans le cas d'une application professionnelle, le pré-questionnaire sera orienté métier.


» Le post-questionnaire

Le post questionnaire permet de recueillir des données globales sur la passation, et notamment le ressenti subjectif. C'est aussi l'occasion d'expliquer certaines phases du test.

Conclusion

La seconde partie de cet article détaillera les phases plus pratiques du test utilisateur : préparation du matériel, passation du test, analyse et restitution des résultats.
> lire la seconde partie

Pour en savoir plus


» Ressources en ligne


http://www.stcsig.org/usability/resources/toolkit/toolkit.html

Formulaires, checklists et documents pour supporter la conduite d'un test utilisateur.


Grant Consulting. A Usability Test Storyboard.

Perfetti, C. & and Landesman, L. Eight Is Not Enough. User Interface Engineering.

Usability.gov. Conducting and Using Usability Tests.

Fast, K. (2002). Recording Screen Activity During Usability Testing. Boxes and Arrows, How to: Methods & Approaches.

Grant, J. (2002). Do-It-Yourself Usability Testing.

Light, A. (2001). "Discount" user testing under fire. Usability News.

Spool, J. & Schroeder, W. (2001). Testing Web Sites: Five Users Is Nowhere Near Enough. Proceedings of ACM CHI Conference on Human Factors in Computing
Version électronique sur www.winwriters.com (fichier pdf, 122 Ko).

Woolrych, A. & Cockton, G. (2001). Why and when five test users aren't enough. Proceedings of IHM-HCI 2001, Volume 2, 105-108. Toulouse, France.
Version électronique sur netraker (fichier pdf, 215 Ko).

Gordon, S. (2000). How to Plan, Execute, and Report on a Usability Evaluation. (première partie : Defining your goals).

Kirby, L. (2000). Professional Website Usability. SitePoint.

Nielsen, J. (2000). Why You Only Need to Test With 5 Users. Alertbox, March 19, 2000.

Fleming, J. (1998). User Testing - How to find out what users want.

Kuniavsky, M. (1998). Why User testing is good.


» Ressources externes

Rubin, J. (1994). Handbook of Usability Testing. John Wiley and Sons, New York, NY.

Nielsen, J. & Landauer, T. K. (1993). A mathematical model of the finding of usability problems. Proc. ACM 1NTERCHI '93, Amsterdam, The Netherlands, 206-213.

Dumas, J.S. & Redish, J. (1993). A Practical Guide to Usability Testing. Ablex, Norwood, NJ.



» A voir aussi sur Ergolab

[03.01.2004]

Recette de test utilisateur, Partie 2

La première partie de cet article définissait les étapes initiales de la mise en œuvre d'un test utilisateur. Cette seconde partie détaille les phases plus pratiques...

» Lire l'article
» http://www.ergolab.net/articles/test-utilisateur-ergonomie-2.php


Ergonomie web

Amélie Boucher

» Lire la chronique
» http://www.ergolab.net/livres/ergonomie-web.php


Don't make me think

Steve Krug

» Lire la chronique
» http://www.ergolab.net/livres/don-t-make-me-think.php