Gou blog

Hier je suis allé à Montréal pour faire tester l'interface d'un système avec les principaux employés auquel il est destiné, soit les employés de la morgue. Outre le dépaysement total par rapport à mon milieu de traval habituel, le test a été un franc succès.

On avait quatre utilisateurs répartis dans la journée, quatre scénarios à faire faire, un questionnaire et la rencontre se terminait par une discussion ouverte. Les utilisateurs ont été en mesure de réaliser les quatre scénarios et ce de façon parfois assez inusitée, ce qui nous a conforté dans les choix de l'interface.

Les tests n'ont pas la prétention de servir de base scientifique à une étude, mais plutôt à l'amélioration d'un produit en cours de développement. À ce titre, on peut dire que c'est un succès. Trois utilisateurs sur quatre nous ont simplement dit que c'était un excellent système et qu'ils aimaient l'utiliser, et ce spontanément, pendant le test!

Dans un souci de partager mon expérience, je vous présente donc le déroulement du test et les phases de préparation au test. À titre indicatif, je me suis basé principalement sur des documents dont j'ai déjà parlé en ces lignes: About Face 2.0: The Essentials of Interaction Design de Alan Cooper et Robert Reimann, Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces de Carolyn Snyder, Aide-mémoire sur l'utilisabilité des sites Web gouvernementaux et sur les tests d'utilisation de Ann Lamontagne et finalement un billet de Kevin Cheng sur OK/Cancel Beginner?s Guide to Moderating a Usability Study (et je viens de voir que Carolyn Snyder y a même déposé un commentaire!).

Phase de préparation

Faire un test d'utilisabilité n'a rien de sorcier. Dans un premier temps, il faut cibler précisément ce que l'on veut tester. Il est inutile, voire même absurde, de tester l'ensemble d'un site, ce que l'on doit faire, c'est déterminer les zones à problème et de faire des scénarios simples permettant de cibler ces problèmes.

La première étape fut de s'asseoir avec l'analyste du dossier et le chargé de projet pour déterminer les zones à problèmes dans le système et l'interface. On en a sorti quelques uns, ça a pris un gros 15 minutes! Suite à cet exercice, c'est avec le pilote et le chargé de projet que je me suis assis. On a déterminé quels scénarios permettraient de tester ces zones risquées. Le pilote a un avantage sur nous c'est qu'il nage dans le domaine d'affaire, ce qui n'est vraiment pas mon cas!

Il y a un principe assez important à respecter dans la détermination des scénarios, il faut utiliser la méthode du sandwich. Un scénario simple au début, histoire de démontrer à l'utilisateur que c'est facile, les scénarios plus complexes au centre et on termine toujours avec un scénario simple. De cette façon, le test se termine sur une bonne note!

On a utilisé la grille déterminée par Carolyn Snyder dans son livre pour définir les scénarios:

Suite à cette préparation des scénarios, il fallait peupler la base de données. Il est très important d'inscrire de vraies données (du moins plausibles), sinon l'utilisateur pourra y déceler des incohérences et si ça ne correspond pas à la réalité, ça va nuire à l'utilisation du système. Les utilisateurs connaissaient les réponses à certains scénarios et si les données avaient été fausses ou incorrectes, ils les auraient relevées et auraient perdu confiance dans le système.

De plus, les scénarios doivent être validés par le pilote et même des utilisateurs potentiels (pas ceux qui feront le test par contre), j'ai déjà vu des utilisateurs mentionner qu'un scénario était impossible dans le contexte donné, ça a nui grandement à la crédibilité du test.

Finalement, on a préparé un protocole incluant les scénarios, ce qui doit être mentionné à l'utilisateur, le questionnaire et une liste de questions à poser lors de la discussion ouverte.

La veille du test

Avant le test, on fait ce qui est nommé le reality check. On demande à un ou plusieurs utilisateurs de tester notre système, on fait une répétition générale pour s'assurer que tous connaissent leur rôle. Cette étape est nécessaire car elle permet déjà de déceler des problèmes. Dans notre cas, on avait un gros problème au niveau du rafraîchissement des pages, les champs ne se vidaient pas (problèmes de développements, disons qu'on était serré...). Il a donc fallu mentionner à l'utilisateur que le modérateur (moi) devait nettoyer les champs avant chaque scénario.

On a aussi préparé une enveloppe par participant contenant les fiches de scénarios et un questionnaire (le tout numéroté). Important, il faut s'assurer, dans le cas d'un site testé à l'externe de nos infrastructures, que tout fonctionne bien. On s'est assuré que tout était ok, mais on avait pas validé de visu, et les CSS ne passaient pas... il a fallu faire des modifs à distance avant le test, ce qui nous a retardé. Étant donné qu'on avait prévu 1h entre chaque test (et une heure par test, ce qui est tout à fait correct), on a pas pris de retard!

Le déroulement du test

Dans un premier temps, j'expliquais à l'utilisateur ce à quoi on s'attendait de lui. Voici donc une liste des choses à dire:

