Des informations précieuses au bon moment : déterminer le niveau idéal de fidélité de conception pour les tests utilisateurs

Chez Intercom, l'un de nos principes de développement de produits est de voir grand, de commencer petit, d'apprendre rapidement.

L'une des façons dont nous apprenons rapidement consiste à effectuer des recherches évaluatives pour renforcer la confiance dans l'orientation de la conception des produits que nous poursuivons. Nous visons souvent à présenter les concepts de produits aux utilisateurs très tôt dans le processus de développement de produits, bien avant que le code n'ait été écrit.

Cette approche des tests utilisateurs pose une question importante et permanente : quel est le bon niveau de fidélité de conception à présenter aux participants à votre recherche ? À quel point ces concepts doivent-ils être proches de la conception finale afin d'obtenir des informations précises de la part de ceux qui les testent ? Comment trouver le bon équilibre entre « brut mais précoce » d'un côté et « poli mais tardif » de l'autre ? Quel niveau d'abstraction de conception atteint le point idéal ?

"Nous avons trouvé qu'il est utile d'éviter d'utiliser le terme ' conception' lorsque nous parlons en interne de ce qu'il faut montrer aux participants - nous préférons utiliser ' stimulus de recherche'"

Les mots comptent

Tout d'abord, bien que nous parlions de fidélité de conception, nous avons trouvé qu'il est utile d'éviter d'utiliser le terme « conception » lorsque nous parlons en interne de ce qu'il faut montrer aux participants lors des tests utilisateurs - nous préférons utiliser « stimulus de recherche ». Des termes comme « stimulus de recherche » ou « artefact de provocation », tout en sonnant un peu bizarre, aident à communiquer que la chose que vous allez montrer à un participant est un outil pour obtenir des informations sur un concept global, plutôt que sur des caractéristiques de conception spécifiques.

Identifiez le problème

Il peut être tentant d'utiliser les fichiers de conception les plus récents et les plus raffinés disponibles lors de la création du stimulus de recherche, mais cela entraîne certains coûts qui doivent être pris en compte. Les participants prêteront attention au plus haut niveau de fidélité que vous fournissez - si vous souhaitez savoir si un concept a de la valeur, entendre les commentaires des participants sur la microcopie sur un CTA est susceptible d'ajouter du bruit aux commentaires que vous recherchez.

Au lieu de cela, nous avons trouvé qu'il est utile de commencer par le problème - ce que nous essayons d'apprendre - et de faire correspondre cela à la fidélité de ce que nous montrons aux participants à la recherche lors des tests utilisateurs.

Ainsi, pour déterminer la fidélité de conception correcte, vous devez identifier lequel des problèmes suivants vous essayez de résoudre :

• Tester des concepts : cette idée a-t-elle une valeur ?
• Conception du système de test : les utilisateurs peuvent-ils avoir une compréhension « suffisamment bonne » de ce système ?
• Test d'utilisabilité : les utilisateurs peuvent-ils utiliser ce produit ?

Une fois que vous avez défini le problème que vous essayez de résoudre, cela vous aidera à déterminer le niveau de fidélité de conception requis pour votre stimulus de recherche.

Être clair sur le problème dès le départ aide également à créer un alignement avec vos partenaires interfonctionnels en matière de conception, de produit et d'ingénierie - d'autant plus important que la création d'un stimulus de recherche est un effort collaboratif, et dont la propriété peut être floue.

"Au début, vous n'êtes pas intéressé par la façon dont ils interagiraient avec cela. Vous voulez savoir si cela leur serait utile ? »

Tester des concepts : cette idée a-t-elle une valeur ?

A ce stade, votre problème est de savoir "Est-ce que cette idée a de la valeur?" Plus précisément, les clients pensent-ils que cette idée les aidera à résoudre les problèmes auxquels ils sont confrontés ? Au début, vous n'êtes pas intéressé par la façon dont ils interagiraient avec lui. Vous voulez savoir si cela leur serait utile.

Pendant le test lui-même, vous voudrez confirmer que le participant rencontre réellement le problème que vous essayez de résoudre, lui montrer le concept et évaluer s'il s'attend à ce qu'il résolve son problème de manière valable.

