dennisyjlee/prototype-reel

Reel de prototype

Prototypez comme si c'était réel, puis racontez l'histoire en vidéo.

Une maquette statique montre à quoi ressemble un écran. Elle ne peut pas montrer ce que le produit procure : ce qui se charge en premier, où votre pouce atterrit, ce qu'il se passe en cas d'échec. Ce skill construit des prototypes qui se comportent comme la chose en cours de développement, les met sous les yeux des gens pour recueillir des retours, puis parcourt le même prototype image par image pour générer une vidéo de démonstration. Pas d'enregistrement d'écran : une modification du design entraîne un nouveau rendu, pas un nouveau tournage.

Les règles ici proviennent de véritables cycles de relecture. Chacune a commencé comme une note d'un relecteur et est devenue une règle par défaut pour que la note n'ait jamais à être donnée deux fois.

Quand l'utiliser (et quand ne pas le faire)

• Prototypez lorsque l'idée dépend du comportement : timing, chargement, transitions, gestes, cas limites ou un flux en plusieurs étapes. Également lorsque les relecteurs réagissent sans cesse aux images plutôt qu'à l'expérience.
• Réalisez une vidéo lorsque le public ne peut pas cliquer : une diapositive en boucle, une vignette de site, une mise à jour asynchrone, une étude de cas. La vidéo est la façon dont le prototype est partagé à grande échelle.
• Ignorez-le pour des questions de mise en page ou visuelles auxquelles une image statique répond, et pour des idées très précoces où un wireframe est moins coûteux. Prototypez une fois la direction choisie.

Workflow

Effectuez ces étapes dans l'ordre. Ne sautez pas directement au rendu.

1. Chargez le contexte. Récupérez les designs réels (fichier de design, captures d'écran, jetons de design), le flux et l'objectif. Demandez ce que le public doit comprendre après avoir regardé ou cliqué. Lisez references/fidelity.md.
2. Listez d'abord les états et comportements. Avant le code, écrivez chaque écran, état et transition : chargement, vide, erreur, succès, retour, le toast, le cas limite. Une ligne chacun. Confirmez la liste avec la personne.
3. Construisez le HTML en direct. Commencez à partir de kit/shell.html. Reconstruisez les écrans en DOM réel avec de véritables cibles tactiles, jamais de captures d'écran avec zones cliquables. Lisez references/behavior.md.
4. Parcourez-le vous-même. Exécutez chaque chemin à la fois sur ordinateur et mobile avec un navigateur sans tête. Capturez chaque état. Zéro erreur dans la console. Corrigez avant de partager.
5. Partagez pour obtenir des retours. Publiez un lien avec des légendes et des indications tactiles activées (references/sharing.md). Consignez chaque note dans le format references/feedback-log.md : la note, la règle qu'elle devient.
6. Rédigez la liste des plans. Une ligne par temps fort : heure | à l'écran | action | plan | point narratif. Nommez chaque temps fort comme un plan (présentation, insert, coupe sur l'action, cut, révélation ; voir references/pacing.md, Grammaire cinématographique). Une idée par temps fort. Obtenez un accord avant de construire la vidéo.
7. Prévisualisez, puis effectuez le rendu. Pilotez le prototype sur une horloge en pause et capturez les images. Envoyez d'abord un aperçu basse résolution (15 ips, demi-taille). Effectuez le rendu en pleine qualité uniquement après approbation du timing. Lisez references/pacing.md et references/motion-tokens.md.
8. QA, puis livrez. Exécutez chaque vérification dans references/qa.md et dites ce que vous avez vérifié dans le message de livraison. Une correction ne modifie que ce qui a été signalé.

Non-négociables

• DOM réel, pas d'images avec zones cliquables. Images uniquement pour les photos, logos et médias.
• Le texte utilise les jetons du design (famille, taille, hauteur de ligne, crénage), jamais de valeurs définies manuellement. Confirmez que les polices sont installées là où vous effectuez le rendu.
• Les toasts et superpositions se situent au-dessus du contenu. Ils ne poussent jamais la page autour.
• Une seule famille d'interpolation par pièce. Ease-out pour les entrées, jamais d'ease-in sur l'interface utilisateur, jamais d'échelle à partir de 0. Pas de rebond sur l'interface utilisateur, sauf pour le moment de révélation (voir motion-tokens.md, Le jeu est pour la révélation).
• Attendez après l'atterrissage sur un nouvel écran avant que quoi que ce soit ne bouge : environ 0,9 s pour un écran léger, 1,4 s par défaut, environ 2,4 s pour les écrans riches en texte.
• Encadrez le tap avec son contexte : effectuez un zoom sur la ligne ou le groupe, pas sur le bouton seul.
• Le langage cinématographique ne prévaut jamais sur le comportement de l'interface utilisateur. Chaque élément s'anime sur son propre calque.
• Marqueur tactile uniquement sur les taps. Pas de doigt sur les défilements.
• Les boucles de diapositives restent à 20 s ou moins, sauf si l'histoire en demande plus et que la personne est d'accord. Les clips explicatifs bouclent uniquement le moment qu'ils enseignent.
• Aperçu basse résolution avant tout rendu complet.
• Pas de livraison sans la validation QA.
• Lorsqu'un relecteur donne une note, transformez-la en règle et notez-la.

Fichiers

• references/behavior.md : faire en sorte que le prototype se comporte comme le vrai produit
• references/fidelity.md : correspondre exactement au design source
• references/sharing.md : le configurer pour les retours
• references/pacing.md : rythme de présentation pour les vidéos de démonstration
• references/motion-tokens.md : easing, durées et motifs d'animation
• references/qa.md : les vérifications que chaque livraison réussit
• references/feedback-log.md : comment les notes deviennent des règles, avec des exemples réels
• kit/shell.html : coque de prototype neutre (barre d'outils, bureau/mobile, cadre d'appareil, légendes, indications tactiles)
• kit/proto.css, kit/proto.js : transitions, feuilles, toasts, squelettes, curseur