La valeur des tests utilisateurs – Questions-réponses avec le fondateur de Validately

Un bon outil de prototypage doit être intégré à une bonne plateforme de tests utilisateurs, c’est pourquoi en ce début d’année 2016, vous aurez une excellente nouvelle de la part de Justinmind : l’intégration complète avec Validately, l’une des meilleures plateformes de tests utilisateurs rapides pour les prototypes et les fonctionnalités actives. Steven Cohn, le fondateur de Validately, donne quelques conseils pratiques sur la manière de mener des tests utilisateurs dans les règles de l’art.

Pourquoi une équipe produit devrait-elle consacrer le peu de temps dont elle dispose aux tests utilisateurs ?

Permettez-moi de vous présenter quelques statistiques du secteur :

• 50 % des fonctionnalités d’un produit typique sont inutilisées par ses clients. C’est exact, la moitié de ce que vous êtes en train de concevoir et de construire ne sera pas utilisée par les clients.
• 30 % des efforts d’une équipe de développement typique sont classés comme du « re-travail ». Il s’agit de recoder une fonctionnalité existante pour mieux refléter les exigences du client ou pour la rendre plus utilisable.

Ces chiffres sont énormes. Des statistiques qui font bouger les aiguilles et qui sont largement répandues. La vérité, c’est que

Il est impossible pour un designer ou un chef de produit de s’asseoir dans une pièce et de deviner comment un client souhaite utiliser une fonction/un produit.

Quelles sont les différentes options de test ?

J’expliquerai les tests d’utilisateurs à l’aide de cette grille :

Lorsque vous testez le design d’une nouvelle fonctionnalité, vous voulez apprendre deux choses :

1. UI Utilisabilité
2. Utilisabilité dans la vie réelle

UI L’utilisabilité est facile à comprendre. Quelqu’un peut-il passer de la page 1 à la page 2, puis à la page 3 et à la page 4 sans s’embrouiller ? L’utilisabilité en situation réelle est plus complexe. Ce type de test permet de déterminer si l’utilisateur se servira réellement de la fonctionnalité dans sa vie réelle. Aussi simple que cela puisse paraître, la réponse est très complexe. N’oubliez pas une chose lorsque vous testez la facilité d’utilisation en conditions réelles :

Ce qu’un client dit qu’il fera, ce qu’il dit avoir fait et ce qu’il fait réellement sont trois choses différentes.

Voici quelques exemples de questions à poser lors de l’évaluation de la facilité d’utilisation en situation réelle :

• Comment utiliseront-ils la fonction dans leur vie quotidienne ? À quelle fréquence ? Dans quelles circonstances ?
• Quelles sont, selon eux, les alternatives à cette caractéristique ? Qu’est-ce qui leur plaît dans cette alternative ? Qu’est-ce qu’ils détestent dans cette alternative ? Qu’est-ce qui les incitera à abandonner cette alternative ?

Je pourrais continuer à énumérer les questions qui permettent de prédire le succès d’un design de fonctionnalité. Mais l’essentiel est là :

Tant que vous n’avez pas présenté un prototype d’une nouvelle fonctionnalité à un client, il n’y a AUCUN moyen de déterminer si elle répond aux exigences du client pour qu’il l’utilise réellement.

Se contenter de recueillir des « exigences » lors d’entretiens n’est pas suffisant. Les clients doivent voir quelque chose visuellement et l’essayer pour vous dire s’ils l’utiliseraient. Avec cette compréhension de base des objectifs des tests d’utilisateurs, la prochaine étape est de savoir comment.

Tests modérés

Le test modéré consiste à tester avec un client en temps réel. Il peut s’agir d’un test à distance ou en personne, mais vous êtes en direct avec le client pour lui demander d’essayer un prototype ou une fonctionnalité déjà construite et lui poser des questions sur l’utilisabilité dans la vie réelle (voir ci-dessus). Vous pouvez également apprendre l’utilisabilité de l’UI à l’aide de tests modérés. L’avantage des tests modérés est qu’ils vous permettent d’obtenir des informations approfondies sur la façon dont le client utilisera le design d’une fonctionnalité. Vous pouvez suivre et poser des questions lorsqu’un utilisateur mentionne quelque chose et approfondir la question. Cependant, ce type de test demande plus de temps. Il est préférable d’utiliser un prototype pour ce type de test, car il est facile d’y apporter des modifications. Vous devrez recruter des testeurs qui correspondent à votre persona et fixer une date pour une session en direct ; faire passer le testeur par un prototype et lui demander d’accomplir des tâches spécifiques ; poser des questions d’utilisabilité réelle, comme indiqué ci-dessus ; prendre des notes et enregistrer la session afin de partager les aspects importants avec les parties prenantes. Il serait bon de parler avec 5 testeurs par persona. Si vous n’avez pas le temps ou le budget pour 5, 3 est mieux que zéro.

