rechercher sur ergolab

s'abonner au fil rss
newsletter

Entrez votre adresse e-mail pour être informé de l'ajout de nouveau contenu :

 

» En savoir plus

03 Janvier 2004

Recette de test utilisateur
Partie 2

TAGS : Méthodes, Test utilisateur

accueil > articles > pratiques > Recette de test utilisateur, Partie 2

« Liste des articles


Introduction
1. Développer le matériel de test
2. Pré-tester avec un ou deux utilisateurs
3. Conduire les tests
4. Analyser les résultats
5. Restituer l'analyse des résultats
Conclusion
Pour en savoir plus…

Introduction

La première partie de cet article définissait les étapes initiales de la mise en œuvre d'un test utilisateur (identification de la cible utilisateur, de ses caractéristiques et objectifs, recrutement des participants, préparation du plan de test, des pré et post questionnaires).

Cette seconde partie détaille les phases plus pratiques du test utilisateur (préparation du matériel, passation du test, analyse et restitution des résultats) :

1. Développer le matériel de test :

La conception du matériel se scinde en deux étapes :

1.1. Matériel conceptuel

= le support du test, ce qui concrétise le plan de test

On peut conduire des tests avec des maquettes papier (croquis ou pages imprimées de gabarits potentiels de pages), des prototypes ou une application en ligne (notamment pour les projets de refonte).

En conception, le plus intéressant semble de travailler sur des prototypes semi-fonctionnels (prototypes dans lesquels toutes les fonctionnalités ne sont pas actives).

Il semble assez pertinent de ne simuler la dynamique du site que pour les points potentiellement critiques (liens principaux du site, éléments de navigation, éléments spécifiques…).

Cette démarche est notamment très utile pour tester des processus (achat en ligne) et la navigation dans le site. Elle permet de faire un compromis entre le coût de développement du prototype et le réalisme d'interface obtenu.

Les outils les plus utilisés pour le prototypage rapide d'interfaces web sont PowerPoint, Html ou Flash.

1.2. Matériel de recueil de données

= matériel physique, tout ce dont on a besoin au niveau technique pour appuyer le matériel conceptuel

On peut aller du plus simple au plus sophistiqué :

- Papier / crayon pour la prise de notes

- Un ordinateur et les applications nécessaires pour lire le prototype.
Si les prototypes sont en html, on peut fixer la bande passante en fonction des caractéristiques de la cible. Des outils sont disponibles pour limiter le débit lors d'un test utilisateur. Ils permettent par exemple de simuler la visite du site sur un modem (voir à cet égard www.netlimiter.com).

- Un logiciel d'enregistrement de l'écran pendant la séquence d'utilisation. Le logiciel Camtasia de TechSmith semble aujourd'hui la solution technologique la plus fiable pour ce type d'enregistrement. Il fournit de plus la possibilité d'accentuer les clics. D'autres applications servent toutefois le même objectif (voir dans les lectures complémentaires le comparatif de Karl Fast).

- Caméras, enregistrements audio, miroirs sans tain, outils de haute technologie (eye-tracking…)

Ces derniers outils sont coûteux à mettre en place, tant du point de vue financier et temporel, que technique. De plus, les données qu'ils permettent d'acquérir sont souvent très longues à analyser. Ils ne sont donc pas indispensables.

Un matériel plus simple ne donnera pas forcément de résultats de moindre qualité. Ça tombe bien car c'est moins cher, plus facile et plus rapide à mettre en oeuvre.

2. Pré-tester avec un ou deux utilisateurs

3. Conduire les tests

3.1. Familiarisation avec la procédure

Il est important d'expliquer aux participants la finalité d'un test. On doit notamment insister sur le fait que c'est bien l'interface qui est évaluée et non la performance de l'utilisateur.

3.2. Familiarisation avec le produit

Si c'est pertinent, on peut introduire une phase de familiarisation avec le produit, qui peut uniquement consister en une présentation verbale de l'application (voilà notre application, à quoi elle ressemble, ce à quoi elle sert globalement…) ou en une découverte guidée de l'interface.
Si on décide d'inclure cette phase de familiarisation, on doit cependant veiller à ce que cela n'entre pas en compétition avec la stratégie du test : s'il est évident que l'utilisateur ne doit avoir aucune confrontation avec l'interface avant de commencer le test, on ne préparera pas de phase de familiarisation.

3.3. Administration du pré-questionnaire

3.4. Test

En ce qui concerne la situation de test elle-même, j'adopte le principe que les influences environnementales ne peuvent ni ne doivent être éliminées à tout prix.

