La base pour commencer à tester est de définir ce qui va être testé, comment et avec qui. Que le test d'utilisabilité soit à distance ou en présentiel, le protocole de test doit inclure des détails tels que :
- le message de bienvenue / introduction,
- les tâches spécifiques, le cas échéant,
- les instructions pour l'utilisateur,
- les instructions pour le modérateur ou le facilitateur et
- les aspects importants à observer.
Être systématique ne signifie pas consacrer trop de temps à cette étape de planification, c'est être rigoureux pour tirer le meilleur parti du processus de test.
De par la nature du test, cette situation se produit plus souvent en mode présentiel qu'à distance : le modérateur suit le protocole à la lettre et manque des opportunités.
Pour systématiser et obtenir des résultats comparables, il est important de suivre la ligne directrice et le protocole. Cependant, le modérateur d'un test d'utilisabilité en présentiel devrait avoir l'autonomie et l'agilité nécessaires pour identifier des opportunités au-delà des instructions initiales, et profiter de ces opportunités tant qu'il dispose de l'utilisateur pour faire de nouvelles découvertes.
Disons que nous testons un site e-commerce où nous devons valider certaines hypothèses, entre autres objectifs du test. Si nous suivons les instructions, nous pourrons probablement valider les hypothèses, mais si nous laissons l'utilisateur effectuer d'autres tâches librement, d'autres découvertes surgiront sûrement.
Quel que soit le type de test d'utilisabilité que vous effectuez, en présentiel ou à distance, il est important de tester le protocole pour valider les instructions, s'assurer que les tâches à accomplir ont été comprises et que le langage utilisé est simple et clair.
En d'autres termes, il faut tester le test. Autrement, si nous nous trompons dans le choix d'un mot et que nous le voyons alors que le modérateur a déjà réalisé plusieurs sessions, nous perdons du temps et de l'argent car il faut augmenter le nombre d'utilisateurs participants.
On nous a dit un jour : « chaque fois que nous faisons des changements drastiques et pensons nous améliorer, nous faisons s'effondrer le centre d'appels ». Cela signifie que, bien que l'équipe de conception et de développement en question apportait des améliorations et simplifiait l'interface, l'utilisateur fréquent connaissait déjà les « manies » du logiciel et était habitué à appuyer 3 fois de suite sur Entrée pour arriver à l'écran principal. Changer ce flux a donc signifié le sortir de sa routine. Il se perdait et c'est pourquoi il appelait le centre d'appels.
Parfois, c'est le passage nécessaire à très court terme pour générer des améliorations de l'expérience à moyen terme. D'autres fois, c'est un risque qu'il faut prendre si l'on veut améliorer l'expérience utilisateur à long terme. Dans ce cas, un segment important à considérer sont les nouveaux utilisateurs qui, s'ils ont des problèmes, c'est parce qu'ils ne connaissent pas l'interface et n'y sont pas habitués. Par conséquent, la période d'apprentissage est lente.
L'objectif est de tester, d'obtenir des insights et des résultats concrets pour, finalement, améliorer une interface et l'expérience utilisateur, et non de filtrer des bases de données.
Consacrer trop de temps et de ressources à filtrer des bases de données clients pour recruter LE parfait utilisateur et le choisir avec des pincettes n'est pas toujours un processus rentable. Il serait peut-être plus judicieux d'investir ces ressources dans la construction de plus de scénarios de test et de tester avec une plus grande variété d'utilisateurs pour obtenir plus de découvertes.
Nous pourrions approfondir ce point, et nous le ferons à l'avenir, mais un détail à planifier soigneusement est le choix des mots dans la communication avec l'utilisateur pendant le test, la formulation des instructions et l'évitement de la fourniture d'« aide » ou de « conseils » pendant l'exécution des tâches.
Pendant le test d'utilisabilité, nous pouvons identifier une série de problèmes. Dans certains cas, les problèmes sont évidents : l'utilisateur ne trouve pas l'information, ne voit pas où se trouve le panier d'achat, ne comprend pas une étiquette, etc.
Dans d'autres situations, le problème est plus complexe et identifier qu'il y a un problème et quelles en sont les causes est la tâche du modérateur et de l'analyste ou du consultant (cela peut être la même personne).
Proposer des solutions à un problème d'utilisabilité peut être une tâche difficile, mais une chose est certaine : c'est le travail de l'équipe derrière l'interface et non de l'utilisateur.
Encore une fois, le test utilisateur n'est pas un focus group (où l'on pourrait demander aux participants de réfléchir à des alternatives possibles).
Si, dans le protocole de test, il y a une question du type « Comment rendriez-vous cette étape plus simple ? », vous devriez envisager de la supprimer et de vous consacrer à mieux observer, analyser les résultats ou améliorer la conception et tester à nouveau.
Penser que le test d'utilisabilité est LA source d'information qui vous dira quoi faire pour optimiser les résultats et ne se fier qu'à cette méthodologie est illusoire.
Voici quelques autres méthodologies de recherche et sources de données pertinentes que vous devriez analyser :
- métriques de trafic (de Google Analytics, par exemple),
- cartes de chaleur d'applications comme Clicktale ou Crazyegg,
- enregistrements de séquences de navigation,
- analyse de cas à partir de demandes reçues par e-mail ou sur les réseaux sociaux,
- analyse de la performance du contenu,
- recherche qualitative par le biais d'entretiens,
- enquêtes de satisfaction,
- benchmarking,
- recherche auprès d'utilisateurs internes tels que des responsables du service client ou des vendeurs, etc.
Bien qu'un test utilisateur puisse être exploratoire dans une première étape, il est important de définir des indicateurs au moment de systématiser le processus et les résultats.
Qu'est-ce qui va être évalué ? Quelques indicateurs de résultats pour un test d'utilisabilité :
- Taux de réussite dans la résolution d'une tâche.
- Temps nécessaire pour effectuer une transaction.
- Temps nécessaire pour trouver une information.
- Taux d'abandon de la tâche.
Lorsque nous réalisons un test d'utilisabilité pour une nouvelle interface, il y a un défi quant aux propositions de flux d'interaction qui seront testées. N'avoir qu'une seule alternative peut trop limiter les résultats du test.
Le flux transactionnel doit-il avoir 3 ou 4 étapes ? L'appel à l'action est-il clair et concret ? Il est préférable de prendre ce type de décisions de conception en comparant l'efficacité de plusieurs alternatives.
Félicitations, nous avons commencé à tester, nous avons une liste de tâches en attente et des priorités de travail pour les prochaines semaines. Et maintenant ?
Si nous améliorons l'expérience utilisateur sur une interface numérique existante, il reste sûrement beaucoup à faire. Si, au contraire, nous concevons un site web ou une application, il est important d'intégrer le test comme partie intégrante du processus de conception et de tester aux étapes principales avant et après le lancement.
Dans les deux cas, rappelons que le test en soi n'est pas une finalité mais un moyen de concevoir des expériences remarquables.
Le test d'utilisabilité avec les utilisateurs n'est pas la même chose que la recherche utilisateur. Ce n'est pas la même chose que de « sortir dans la rue », dans le langage des startups, pour tester un produit minimum viable (PMV). Ce n'est pas un test de compatibilité de navigateurs, un test A/B, une enquête de satisfaction, un focus group, un test de goûts ou de préférences, etc.
Comprendre les différences entre chaque méthode et savoir l'expliquer en interne ou l'évangéliser, c'est s'assurer que tous les acteurs impliqués utilisent un langage commun.
Attention à vouloir tester des alternatives comme un bouton jaune versus un bouton rouge. Pour tester de petites différences et obtenir des données significatives à partir d'un échantillon plus grand, il est préférable d'envisager des tests de type A/B testing. Le test d'utilisabilité n'est pas la meilleure méthodologie pour mesurer l'impact de ce type de variable.
Penser qu'un test d'utilisabilité réussi signifie une transaction réussie, des conversions hallucinantes ou des ventes une fois l'interface en production, c'est assumer une relation de causalité en ignorant l'impact d'autres variables.
Nous avons rencontré des situations où, suite à un test utilisateur, un flux transactionnel est amélioré (et il est validé qu'il a été amélioré), mais qu'une fois « en ligne », les résultats laissent à désirer. Peu d'utilisateurs utilisent réellement le flux respectif, ce qui génère peu de transactions et, finalement, l'équipe interne déclare que les objectifs n'ont pas été atteints ; c'est presque un échec.
Cela signifie-t-il que le résultat du test était erroné ? Ou que la transaction est mal conçue ? Pas nécessairement. Les faibles indicateurs de résultats (ou KPI, pour key performance indicators, en anglais) peuvent être attribués à d'autres causes comme, par exemple, une architecture de l'information déficiente : au milieu de la mer d'informations du site, la transaction se perd.
Contrairement à l'instance de test, où l'utilisateur doit accomplir la tâche d'effectuer une transaction, un paiement en ligne par exemple, en partant de l'étape 1 et en terminant à l'étape x, lorsque le paiement est en production et que l'utilisateur doit passer par la page d'accueil, l'accès à la transaction « rivalise » avec d'autres éléments de contenu. Autre exemple : lorsque la nouvelle fonctionnalité est en ligne, le lancement coïncide avec des problèmes d'hébergement, de sorte que le temps de chargement de la page augmente et les utilisateurs abandonnent la transaction.
Pour éviter ce type de faux problème de cause à effet, il est important d'analyser en profondeur ce qui se passe et de disposer de sources d'information complémentaires, tant qualitatives que quantitatives.
Si vous pensez qu'un test d'utilisabilité éliminera tous les risques face à un changement de conception majeur, assurera le succès d'une mise en production ou sera synonyme d'une augmentation des ventes, vous devriez reconsidérer le processus et vous assurer que vous choisissez la bonne méthode pour le bon objectif.
Si, au contraire, c'est clair pour vous, alors vous êtes en mesure de communiquer à votre client et à votre équipe pourquoi vous faites un test utilisateur et ce qu'ils devraient attendre des résultats.
Quelles autres erreurs fréquentes avez-vous observées lors de tests d'utilisabilité avec des utilisateurs ?
Par 
