J’ai réalisé récemment des tests utilisateurs à distance et je vous propose un petit retour d’expérience.

J’ai réalisé ces tests avec Evalyzer. Ce n’est pas le seul outil de test à distance, ils sont nombreux, mais toujours est-il, c’est celui que j’ai utilisé et dont je vais me servir pour illustrer cet article.

Avant de commencer, je me suis posé la question de la validité des tests à distance ou plus précisément en quoi ils diffèrent de tests en laboratoire. Une étude (Thomas Tullis, 2016) sur le sujet est présente une comparaison de tests à distance et en laboratoire sur des mêmes sites de type bancaire. Classiquement un certain nombre de tâches sont demandées dans les deux cas. Il en ressort que la réussite et le temps de réalisation ne sont pas significativement différents entre les deux cas. Les problèmes d’utilisabilités trouvés sont les principalement les même. Les problèmes critiques sont trouvés dans les deux cas. Les tests à distances peuvent permettre une plus grande diversité de problèmes car les utilisateurs sont sur leur poste de travail dans une situation plus naturelle. À l’inverse, la situation de laboratoire est propice à faire apparaître d’autres problèmes d’ergonomie, mais c’est limité par le nombre relativement faible d’utilisateurs.

Résultats de l’expérimentation

Mise en place

Assez classiquement la mise en place d’un test utilisateurs commence par la rédaction de la consigne. Il faut par contre garder à l’esprit que l’utilisateur sera tout seul devant son ordinateur, donc sans être trop directif, il faut être précis et ne rien oublier. La consigne doit donc être relue et testé auprès de plusieurs personnes.

Comme dans toutes consignes, vous avez un contexte, une tâche et un objectif. C’est là où ça devient un peu complexe car il va falloir paramétrer le service de test en fonction de ces objectifs. Par exemple, si l’objectif est d’atteindre la page de confirmation dans un tunnel de commande, c’est facile à paramétrer, mais dans certains cas le paramétrage est plus complexe. Un objectif peut être atteint de diverses manières ou sur différentes pages ou en affichant certaines informations ou champs. Donc ça peut être relativement compliqué de saisir les bonnes conditions. Si les conditions sont mal saisies, ça va compliquer l’analyse des résultats. Certaines tâches seront comptées comme en échec ou en réussite alors que ce ne sera pas forcément le cas. Cette phase de paramétrage peut donc être un peu complexe.

Page des paramètres de la réussite

Surtout le site ne doit pas être modifié entre le paramétrage et les tests. Et il faut bien sûr un site accessible sur le web, pour que chacun puisse y accéder.

Les outils de tests à distances proposent aussi des questionnaires prés ou post-test soit sur la base de formulaire, soit à l’aide de tests normalisés comme le SUS.

Recrutement

Une des limites des tests à distance porte sur le recrutement. Certains sites proposent de recruter les utilisateurs en fonction de critères. Ce n’est pas forcément une bonne idée car vous allez avoir des utilisateurs professionnels qui font ça de manière régulière. De plus avec les tests à distance, vous ne pouvez atteindre qu’une certaine population relativement à l’aise avec l’informatique.

Dans mon cas, les utilisateurs ont été recrutés sur la base d’un mailing fait auprès d’utilisateurs souhaitant participer au bêtatest. Ça permet d’avoir un bon taux de réponse pour un mailing (une quinzaine de réponses sur 30). L’avantage aussi des tests à distance, c’est qu’une fois le mailing envoyé, il suffit d’attendre les résultats. Vous n’avez pas besoin d’être disponibles ni de fixer des créneaux horaires. De plus les participants étaient répartis sur toute la France !

Les utilisateurs doivent installer un plug-in sur leur navigateur et pas n’importe quel navigateur (Chrome ou Firefox généralement) ou une app sur mobile. Donc il peut être nécessaire de proposer à certains une assistance à distance pour cela, mais la procédure est quand même bien faite et se passe sans trop de soucis. Il faut juste penser à le dire et le redire dans les divers échanges.

Passation

Pour la passation, c’est assez simple, il n’y a rien à faire !

Ou presque, il suffit de suivre les résultats et de voir qui a répondu, de relancer au besoin et de faire le tri dans les personnes qui ont commencé une session de test pour voir et qui n’ont rien fait au final.

Donc le gain de temps, sur cette phase est juste énorme. Le suivi va prendre au maximum une demi-journée, contre plusieurs jours dans des tests normaux. Vous pouvez aussi en profiter pour commencer à regarder les vidéos.

Analyse

La phase d’analyse est par contre un peu plus longue qu’en temps normal, car il faut regarder les vidéos de manière exhaustive. Sur des tests classiques, on a déjà une idée des moments les plus pertinents des sessions vu que l’on était présent ! Mais sur une vidéo il est aussi possible d’accélérer et de passer rapidement les temps morts pour aller à l’essentiel.

De plus, un outil comme Evalyzer propose des résultats statistiques pour tout ce qui est mesurable. Donc sans bouger le petit doigt mais simplement en trois clics avec l’index, vous avez accès aux principaux résultats, comme les temps de réalisation, les taux de réussites, etc.