Votre stimulus de test n'a pas besoin de ressembler à une interface à ce stade. En fait, c'est probablement mieux si ce n'est pas le cas - si vous choisissez de présenter les concepts sous forme d'interface, sachez que vos participants peuvent penser rapidement à la manière dont ils interagiraient avec elle, comment cela se rapporterait au reste de votre produit et ce qu'ils pensent de la conception visuelle. Ce type de feedback est plus facile à donner, de sorte que les participants graviteront naturellement vers lui au lieu de réfléchir profondément au concept lui-même et à la manière dont il pourrait résoudre le problème qu'ils rencontrent. Votre stimulus de recherche doit simplement communiquer l'idée que vous testez, et rien d'autre.

Les descriptions textuelles rapides, les storyboards, les maquettes de pages de destination, les diagrammes dans Google Slides ou les griffonnages de style tableau blanc sont toutes des options légitimes. Restez simple et ciblé en brouillant les copies inutiles et en utilisant des graphiques d'espace réservé évidents.

Conception du système de test : les utilisateurs peuvent-ils avoir une compréhension « suffisamment bonne » de ce système ?

Parfois, une équipe produit peut travailler à la création d'un système complet plutôt que d'interfaces ou de flux. Lorsque vous effectuez des recherches à ce stade, votre question est probablement de savoir si, sur la base de ce que l'équipe a conçu jusqu'à présent, vos utilisateurs peuvent former des modèles mentaux fonctionnels qui leur permettront d'utiliser le produit sans être bloqués ou confus. La meilleure preuve en est que les utilisateurs peuvent faire des prédictions précises sur la façon dont ils effectueraient des tâches représentatives au sein de votre système.

Bien que vous puissiez simplement montrer des diagrammes abstraits du système et demander aux utilisateurs comment ils s'attendent à interagir avec lui, cela n'a pas beaucoup de validité écologique ; en fait, montrer des stimuli qui ressemblent davantage à une interface utilisateur rend la recherche plus réaliste. Encore une fois cependant, nous avons constaté que demander à un participant d' utiliser réellement un prototype rend presque impossible de ne pas détourner son attention vers la conception d'interaction, et vous n'êtes probablement toujours pas en train de résoudre ce problème.

Envisagez de leur donner des problèmes réalistes et de leur demander de vous expliquer comment ils s'attendent à les résoudre à l'aide de vos interfaces simulées, pendant que vous partagez votre écran et que vous vous occupez des interactions spécifiques qui les déplacent dans le produit. Cela vous évitera soit de construire des prototypes entièrement interactifs avant d'avoir confiance dans la direction de la conception, soit de risquer de frustrer les participants avec des interactions que vous savez encore loufoques.

Test d'utilisabilité : les utilisateurs peuvent-ils utiliser ce produit ?

À ce stade, vous souhaiterez savoir si un utilisateur peut interagir avec votre produit avec un niveau d'assistance réaliste (par exemple, pas plus d'intégration que vous êtes susceptible de fournir dans le produit final) et effectuer des tâches qui représentent le problème que vous résolvons.

Il existe de nombreux types de tests d'utilisabilité, et dans chacun d'eux, la conception de l'interaction devient plus importante. Vous pouvez tester la convivialité avec des prototypes de différents niveaux de fidélité, une fois que vous êtes clair et précis sur les tâches que vous souhaitez que vos participants effectuent et testent, et les interactions nécessaires pour les activer sont prises en charge dans le prototype.

En résumé

Les lignes entre ces phases sont floues et il peut être difficile de trouver le bon protocole pour votre situation. Préparez-vous à modifier à la fois le stimulus de recherche et les questions que vous posez d'une session à l'autre.

Enfin, il n'y a pas de mal à demander à vos participants comment ils ont trouvé la session de recherche elle-même, plutôt que les stimuli de recherche. La confusion ou la frustration sont un signe que vous avez encore du travail à faire. Et si vous êtes bloqué, n'oubliez pas de commencer par le problème : qu'essayez-vous exactement d'obtenir de la session de test utilisateur ?

Vous voulez en savoir plus sur le travail avec notre équipe? Découvrez nos valeurs, notre façon de travailler et nos rôles ouverts ici.