Qu'est-ce qu'un prototype testable ?

Un prototype d'interface utilisateur est une hypothèse - une solution de conception candidate que vous envisagez pour un problème de conception spécifique. La manière la plus simple de tester cette hypothèse est d'observer les utilisateurs travailler avec elle.

Il existe de nombreux types de prototypes, allant de ces paires d'extrêmes :

• Une seule page par rapport à plusieurs pages avec suffisamment de menus, d'écrans et de cibles de clic pour que l'utilisateur puisse accomplir entièrement une tâche.
• Réaliste et détaillé par rapport à esquissé à la main sur un morceau de papier.
• Interactif (cliquable) par rapport à statique (nécessitant une personne pour manipuler différentes pages et agir comme un "ordinateur").

Le choix du prototype variera grandement en fonction des objectifs du test, de l'exhaustivité de la conception, des outils utilisés pour créer le prototype et des ressources disponibles pour aider avant et pendant les tests d'utilisabilité. Mais, quel que soit le prototype que vous utilisez, le tester vous aidera à en apprendre davantage sur les interactions et les réactions des utilisateurs, afin que vous puissiez améliorer la conception.

‍

Pourquoi tester un prototype ?

Modifier du code est très coûteux. Modifier un prototype ne l'est pas, surtout s'il s'agit simplement d'un morceau de papier.

Commençons d'abord par examiner les arguments courants pour ne pas tester un prototype. Ceux-ci sont :

• Attendre qu'une conception soit mise en œuvre avant de la tester signifie que la conception fonctionne réellement, et les participants aux tests peuvent l'utiliser de manière naturelle.
• Il n'y a pas d'ajustement à apporter aux processus Agile ou Waterfall pour accommoder l'UX et la conception itérative.
• Certains partisans du Lean disent que, sans test de prototype, il n'y a pas de prototype à jeter lorsque celui-ci (inévitablement) échoue aux tests, donc il n'y a pas de gaspillage.

