Choisir un prototype ne consiste pas à décider à quel point il doit ressembler au produit final. Il s’agit de déterminer quelle question importante doit être résolue avant d’investir davantage de temps et de budget. Un croquis peut aider à vérifier si une proposition est comprise ; il ne démontre pas que la technologie peut la prendre en charge. Un test technique peut réduire cette incertitude, mais ne confirme pas que quelqu’un voudra utiliser le produit.
Pour les responsables produit, métier et technique, la règle pratique est simple : le format doit répondre à l’incertitude principale, avec le coût et le réalisme les plus faibles qui restent suffisants. On évite ainsi de trop construire et de prendre une réaction favorable pour une preuve de faisabilité ou d’usage réel.
Commencez par nommer l’incertitude
Avant d’ouvrir un outil de conception ou d’écrire du code, précisez quelle décision dépendra des enseignements de l’expérience. Plusieurs questions peuvent se poser, mais il est préférable d’en privilégier une par expérimentation :
- Problème : le public rencontre-t-il un besoin important et en reconnaît-il les conséquences ?
- Compréhension : comprend-il ce que propose la solution et ce qu’il doit faire ?
- Désirabilité : la solution a-t-elle suffisamment de valeur pour que la personne souhaite poursuivre ?
- Faisabilité technique : les intégrations, les données ou les contraintes importantes peuvent-elles être prises en charge ?
- Opérations : le service peut-il être fourni avec les personnes, les processus et les délais disponibles ?
Un entretien ou une preuve de concept de service sera peut-être plus pertinent qu’un prototype visuel si l’importance du problème n’est pas encore établie. En revanche, si les personnes décrivent un besoin concret, mais que la manière d’accomplir la tâche reste floue, il peut être utile de tester une structure ou un parcours.
Croquis ou wireframe : vérifier la structure et la compréhension
Un croquis sur papier ou un wireframe simple permet d’explorer la hiérarchie, le contenu et l’organisation des écrans sans investir dans les détails visuels. Il est utile pour vérifier si une personne repère l’action principale, comprend les libellés ou trouve les informations dont elle a besoin.
Proposez une tâche concrète, par exemple « trouvez comment modifier l’adresse de livraison », plutôt que de demander si l’écran plaît. Observez ce que la personne essaie de faire, où elle s’arrête et comment elle interprète les éléments. Si plusieurs personnes butent sur la même consigne, c’est un signal qui invite à revoir la conception.
Ce que ce format peut apporter : des indications sur la compréhension, la hiérarchie et la structure. Ce qu’il ne démontre pas : la qualité de l’interface finale, la facilité d’utilisation en production ni la volonté de payer. Comme il est schématique, il peut omettre des signaux visuels susceptibles d’influencer la décision.
Prototype interactif : évaluer des parcours sans construire le produit
Un prototype interactif simule des écrans et des transitions pour permettre à une personne de suivre un parcours, comme s’inscrire, comparer des options ou démarrer une demande. Il convient lorsque la question porte sur l’ordre des étapes, la clarté des choix ou les frictions entre les écrans.
Définissez une tâche réaliste et laissez la personne avancer sans lui indiquer où cliquer. Notez les erreurs, les retours en arrière, les hésitations, les abandons et les moments où elle demande de l’aide. Si le parcours comprend des états importants — une erreur, une confirmation ou une solution de remplacement, par exemple —, incluez-les : un parcours qui ne fonctionne que dans le scénario idéal peut masquer des problèmes.
Le prototype peut sembler convaincant, mais les éléments simulés ne sont pas des fonctionnalités opérationnelles. Il ne permet pas de conclure que les performances, la sécurité, les intégrations ou le comportement avec des données réelles sont satisfaisants. Précisez quelles parties sont simulées afin de ne pas confondre une démonstration fluide avec un produit déjà viable.
Simulation ou service manuel : tester l’expérience complète
Lorsque la proposition dépend d’un travail humain en coulisses, une simulation permet de tester le service avant de l’automatiser. Par exemple, une équipe peut recevoir des demandes au moyen d’un formulaire et les traiter manuellement pour observer les informations manquantes, l’effort nécessaire pour chaque cas et ce que l’utilisateur attend après l’envoi.
Cette approche est précieuse si l’incertitude principale concerne les opérations : qui prend en charge les demandes, quelles étapes se répètent, quelles exceptions surviennent ou à quel endroit les retards se produisent. Il convient de délimiter le périmètre, d’expliquer honnêtement les conditions du test et de protéger les éventuelles données personnelles recueillies. Ne promettez pas une capacité que l’équipe n’est pas encore en mesure de fournir de façon constante.
Une expérience manuelle aide à comprendre le processus, mais ne prouve ni que les opérations peuvent passer à l’échelle ni qu’une automatisation future le reproduira. Si chaque cas exige une intervention exceptionnelle, c’est un élément à prendre en compte dans la décision, et non un détail à dissimuler derrière un écran soigné.
Test technique ou spike : réduire les risques de mise en œuvre
Si l’incertitude concerne une intégration, un format de données, une contrainte d’architecture ou l’accès à un système, un petit test technique peut être plus utile qu’une nouvelle série de travaux de conception. L’objectif n’est pas de construire une première version complète, mais de répondre à une question vérifiable : peut-on échanger cette donnée ? Quelle limite apparaît ? Quelle autre option mérite d’être évaluée ?
Avant de commencer, définissez le périmètre, l’hypothèse testée et le résultat qui pourrait modifier la décision. Documentez les dépendances, les contraintes et les éléments qui n’ont pas été testés. Une démonstration dans un environnement contrôlé ne garantit ni la fiabilité, ni la sécurité, ni les performances, ni la conformité en production. Si ces aspects sont déterminants, ils doivent faire l’objet de leur propre évaluation et être confiés à des responsables.
Comment choisir le format adapté
Comparez chaque option en fonction des enseignements attendus, du coût de préparation, du niveau de réalisme nécessaire et du risque de lui faire dire plus qu’elle ne démontre. Il n’est pas nécessaire de maximiser le réalisme dans tous les cas : une fidélité accrue peut détourner l’attention ou amener à confondre apparence et fonctionnement.
- Si l’équipe débat encore de l’importance du problème, commencez par étudier celui-ci avant de prototyper l’interface.
- Si la question porte sur l’endroit où trouver un élément ou sur la compréhension d’un écran, utilisez un croquis ou un wireframe.
- Si vous devez observer une séquence d’actions, préparez un prototype interactif et des tâches concrètes.
- Si le service exige une intervention humaine, simulez le processus et consignez le travail nécessaire.
- Si une dépendance technique peut bloquer la proposition, limitez le test technique à cette dépendance.
Vous pouvez également combiner plusieurs formats, mais de manière séquentielle : commencez par un test peu coûteux qui élimine une incertitude précoce, puis passez à un test plus réaliste si la décision reste en suspens. L’équipe n’investit ainsi pas dans un parcours détaillé avant de savoir si le besoin mérite d’être satisfait.
Participants, signaux et limites d’interprétation
Choisissez des participants qui ressemblent au public concerné par la décision ; le fait qu’il soit pratique de recruter des personnes proches de l’équipe ne les rend pas représentatives. Le nombre de sessions ne suffit pas, à lui seul, à corriger un échantillon biaisé. Décrivez qui a participé, dans quel contexte et quels facteurs peuvent limiter l’interprétation des résultats.
Privilégiez les signaux observables liés à la tâche : la personne l’a-t-elle menée à bien, où a-t-elle hésité, quelle option a-t-elle choisie ou quelles informations a-t-elle demandées ? Les opinions aident à expliquer une réaction, mais « j’aime bien » ne signifie pas usage, adoption ou achat. De même, réussir une tâche dans un contexte guidé ne prouve pas que la personne reviendra de sa propre initiative.
Évitez les questions qui suggèrent une réponse, comme « trouvez-vous cela facile ? ». Demandez plutôt à la personne d’expliquer ce qu’elle s’attend à voir se produire ou de réaliser une tâche sans aide. Notez les résultats qui confirment l’hypothèse comme ceux qui la contredisent ; ne retenir que les éléments sélectionnés après coup facilite les conclusions hâtives.
Transformer les enseignements en décision
Avant le test, convenez des résultats qui permettraient d’avancer, des observations qui imposeraient de changer d’approche et des risques nécessitant une autre évaluation. Il n’est pas nécessaire de fixer des seuils numériques arbitraires : l’essentiel est que l’équipe définisse à l’avance les éléments de preuve suffisants pour prendre la décision concernée.
Ensuite, résumez la question, le format utilisé, les conditions du test, les signaux observés et les limites. Décidez s’il faut apporter des modifications, réexaminer le problème, explorer une autre solution ou passer à une étape de validation ultérieure. Si les enseignements ne sont pas concluants, adaptez l’expérimentation pour isoler l’incertitude, au lieu de présenter celle-ci comme un résultat positif.
Un bon prototype n’est pas celui qui semble le plus abouti, mais celui qui permet de prendre une décision mieux éclairée. Le choisir en fonction de l’incertitude permet de proportionner l’effort au risque et de préciser ce que l’on sait, ce qui reste à découvrir et quelle est la prochaine étape raisonnable.