Prototypage

Ce que couvre cette catégorie

Rendre quelque chose cliquable avant que quiconque ne le construise : maquettes interactives, changements d’état, parcours que l’on peut vraiment essayer, et tests qui transforment des opinions en observations.

Le recoupement avec les logiciels de design est important, puisque la plupart des plateformes de design incluent désormais le prototypage. Des outils dédiés existent pour les cas où l’interaction porte une vraie logique, ou lorsque la recherche utilisateur exige enregistrement et analyse.

La conception d’écrans et les systèmes de design relèvent du design. La création d’applications complètes sans code relève du no-code et de l’automatisation.

La fidélité est une décision, pas un réglage par défaut

Le gaspillage le plus courant dans cette catégorie consiste à construire un magnifique prototype pour répondre à une question que des cases grises auraient réglée.

La basse fidélité teste la structure : si les gens comprennent le parcours, ce qu’ils attendent ensuite, où ils hésitent. C’est rapide, peu coûteux, et presque impossible d’y trop investir.

La haute fidélité teste la compréhension et la confiance. Le soin visuel modifie les comportements, et un écran brut rend les gens indulgents d’une façon qu’un vrai produit n’obtient pas : tout ce qui touche à la confiance ou à l’achat doit donc paraître abouti.

Décidez d’abord de la question, choisissez ensuite la fidélité. Procéder à l’envers, c’est ainsi que trois semaines disparaissent dans des animations dont personne ne demandait rien.

Ce qui distingue les outils

• La profondeur des interactions, des simples liens aux conditions et aux variables.
• L’état, pour qu’un écran se souvienne de ce qui vient d’être saisi.
• Les composants, réutilisés d’un écran à l’autre sans doublonner le travail.
• Les données, réelles ou réalistes, plutôt que le même texte factice partout.
• Le test sur appareil, sur un vrai téléphone plutôt que dans un cadre mis à l’échelle.

Variables et conditions marquent la ligne de partage. Un prototype capable de conserver une saisie de formulaire, de bifurquer selon elle, de mémoriser le choix et d’afficher un véritable état d’erreur répond à des questions que l’approche par écrans reliés ne peut pas traiter.

Un contenu réaliste compte plus qu’on ne le croit. Noms longs, listes vides, images manquantes et messages d’erreur sont là où les maquettes se cassent, et le texte factice les masque tous.

Les tests, qui sont le vrai but

Un prototype existe pour être montré à quelqu’un qui n’était pas dans la pièce.

Les séances animées produisent du raisonnement : pourquoi une personne a hésité, ce qu’elle a compris d’un mot. Les tests sans animateur produisent du comportement à grande échelle et à moindre coût, sans la question de relance. Les deux valent mieux qu’une réunion de revue où l’opinion la plus bruyante l’emporte.

Cinq participants par groupe d’utilisateurs révèlent la plupart des problèmes d’utilisabilité. Au-delà, le rendement chute nettement, et le temps est mieux employé à corriger ce qui a été trouvé puis à tester de nouveau.

Rédigez la tâche avant de recruter qui que ce soit. Regarder quelqu’un tenter d’accomplir une action précise est une preuve, alors que demander son avis sur un écran est une conversation de goût.

Du prototype à la réalisation

La question de la passation est de savoir ce qui survit.

Certaines équipes traitent le prototype comme une spécification : le relevé de chaque état, transition, cas vide et cas limite qui seraient sinon débattus pendant l’implémentation. C’est là que se trouve l’essentiel de la valeur.

Le code généré s’est amélioré et doit encore être réécrit pour la production. Considérez tout export comme une esquisse de départ plutôt qu’un raccourci, et attendez-vous à ce que l’implémentation réelle soulève des questions que le prototype n’a jamais rencontrées, notamment sur les performances et l’accessibilité.

Coût et contraintes pratiques

La tarification se fait par éditeur et par mois, les lecteurs étant généralement gratuits, tandis que les plateformes de recherche dédiées facturent plutôt par étude ou par participant.

Le coût le plus lourd est le temps. Un prototype qui prend deux semaines à construire a coûté plus cher que la réunion qu’il remplaçait : gardez donc le périmètre lié à la question. Les services de test ajoutent des frais par participant, parfois avec le recrutement inclus, et c’est normalement de l’argent bien dépensé comparé à des suppositions. Les habitudes tarifaires plus générales du logiciel sont décrites dans ce que cachent les pages de tarifs.

Là où les prototypes valent leur coût

Trois situations rentabilisent à coup sûr l’effort d’en construire un.

Un parcours réellement complexe, où les descriptions écrites donnent des images différentes dans des têtes différentes et où le désaccord n’apparaît qu’à l’implémentation.

Une décision qui engage de l’argent, où un paiement, une page de tarifs ou un parcours d’inscription peuvent être testés avec de vraies personnes avant que quiconque ne les construise.

Une présentation, interne ou externe, où montrer quelque chose qui fonctionne fait passer la conversation de l’opinion au détail.

En dehors de ces cas, une description bien écrite et un écran statique font souvent l’affaire. La discipline à garder est de se demander à quelle question le prototype répond, et de s’arrêter dès qu’on y a répondu, au lieu de continuer parce que le fichier est agréable à travailler.