Tests non modérés

Les tests non modérés sont asynchrones. Vous mettez en place un test, vous l’envoyez aux participants et vous enregistrez leurs interactions, et souvent leurs voix, lorsqu’ils tentent d’accomplir certaines tâches. Vous n’êtes pas en direct avec eux. Le principal avantage de cette méthode est qu’elle est rapide parce qu’elle est asynchrone. Vous pouvez obtenir un grand nombre de réponses pendant que vous travaillez sur autre chose. Cependant, vous ne pouvez pas poser de questions de suivi et approfondir les choses lorsqu’un utilisateur est en train d’être testé. Ainsi, vous ne pouvez réellement apprendre que l’utilisabilité de l’UI. Unmoderated n’est PAS utile pour apprendre l’utilisabilité dans la vie réelle. Il est préférable d’effectuer ce test avec un prototype cliquable, car vous allez certainement apprendre et vouloir apporter des modifications. Vous devrez recruter des testeurs qui correspondent à votre persona, soit à partir d’un panel, soit par vos propres moyens. Vous donnez aux testeurs une tâche à accomplir sur le prototype cliquable et vous mesurez combien d’entre eux peuvent accomplir la tâche dans un délai raisonnable. Souvent, vous souhaitez que le participant partage ses pensées à haute voix pendant qu’il tente d’accomplir une tâche. Vous pouvez ensuite poser des questions qualitatives telles que l’approche de notation SUS. Les tâches ne doivent pas être trop prescriptives et ne doivent pas utiliser des mots spécifiques utilisés dans l’UI. Par exemple :

• Mauvaise tâche : Allez dans le tableau de bord et « Ajoutez une nouvelle histoire » à la file d’attente. [since there are buttons labeled Dashboard and Add A New Story in the UI]
• Bonne tâche : Ajoutez une histoire à votre carnet de commandes

Il existe deux approches pour les tests non modérés en termes de nombre de testeurs :

• Tests de clics à haut volume : typiquement 100 répondants et vous ne regardez que les modèles de clics et les réponses qualitatives.
• Talk-alouds : c’est lorsque les utilisateurs expriment leurs pensées à haute voix. Vous n’avez besoin que de 5 testeurs par persona pour connaître 85 % des problèmes d’utilisabilité.

Comment Validately vous aide-t-il à réaliser des tests utilisateurs ?

Lorsque nous discutons avec des Product Managers, des UX Designers et des User Researchers pour savoir pourquoi ils ne mènent pas plus de User Research/Testing, ils répondent généralement la même chose….je n’ai pas le temps ! Lorsque nous nous penchons sur cette question, nous constatons que c’est parce que le processus entourant les sessions de test prend plus de temps que les sessions de test elles-mêmes. En particulier, les points de douleur suivants :

• Trouver des clients représentatifs (Personas) pour effectuer des tests
• Programmation de ces tests
• Effectuer ces tests sans utiliser de logiciel d’enregistrement
• Produire des rapports post-tests de manière à ce qu’ils puissent être partagés avec les parties prenantes.

Validately facilite la recherche et les tests utilisateurs en automatisant toutes ces étapes pour nos clients. Nous nous attaquons à ces points douloureux afin de faciliter la communication avec votre Persona et de tester des prototypes ou du code réel. Nous offrons des solutions simples et abordables pour les tests avec ou sans modérateur.

Comment le prototypage aide-t-il à tester les utilisateurs ?

Attendre pour effectuer des tests utilisateurs sur des fonctionnalités codées est une approche extrêmement inefficace et coûteuse. Voici les données (IBM) :