• Le modérateur explique le déroulement du test: le test, le questionnaire et la discussion;
• Le test sert à valider une interface et non ses compétences;
• Il doit penser à voix haute tout au long du test, donner ses impressions et non dire littéralement ce qu'il fait;
• Le modérateur n'est pas toujours en mesure d'offrir de l'aide mais l'utilisateur est libre de demander de l'assistance à tout moment;
• Indiquer si le système testé n'est qu'un prototype partiel dont des éléments n'ont pas encore été complétés. Dire qu'il possède toutes les fonctions nécessaires au bon déroulement de chaque tâche (cette notion est importante, si l'utilisateur se croit devant un produit fini, il aura moins tendance à passer des commentaires. En sachant qu'il n'est pas terminé, il ne sera pas influencé);
• Les observateurs prennent des notes pour améliorer l'interface;
• Il se peut que certaines tâches ne soient pas complétées, l'utilisateur n'a pas à s'inquiéter, c'est un signe que l'interface a à être améliorée. Il n'y a pas de limite de temps et l'utilisateur peut arrêter quand il le désire;

L'utilisateur était alors confronté à l'interface pour la première fois et lisait à voix haute le scénario. Il expliquait ce qu'il faisait et je lui indiquais, lorsqu'il cliquait sur une fonction qui n'était pas fonctionnelle, quelle était la réaction du système, par exemple, s'il cliquait sur un hyperlien permettant d'afficher une description en pop-up (je sais, les pop-up, c'est mal!). Mes collègues prenaient des notes, j'étais le seul à interagir avec l'utilisateur.

Une fois l'étape des scénarios terminée, il passait au questionnaire. Chose importante, il est préférable de ne pas influencer l'utilisateur et le laisser répondre seul au questionnaire. Certains nous posaient des questions et nos réponses influençaient.

Pour le questionnaire, je me suis basé sur les questions répertoriés dans un article de Jacques Nantel et al parue dans la revue Gestion (volume 30 numéro 1, printemps 2005, pp. 16-23), L'efficacité des sites Web: quand les consommateurs s'en mêlent. Ces questions sont à la base de l'indice HEC-Chaire RBC. Bien entendu, certaines questions n'ont aucun rapport avec le contexte du site testé, il a donc fallu en éliminer quelques unes et en reformuler pour mieux s'adapter au besoin.

Facilité d'utilisation et ergonomie du site

Ce site est facile à utiliser.

Il est facile de chercher des informations sur ce site.

Il est facile de se déplacer et de trouver ce que l'on recherche sur ce site.

L'organisation et la mise en page de ce site facilitent la recherche d'informations.

La mise en page de ce site est claire et simple.

Qualité et quantité d'informations proposées sur le site

Ce site fournie un information détaillée sur les produits et services proposés.

L'information sur ce site est pertinente.

L'information sur ce site est précise.

Design et aspect esthétique du site

Ce site est joli.

Ce site fait preuve de créativité.

Ce site est visuellement attirant.

Sécurité des données financières et respect de la vie privée

Globalement, j'ai confiance en la sécurité du site.

Ce site me garantit une navigation en toute sécurité.

Je pense que ma vie privée est protégée sur ce site.

Je fais confiance à ce site pour qu'il n'utilise pas mes informations personnelles à mauvais escient.

Interactivité et personnalisation du site

Je peux interagir avec ce site pour recevoir des informations personnalisées.

Ce site est personnalisé selon mes besoins.

Ce site a des fonctions interactives qui m'aident dans l'accomplissement de ma navigation.

Ce site enregistre mes préférences et m,offre des services supplémentaires ou de l'information basée sur ces préférences.

Finalement, lors de la discussion, on a demandé à l'utilisateur, de façon purement subjective, ses commentaires sur l'ensemble du site et sur des points plus précis: type d'information présentée, est-ce qu'il y en aurait d'autre qui serait nécessaire, devrait-on revoir la formulation de tel mot? si oui, quelle expression serait plus appropriée...

Et après?

Il est primordial de mettre en commun toutes les notes prises et de se faire une liste des choses à modifier. Cet exercice sera fait le plus rapidement après le test pour ne pas oublier ce qui s'est passé. On a déterminé des éléments plus fonctionnels, d'autres visuels ou encore des données à vérifier (ajout d'information). Bref, l'exercice a été un véritable succès qui nous donne des pistes pour améliorer le produit. Il ne faut surtout pas laisser tout stagner, il faut agir!

C'était ma seconde expérience en tant que modérateur, j'avais déjà agi comme utilisateur dans un test, je connaissais bien la théorie de la conception des scénarios et tout, et c'était la seconde fois que j'avais à encadrer une équipe de développement pour la réalisation d'un test avec des utilisateurs du système. La première fois avait été faite avec un prototype papier, et cette fois-ci avec un système informatique fonctionnel dont j'avais réalisé l'interface. À cet effet, il est généralement déconseillé que le concepteur soit modérateur, mais il arrive des situations nous y obligeant, ce qui était le cas hier. De plus, tout concepteur doit être en mesure de se détacher de son interface pour en accepter la critique, c'est une règle de survie. Il faut accepter que l'utilisateur ne soit pas en mesure de l'utiliser et il faut penser à s'améliorer et ne pas tenter de défendre son produit à tout prix.

En conclusion de cet immense billet (que j'espère que vous trouverez utile), je dois dire que de faire des tests d'utilisabilité est une exercice simple, mais ô combien efficace. Tous les intervenants ont été ravis et, en plus, ça ne coûte pas cher en plus de rapporter gros! un très bon ROI quoi!