Test utilisateur

Le test utilisateur est parfois réalisé au démarrage du projet en particulier dans le cadre de la refonte d’une application[6]. Toutefois, il est plus efficace de conduire le test sur une maquette intermédiaire afin d’obtenir des retours sur les choix de conception qui ont été effectués. Des tests sur des maquettes « papier » non finalisées permettent de valider rapidement certaines parties de l’interface. Il n’est pas nécessaire de disposer de la version finale de l’application pour conduire un test utilisateur[7].

La nature des tests et des scénarios d’évaluation dépend du niveau d’interactivité de la maquette. Sur une maquette statique, le test, dit « de perception », portera sur la compréhension et la visibilité des zones de l’écran. Ensuite, une maquette semi-fonctionnelle permet de conduire plusieurs scénarios prédéfinis et donc de valider la navigation dans l’interface. Finalement, une maquette fonctionnelle ou prototype, présentant une partie significative des fonctionnalités de l’application, offre une plus grande liberté de navigation à l’utilisateur et permet une exploration libre du logiciel ou du site. D'une manière générale, l’objectif du test est d’identifier les problèmes d’utilisabilité et non de mesurer la capacité de l’utilisateur à se servir de l’application.

Bien qu'en apparence, un test utilisateur puisse sembler simple à mettre en place, sa qualité va dépendre en grande partie de la rigueur avec laquelle son protocole est élaboré. Le suivi d'un protocole de test précis permet de généraliser les résultats à l’ensemble de la population visée et minimiser les risques dans les développements qui vont être planifiés à la suite du test. Un protocole de test rigoureux nécessite :

• Des objectifs clairs et des hypothèses qui en découlent : ils sont définis avec l’équipe projet en fonction de la nature de l’interface, du type de tâche demandée et des questions soulevées par l’équipe chargée de la conception. Le test doit permettre de valider une ou plusieurs hypothèses associées aux objectifs, en supposant que l'interface réponde correctement à ces objectifs ;
• Des mesures permettant de vérifier ces hypothèses, effectuées lors des scénarios d'utilisation : il s'agit de questions ou d'actions réalisées par l’utilisateur. Selon la réponse à ces questions ou selon la réussite de l’action identifiée, l’hypothèse est validée ou non. Sur une application, les mesures généralement réalisées concernent : la réussite de la tâche, le temps de réalisation de la tâche, le nombre d’erreur, le nombre de clics, etc. ;
• Un panel d’utilisateurs représentatif de la population visée à la fois en nombre et en profil : en général, il s’agit des utilisateurs finaux de l’application, mais il peut être intéressant d’intégrer également dans le panel des personnes qui ne connaissent pas l’application (ils apporteront le point de vue des novices), voire des utilisateurs d’un produit concurrent.

Lors de la passation du test utilisateur, il est préférable de définir des besoins et des exigences à satisfaire sous la forme de mesures qualitatives et quantitatives telles que :

