Relier un prototype interactif aux écrans présentés

Décrire le parcours réellement montré

Donnez un nom à chaque scénario : consulter une commande, modifier une adresse ou confirmer une réservation. Notez l’écran de départ, l’action attendue et l’écran d’arrivée. Cette description reste utile même si le prototype devient inaccessible.

Distinguez les chemins démontrés des possibilités simplement évoquées. Si une interaction n’a pas été testée pendant la séance, indiquez-le. Les personnes absentes pourront ainsi comprendre la portée des retours sans imaginer un produit entièrement simulé.

Associer les écrans aux étapes

Attribuez des références aux écrans sélectionnés, puis reportez-les dans la carte des parcours. Conservez des exports lisibles avec leurs états particuliers : erreur affichée, dialogue ouvert ou donnée de test choisie pour la démonstration.

Une même page peut apparaître plusieurs fois avec des contenus différents. Ne lui donnez pas une référence unique si cette différence change la compréhension du parcours. Décrivez les données fictives pour éviter de les confondre avec un contenu validé.

Noter les limites de la simulation

Indiquez ce qui était simulé : recherche figée, chargement absent, formulaire non connecté ou retour arrière simplifié. Ces informations aident à distinguer un choix de conception d’un raccourci destiné à rendre la présentation plus fluide.

Relevez les comportements attendus qui n’apparaissent pas dans les captures, notamment les transitions et les conditions d’affichage. Ne présentez pas la démonstration comme une validation technique du futur service ; elle constitue une base de discussion de conception.

Conserver les retours avec leur contexte

Reliez chaque remarque au scénario et à l’écran concernés. Une demande « ajouter une étape » doit préciser où elle intervient et quel problème elle cherche à résoudre. Faites confirmer les points qui ont reçu des avis contradictoires.

Archivez le relevé de séance avec les écrans et la carte des parcours. Si le prototype évolue, créez une nouvelle référence de présentation. Gardez l’ancien lien dans l’historique sans supposer qu’il affiche encore l’état montré ce jour-là.

Exemple fictif : présentation Transit du 8 avril

Exemple fictif à adapter à votre projet.

Scénario du projet Transit	Écrans conservés	Limite notée
Modifier une adresse	T12, T13, T15	Données de test fixes
Confirmer le changement	T15, T16	Envoi simulé
Revenir à la commande	T16, T10	Retour simplifié

Parcours et références fictifs ; la table permet de retrouver les écrans réellement commentés.

Avant de transmettre

• Nommer chaque scénario présenté.
• Identifier les écrans et leurs états.
• Conserver les données de démonstration utiles.
• Écrire les limites de simulation.
• Rattacher les retours au bon parcours.

Questions pratiques

Pourquoi garder des écrans si le lien fonctionne ?

Le lien peut montrer un nouvel état. Les écrans identifiés et le relevé des transitions permettent de comprendre la présentation antérieure et ses décisions.

Faut-il enregistrer toute la séance ?

Choisissez un moyen adapté aux participants et aux règles du projet. Une carte des parcours et un relevé précis peuvent suffire à documenter les points discutés.

Pour poursuivre

Livrer une interface avec son contexte

Conserver une décision de validation

Préparer une présentation exploitable

Cette méthode aide à identifier et conserver les pièces du projet. Elle ne remplace pas sa validation technique ni l’examen des droits et engagements applicables.