dennisyjlee/prototype-reel

Prototype Reel

Prototypen wie echt, dann die Geschichte mit Video erzählen.

Ein statischer Mock zeigt, wie ein Bildschirm aussieht. Er kann nicht zeigen, wie sich das Produkt anfühlt: was zuerst lädt, wo der Daumen landet, was passiert, wenn es fehlschlägt. Diese Fähigkeit baut Prototypen, die sich wie das zu bauende Ding verhalten, stellt sie vor Leute für Feedback und fährt dann denselben Prototypen Frame für Frame, um ein Walkthrough-Video zu rendern. Es gibt keine Bildschirmaufnahme, also bedeutet eine Änderung am Design ein erneutes Rendern, nicht eine erneute Aufnahme.

Die Regeln hier stammen aus echten Review-Runden. Jede begann als Notiz eines Reviewers und wurde zu einem Standard, damit die Notiz nie wieder gegeben werden musste.

Wann verwenden (und wann nicht)

• Prototyp erstellen, wenn die Idee von Verhalten abhängt: Timing, Laden, Übergänge, Gesten, Randfälle oder ein mehrschrittiger Ablauf. Auch wenn Reviewer ständig auf Bilder statt auf das Erlebnis reagieren.
• Video erstellen, wenn die Zielgruppe nicht klicken kann: eine Diashow, ein Website-Tile, ein asynchrones Update, eine Fallstudie. Video ist, wie der Prototyp in großem Maßstab geteilt wird.
• Überspringen für Layout- oder visuelle Fragen, die ein statisches Bild beantwortet, und für sehr frühe Ideen, bei denen ein Wireframe günstiger ist. Prototyp erstellen, wenn die Richtung gewählt ist.

Workflow

Diese Schritte in der Reihenfolge ausführen. Nicht zum Rendern vorspringen.

1. Kontext laden. Die echten Designs holen (Design-Datei, Screenshots, Design-Tokens), den Ablauf und das Ziel. Fragen, was das Publikum nach dem Anschauen oder Klicken verstehen soll. references/fidelity.md lesen.
2. Zustände und Verhalten zuerst auflisten. Vor dem Code jeden Bildschirm, jeden Zustand und jeden Übergang aufschreiben: Laden, Leer, Fehler, Erfolg, Zurück, den Toast, den Randfall. Jeweils eine Zeile. Die Liste mit der Person bestätigen.
3. Live-HTML bauen. Mit kit/shell.html beginnen. Bildschirme als echtes DOM mit echten Tippzielen neu aufbauen, niemals Screenshots mit Hotspots. references/behavior.md lesen.
4. Selbst durchklicken. Jeden Pfad sowohl auf dem Desktop als auch auf dem Mobilgerät mit einem Headless-Browser ausführen. Jeden Zustand screenshoten. Null Konsolenfehler. Vor dem Teilen beheben.
5. Für Feedback teilen. Einen Link mit Bildunterschriften und Tipphinweisen veröffentlichen (references/sharing.md). Jede Notiz im Format references/feedback-log.md protokollieren: die Notiz, die Regel, die daraus wird.
6. Shot-Liste schreiben. Eine Zeile pro Beat: Zeit | auf dem Bildschirm | Aktion | Einstellung | Story-Punkt. Jeden Beat als Einstellung benennen (Etablierung, Detail, Schnitt auf Aktion, Match Cut, Auszahlung; siehe references/pacing.md, Filmsprache). Eine Idee pro Beat. OK einholen, bevor das Video gebaut wird.
7. Vorschau, dann rendern. Den Prototypen mit angehaltener Uhr fahren und Frames aufnehmen. Zuerst eine niedrig aufgelöste Vorschau senden (15fps, halbe Größe). In voller Qualität nur rendern, nachdem das Timing genehmigt wurde. references/pacing.md und references/motion-tokens.md lesen.
8. QA, dann ausliefern. Jede Prüfung in references/qa.md durchführen und in der Liefernachricht sagen, was geprüft wurde. Eine Korrektur ändert nur das, was beanstandet wurde.

Unverhandelbar

• Live-DOM, keine Bilder mit Hotspots. Bilder nur für Fotos, Logos und Medien.
• Text verwendet die Design-Tokens (Schriftfamilie, Größe, Zeilenhöhe, Tracking), niemals handgesetzte Werte. Sicherstellen, dass die Schriftarten dort installiert sind, wo gerendert wird.
• Toasts und Overlays liegen über dem Inhalt. Sie schieben die Seite niemals herum.
• Eine Easing-Familie pro Stück. Ease-out für Eingänge, niemals Ease-in auf UI, niemals von 0 skalieren. Kein Bounce auf UI, außer im Auszahlungsmoment (siehe motion-tokens.md, Spiel ist für die Auszahlung).
• Nach dem Landen auf einem neuen Bildschirm halten, bevor sich etwas bewegt: etwa 0,9s für einen leichten Bildschirm, 1,4s standardmäßig, etwa 2,4s für textlastige Bildschirme.
• Den Tipp mit seinem Kontext rahmen: in die Zeile oder Gruppe hineinzoomen, nicht nur auf den Button.
• Filmsprache überschreibt niemals das UI-Verhalten. Jedes Element animiert auf seiner eigenen Ebene.
• Tippmarker nur bei Tipps. Kein Finger beim Scrollen.
• Diashow-Schleifen bleiben bei 20s oder weniger, es sei denn, die Geschichte braucht mehr und die Person stimmt zu. Erklärclips schleifen nur den Moment, den sie lehren.
• Niedrig aufgelöste Vorschau vor jedem vollständigen Render.
• Keine Lieferung ohne die QA-Prüfung.
• Wenn ein Reviewer eine Notiz gibt, in eine Regel umwandeln und aufschreiben.

Dateien

• references/behavior.md: den Prototypen wie das echte Produkt verhalten lassen
• references/fidelity.md: das Quelldesign exakt nachbilden
• references/sharing.md: für Feedback einrichten
• references/pacing.md: Präsentationsgeschwindigkeit für Walkthrough-Videos
• references/motion-tokens.md: Easing, Dauern und Bewegungsmuster
• references/qa.md: die Prüfungen, die jede Lieferung besteht
• references/feedback-log.md: wie Notizen zu Regeln werden, mit echten Beispielen
• kit/shell.html: neutrale Prototyp-Hülle (Werkzeugleiste, Desktop/Mobil, Geräterahmen, Bildunterschriften, Tipphinweise)
• kit/proto.css, kit/proto.js: Übergänge, Sheets, Toasts, Skeletons, Cursor