La réunion d’approbation d’un prototype haute fidélité est trompeuse. Les toiles sont belles, tout le monde hoche la tête, quelqu'un dit "ça a l'air génial" et le projet avance. Des semaines plus tard, le développement s'arrête sur des questions que personne n'a posées dans cette salle : que se passe-t-il lorsque la liste est vide ? Qu’en est-il de l’état d’erreur ? Et hors ligne ?
La différence entre un prototype qui fait le travail et un autre qui cache les problèmes n’est pas la beauté. C’est dans la rigueur de l’examen. L'approbation basée sur l'apparence est l'erreur la plus courante et la plus coûteuse commise par ceux qui travaillent avec des produits.
Ce texte s’adresse à ceux qui sont sur le point de se décider : allons-nous construire cela ? Au lieu d'expliquer ce qu'est un prototype haute fidélité, il propose une liste de contrôle, les questions qui séparent un prototype prêt à devenir un produit de celui qui générera des retouches.
Pourquoi approuver sur la base de l'apparence est risqué
La haute fidélité trompe le cerveau. Quand quelque chose semble réel, nous supposons qu’il est terminé. C'est un parti pris connu : le réalisme visuel crée un sentiment de préparation qui souvent ne correspond pas à la profondeur de ce qui a été pensé.
Le résultat est que les décisions importantes deviennent invisibles. Le prototype montre le chemin heureux, l'utilisateur fait tout correctement, la connexion fonctionne, les données existent. Mais le vrai produit vit de manière malheureuse : champs erronés, connexions instables, listes vides, autorisations refusées.
Un prototype haute fidélité qui ne couvre que le chemin du bonheur n'est pas prêt à être approuvé. Il est prêt à être interrogé. Et un questionnement structuré est ce que garantit la liste de contrôle.
La thèse : la checklist protège de l'optimisme
Je préconise que chaque approbation de prototype haute fidélité soit soumise à un examen délibéré, avec des questions fixes, aussi convaincantes soient-elles. Non pas par méfiance, mais parce que l’optimisme est l’état naturel de quelqu’un qui vient de produire quelque chose de beau.
La liste de contrôle n’est pas de la bureaucratie. C'est le moyen de détourner l'attention de « est-ce que ça a l'air sympa ? à "est-il complet et constructible ?". Cela force la conversation difficile avant de s'engager, alors qu'elle est encore bon marché.
Les équipes qui adoptent cette discipline voient une vraie baisse de retravail. Les problèmes qui apparaîtraient dans le sprint 3 apparaissent dans la revue du prototype, coûtant une conversation au lieu d'une refonte.
La liste de contrôle des états et exceptions
Le premier front de révision est le plus négligé : celui des États qui ne sont pas sur la bonne voie.
Pour chaque écran important, demandez : Comment apparaît-il vide, sans données ? Comment se présente le chargement ? Comment apparaît-il en cas d'erreur ? Qu’en est-il lorsqu’il y a trop de données, une liste avec des centaines d’éléments, un nom trop long, un texte qui surcharge la mise en page ?
Allez plus loin et couvrez les exceptions de connexion : que voit l’utilisateur hors ligne ? Que se passe-t-il lorsque l'opération échoue au milieu ? Qu’en est-il s’il n’a pas la permission pour ce qu’il a essayé de faire ?
Si le prototype ne répond pas à ces questions, ce n’est pas faux, il est incomplet. Et approuver un prototype incomplet comme s'il était prêt transfère le problème au développeur, qui inventera des réponses sous la pression des délais.
La liste de contrôle du contenu et de la clarté
Le deuxième front est celui du contenu. Les prototypes haute fidélité utilisent souvent du texte soigneusement choisi pour s'adapter parfaitement. Le vrai produit n’a pas ce luxe.
Vérifiez que les textes sont réels et plausibles, non optimisés pour la mise en page. Testez avec le nom le plus long, la valeur la plus élevée, le titre le plus long. Confirmez que les étiquettes des boutons indiquent ce qu'ils font, que les messages d'erreur guident plutôt qu'effrayent et que les termes techniques n'ont pas filtré dans l'interface utilisateur final.
Dans un service public numérique, cette préoccupation est encore plus sérieuse. Le citoyen a besoin de comprendre ce qui lui est demandé sans connaître le vocabulaire interne de l'agence. Une étiquette ambiguë sur un formulaire de prestations peut entraîner des erreurs de remplissage massives et un service en face à face que les services numériques auraient dû éviter.
Le contenu fait partie de l’expérience, pas de l’embellissement. Un prototype approuvé sans révision du texte reporte un problème garanti.
La checklist de faisabilité technique
Le troisième front exige que l’ingénierie participe à l’examen, et pas seulement la conception et les affaires.
Demandez : ce flux est-il constructible dans le délai prévu ? Y a-t-il des interactions qui semblent simples dans le prototype mais qui sont coûteuses à mettre en œuvre ? Les données qui apparaissent à l'écran existent-elles réellement dans le système, ou ont-elles été inventées pour donner une belle apparence au prototype ?
Cette dernière question bouleverse de nombreux prototypes. Il est courant de concevoir des écrans avec des informations que le système ne peut pas fournir ou qui dépendent d'intégrations qui n'existent pas. Découvrir cela dans la revue coûte une conversation. Découvrir la mise en œuvre coûte une refonte.
Amener l’ingénierie à l’approbation n’est pas une méfiance à l’égard de la conception. C’est reconnaître que la faisabilité fait partie de la qualité d’un prototype. Un beau prototype inconstructible est un document de frustration future.
La liste de contrôle des attentes et de la portée
Le quatrième front concerne les personnes présentes dans la pièce, pas les écrans.
Avant de clôturer l’approbation, soyez clair : que couvre ce prototype et que ne couvre-t-il pas ? Est-ce que cela représente la version finale ou juste une partie ? Combien de temps sépare réellement ce prototype du produit livré ?
Cet alignement évite l’attrition classique dans laquelle les parties prenantes voient le prototype réaliste et commencent à le traiter comme un produit presque fini. Lorsque ce qui est livré n’est pas à la hauteur du prototype, la perception est celle d’un échec, alors qu’en réalité ce n’était que la distance naturelle entre simulation et construction.
Enregistrer la portée du prototype, même en une seule phrase, protège l'équipe et protège la relation avec celui qui sponsorise le projet.
Faire de la liste de contrôle une habitude
Une liste de contrôle ne fonctionne que si elle est utilisée à tout moment, et pas seulement lorsque le projet est de grande envergure. La tentation est de sauter l'examen lorsque le prototype « semble évident ». C’est précisément dans ces cas-là que les États oubliés passent inaperçus.
La meilleure façon d'intégrer cela est de le rendre léger : une courte liste, examinée ensemble, avec la conception, le produit et l'ingénierie dans la même conversation. Il n’est pas nécessaire que ce soit un formulaire long. Il doit s’agir d’une pause délibérée avant de « passer ».
Le leadership définit si cela tient. Lorsque les dirigeants posent des questions difficiles lors de l’évaluation, l’équipe comprend que l’approbation est une responsabilité et non une formalité. Lorsque la direction approuve sur la base de l’apparence, l’équipe apprend à se concentrer sur la vitrine et à ignorer le fond.
En fin de compte, la liste de contrôle est un acte d’honnêteté envers l’avenir. Il échange le confort du « c'est beau, approuvé » contre le travail consistant à faire en sorte que ce qui est beau soit également complet, clair et constructible. Ce travail n’est pas glamour, mais c’est ce qui différencie les équipes qui livrent des résultats des équipes qui refont.
Si vous mettez en place un processus d'approbation de prototype et souhaitez structurer une évaluation comme celle-ci, il existe d'autres textes ici sur le blog sur le prototypage et la qualité des produits. Et si vous souhaitez discuter de la manière d’adapter la liste de contrôle à votre contexte, il vous suffit d’appeler pour en parler.
A lire aussi
- Prototype haute fidélité : qu'est-ce que c'est et quand ça vaut le coup
- Prototype haute fidélité : guide rapide pour le faire sans perdre de temps -Découverte de produits - Frameworks avec liste de contrôle -Le prototypage d'applications en pratique : comment tester des idées avant de dépenser du code -Prototypage d'applications : comment transformer des prototypes en routines produits
- Prototypage d'applications : optimisation avec des exemples