Ce choix est lié au fait que l'intérêt de conduire des tests sur le terrain est que l'on teste l'interface avec de vrais utilisateurs, dans une situation qui pourrait être réelle. Personne ne consulte un site web dans un environnement épuré, sans bruit, sans intervention de l'extérieur, sans perturbation possible.

On doit donc garder la situation de test informelle (voir illustration), et mettre l'utilisateur dans une situation opposée à celle d'un test.




Photos de deux situations de test utilisateur.

Situations typiques de tests utilisateurs écologiques.



On pourrait même aller jusqu'à dire que les éventuelles distractions créent une situation de test plus proche de la réalité. Les réponses et réactions seront plus spontanées si on est dans une discussion, une conversation, qu'un entretien.

Etre proche de l'utilisateur c'est aussi pouvoir interagir avec lui. Une des règles d'un test utilisateur est d'inciter l'utilisateur à "penser à voix haute", à verbaliser ses impressions, commentaires, envies, objectifs ("verbalisez ce que vous faites et pourquoi vous le faites").
Il semble difficile de croire qu'un utilisateur seul dans une pièce (qui de plus se sait filmé et enregistré) pourra respecter cette consigne. Il n'est pas naturel de parler à des murs.

Il est important de considérer le test utilisateur pour ce qu'il est dans la pratique. On n'est pas dans un laboratoire de psychologie expérimentale. Tout contrôler est intéressant dans une véritable étude fondamentale, avec un nombre de sujets qui permette de tirer des conclusions statistiques des résultats. Ce n'est souvent pas le but de l'ergonomie de terrain.
On vise plutôt à atteindre une situation de test écologique, qui corresponde à ce que l'utilisateur rencontre dans ses interactions habituelles avec ce type d'applications.

La personne qui conduit le test doit s'intégrer au test et interagir avec l'utilisateur, sans pour autant l'influencer. On doit donc rester objectif dans le test mais subjectif dans sa relation avec l'utilisateur. C'est un rôle très paradoxal mais qui semble le meilleur compromis à adopter.

Ne pas séparer l'ergonome et l'utilisateur, c'est cependant prendre le risque que l'utilisateur soit influencé par l'observateur.

On doit veiller à ne pas modifier le comportement de l'utilisateur par des paroles, gestes… Les questions posées ne doivent pas être orientées vers la réponse que l'on veut entendre ou observer. On s'attachera donc à respecter le "watch and learn" de Keith Instone.


» Combien d'experts?

Interagir avec l'utilisateur est en soi une activité à plein temps, qui demande beaucoup de ressources. Le plan de test doit être respecté, on ne doit pas oublier d'étapes, réagir de façon pertinente aux actions et réactions de l'utilisateur, veiller à ne pas l'influencer…

Il est donc plus facile de travailler à deux ou à plusieurs : une personne conduisant le test avec l'utilisateur et d'autres analysant et recueillant les réponses au fur et mesure (observation, écoute, prise de notes…)


» Recueil d'informations

Le recueil d'informations lors d'un test n'est pas forcément limité à l'enregistrement de la performance de l'utilisateur. On peut apprendre beaucoup en regardant l'utilisateur pendant son interaction. On peut observer de la confusion, de la frustration, de la satisfaction, de la surprise… La communication non verbale est parfois beaucoup plus parlante que les mots.

De plus, lorsque l'utilisateur identifie un problème, il est très intéressant de lui demander comment il imaginerait améliorer l'interface pour y pallier (améliorations en termes de fonctionnalités, de terminologie, d'organisation de l'information, de design, d'éléments d'interface…).

3.5. Administration du post-questionnaire et debriefing

L'administration du post-questionnaire est souvent suivie d'un debriefing, même si ce dernier est informel. C'est l'occasion d'une discussion post-test avec l'utilisateur.