• le taux de succès pour la réalisation des tâches à effectuer ;
• le nombre d'erreurs effectuées (et éventuellement les contournements réalisés) ;
• le temps d'exécution de chaque tâche (et éventuellement, les différences de temps pour une même tâche répétée) ;
• Le nombre d'étapes nécessaires à la complétion de la tâche ;
• Le recours éventuel à un support ou une aide interne ou externe au produit (ex : l'animateur de la session de test) ;
• Le rythme d'apprentissage ;
• La satisfaction des utilisateurs…

Le script précise le déroulement du test dans tous ses détails (ex : tâches demandées, consignes, questions) afin de conduire le test dans les mêmes conditions avec tous les participants. Il précise également les artifices employés par l’animateur pour placer l’utilisateur dans une situation réaliste (ex: documents factices). Le script permet à l’observateur de noter les réponses et les données récoltées directement (ex: réussite de la tâche, nombre d’erreurs, temps de saisie, etc.).

Le test est conduit dans un contexte le plus proche possible de l’utilisation réelle. Le test est réalisé dans la mesure du possible, sur le lieu de travail des utilisateurs, ou dans un local dédié. Dans ce dernier cas de figure, les salles de test disposent généralement d’une pièce attenante séparée par une glace sans tain depuis laquelle les membres de l’équipe projet peuvent assister au test. Il est préférable que l’observateur se tienne à côté du participant, légèrement en retrait, afin d’établir une relation de confiance qui favorisera les échanges et l’observation. Le principal intérêt du test est d’observer l’utilisateur dans le contexte réel d’utilisation. Il est donc essentiel de ne pas l’aider, sauf bien entendu en cas d’impasse. En effet, afin d’identifier clairement les problèmes, il faut le laisser « se débrouiller » comme il le fera quand il sera seul face au produit. Par contre, une fois la source de l’erreur identifiée, afin de mettre à nouveau en confiance l’utilisateur, il convient de le tranquilliser en lui indiquant que l’erreur vient du produit et non de lui. L’observateur doit rester le plus neutre possible afin de ne pas influencer les réponses et les actions de l’utilisateur. Chaque session dure au maximum 60 minutes afin de s'assurer de l'attention et de l'objectivité optimale du participant.

Pendant le test, l'utilisateur doit être incité à verbaliser afin de traduire en mots ce qu'il fait et ce qu'il pense. On lui pose des questions qui vont le conduire à éliciter ses processus mentaux :

• Que voulez-vous faire ? (objectifs) ;
• Comment faites-vous cela ? (mode opératoire) ;
• Que fait le logiciel ? Qu'attendiez-vous que le logiciel fasse ? (réponse attendue) ;
• Pourquoi a-t-il fait cela ? Que veut dire ce message ? (compréhension).

Ces différentes réponses peuvent faire l’objet, une fois le test terminé, d’une analyse « à chaud » avec l’utilisateur afin de mieux comprendre les causes des problèmes. Des solutions originales naissent parfois de ces échanges.

Au début des années 1990, Nielsen, alors chercheur chez Sun Microsystems, a popularisé le principe de n'utiliser qu'un petit nombre d'utilisateurs test, à savoir 5 participants à chaque étape du processus de développement. Son argument, basé sur de nombreux tests qu'il a réalisés, repose sur l'idée que le test utilisateur est une évaluation qualitative et les problèmes d’utilisabilité viennent du logiciel et non des utilisateurs. De fait, cinq utilisateurs permettraient de lever au moins 80 % des problèmes d’utilisabilité[8].

Le principe de « Cinq utilisateurs suffisent » a ensuite été décrit par une formule mathématique[9], qui définit la proportion de problèmes non-levés U.

${\displaystyle U=1-(1-p)^{n}}$

où p est la probabilité qu'un utilisateur identifie un problème particulier et n le nombre d'utilisateurs (ou session de test). Cette formule peut être représentée sous la forme d'une graphique asymptotique tendant vers le nombre de vrais problèmes existants.

Toutefois, certaines études indiquent que 5 utilisateurs ne suffisent pas toujours pour obtenir une couverture significative de l’application, il est préférable de prévoir 10 à 20 utilisateurs par test[10]. Dans ces conditions, la conduite de tests comprend différents profils et 5 utilisateurs par profil, permettant alors d’obtenir des résultats significatifs généralisables à l’ensemble de la population.

D'autres travaux de recherche ont contesté la proposition de Nielsen par des preuves empiriques et des formules mathématiques avancées[11]. Deux points en particulier sont contestés :

1. Dans la mesure où l'utilisabilité est liée en particulier à un groupe d'utilisateurs, ce petit échantillon n'est probablement pas représentatif de la population en général et les données recueillies ne reflètent probablement que ce groupe d'utilisateurs.
2. Tous les problèmes d'utilisabilité ne sont pas détectables aussi facilement les uns les autres. Des problèmes insolubles peuvent subvenir et altérer la tâche dans son ensemble. Dans ces conditions, la progression d'une tâche peut être beaucoup moins approfondie que ne le prédit la formule de Nielsen[12].
3. Le nombre de problèmes d'utilisabilité détectables a tendance à tendre vers l'infini. Une série d'études[13]montre qu'avec l'augmentation du nombre de participants et plus les techniques varient, de nouveau problèmes apparaissent quasiment à l'infini.
4. Le nombre de participants pour un test utilisateurs peut être calculé sur la base d'un pré-test à l'aide d'une formule mathématique.

• Ergonomie
• Ergonomie informatique
• Utilisabilité
• Intervention ergonomique
• Prototypage
• Méthode de la pensée à voix haute
• Entretien d'explicitation
• But d'utilisabilité