Résultat des tests

Il faudra par contre se familiariser avec des notions comme les fausses réussites (La personne pense avoir réussi mais elle se trompe) ou les faux échecs (La personne pense avoir échoué mais elle a en réalité réussi). Ces différents types de résultats sont très dépendants des paramétrages que vous avez faits en amont. Mais il est aussi possible de corriger, tâche par tâche, utilisateur par utilisateur les résultats, ce qui est bien sûr relativement long. Donc un bon paramétrage en amont, vous évitera du travail à la fin, mais celui-ci n’est pas toujours évident quand vous avez par exemple un service avec beaucoup de Javascripts qui va recharger des bouts d’écrans sans recharger la page.

Les outils proposent aussi des résultats très détaillés avec des arbres de parcours, des sélections d’utilisateurs (les plus fainéants, les plus performants, les menteurs,…), toute la panoplie de statistiques. Toutes ces informations peuvent être un peu complexes à comprendre et à analyser. Je pense que dans ces cas, notamment si vous travaillez sur un service avec des tâches complexes, il faut poser des hypothèses et trouver les bonnes variables qui répondront à ces questions. On est pas loin d’une démarche à Sherlock Holmes où l’on cherche les traces et les mobiles complexes de l’utilisateur.

Dans l’analyse, il y a aussi les questionnaires. Pour ceux normé comme le SUS, c’est relativement simple, il faut par contre savoir interpréter le résultat. Par exemple un score de 70 est souvent corrélé avec une utilisabilité moyenne, ce n’est pas un pourcentage de réussite.

Résultat du SUS

Communiquer les résultats

C’est toujours le point clef des tests, communiquer les résultats à l’équipe ou au client. Personnellement, j’essaye d’impliquer au maximum mes clients dans ses processus de test et donc par exemple de leur donner un accès à l’ensemble des résultats. Mais cela n’est valable que pour les clients qu’ils le valent bien.

Les vidéos, c’est toujours ce qui fait la force des tests utilisateurs en termes de communications. Là, elles sont téléchargeables et déjà découpées par tâches. C’est donc assez facile d’extraire les vidéos les plus parlantes pour les mettre par exemple dans un dossier consultable par le client. Par contre, pour le côté statistique, il faut expliquer et encore expliquer ! Certaines notions ne sont pas faciles à maîtriser ou simplement pas connues. Oui, la moyenne et la médiane sont deux notions différentes !

On ne peut donc pas passer à côté d’une restitution formelle à l’oral, par exemple, pour s’assurer que le client a bien compris ce qui c’est déroulé pendant les tests et discuter des solutions à mettre en œuvre. Il faut prendre en compte que le client ne peut pas venir voir les tests in situ et se rendre compte directement comme c’est souvent le cas avec les tests en laboratoire. À moins d’être impliqué dans la passation, il va donc être un peu frustré.

Prix

Un aspect non négligeable des tests à utilisateurs c’est le prix. Il faut compter une trentaine d’euros par utilisateurs (hors recrutement et cadeaux). Ce qui revient donc pour un test avec une quinzaine d’utilisateurs à un maximum de 500 € soit même pas le prix de la location d’une salle de test. Ça permet donc de faire passer plus d’utilisateurs si besoin ou de s’adapter à des structures avec des budgets moindres sans renier sur la qualité.

Ma conclusion

J’ai longtemps regardé de loin les tests utilisateurs à distances, un peu par habitude. J’avais déjà testé des méthodologies comme le tri par cartes à distance qui fonctionne très bien. Là c’est l’occasion qui a fait le larron, avec des contraintes de budget, de temps et de disponibilités des utilisateurs réparti sur toute la France. Le test à distance permet d’avoir des retours pertinents, de bien mettre en évidence les problèmes d’utilisabilité rencontrés. Il est sans doute un peu plus froid qu’un test en présentiel mais il apporte aussi un côté plus factuel avec un grand nombre de statistiques. Une solution que je devrai peut-être tester c’est de faire des tests classiques mais en enregistrant les résultats avec un outil de tests à distance. Comme ça, on aurait un gros gain de temps sur le dépouillement, tout en pouvant s’adresser à un public plus large que celui des utilisateurs distants.

Deux points clefs sont à retenir avec les tests utilisateurs, le prix et le temps. Ça me parait une excellente méthodologie pour certaines structures comme les start-ups ou les associations qui ont un budget limité mais qui veulent travailler proprement. Pour une startup, une fois le problème du recrutement résolu (Bêtatesteur ?) ça doit permettre de faire des tests régulièrement en fonction des itérations.

Le gain de temps sur la passation et le dépouillement est aussi important. L’aspect automatique permet aussi d’éviter des erreurs. Qui n’a pas oublié de noter la durée d’une tâche lors d’un test !

Bibliographie

An Empirical Comparison of Lab and Remote Usability Testing of Web Sites
Tom Tullis, Stan Fleischman, Michelle McNulty, Carrie Cianchette, and Marguerite Bergel