Et si vous faisiez un prototype papier?

Désuet? Low tech? Il reste pourtant encore utilisé par de nombreuses entreprises au détriment d’autres outils plus sophistiqués. Alors que la complexité de prise en main d’outils de prototypage digitaux baisse, faisons ici un inventaire pour voir à quoi sert le prototype papier (PP), pourquoi/pour qui il reste une alternative séduisante, quand il est pertinent de l’utiliser et à quelles fins.

Pré-requis pour un prototype (papier ou non)

Le but d’un prototype — qu’il soit en papier ou non — c’est de répondre à des questions au sujet d’utilisateurs, en évaluant leur taux de succès dans la réalisation de certaines tâches à l’aide de celui-ci.

Créer un prototype exige donc que l’on ait définit ses utilisateurs (personas), et des scénarios qui leurs sont propres. Les scénarios d’utilisation permettent de définir les éléments fonctionnels (parties visibles du prototype pour l’utilisateur ). Lors de la phase de test on évalue l’interaction entre l’utilisateur et les éléments fonctionnels, le taux de succès de scénarios (par exemple: “trouvez un maillot de bain rouge pour hommes” sur un site de e-commerce), la compréhension générale et l’appréciation du produit par l’utilisateur.

Pour qui est-ce utile?

Pour les équipes multidisciplinaires dont certains membres ne possèdent pas de compétences en outils de prototypage digitaux. Par sa simplicité, le PP permet d’assurer que chaque membre d’une équipe ait une chance de contribuer au développement du produit, ce qui maximise les chances d’inclure les points de vue de toutes les parties prenantes (support client, vente, etc.). A l’inverse, le prototypage digital suppose la maitrise d’un outil et peut donc être une barrière à la participation de ces profils peu/pas techniques qui ont des informations clés à faire valoir. La diversité d’opinions permet d’augmenter les chances de concevoir un produit qui ne soit pas le fruit d’un biais de confirmation, de manière générale il est donc positif d’abaisser au maximum la barrière à l’entrée pour permettre au plus grand nombre de prendre part à cet exercice.

Quand est-il utile?

Quand le produit final potentiel est une solution digitale qui fait appel à de nombreuses bases de données, de couches logiques, on peut gagner un certains temps à les simuler avec du papier et des interactions humaines (staging). On économise alors le temps de développement que ces éléments auraient engendrés.

Quand on cherche à comprendre si la navigation à travers différents écrans ou workflows, (pour un produit digital) ou les étapes d’utilisation (pour un produit physique) et l’emplacement d’éléments fonctionnels, les termes utilisés ou encore les catégories sont compréhensibles et font sens pour les futurs utilisateurs.

Quand on veut mener un test utilisateur avec l’ensemble de l’équipe produit et que l’on veut créer des changements de mise en page (layout) à la volée.

Quand on veut créer de la cohésion d’équipe et de l’alignement au sujet des objectifs à atteindre entre les parties prenantes en début de projet et éliminer les prises de position subjectives basées sur l’opinion.

Quand et pour qui est-il potentiellement inutile?

Quand une équipe ne peut pas répondre à la question “quel est le problème que nous cherchons à résoudre?” Si la réponse diffère entre les membres d’une équipe, mieux vaut prendre le temps de clarifier cette question en passant du temps sur la recherche utilisateur.

Quand on cherche à comprendre les problèmes sur une solution existante, duhhh, à ce moment autant utiliser le vrai produit.

Le PP est moins efficace quand il s’agit de délivrer de l’information complexe rapidement, l’humain ne pouvant rivaliser avec l’ordinateur pour ce type de tâches.

Pour une petite équipe de designer qui maitrise un outil de prototypage digital, celui-ci va leur sauver de précieuses heures de travail grâce à l’automatisation.

Que permet-il de découvrir?

D’aucuns diront: mais je ne vais pas montrer un produit à moitié fini ou bancal à mes futurs clients, ça me décrédibilisera. Ce que l’on cherche à découvrir c’est comment l’utilisateur va se servir de la solution et ce qu’il en comprend. Pas ce qu’il aime, ou ce qu’il pense du graphisme. On peut toujours accompagner une séance de testing d’un peu de contexte, par exemple en expliquant: “le graphisme sera adressé dans une étape suivante donc ne vous en souciez pas à ce stade”.

Comment gérer les bases de données et les liens?

Quand on parle de créer des solutions digitales, la partie la plus complexe à gérer avec un prototype papier est la partie “dynamique”. Pour palier à cette complexité il faut prévoir des scénarios d’utilisation dans lesquels les données qui devront apparaître sont prédictibles. Quand à la partie des clicks, il faut observer l’utilisateur et se montrer proactif, quand il pointe son doigt sur un texte qui est censé être un lien, le facilitateur doit faire apparaître le contenu (objet, fenêtre, feedback, etc.) qui correspond à sa requête. Lorsque l’utilisateur pointe sur un texte qui n’est censé être un lien alors on peut également se demander si ça ne vaudrait pas la peine qu’il y en ait un dans le produit fini.

Conclusion

Bien que les outils de prototypages digitaux se démultiplient, deviennent de moins en moins couteux, de plus en plus simples à prendre en main et permettent une plus grande flexibilité (notamment en matière de testing à distance, d’enregistrement de sessions, d’automatisation) ils restent intimidants pour certains, donc clivants et augmentent le risque d’un manque de perspective sur le problème à résoudre.

Faire un atelier de prototypage papier “early stage” peut donc s’avérer un excellent outil d’alignement entre équipes en ce qu’il amène tout le monde à se mettre d’accord autour de la question du “problème à résoudre” et à s’investir dans la création d’une première réponse. “Une image vaut 1000 mots mais un prototype 1000 réunions”.