Test d’utilisabilité

Réaliser un test d’utilisabilité (ou Test utilisateur) afin d’évaluer un logiciel ou une application

Le test d’utilisabilité (ou test utilisateur), est la méthode la plus efficace pour évaluer un logiciel. Le test consiste à observer directement l’utilisateur en train de se servir de l’application ou du logiciel. Il permet d’identifier concrètement les problèmes. L’utilisabilité peut être mesurée en calculant la performance de l’utilisateur.

Le test d’utilisabilité est l’occasion de voir l’utilisateur en situation et d’observer les problèmes qu’il rencontre, les questions qu’il se pose et les fonctionnalités qu’il apprécie ou non. Les équipes de développement recueillent ainsi des éléments précieux sur la façon de rendre le logiciel plus agréable à utiliser.

Avantages

  • Le test permet d’observer l’utilisateur dans un contexte réel d’utilisation.
  • Les problèmes identifiés sont ceux que l’utilisateur rencontre lorsqu’il se sert du logiciel.
  • Les problèmes sont identifiés objectivement par des difficultés freinant l’utilisateur dans sa tâche.
  • Des mesures peuvent être effectuées pendant le test.

Inconvénients

  • Le test peut difficilement couvrir l’ensemble des fonctionnalités du logiciel.

Mode opératoire

Le test d’utilisabilité est mené dans un contexte le plus proche possible de l’utilisation réelle. L’utilisateur réalise les principales tâches pour lesquelles le logiciel a été conçu.

Lorsque l’évaluation porte sur un logiciel existant, le test est réalisé sur la version commerciale du produit. En phase de conception, le test est conduit sur un prototype vertical.

L’observateur donne à l’utilisateur des consignes qui vont le conduire à effectuer des tâches typiques du logiciel ou du site Web.

Il est essentiel de ne pas l’aider sauf, bien entendu, en cas d’impasse. Afin d’identifier clairement les problèmes, il est préférable de laisser l’utilisateur « se débrouiller » comme il le fera quand il sera seul face au logiciel.

L’observateur note les erreurs commises, les incompréhensions, les impasses, tout événement qui montre une difficulté d’utilisation du logiciel.

Ces différentes observations font 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 généralement de ces discussions.

En phase de conception, le test d’utilisabilité permet de valider des hypothèses sur le comportement de l’utilisateur, par exemple : la façon dont il navigue dans l’interface, les informations qu’il recherche ou les commandes dont il se sert le plus souvent.

Mesurer l’utilisabilité

Pour déterminer l’utilisabilité de façon objective, on calcule la performance de l’utilisateur, c’est à dire l’exactitude de la tâche par rapport aux ressources consommées. En d’autres termes : l’utilisateur a-t-il pu accomplir correctement la tâche et dans le temps voulu ?

Plus précisément, la norme ISO 9241-11 définit l’utilisabilité de la manière suivante : « Un système est utilisable lorsqu’il permet à l’utilisateur de réaliser sa tâche avec efficacité, efficience et satisfaction dans le contexte d’utilisation spécifié ».

Cette définition nous fournit des critères objectifs pour évaluer l’utilisabilité du logiciel : un logiciel est utilisable lorsque l’utilisateur peut réaliser sa tâche (efficacité), qu’il consomme un minimum de ressources pour le faire (efficience) et que le système est agréable à utiliser (satisfaction).

Mesurer l’utilisabilité consiste donc à effectuer 3 types de mesures :

  • Efficacité : Vérifier que les objectifs visés par l’utilisateur sont atteints.
  • Efficience : Mesurer les ressources nécessaires pour atteindre ces objectifs, par exemple le temps mis par l’utilisateur pour réaliser la tâche.
  • Satisfaction : Déterminer si le système est agréable à utiliser, par exemple en décomptant le nombre de remarques négatives émises par les utilisateurs lors du test.

La norme définit l’utilisabilité sur la base de ces 3 caractéristiques. Il s’agit effectivement des points les plus représentatifs dans le cas général. Cependant, il peut être utile, selon l’application, d’évaluer d’autres aspects :

  • Sécurité : Nombre d’erreurs commises par l’utilisateur et rapidité de correction des erreurs.
  • Facilité d’apprentissage : Compréhension correcte et assimilation rapide du mode de fonctionnement.

Pour chaque consigne, les variables d’utilisabilité sont mesurées. De cette manière, l’équipe projet apprécie objectivement la valeur d’utilisabilité du logiciel. A chaque itération, les mesures permettent de quantifier les améliorations d’un prototype à l’autre.

En savoir plus : L’Institut Américain des Normes propose un formalisme pour normaliser les tests d’utilisabilité.

Conseil

Lors du test, il arrive que l’utilisateur n’ose pas dire qu’il ne réussit pas à se servir du logiciel ou du site Web. Il préfère cacher ses difficultés, rendant caduques les résultats du test. Il est essentiel de mettre l’utilisateur en confiance au début de la séance en lui rappelant que :

  • Le test vise à évaluer le logiciel, pas l’utilisateur.
  • L’utilisateur ne réussit pas à se servir du logiciel parce que le logiciel a été mal conçu.
  • L’objectif du test est d’identifier les problèmes d’utilisabilité de l’application et non de mesurer la capacité de l’utilisateur à se servir du logiciel ou du site Web.

Il faut en outre définir un objectif précis par séance de test. Lorsque la consigne est bien choisie, qu’elle répond à un objectif précis en terme de tâche utilisateur, les résultats du test sont aisément exploitables. Dans le cas contraire, le résultat peut être source d’interprétations multiples, ne facilitant pas la révision du logiciel.
Une bonne adéquation entre l’objectif de la séance, les utilisateurs impliqués et les consignes permet de garantir la représentativité des résultats. Une attention toute particulière doit être portée à l’élaboration du protocole de test. Une phase de « pré-test » avec les membres de l’équipe projet est aussi utile.

Choisir un panel utilisateur représentatif :

  • Les utilisateurs doivent être ceux visés par l’application évaluée. Il est essentiel que soit ceux qui utiliseront effectivement le logiciel, sinon les résultats ne seront pas pertinents.
  • On rencontre parfois des « abonnés aux expérimentations » qui participent à de nombreux tests. Cette présence témoigne de leur motivation. Ce sont généralement des sujets imaginatifs. Mais sont-ils vraiment représentatifs des utilisateurs ? Leurs fréquentes participations aux expérimentations ne biaisent-elles pas leur appréhension du logiciel ?
  • Pour des applications grand public, il est préférable de changer fréquemment la composition du panel utilisateur.

5 utilisateurs suffisent :

  • J. Nielsen a montré que des tests menés avec 5 utilisateurs permettent de lever au moins 80 % des problèmes d’utilisabilité. En augmentant le nombre d’utilisateurs, on ne trouve pas plus de problèmes.
  • Tester avec un plus grand nombre d’utilisateurs augmente le coût du test, pas la pertinence des résultats. Plutôt que de mener un test avec 15 utilisateurs, J. Nielsen considère qu’il est préférable de faire 3 tests avec 5 utilisateurs, en améliorant l’interface à chaque itération.
  • Bien entendu, lorsque l’application vise différents types d’utilisateurs, il importe de tester auprès des différents groupes.

En savoir plus : l’article de J. Nielsen Why You Only Need to Test With 5 Users

Construire un test utilisateur ou test d’utilisabilité

Pour identifier les véritables problèmes que rencontre l’utilisateur de votre application, nous construisons avec vous le test utilisateur.

Notre expertise en test utilisateurs