Ces arguments peuvent sembler bons à première vue. Mais en réalité, tester des produits finaux est mal informé et risqué. Les équipes éclairées créent des prototypes, les font tester par les utilisateurs, et itèrent la conception jusqu'à ce qu'elle soit suffisamment bonne. (Remarque : nous testons également les produits finaux pour évaluer l'utilisabilité à la fin d'un projet ou au début d'un nouveau, pour évaluer le retour sur investissement, pour mener des études concurrentielles, et pour effectuer une vérification finale et apporter de petites retouches.)

‍

Prototypes interactifs vs statiques

Du travail doit être effectué pour donner vie à un prototype lors des tests d'utilisabilité. Pour le rendre réactif aux actions des utilisateurs, nous pouvons passer du temps à implémenter l'interaction avant le test ou nous pouvons "simuler" l'interaction pendant le test. Les deux méthodes ont des avantages et des inconvénients.

Prototypes interactifs (cliquables)

Avec des prototypes interactifs, le concepteur doit définir une réponse pour chaque action utilisateur possible avant que le test n'ait lieu. Même avec le bon outil, la construction d'un prototype interactif peut être chronophage : il faut obtenir tous les points de clics corrects, et faire en sorte que le système réponde uniquement lorsque l'utilisateur interagit avec une cible cliquable.

Prototypes statiques

Avec des prototypes statiques, les réponses aux actions des utilisateurs sont données en temps réel pendant le test par une personne familiarisée avec la conception. Il existe plusieurs méthodes qui peuvent être utilisées avec des prototypes statiques :

• Le Magicien d'Oz. Cette méthode est nommée d'après le célèbre livre de Frank Baum (et le film encore plus célèbre) du même nom. (Si vous n'êtes pas familier avec le livre ou le film : dans celui-ci, le grand Magicien d'Oz est incarné par un humain ordinaire se cachant derrière un rideau.) Le "magicien" (le concepteur ou quelqu'un d'autre familiarisé avec la conception) contrôle l'écran de l'utilisateur à distance depuis une autre pièce. Aucun des clics ou des tapes de l'utilisateur ne produit réellement quelque chose. En fait, lorsque l'utilisateur clique, le "magicien" décide de ce qui devrait venir ensuite, puis affiche cette page sur l'écran de l'utilisateur. Le "magicien" peut même créer la page à la volée et la servir. Les utilisateurs ne savent pas ce qui produit la réponse. En fait, on leur dit généralement très peu à part que le système est "incomplet et lent". Les tests du Magicien d'Oz sont particulièrement utiles pour tester les systèmes basés sur l'IA avant que vous n'ayez implémenté l'intelligence artificielle. L'humain qui contrôle l'ordinateur peut simuler les réponses de l'IA basées sur l'intelligence naturelle.
• "Ordinateur" en papier. La conception est créée sur papier. Une personne qui connaît bien la conception joue le rôle de l'"ordinateur" et dispose les papiers sur une table, près de la table de test de l'utilisateur mais pas dans son champ de vision. Lorsque l'utilisateur tape du doigt sur un "écran" en papier devant elle, l'"ordinateur" prend la page (ou la partie modulaire) représentant la réponse et la place devant l'utilisateur. (Dans cet article, nous utilisons la notation "ordinateur" pour désigner l'humain qui met en œuvre l'interface utilisateur pendant la session de test.) CONSEILS : L'"ordinateur" doit indiquer aux utilisateurs quand "il" a fini de travailler et qu'ils peuvent poursuivre l'interaction. Cela peut être fait soit en utilisant un geste désigné de manière cohérente (par exemple, les mains pliées devant vous), soit en utilisant une impression spéciale de "Travail en cours" ou d'icône de sablier qui est montrée aux utilisateurs pendant que l'"ordinateur" cherche la réponse appropriée et qui est retirée dès que l'"ordinateur" a fini de travailler.Le facilitateur doit éviter de trop expliquer les éléments de conception ou le processus.
• "Ordinateur" volant la souris. Cette méthode est une version de la technique du Magicien d'Oz dans laquelle le "magicien" est dans la même pièce que l'utilisateur. (Le rôle du "magicien" pourrait être joué par le facilitateur.) Le prototype est montré à l'utilisateur sur un écran d'ordinateur. Lorsque l'utilisateur clique, le facilitateur demande à l'utilisateur de détourner le regard du moniteur pendant un moment et le "magicien" navigue vers la page qui devrait apparaître ensuite. L'utilisateur est ensuite invité à regarder le moniteur et à continuer.

‍

Avantages des prototypes haute-fidélité

1. Les prototypes avec une interactivité haute-fidélité offrent une réponse système réaliste (plus rapide) pendant le test. Parfois, il peut prendre plus de temps à la personne jouant le rôle de l'ordinateur, que ce soit en ligne ou sur papier, pour trouver le bon écran et répondre au clic de l'utilisateur. Un délai trop long entre l'action de l'utilisateur et la réponse de l'ordinateur peut interrompre le flux des utilisateurs et les faire oublier ce qu'ils ont fait précédemment ou ce qu'ils attendaient de voir ensuite. Un retard donne également aux utilisateurs plus de temps pour étudier la page actuelle. Ainsi, avec un prototype lent, les participants aux tests d'utilisabilité peuvent remarquer plus de détails de conception ou absorber plus de contenu que ce qu'ils feraient normalement avec un système en direct. CONSEIL : Si la page censée apparaître ensuite est difficile à trouver dans un prototype sur papier ou longue à charger dans un prototype cliquable, enlevez l'écran actuel que l'utilisateur regarde, afin qu'il regarde plutôt une page ou une zone vide. Lorsque la page suivante est prête, affichez d'abord à nouveau la page précédente pendant quelques instants pour que l'utilisateur puisse se repérer, puis remplacez cet écran par le suivant. Le facilitateur du test peut aider ce processus en disant quelques mots pour aider l'utilisateur à récupérer le contexte, par exemple, "Juste pour rappel, vous avez cliqué sur À propos de nous".
2. Avec une interactivité et/ou des visuels haute-fidélité, vous pouvez tester le flux de travail, des composants d'interface utilisateur spécifiques (par exemple, les méga-menus, les accordéons), des éléments graphiques tels que l'affordance, la hiérarchie des pages, la lisibilité du texte, la qualité des images, ainsi que l'engagement.
3. Les prototypes haute-fidélité ressemblent souvent à des logiciels "en direct" pour les utilisateurs. Cela signifie que les participants aux tests auront plus tendance à se comporter de manière réaliste, comme s'ils interagissaient avec un système réel, alors qu'avec un prototype esquissé, ils peuvent avoir des attentes floues sur ce qui est censé fonctionner et ce qui ne l'est pas. (Bien que ce soit étonnant à quel point la suspension de l'incrédulité est forte pour de nombreux utilisateurs dans des situations de test où tout n'est pas réel.)
4. Une interactivité haute-fidélité permet au concepteur de se concentrer sur l'observation du test au lieu de réfléchir à ce qui devrait venir ensuite. Personne n'a besoin de s'inquiéter pendant le test pour faire fonctionner le prototype.
5. Les tests de prototypes interactifs sont moins susceptibles d'être affectés par les erreurs humaines. Avec un prototype statique, il y a beaucoup de pression sur l'ordinateur et il y a de fortes chances de faire une erreur. La précipitation, le stress, les nerfs, le fait de prêter une attention particulière aux clics des utilisateurs et de naviguer à travers une pile de papiers peuvent tous faire paniquer ou simplement glisser l'ordinateur pendant le test.

‍

Avantages des prototypes basse-fidélité

1. Moins de temps pour préparer un prototype statique, plus de temps pour travailler sur la conception, avant le test. La création d'un prototype cliquable prend du temps. Sans avoir à faire fonctionner le prototype, vous pouvez passer plus de temps à concevoir plus de pages, de menus ou de contenu. (Vous devez toujours organiser les pages avant le test afin que l'"ordinateur" puisse facilement trouver celle à présenter. Mais cela est généralement beaucoup plus rapide que de préparer un prototype cliquable.)
2. Vous pouvez apporter des changements de conception plus facilement pendant le test. Un designer peut esquisser une réponse rapide, effacer ou modifier une partie de la conception entre les sessions de test (ou pendant une session) sans se soucier de lier la nouvelle page dans le prototype interactif.
3. Les prototypes basse-fidélité mettent moins de pression sur les utilisateurs. Si une conception semble incomplète, les utilisateurs n'ont généralement aucune idée de savoir si cela a pris une minute ou des mois pour la créer. Ils peuvent mieux comprendre que vous testez effectivement la conception et non eux, se sentir moins obligés de réussir et être plus susceptibles d'exprimer des réactions négatives.
4. Les designers sont moins attachés aux prototypes basse-fidélité. Les designers sont plus susceptibles de vouloir changer une conception esquissée qu'une conception avec une interactivité et une esthétique complètes. Une fois que nous investissons plus de temps et d'efforts dans une conception, il est plus difficile de l'abandonner si elle ne fonctionne pas bien.
5. Les parties prenantes reconnaissent que le travail n'est pas encore terminé. Lorsque les gens voient un prototype rudimentaire, ils ne s'attendent pas à ce qu'il soit livré demain. Tout le monde dans l'équipe s'attendra à des changements avant que la conception ne soit finalisée. (En revanche, lorsque la conception semble très soignée, il est facile pour un dirigeant de tomber dans le piège de dire, "cela a l'air bien, faisons-le fonctionner maintenant.")

