Launch-Video für ein Softwareprodukt
Erstelle ein 30–60-Sekunden-Video, das jemanden das Produkt verstehen und haben möchte.
Die Entscheidung, die alles bestimmt: Nachbauen, nicht aufzeichnen
Bildschirmaufnahmen kämpfen gegen dich. Echte Latenz ist tote Luft. Wiederholungen sind teuer. Du kannst kein Bild halten, keinen Schlag verlangsamen und einen anderen beschleunigen, und du kannst nicht eng zuschneiden, ohne in Kompressionsmatschen zu landen.
Baue die UI also als frame-gesteuertes React innerhalb von Remotion nach. Jedes visuelle Element ist eine
reine Funktion von useCurrentFrame(). Die Eingabe landet auf einer exakten Kurve, ein
Ladezustand löst sich auf dem Beat auf, und eine Wiederholung kostet eine Zahl.
Das ist nur sinnvoll, weil du den eigentlichen Code des Produkts lesen kannst (wenn lokal) oder das DOM+CSS (wenn gehostet) und es getreu reproduzieren kannst. Mach das – nimm die echten Klassennamen, die echten Farben, den echten Text. Der Nachbau sollte von einer Aufnahme nicht zu unterscheiden sein, dann besser.
Wann besser aufzeichnen: schweres 3D, Videoinhalte innerhalb des Produkts, eine
Canvas/WebGL-Oberfläche oder eine native Desktop-App. Wenn eine bestimmte Oberfläche nicht nachgebaut werden kann, zeichne nur diese auf und erstelle die Compositing mit <OffthreadVideo>.
Phase 1 – Das Produkt verstehen
Lese references/discovery.md vor Beginn dieser Phase. Es behandelt die
Durchsuchungs- und Triage-Prozedur, das Gespräch über Zugangsdaten und wie man ein
Designsystem von einer Live-Site extrahiert.
Kurzfassung:
- Bei einer URL: durchsuche sie. Zuerst die Landing Page (sie sagt dir, wie sie sich positionieren), dann die App selbst. Finde heraus, welche Aufgabe das Produkt für wen erfüllt.
- Bei einem lokalen Repo/Dev-Server: lies den Code. Viel reichhaltiger – du bekommst die echten Komponenten, die echten Theme-Token, die echten Seed-Daten.
- Triage der Seiten. Die meisten Produkte haben 20 Bildschirme und 3, die zählen. Auth, Einstellungen, Abrechnung, Datenschutz, Konto, Onboarding-Boilerplate – diese sind fast nie die Geschichte. Finde den Bildschirm, auf dem das Produkt das tut, was nur es kann.
- Wenn die guten Inhalte hinter einem Login liegen, frage zuerst – Testzugangsdaten oder ein
gesätes Konto im lokalen Dev. Wenn keines verfügbar ist, gib nicht auf und
erfinde keine Sitzung, die du nie gesehen hast: Wechsle zur kapitelbasierten Form und
baue aus den eigenen Feature-Karten, Texten und Komponenten der Landing Page.
discovery.mdenthält die Ernteprozedur und die Ehrlichkeitsregeln.
Bestätige dann deine Einschätzung mit dem Benutzer, bevor du baust – eine falsche Einschätzung des Produkts kostet einen gesamten Build. Zeige ihnen: Was du denkst, was das Produkt tut, die 2–4 Bildschirme, die du zeigen möchtest, das Helden-Szenario, die Shot-Liste und die Musikfrage (siehe Phase 4). Ein Checkpoint, dann los.
Phase 2 – Die Form wählen
Lese references/structure.md. Zwei Formen funktionieren; die falsche Wahl kostet den
Build.
Form A – die einzelne Erzählung. Der Standard. Ein Benutzer, eine Aufgabe, ein Artefakt. Keine Feature-Tour.
| Beat | Aufgabe |
|---|---|
| Hook (0–5s) | Das Problem in den eigenen Worten des Zuschauers nennen. Noch kein UI. |
| Ask (5–12s) | Der Benutzer verlangt nach der Sache. Nah am Eingabefeld. |
| Work (12–25s) | Das Produkt tut sichtbar etwas Schwieriges. Zeig die Bestätigung. |
| Artefakt (25–35s) | Das Ergebnis, in voller Größe, lesbar. |
| Control (35–45s) | Der Benutzer ändert etwas und bleibt an der Macht. |
| Slate (45–50s) | Logo, eine Zeile, Domain. |
Die Work- und Control-Beats unterscheiden eine echte Demo von einem Mockup. „Es hat mich gefragt, statt zu raten“ und „Ich konnte bearbeiten, was es gemacht hat“ sind Vertrauensargumente, und Vertrauen ist das, was ein Launch-Video eigentlich verkauft.
Wähle den Moment, in dem das Produkt etwas tut, was eine Person nicht einfach selbst tun könnte, und mache das Ergebnis konkret und sichtbar – ein generiertes Dokument, ein erstellter Chart, ein behobener Bug, eine deployed Seite. Konkrete Artefakte sind, woran sich die Leute erinnern.
Form B – der kapitelbasierte Feature-Film. Drei Features, jedes eingeleitet durch eine Klartext-Label-Karte, dann gezeigt.
hook → [01 label → feature] → [02 label → feature] → [03 label → feature] → slate
Verwende sie, wenn das Produkt gesperrt ist und du von seiner Landing Page aus arbeitest, oder wenn die Features keinen gemeinsamen Benutzer-Workflow haben, oder wenn du drei eigenständige Clips aus einem Build haben willst. Drei ist die Zahl – vier bedeutet, dass keins von ihnen ankommt.
Kapituliere keinen Ablauf. Wenn die Fähigkeiten nacheinander in einer einzigen Sitzung auftreten (Recherche → Entwurf → Bearbeitung), ist das ein Workflow, und das Labeln mit drei Features kämpft gegen das Material. Wenn jemand Kapitel für ein sequentielles Produkt verlangt, biete stattdessen den Mittelweg an: Behalte die einzelne Erzählung und setze die Labels über die Aktion, während jede Fähigkeit erscheint. Gleiche Lesbarkeit, gleiche Clip-Grenzen, keine Laufzeitkosten, Story intakt.
structure.md behandelt Kapitelkarten-Design, wie die Labels zu schreiben sind (das Ergebnis nennen, nicht den Mechanismus; die eigenen Worte des Produkts stehlen), Übergänge und Reihenfolge.
Phase 3 – Alles fundieren
Unabhängig von der Domäne des Produkts, erfinde seinen Inhalt nicht. Wenn es ein Rechtsprodukt ist, muss der Gesetzestext real sein. Wenn es Analytics ist, müssen die Zahlen plausibel und intern konsistent sein. Wenn es ein Code-Tool ist, muss der Code im Kopf des Lesers kompilieren.
Hole das Reale aus dem Repo, der API, den Seed-Daten oder den Docs. Domänenexperten schauen sich diese Videos an und ein erfundenes Detail kostet dich alle von ihnen. Parteinamen, Daten und Geldbeträge sind in Ordnung zu erfinden – diese sind spezifisch für einen Kunden, keine Behauptungen über die Welt.
Führe eine Herkunftsnotiz in der Datendatei, die sagt, woher jede Tatsache kam. Das zukünftige Du wird sie brauchen.
Phase 4 – Bauen
Führe das Scaffold aus, das die Versionen festlegt, die tatsächlich zusammen funktionieren, und die Konfiguration schreibt:
python3 <skill-dir>/scripts/scaffold_video.py <target-dir> \
--name "product-launch" --fps 60 --seconds 45
Es erstellt ein eigenständiges Remotion-Projekt (ein eigenes Git-Repo – füge niemals Video-Tooling zum Produkt-Repo hinzu, es sei denn, es wird verlangt), kopiert useCamera.ts hinein und hinterlässt dir ein Timeline-Modul zum Ausfüllen.
Dann, in dieser Reihenfolge:
-
src/timeline.ts— Frame-Mathematik und Shot-Grenzen. Wähle einen BPM, dessen Beat eine ganze Anzahl von Frames ist (bei 60fps: 120 BPM = 30 Frames, 90 BPM = 40). Setze jede Shot-Grenze auf einen Beat. Selbst ohne Musik gibt dies dem Schnitt einen inneren Rhythmus, und es bedeutet, dass eine Musikuntermalung später hinzugefügt werden kann, ohne erneut zu schneiden. -
src/data/script.<lang>.ts— jeder String, jede Zahl, jedes Stück Dokumenteninhalt, in einer Datei mit Herkunftskommentaren. Nichts hartcodiert in Komponenten. Zeitanpassungen und Übersetzungen werden beide trivial. -
Komponenten – die UI des Produkts nachbauen. Kopiere echte Klassennamen. Wenn das Produkt Tailwind verwendet, bringe dessen Konfiguration und Theme-CSS mit; wenn es CSS-Variablen für Farbe verwendet, musst du diese mitbringen, sonst wird alles farblos gerendert.
-
src/scenes/ProductScene.tsx– ein exportiertesB-Objekt, das jeden Beat als absolute Frame-Nummer hält. Alles liest daraus: das DOM, die Kamera, der Sound. Zeitanpassung bedeutet, diesen Block zu bearbeiten und sonst nichts.
Lies references/camera.md für das Shot-System, references/motion.md für
Dauern und Typografie.
Phase 5 – Audio
Zwei Spuren, zwei Dateien, zwei <Audio>-Tags: Effekte und Musik. Halte sie getrennt, damit eine ersetzt werden kann, ohne die andere zu regenerieren.
Effekte – references/sound.md. Zurückhaltung ist die ganze Disziplin: ein
45-Sekunden-Video braucht normalerweise insgesamt drei bis fünf Ereignisse. Ein Pop bedeutet, dass etwas erschien, ein Swish bedeutet, dass sich ein Element im Shot bewegte, ein Whoosh bedeutet, dass sich der Shot bewegte.
python3 <skill-dir>/scripts/make_sfx.py sfx.spec.json public/sfx.wav
Musik – references/music.md. Frage, bevor du eine baust. Die meisten Leute
haben eine Meinung und viele haben bereits einen Track; Fragen kostet einen Satz und kann den gesamten Aufwand retten:
Möchtest du eine Musikuntermalung? Wenn du einen Track hast, sende ihn und ich schneide darauf. Wenn nicht, kann ich einen synthetisieren – energiegeladen, ruhig, cineastisch, minimalistisch, warm, oder angespannt?
Wenn sie einen Track haben, schneide darauf: Finde seinen BPM, setze die Timeline entsprechend, verschiebe die Shot-Grenzen auf seine Takte. Andernfalls synthetisiere eine Untermalung, deren Arrangement-Änderungen auf deine Schnitte zum Frame hin landen:
python3 <skill-dir>/scripts/make_music.py music.spec.json public/music.wav
Setze einen sections-Eintrag an jede reale Shot-Grenze, einen hits-Eintrag auf deinen
wichtigsten Schnitt und einen ducks-Eintrag unter jede gehaltene Zeile, die du gelesen statt gefühlt haben möchtest. Musik bei Peak ~0.30, Effekte bei ~0.62. Wähle die Stimmung entsprechend dem, was das Produkt ist – ernste Themen brauchen eine ruhigere Untermalung, und ein geschäftiger Schnitt braucht eine sparsamere.
Phase 6 – Mit Standbildern verifizieren, bevor du renderst
Das ist die enge Schleife, und das Überspringen kostet Stunden.
npx remotion still <CompositionId> out/f0700.png --frame=700
Dann schau dir das PNG tatsächlich an. Renders ein Standbild pro Shot, plus eines an jedem Übergang. Überprüfe: Ist das Motiv im Bild, wird etwas mitten im Wort abgeschnitten, gibt es toten Raum, passt der Text.
Füge eine stille Komposition hinzu (defaultProps: { withAudio: false }), damit Standbilder
nicht die Audiodatei benötigen.
Stimme numerisch ab, wo immer möglich. Easing-Kurven, Scroll-Distanzen, Spektralinhalt – das sind alles berechenbare Werte. Schreibe ein Wegwerf-Python-Skript, das die Kurve sampelt und das ausgibt, was du sonst nur raten könntest. Es ist schneller als ein Render und es ist korrekt.
Rendere das Ganze erst, wenn die Standbilder richtig sind.
npx remotion render <CompositionId> out/video.mp4 --concurrency=4
Begrenze die Parallelität auf etwa 4 auf einem 16GB-Rechner – Remotion startet einen Chrome-Tab pro Slot und der Standardwert (Anzahl der Kerne) wird auslagern.
Phase 7 – Ehrlich übergeben
Sende die Datei. Sage dann deutlich:
- Was du nicht überprüfen konntest. Du kannst Standbilder lesen; du kannst nicht beurteilen, wie sich acht Sekunden anfühlen, und du kannst das Audio nicht hören. Sage das.
- Jeden Bildschirm, den du rekonstruiert statt beobachtet hast – insbesondere bei einem gesperrten Produkt. Liste sie auf und biete an, diese Beats zu wiederholen, wenn sie Zugang teilen.
- Wo du eine Ermessensentscheidung getroffen hast, mit der sie möglicherweise nicht einverstanden sind.
- Wie die Musik getauscht wird: Lege eine beliebige WAV oder MP3 unter
public/music.wavab und rendere erneut. - Alles, was du beim Bauen in ihrem Produkt gefunden hast – einen Rendering-Bug, ein falsches Label, einen fehlenden Zustand. Du hast gerade ihr UI genauer gelesen als die meisten Leute es jemals tun werden. Diese Beobachtung ist oft mehr wert als das Video.
Referenzdateien
Lies diese, wenn du die entsprechende Phase erreichst – sie sind detailliert und es bringt nichts, alle auf einmal zu laden.
| Datei | Wann |
|---|---|
references/discovery.md | Phase 1 – Browsen, Seiten-Triage, Zugangsdaten, Designsysteme, und Bauen von der Landing Page eines gesperrten Produkts |
references/structure.md | Phase 2 – einzelne Erzählung vs. Kapitel, Kapitelkarten-Design, Feature-Labels schreiben, Übergänge, Reihenfolge |
references/camera.md | Shots bauen – Layout-Raum, Fokus-Punkt-Kamera, Cut vs. Push vs. Morph, Komponenten isolieren |
references/motion.md | Animationsdauern, Typografie, Hook-Muster, die Frage-Sequenz |
references/sound.md | Sounddesign – das Pop/Swish/Whoosh-Vokabular, Zurückhaltung, Synthetisieren von Tastatur und Klicks |
references/music.md | Beschaffen vs. Synthetisieren einer Untermalung, Stimmung wählen, Sektionen an Cuts ausrichten, unter den Effekten mischen |
references/pitfalls.md | Lies dies vor deinem ersten Render. Bugs, die echte Stunden kosten, jeweils mit der Lösung. |
Mitgelieferte Skripte
<skill-dir> unten ist das eigene Verzeichnis dieses Skills – der Pfad, der dir gegeben wurde, als
das Skill geladen wurde. Gehe nicht von einem festen Installationsort aus; das Skill kann persönlich
installiert, als Plugin oder in einem Projekt ausgecheckt sein.
| Skript | Was |
|---|---|
scripts/scaffold_video.py | Erstellt das Remotion-Projekt mit funktionierenden Version-Pins und Konfiguration |
scripts/make_sfx.py | Synthetisiert eine Soundeffekt-Spur aus einer JSON-Ereignisliste. Keine Samples, keine Abhängigkeiten außer numpy. |
scripts/make_music.py | Synthetisiert eine Musikuntermalung in einer von sechs Stimmungen, mit Arrangement synchron zu deinen Cuts. Gleiche Abhängigkeiten. |
assets/useCamera.ts | Der Fokus-Punkt-Kamera-Hook – kopieren nach src/hooks/ |
assets/ChapterCard.tsx | Kapitelkarte für die kapitelbasierte Form – kopieren nach src/components/ |
Die Kurzfassung
Nachbauen statt aufzeichnen. Eine Geschichte, ein Artefakt – es sei denn, das Produkt ist gesperrt oder seine Features sind wirklich getrennt, dann drei Kapitel mit einfachen Labels. Fundiere jedes Domänenfakt. Frames sind die Einheit von allem. Isoliere eine Komponente statt die Seite zu beschneiden. UI-Bewegung ist 150–300ms, Kamerafahrten sind ~1s. Vier Sounds sind genug. Frage, bevor du Musik machst. Schaue die Standbilder an, bevor du renderst. Sage, was du nicht überprüfen konntest und was du abgeleitet hast.