De façon optionnelle et pour les études de grandes envergure, on peut envisager de conduire des auto-confrontations vidéo (on repasse à l'utilisateur le film de la session de test et on approfondit les points-clés avec lui).

Enfin, on dédommagera l'utilisateur pour sa participation au test.

3.6. Intérêt d'une démarche cyclique

Si on dispose d'un nombre d'utilisateurs suffisant, on peut conduire une partie des tests avec un premier groupe de participants, puis reconcevoir les plans de tests et maquettes pour conduire une deuxième session de test.

4. Analyser les résultats

Cette étape consiste à lister les problèmes et à les classer par priorité et fréquence. Il s'agit de mettre en rapport les données avec les objectifs d'utilisabilité : combien d'utilisateurs ont été confrontés au problème, quelles conséquences a-t-il, est-il critique dans la réalisation de la tâche…

Cette analyse permet de dégager des tendances, des profils. On cherche des indices pour comprendre la réussite / l'échec à une tâche. Les meilleurs indices sont dans les patterns de comportements, dans les répétitions de remarques, de difficultés, d'observations…

L'objectif final de cette analyse est de développer des suggestions pour contourner le problème, améliorer l'interface là où elle est mal conçue.

Dans l'idéal, il est préférable de concevoir des solutions visuelles pour concrétiser ces suggestions (maquettes pour l'équipe de développement ou pour un prochain test)

5. Restituer l'analyse des résultats


5.1. Un moyen de valider ou de modifier les recommandations

La restitution permet de discuter de la pertinence des recommandations au vu de critères externes à l'ergonomie.

Une intervention ergonomique n'est qu'une intervention ergonomique. On doit la considérer dans le contexte du projet. Les recommandations devront être pondérées en fonction du design, du marketing, de la technologie…

5.2. Restitution écrite : des cibles différenciées

Un rapport écrit classique doit mentionner les points suivants :
- objectifs de l'évaluation et méthodologie
- description des utilisateurs, du plan de test
- présentation des résultats et solutions potentielles (les points problématiques doivent être présentés sous la forme d'une combinaison entre description textuelle et captures d'écrans)

On doit cependant différencier la présentation des résultats au client et à l'équipe en charge du projet:

» Présenter les résultats au client

» Faciliter la lecture des recommandations

L'objectif de cette étape est de rendre compte de l'intervention ergonomique et de ses implications pour l'interface.

Le plus compréhensible pour le client est de raisonner en termes d'éléments visuels. La confrontation aux enregistrements vidéo est aussi un moyen de présenter les défauts de l'interface, puis d'y faire suivre des propositions de solutions.

Les recommandations doivent être synthétisées. Pour permettre au client d'avoir une vue globale de l'intervention sans entrer dans le détail des recommandations, il paraît indispensable de fournir un résumé des spécifications.

Pour quelqu'un d'extérieur, il est primordial de cerner les points centraux et les points de détail. Il est donc souvent intéressant de définir une hiérarchie de recommandations.

Enfin, on peut proposer des interventions futures pour affiner les résultats.


» Présenter les résultats à l'équipe

» Des recommandations orientées conception

L'objectif de cette étape est de supporter le travail de conception des équipes de design et de développement. Il s'agit donc de transformer les recommandations en spécifications.

Le moyen le plus efficace et le plus simple de transmettre ces informations est de les implémenter dans une maquette.

Fournir un gabarit des pages types, des éléments de l'interface et de leurs états potentiels est le meilleur moyen de faire comprendre rapidement la teneur des recommandations et de s'assurer de leur prise en compte.

Dans le domaine du web, les documents qui seront les plus utiles pour la conception sont les suivants : architectures de site et gabarits de pages types avec intégration du zoning (division de la page en espaces d'information).





Deux types de documents : gabarit de page avec intégration de zoning et architecture de site.

Représentations visuelles des concepts ergonomiques :
Gabarit de page avec intégration de zoning et architecture de site




5.3. Restitution orale

Une restitution orale permet de discuter des résultats avec les clients ou avec d'autres experts intégrés au projet.

Lorsque les recommandations ont été implémentées, il est intéressant de conduire des tests sur la version améliorée pour confirmer les décisions. Ce type de procédure n'est évidemment envisageable que sur des projets de grande envergure.

Conclusion

Le test utilisateur est une méthode clé en ergonomie informatique. En effet, il permet de recueillir des données objectives et subjectives, fournies par les utilisateurs finaux ou leurs représentants.

De plus, lorsque le test se déroule sur des maquettes ou prototypes, il permet à l'ergonome d'être confronté de façon répétée à l'interface qu'il a spécifiée. Cette répétition permet souvent de déceler de nouveaux points à travailler.

L'inconvénient de la méthode du test utilisateur est l'investissement temporel et financier élevé qu'elle suppose (préparation, passations et analyse des données / intervention de l'ergonome et rémunération des participants).

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.




« Liste des articles

à voir aussi sur Ergolab

[03.01.2004]

Recette de test utilisateur, Partie 1

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...

» Lire l'article


Ergonomie web

Amélie Boucher

» Lire la chronique


Don't make me think

Steve Krug

» Lire la chronique


ergolab