‍

Interaction avec l'utilisateur pendant tout test de prototype

Lors des tests de prototype, les facilitateurs parlent souvent un peu plus avec les participants que lors des tests de systèmes en direct, principalement pour les bonnes raisons suivantes :

• Ils doivent expliquer la nature du support de prototype (et non pas comment fonctionne la conception elle-même) à l'utilisateur, avant le début de l'étude.
• Ils peuvent occasionnellement avoir besoin d'expliquer l'état du système (par exemple, "Cette page ne fonctionne pas encore") et demander "Qu'attendiez-vous qu'il se passe ?"
• Ils peuvent devoir découvrir si les utilisateurs qui restent inactifs attendent une réponse (d'un système lent) ou pensent que la tâche est terminée.

Même avec les interactions nécessaires entre le facilitateur de test et l'utilisateur, l'objectif ultime du facilitateur de test devrait être d'observer silencieusement la personne interagissant avec la conception, et non pas d'avoir une conversation avec le participant.

CONSEILS :

1. Si les utilisateurs cliquent sur un élément pour lequel il n'y a pas encore de réponse préparée :
   1. Dire : "Cela ne fonctionne pas."
   2. Demander : "Que vous attendiez-vous qu'il se passe lorsque vous avez cliqué là-dessus ?"
   3. Présenter la deuxième meilleure page s'il en existe une, et dire quelque chose comme explication. Par exemple, "Vous avez cliqué sur le lien des voitures compactes. Nous n'avons pas ces écrans aujourd'hui. Alors veuillez faire comme si vous aviez cliqué sur les voitures de taille moyenne. D'accord ?" Après que l'utilisateur confirme, présenter la page des voitures de taille moyenne. Ensuite, dire le moins possible et rester neutre.
2. Si la mauvaise page apparaît après que l'utilisateur a cliqué, le "ordinateur" doit retirer cette page dès que possible et revenir à la page précédente. Le facilitateur doit immédiatement informer l'utilisateur que la page était incorrecte, puis répéter ce que l'utilisateur a fait sur la page actuelle, "Vous avez tapé sur À propos de nous." Ensuite, le "ordinateur" présente la bonne page.

‍

Les erreurs du "ordinateur" ont un impact négatif

Notez que les erreurs du "ordinateur" peuvent sérieusement affecter le test. Au fur et à mesure que les écrans apparaissent, les utilisateurs se font une représentation mentale du fonctionnement du système et de la méthode de recherche. Si la mauvaise page apparaît, ne supposez pas que vous pouvez faire oublier aux utilisateurs ce qu'ils viennent de voir. (Les effacements de mémoire ne fonctionnent que dans Star Trek.) Même si vous retirez l'écran ou essayez d'expliquer l'erreur, les utilisateurs peuvent déduire que la mauvaise page est liée à la tâche ou obtenir plus de connaissances de votre explication, et peuvent être plus tard influencés par ces informations. Voir la mauvaise page rompt également le flux des utilisateurs et peut les confondre. Enfin, plus tard dans le test, si un écran apparaît de manière inattendue, ils pourraient penser que le prototype dysfonctionne à nouveau. Cela affecte les attentes des utilisateurs, la confiance dans la méthode de recherche et la capacité à former un modèle mental cohérent.

Étant donné que les erreurs du "ordinateur" peuvent avoir un impact négatif sur l'étude, prenez le temps de tester pilote et de résoudre les problèmes avec le prototype avant que ne se déroulent les séances.

‍

Conclusion

Ne vous trompez pas : vous ne pouvez pas vous permettre de ne pas tester les prototypes. Votre conception sera testée, que vous le prévoyiez ou non. Une fois que votre système est mis en ligne et que les gens commencent à l'utiliser, ils le testent. Plutôt que de recueillir des commentaires dans un cadre de recherche à faible risque, où vous pouvez apprendre, réagir et modifier la conception, vous aurez des clients réels mécontents entre les mains. Avec eux viendront une multitude de problèmes tels que des ventes perdues, des commandes abandonnées, une mauvaise compréhension du contenu et des produits, une aliénation due à une mauvaise tonalité, des produits retournés, une augmentation des appels de support, des coûts de formation accrus, des partages sociaux d'expériences négatives, de faibles scores de promoteur net et l'abandon de la marque. L'entreprise devra trouver comment résoudre tous ces problèmes. L'équipe de développement réagira en s'efforçant de corriger la conception, en retirant du code fonctionnel, des éléments visuels et du contenu, et en le remplaçant par des remplacements seulement marginalement meilleurs mais précipités. Tout cela entraînera un coût élevé. Redessiner, retirer du code, recoder avec la nouvelle conception, tester la qualité de ce code et, le cas échéant, modifier les matériaux marketing et de documentation, est bien plus coûteux que de jeter un prototype.

Testez les prototypes, qu'ils soient cliquables ou statiques, qu'ils soient de haute ou de basse fidélité. Visez à apprendre comment changer et améliorer votre conception. De cette façon, vos clients ne verront jamais vos échecs de conception.

‍