Avant de faire développer un onboarding, un espace client ou un tunnel de commande, il y a une étape qui coûte peu et que l'on saute souvent : le prototype cliquable. Quelques écrans reliés entre eux, sur lesquels on clique comme sur le vrai produit, pour voir si quelqu'un comprend où aller. On le saute parce que « les développeurs vont commencer de toute façon », et on le paie trois sprints plus tard.
J'en parle parce que c'est ainsi que j'ai conçu le produit de Moonworkers, ma propre entreprise : en partant des utilisateurs, avec des personas, des wireframes, un design system dans Figma et beaucoup d'allers-retours. Et parce que mes missions m'ont appris que l'outil compte moins que deux choses : le nombre de pistes qu'on montre, et leur niveau de finition. Voici comment je m'y prends aujourd'hui.
01Ce qu'un prototype cliquable permet de décider
Un prototype, c'est une hypothèse qu'on met à l'épreuve, bien plus qu'une version allégée du produit. Kara Pernice, chez Nielsen Norman Group, le dit simplement dans son article sur la fidélité des prototypes : la façon la plus directe de tester cette hypothèse, c'est de regarder des utilisateurs s'en servir.
Avant d'ouvrir Figma, j'écris la question à laquelle le prototype doit répondre, en une phrase. Par exemple : « Est-ce qu'un nouvel utilisateur comprend quelle information il doit fournir avant de pouvoir continuer ? » ou « Est-ce que les trois étapes de l'inscription peuvent tenir sur un seul écran ? ». Si vous n'arrivez pas à l'écrire, le prototype deviendra une démo, et une démo ne tranche rien.
C'est la même discipline que dans mes machines de contenu : le brief bloque la rédaction tant que l'angle et la promesse ne sont pas écrits. Sans ce verrou, on produit tout de suite, sur des généralités, et on découvre après coup qu'il n'y avait pas de question.
Le manuel de service du gouvernement britannique, dans sa page sur la fabrication de prototypes, donne la même logique : prototyper pour explorer, partager et tester avant de construire, en faire plusieurs rapidement et jeter ceux qui testent mal. Jeter fait partie du travail.
02Basse ou haute fidélité : choisir selon la question posée
La fidélité, c'est la ressemblance avec le produit final. Elle joue sur trois choses : l'interactivité, le visuel et le contenu. On peut être très fidèle sur l'une et pas sur les autres.
Un prototype basse fidélité, ce sont des écrans en gris, des textes résumés, parfois du papier. Il se modifie entre deux sessions de test. Selon le même article de Nielsen Norman Group, les gens osent davantage le critiquer, et les concepteurs y sont moins attachés. C'est le bon format pour une question d'architecture : dans quel ordre, combien d'étapes, qu'est-ce qui va où.
Un prototype haute fidélité a le vrai contenu, les vraies couleurs, des réactions immédiates au clic. Les gens s'y comportent presque comme sur un logiciel en ligne. C'est le bon format pour tester un parcours précis, la lisibilité d'un formulaire ou la compréhension d'un message réglementaire.
Choisissez à partir de la question, plutôt qu'en fonction de l'avancement du projet. Une question de structure se teste en gris, même tard. Une question de libellé se teste avec les vrais mots, même tôt.
03Trois pistes au même niveau de finition
S'il ne fallait garder qu'une chose de mes missions sur ce sujet, ce serait celle-ci : montrer plusieurs directions de maquette au même niveau de finition débloque une décision. Une maquette présentée seule se juge contre ce que chacun a en tête, et chacun a quelque chose de différent en tête. La discussion tourne alors autour de la maquette au lieu de trancher.
Le niveau de finition compte autant que le nombre. Mettez une piste soignée à côté d'une piste esquissée et la soignée gagnera, simplement parce qu'elle a l'air finie. Avec trois prototypes cliquables au même niveau, on compare enfin des idées, et non le temps passé sur chacune. On peut alors corriger ensemble à partir de là.
La recherche en ergonomie décrit cette méthode sous le nom de design parallèle. L'article de Therese Fessenden chez Nielsen Norman Group rapporte une étude où quatre versions avaient été créées en parallèle : la version qui fusionnait les meilleures idées des quatre était 70 % plus utilisable que leur moyenne. Le même article recommande au moins trois alternatives, cinq au maximum, et peu coûteuses : quelques jours chacune.
Je ne retiens pas le chiffre comme une promesse. Je retiens l'idée que la piste perdante apporte souvent quelque chose à la gagnante.
04Monter le prototype dans Figma, pas à pas
J'utilise Figma, comme pour le design system de Moonworkers. Le design et le prototype vivent dans le même fichier, et les personnes qui le consultent commentent directement sur le lien partagé.
La méthode que je suis
- Écrire la question du test et le parcours à couvrir, du premier écran à la sortie attendue.
- Dessiner uniquement les écrans de ce parcours, plus un ou deux états d'erreur réalistes (un champ refusé, un document illisible).
- Relier les zones cliquables aux écrans suivants. Le guide de prototypage de Figma appelle cela des connexions, avec un déclencheur (clic, survol, glisser) et une action (aller vers un autre cadre).
- Définir un point de départ par flux. Un fichier peut contenir plusieurs flux : j'en fais un par piste, pour partager un lien distinct pour chacune.
- Mettre les trois pistes au même niveau : mêmes textes, même contenu, même finition visuelle. C'est l'étape qu'on bâcle et celle qui compte le plus.
- Cliquer soi-même tout le parcours, puis le faire cliquer par quelqu'un qui ne l'a jamais vu, avant le premier test.
Si le prototype est partagé en ligne, je suis le conseil du manuel de service GOV.UK : le protéger par mot de passe, pour que personne ne le prenne pour le vrai service.
05Le tester avec cinq personnes
Vous n'avez pas besoin de cinquante testeurs, ni d'un logiciel. Nielsen Norman Group a mis en ligne sur sa chaîne une démonstration de test sur prototypes papier : des écrans simulés, basse puis plus haute fidélité, testés sur un site, un mobile et une borne. La vidéo a été tournée en 2011, et NN/g précise que la méthode vaut toujours.
Sur le nombre de personnes, Jakob Nielsen, dans un article de Nielsen Norman Group souvent cité, montre qu'un test avec cinq personnes trouve environ 85 % des problèmes d'utilisabilité, et que trois petits tests de cinq valent mieux qu'un seul test de quinze. Ce qui compte, c'est de corriger entre deux tours.
Avec plusieurs pistes, je fais voir deux ou trois versions à chaque personne, en changeant l'ordre d'une personne à l'autre, comme le recommande l'article sur le design parallèle. Sinon, la première piste vue part avec un avantage, ou un handicap.
Pendant la session, je parle peu. Je donne une tâche (« créez votre compte et invitez un collègue »), je regarde où la personne hésite, et je note l'endroit exact. Quand elle clique sur une zone qui ne mène nulle part, je lui demande ce qu'elle s'attendait à trouver. Cette réponse vaut souvent plus que le reste de la séance.
06Ce qu'un prototype ne vous dira pas
Un prototype a des limites, et je préfère les dire dès le départ.
Il ne teste pas la technique, et vous ne le saurez qu'au développement. Un écran qui s'affiche instantanément dans Figma peut mettre quatre secondes en production parce qu'il interroge trois systèmes. Il ne teste pas non plus les vraies données : un nom de quarante caractères, une adresse étrangère, un compte sans historique. Ces cas-là se voient en recette, et j'en parle dans ma checklist de recette et de mise en production.
Il ne remplace pas la spécification. Une fois la piste choisie, il faut encore écrire ce qui se passe derrière chaque bouton, ce que j'explique dans l'article sur la spécification d'intégration. Et le prototype ne se recycle pas en code : GOV.UK le dit sans détour, on ne copie pas du code de prototype en production.
Enfin, il coûte du temps. Trois pistes au même niveau, c'est trois fois plus de travail qu'une. Pour une page simple ou un écran d'administration utilisé par deux personnes, je ne le fais pas : une maquette et une discussion suffisent.
07Par où commencer la semaine prochaine
Si vous avez un développement d'interface prévu dans les prochaines semaines, commencez petit :
- écrivez la question que le prototype doit trancher, en une phrase ;
- choisissez la fidélité à partir de cette question ;
- préparez au moins deux pistes, idéalement trois, au même niveau de finition ;
- trouvez cinq personnes qui ressemblent à vos utilisateurs et réservez une heure avec chacune ;
- notez ce qui bloque, corrigez, puis refaites un petit tour.
Si vous voulez un regard extérieur sur un parcours avant de lancer le développement, c'est une partie de ce que je fais dans mes missions de conseil et de construction. On peut en parler.