Launch-Video für ein Softwareprodukt
Erstelle ein 30–60 Sekunden langes Video, das jemanden das Produkt verstehen und haben will.
Die Entscheidung, die alles bestimmt: Neu aufbauen, nicht aufnehmen
Screen-Recordings kämpfen gegen dich. Echte Latenz ist tote Luft. Wiederholungen sind teuer. Du kannst keinen Frame halten, du kannst einen Beat nicht verlangsamen und einen anderen beschleunigen, und
du kannst nicht eng zuschneiden, ohne Matsch durch Kompression zu bekommen.
Also baue die UI als frame-basiertes React in Remotion nach. Jedes visuelle Element ist eine
reine Funktion von useCurrentFrame(). Tippen landet auf einer exakten Kurve, ein
Ladezustand löst sich auf den Beat auf, und eine Wiederholung kostet eine Zahl.
Dies ist nur sinnvoll, weil du den tatsächlichen Code des Produkts (wenn lokal) oder das DOM+CSS (wenn gehostet) lesen und originalgetreu reproduzieren kannst. Tu das — nimm die echten Klassennamen, die echten Farben, den echten Text. Der Nachbau sollte von einer Aufnahme nicht zu unterscheiden sein, dann besser.
Wann stattdessen aufnehmen: Starkes 3D, Videoinhalte im Produkt, eine
Canvas/WebGL-Oberfläche oder eine native Desktop-App. Wenn eine bestimmte Oberfläche nicht nachgebaut
werden kann, nimm nur diese Oberfläche auf und setze sie mit <OffthreadVideo> zusammen.
Phase 1 — Das Produkt verstehen
Lese references/discovery.md vor dieser Phase. Es behandelt die
Browse-und-Triage-Prozedur, das Gespräch über Anmeldeinformationen und wie man ein
Designsystem aus einer Live-Website 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: Lese den Code. Viel reichhaltiger — du bekommst die echten Komponenten, die echten Theme-Tokens, die echten Seed-Daten.
- Triage der Seiten. Die meisten Produkte haben 20 Bildschirme und 3, die wichtig sind. Auth, Einstellungen, Abrechnung, Datenschutz, Konto, Onboarding-Boilerplate — das sind fast nie die Geschichte. Finde den Bildschirm, auf dem das Produkt das tut, was nur es tun kann.
- Wenn das Gute hinter einem Login steckt, frage zuerst — Test-Anmeldedaten oder ein gesäten
Account in ihrem lokalen Dev. Wenn keins verfügbar ist, gib nicht auf und erfinde keine Sitzung,
die du nie gesehen hast: wechsle zur Kapitel-Form und baue aus den eigenen Feature-Karten der
Landing-Page, Text und Komponenten.
discovery.mdhat die Ernteprozedur und die Ehrlichkeitsregeln.
Dann bestätige dein Verständnis mit dem Benutzer, bevor du baust — ein falsches Verständnis des Produkts kostet einen gesamten Bau. Zeige ihnen: was du glaubst, was das Produkt tut, die 2–4 Bildschirme, die du zeigen willst, das Helden-Szenario, die Einstellungsliste und die Musikfrage (siehe Phase 4). Ein Checkpoint, dann los.
Phase 2 — Das Format wählen
Lese references/structure.md. Zwei Formate funktionieren; die falsche Wahl kostet den Bau.
Format A — die einzelne Erzählung. Der Standard. Ein Benutzer, eine Aufgabe, ein Artefakt. Keine Feature-Tour.
| Beat | Aufgabe |
|---|---|
| Aufhänger (0–5s) | Formuliere das Problem in den eigenen Worten des Betrachters. Noch keine UI. |
| Frage (5–12s) | Der Benutzer fragt nach dem Ding. Nah am Eingabefeld. |
| Arbeit (12–25s) | Das Produkt tut sichtbar etwas Schwieriges. Zeige die Belege. |
| Artefakt (25–35s) | Die Ausgabe, vollständig, in lesbarer Größe. |
| Kontrolle (35–45s) | Der Benutzer ändert es und bleibt am Drücker. |
| Schluss (45–50s) | Logo, eine Zeile, domain. |
Die Arbeit- und Kontrolle-Beats unterscheiden eine echte Demo von einem Mockup. „Es hat mich gefragt, anstatt 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, das eine Person nicht einfach selbst tun könnte, und mache die Ausgabe konkret und sichtbar — ein generiertes Dokument, ein erstelltes Diagramm, ein behobener Bug, eine bereitgestellte Website. Konkrete Artefakte sind das, woran sich Leute erinnern.
Format B — der kapitelbasierte Feature-Film. Drei Features, jedes durch eine klarsprachliche Labelkarte eingeleitet, dann gezeigt.
Aufhänger → [01 Label → Feature] → [02 Label → Feature] → [03 Label → Feature] → Schluss
Verwende es, wenn das Produkt gated ist und du von seiner Landing-Page aus arbeitest, odern wenn die Features wirklich keine gemeinsame User-Reise teilen, oder wenn du drei eigenständige Clips aus einem Bau haben willst. Drei ist die Zahl — vier bedeutet, dass keines ankommt.
Keine Sequenz kapiteln. Wenn die Fähigkeiten nacheinander in einer einzigen Sitzung passieren (Recherche → Entwurf → Bearbeitung), ist das ein Workflow, und das Etikettieren als drei Features kämpft gegen das Material. Wenn jemand Kapitel für ein sequentielles Produkt möchte, biete den Mittelweg an: behalte die einzelne Erzählung und setze die Labels über die Aktion, wenn jede Fähigkeit erscheint. Gleiche Lesbarkeit, gleiche Clip-Grenzen, keine Laufzeitkosten, Geschichte intakt.
structure.md behandelt Kapitel-Karten-Design, wie man die Labels schreibt (benenne das
Ergebnis, nicht den Mechanismus; kaue die eigenen Wörter des Produkts), Übergänge und
Reihenfolge.
Phase 3 — Alles fundieren
In welcher Domäne das Produkt auch ist, erfinde keine Inhalte. Wenn es ein rechtliches Produkt ist, muss das Gesetz echt sein. Wenn es Analytics ist, müssen die Zahlen plausibel und in sich konsistent sein. Wenn es ein Code-Tool ist, muss der Code im Kopf des Lesers kompilieren.
Ziehe die echten Dinge aus dem Repo, der API, den Seed-Daten oder den Docs. Domänenexperten sehen sich diese Videos an, und ein erfundener Detail kostet dir alle. Parteinamen, Daten und Dollarbeträge sind in Ordnung zu erfinden — diese sind kundenspezifisch, keine Behauptungen über die Welt.
Führe einen Herkunftshinweis in der Datendatei, der sagt, wo jede Tatsache herkommt. Das zukünftige Du wird es wollen.
Phase 4 — Bauen
Führe das Scaffold aus, das die tatsächlich zusammenarbeitenden Versionen festlegt 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 Repo des Produkts hinzu, es sei denn, du wirst darum gebeten), kopiert useCamera.ts
herein und hinterlässt dir ein Timeline-Modul zum Ausfüllen.
Dann, in dieser Reihenfolge:
-
src/timeline.ts— Frame-Mathematik und Einstellungsgrenzen. Wähle einen BPM, bei dem der Beat eine ganze Anzahl von Frames ist (bei 60fps: 120 BPM = 30 Frames, 90 BPM = 40). Lege jede Einstellungsgrenze auf einen Beat. Auch ohne Musik gibt dies dem Schnitt einen inneren Rhythmus, und es bedeutet, dass später ein Musikbett hinzugefügt werden kann, ohne neu zu schneiden. -
src/data/script.<lang>.ts— Jeder String, jede Zahl, jedes Stück Dokumenteninhalt, in einer Datei mit Herkunftskommentaren. Nichts fest in Komponenten kodiert. Nachsynchronisierung und Übersetzung werden trivial. -
Komponenten — erstelle die UI des Produkts nach. Kopiere echte Klassennamen. Wenn das Produkt Tailwind verwendet, nimm seine Konfiguration und Theme-CSS auf; wenn es CSS-Variablen für Farben verwendet, musst du diese übernehmen, sonst wird alles farblos dargestellt.
-
src/scenes/ProductScene.tsx— ein exportiertesB-Objekt, das jeden Beat als absolute Framenummer hält. Alles liest daraus: das DOM, die Kamera, der Ton. Nachsynchronisierung bedeutet, diesen Block zu bearbeiten und sonst nichts.
Lese references/camera.md für das Einstellungssystem, references/motion.md für
Dauern und Typografie.
Phase 5 — Audio
Zwei Spuren, zwei Dateien, zwei <Audio>-Tags: Effekte und Musik. Halte sie
getrennt, so dass jeder ersetzt werden kann, ohne den anderen neu zu generieren.
Effekte — references/sound.md. Zurückhaltung ist die gesamte Disziplin: Ein
45-Sekunden-Video benötigt normalerweise drei bis fünf Ereignisse insgesamt. Ein Pop bedeutet, dass ein Ding erschienen ist,
ein Swish bedeutet, dass ein Element innerhalb der Einstellung bewegt wurde, ein Whoosh bedeutet, dass
die Einstellung selbst bewegt wurde.
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 könnte die gesamte
Mühe retten:
Möchtest du ein Musikbett? Wenn du einen Track hast, sende ihn und ich schneide darauf zu. Wenn nicht, kann ich einen synthetisieren — energiegeladen, ruhig, cineastisch, minimalistisch, warm, oder angespannt?
Wenn sie einen Track haben, schneide darauf zu: Finde seinen BPM, stelle die Timeline so ein, dass sie passt, verschiebe die Einstellungsgrenzen auf seine Takte. Andernfalls synthetisiere ein Bett, dessen Arrangementwechsel auf deinen Schnitte auf den Frame fallen:
python3 <skill-dir>/scripts/make_music.py music.spec.json public/music.wav
Setze einen sections-Eintrag auf jede reale Einstellungsgrenze, einen hits-Eintrag auf deinen
größten Schnitt und einen ducks-Eintrag unter jede gehaltene Zeile, die gelesen statt gefühlt werden
soll. Musik bei Peak ~0,30, Effekte bei ~0,62. Wähle die Stimmung aus dem, was das Produkt ist —
ernste Themen erfordern ein ruhigeres Bett, und ein geschäftiger Schnitt benötigt ein spärlicheres.
Phase 6 — Mit Standbildern überprüfen, bevor du renderst
Dies ist die enge Schleife, und sie zu überspringen verschwendet Stunden.
npx remotion still <CompositionId> out/f0700.png --frame=700
Dann schaue dir das PNG tatsächlich an. Rendere ein Standbild pro Einstellung, plus eines an jedem Übergang. Überprüfe: Ist das Motiv im Frame, ist irgendetwas 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 vorhanden sein müssen.
Stimme numerisch ab, wo immer du kannst. Easingkurven, Scroll-Distanzen, spektraler Inhalt — dies sind alle berechenbar. Schreibe ein wegwerfbares Python-Skript, das die Kurve abtastet und das ausgibt, was du sonst erraten würdest. Es ist schneller als ein Render und es ist richtig.
Rendere das Ganze erst, wenn die Standbilder richtig sind.
npx remotion render <CompositionId> out/video.mp4 --concurrency=4
Begrenze die Gleichzeitigkeit auf etwa 4 auf einer 16-GB-Maschine — Remotion startet einen Chrome-Tab pro Slot und der Standardwert (Kernanzahl) wird auslagern.
Phase 7 — Übergib es ehrlich
Sende die Datei. Sage dann klar:
- Was du nicht verifizieren konntest. Du kannst Standbilder lesen; du kannst nicht beurteilen, wie acht Sekunden sich anfühlen, und du kannst das Audio nicht hören. Sage es.
- Jeden Bildschirm, den du rekonstruiert hast, anstatt ihn beobachtet zu haben — besonders bei einem gated Produkt. Liste sie auf und biete an, diese Beats zu wiederholen, wenn sie dir Zugriff geben.
- Wo du eine Entscheidung getroffen hast, mit der sie möglicherweise nicht einverstanden sind.
- Wie man die Musik austauscht: Lege eine beliebige WAV- oder MP3-Datei in
public/music.wavund rendere erneut. - Alles, was du während des Bauens in ihrem Produkt gefunden hast — ein Rendering-Bug, ein falsches Label, einen fehlenden Zustand. Du hast gerade ihre UI sorgfältiger gelesen als die meisten Leute jemals werden. Diese Beobachtung ist oft mehr wert als das Video.
Referenzdateien
Lese diese, wenn du die entsprechende Phase erreichst — sie sind detailliert und es hat keinen Wert, sie alle auf einmal zu laden.
| Datei | Wann |
|---|---|
references/discovery.md | Phase 1 — Durchsuchen, Seiten-Triage, Anmeldeinformationen, Designsysteme, und Bauen von der Landing-Page eines gated Produkts |
references/structure.md | Phase 2 — Einzelnarrativ vs Kapitel, Kapitel-Karten-Design, Schreiben von Feature-Labels, Übergänge, Reihenfolge |
references/camera.md | Einstellungen bauen — Layout-Raum, Fokuspunkt-Kamera, Schnitt vs Push vs Morph, Isolieren von Komponenten |
references/motion.md | Animationsdauern, Typografie, Aufhängermuster, die Frage-Spule |
references/sound.md | Sound-Design — das Pop/Swish/Whoosh-Vokabular, Zurückhaltung, Synthese von Tastatur und Klicks |
references/music.md | Beschaffung vs Synthese eines Betts, Wahl einer Stimmung, Ausrichtung von Abschnitten an Schnitten, Mischen unter den Effekten |
references/pitfalls.md | Lies dies vor deinem ersten Render. Bugs, die echte Stunden kosten, jeweils mit Lösung. |
Mitgelieferte Skripte
<skill-dir> unten ist das eigene Verzeichnis dieses Skills — der Pfad, der dir gegeben wurde, als
der Skill geladen wurde. Geh nicht von einem festen Installationsort aus; der Skill kann persönlich
installiert sein, als Plugin oder in ein Projekt ausgecheckt worden sein.
| Skript | Was |
|---|---|
scripts/scaffold_video.py | Erstellt das Remotion-Projekt mit funktionierenden Versions-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 ein Musikbett in einer von sechs Stimmungen, mit Arrangement ausgerichtet an deinem Schnitt. Gleiche Abhängigkeiten. |
assets/useCamera.ts | Der Fokuspunkt-Kamera-Hook — in src/hooks/ kopieren |
assets/ChapterCard.tsx | Kapitelkarte für das Kapitel-Format — in src/components/ kopieren |
Die Kurzfassung
Baue nach, anstatt aufzunehmen. Eine Geschichte, ein Artefakt — es sei denn, das Produkt ist gated oder seine Features sind wirklich getrennt, dann drei Kapitel mit klaren Labels. Fundiere jede Domänenfakten. Frames sind die Einheit von allem. Isoliere eine Komponente, anstatt die Seite zuzuschneiden. UI-Bewegung ist 150–300ms, Kamerabewegungen sind ~1s. Vier Geräusche sind genug. Frage, bevor du Musik machst. Schau dir die Standbilder an, bevor du renderst. Sage, was du nicht überprüfen konntest und was du abgeleitet hast.