Launch-Video für ein Softwareprodukt
Produzieren Sie ein 30–60 Sekunden langes Video, das das Produkt verständlich und begehrenswert macht.
Die alles entscheidende Entscheidung: Nachbauen, nicht aufzeichnen
Bildschirmaufzeichnungen kämpfen gegen einen. Echte Latenz ist tote Luft. Nachdrehs sind teuer. Man kann keinen Frame halten, nicht einen Schlag verlangsamen und einen anderen beschleunigen, und man kann nicht eng zuschneiden, ohne in Kompressionsmatsch zu landen.
Also bauen Sie die Benutzeroberfläche als frame-getriebenes React in Remotion nach. Jedes visuelle Element ist eine
reine Funktion von useCurrentFrame(). Tippen landet auf einer exakten Kurve, ein
Ladezustend auf dem Beat, und ein Nachdreh kostet eine Zahl.
Dies ist nur sinnvoll, weil Sie den tatsächlichen Code des Produkts lesen können (lokal) oder DOM+CSS (gehostet) – und ihn originalgetreu reproduzieren. Tun Sie das – nehmen Sie die echten Klassennamen, die echten Farben, den echten Text. Der Nachbau sollte sich von einer Aufzeichnung nicht unterscheiden lassen und dann besser sein.
Wann man doch aufzeichnen sollte: schwere 3D-Grafiken, Videoinhalte im Produkt,
eine Canvas/WebGL-Oberfläche oder eine native Desktop-App. Wenn eine bestimmte Oberfläche nicht nachgebaut
werden kann, zeichnen Sie nur diese Oberfläche auf und fügen sie mit <OffthreadVideo> ein.
Phase 1 – Das Produkt verstehen
Lesen Sie references/discovery.md, bevor Sie diese Phase beginnen. Es behandelt die
Browse-and-Triage-Prozedur, das Gespräch über Zugangsdaten und die Extraktion eines
Designsystems von einer Live-Seite.
Kurzfassung:
- Bei einer URL: Durchsuchen Sie sie. Zuerst die Landingpage (sie zeigt, wie das Produkt sich positioniert), dann die App selbst. Finden Sie heraus, welche Aufgabe das Produkt für wen erledigt.
- Bei einem lokalen Repo/Dev-Server: Lesen Sie den Code. Viel reichhaltiger – Sie erhalten 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. Authentifizierung, Einstellungen, Abrechnung, Datenschutz, Konto, Onboarding-Boilerplate – diese sind fast nie die Geschichte. Finden Sie den Bildschirm, auf dem das Produkt das tut, was nur es kann.
- Wenn die guten Inhalte hinter einem Login sind, fragen Sie zuerst – Test-Zugangsdaten oder ein eingerichtetes Konto in deren lokaler Entwicklung. Wenn beides nicht verfügbar ist, geben Sie nicht auf und erfinden Sie keine Sitzung, die Sie nie gesehen haben: Wechseln Sie zur Kapitelform und bauen Sie von den eigenen Feature-Karten der Landingpage, deren Text und Komponenten.
discovery.mdenthält das Ernteverfahren und die Ehrlichkeitsregeln.
Bestätigen Sie dann Ihr Verständnis beim Benutzer, bevor Sie bauen – ein falsches Verständnis des Produkts kostet einen gesamten Build. Zeigen Sie ihm: Was Sie denken, was das Produkt tut, die 2–4 Bildschirme, die Sie zeigen wollen, das Helden-Szenario, die Aufnahmeliste und die Musikfrage (siehe Phase 4). Ein Checkpoint, dann los.
Phase 2 – Die Form wählen
Lesen Sie references/structure.md. Zwei Formen funktionieren; die falsche Wahl kostet den Build.
Form A – Die einzelne Erzählung. Der Standard. Ein Benutzer erledigt eine Aufgabe und erhält ein Ergebnis. Keine Feature-Tour.
| Schlag | Aufgabe |
|---|---|
| Hook (0–5s) | Nennen Sie das Problem in den eigenen Worten des Betrachters. Noch kein UI. |
| Frage (5–12s) | Der Benutzer fragt nach dem Ding. Nah an der Eingabe. |
| Arbeit (12–25s) | Das Produkt tut sichtbar etwas Schwieriges. Zeigen Sie die Belege. |
| Ergebnis (25–35s) | Die Ausgabe, vollständig, in lesbarer Größe. |
| Kontrolle (35–45s) | Der Benutzer ändert sie und bleibt am Steuer. |
| Slate (45–50s) | Logo, eine Zeile, Domain. |
Die Schläge Arbeit und Kontrolle unterscheiden eine echte Demo von einem Mockup. „Es hat mich gefragt, statt zu raten“ und „Ich konnte bearbeiten, was es erstellt hat“ sind Vertrauensargumente, und Vertrauen ist das, was ein Launch-Video eigentlich verkauft.
Wählen Sie den Moment, in dem das Produkt etwas tut, das ein Mensch nicht leicht selbst tun könnte, und machen Sie die Ausgabe konkret und sichtbar – ein generiertes Dokument, ein erstelltes Diagramm, ein behobener Fehler, eine bereitgestellte Website. Konkrete Ergebnisse sind das, woran sich Menschen erinnern.
Form B – Der kapitele Feature-Film. Drei Funktionen, jede eingeführt durch eine einfachsprachliche Beschriftungskarte, dann gezeigt.
hook → [01 Label → Feature] → [02 Label → Feature] → [03 Label → Feature] → slate
Verwenden Sie sie, wenn das Produkt zugangsgeschützt ist und Sie von der Landingpage aus arbeiten, oder wenn die Funktionen wirklich keine gemeinsame Benutzerreise teilen, oder wenn Sie drei eigenständige Clips aus einem Build haben möchten. Drei ist die Zahl – vier bedeutet, dass keine von ihnen ankommt.
Kapitulieren Sie keine Sequenz. Wenn die Fähigkeiten nacheinander in einer einzigen Sitzung ablaufen (Recherche → Entwurf → Bearbeitung), dann ist das ein Workflow, und ihn als drei Funktionen zu beschriften, kämpft gegen das Material. Wenn jemand Kapitel für ein sequenzielles Produkt verlangt, bieten Sie den Mittelweg an: Behalten Sie die einzelne Erzählung und setzen Sie die Labels über die Aktion, sobald jede Fähigkeit erscheint. Gleiche Lesbarkeit, gleiche Clip-Grenzen, keine Laufzeitkosten, intakte Geschichte.
structure.md behandelt Kapitelkarten-Design, wie man die Labels schreibt (das Ergebnis benennen, nicht den Mechanismus; die eigenen Worte des Produkts stehlen), Übergänge und Reihenfolge.
Phase 3 – Alles fundieren
Egal in welcher Domain das Produkt ist, erfinden Sie keine Inhalte. Wenn es ein juristisches Produkt ist, muss das Gesetz echt sein. Wenn es Analysen sind, müssen die Zahlen plausibel und intern konsistent sein. Wenn es ein Code-Tool ist, muss der Code im Kopf des Lesers kompilieren.
Holen Sie die echten Dinge aus dem Repo, der API, den Seed-Daten oder der Dokumentation. Domain-Experten sehen diese Videos und ein einziges erfundenes Detail kostet Sie alle. Parteinamen, Daten und Geldbeträge dürfen erfunden sein – diese sind kundenspezifisch, keine Behauptungen über die Welt.
Führen Sie im Datenfile eine Provenienznotiz, die sagt, woher jede Tatsache stammt. Das zukünftige Ich wird es wollen.
Phase 4 – Bauen
Führen Sie das Gerüst aus, das die tatsächlich zusammenarbeitenden Versionen fixiert und die Konfiguration schreibt:
python3 <skill-dir>/scripts/scaffold_video.py <target-dir> \
--name "productlaunch" --fps 60 --seconds 45
Es erstellt ein eigenständiges Remotion-Projekt (eigenes Git-Repo – fügen Sie niemals Video-Tooling zum Produkt-Repo hinzu, es sei denn, es wird darum gebeten), kopiert useCamera.ts und hinterlässt ein Zeitachsenmodul zum Ausfüllen.
Dann, der Reihe nach:
-
src/timeline.ts– Frame-Mathematik und Aufnahmegrenzen. Wählen Sie einen BPM, dessen Beat eine ganze Anzahl von Frames ergibt (bei 60fps: 120 BPM = 30 Frames, 90 BPM = 40). Setzen Sie jede Aufnahmegrenze auf einen Beat. Selbst 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 Dokumentinhalt, in einer Datei mit Provenienzkommentaren. Nichts in Komponenten hartcodiert. Nachzeitnahme und Übersetzung werden beide trivial. -
Komponenten – Bauen Sie die Benutzeroberfläche des Produkts nach. Kopieren Sie echte Klassennamen. Wenn das Produkt Tailwind verwendet, bringen Sie dessen Konfiguration und Theme-CSS mit; wenn es CSS-Variablen für Farben verwendet, müssen Sie diese übernehmen, sonst rendert alles farblos.
-
src/scenes/ProductScene.tsx– Ein exportiertesB-Objekt, das jeden Schlag als absolute Framenummer hält. Alles liest daraus: das DOM, die Kamera, der Ton. Nachzeitnahme bedeutet, diesen Block zu bearbeiten und sonst nichts.
Lesen Sie references/camera.md für das Aufnahmesystem, references/motion.md für Dauern und Typografie.
Phase 5 – Audio
Zwei Spuren, zwei Dateien, zwei <Audio>-Tags: Effekte und Musik. Halten Sie sie getrennt, damit jede ersetzt werden kann, ohne die andere neu zu generieren.
Effekte – references/sound.md. Zurückhaltung ist die ganze Disziplin: Ein 45-Sekunden-Video benötigt normalerweise insgesamt drei bis fünf Ereignisse. Ein Pop bedeutet, dass etwas erschienen ist, ein Swish bedeutet, dass ein Element sich innerhalb der Aufnahme bewegt hat, ein Whoosh bedeutet, dass die Aufnahme sich bewegt hat.
python3 <skill-dir>/scripts/make_sfx.py sfx.spec.json public/sfx.wav
Musik – references/music.md. Fragen Sie, bevor Sie eine bauen. Die meisten Leute haben eine Meinung und viele haben bereits einen Track; das Fragen kostet einen Satz und kann die gesamte Mühe ersparen:
Möchten Sie ein Musikbett? Wenn Sie einen Track haben, senden Sie ihn, und ich schneide darauf. Wenn nicht, kann ich einen synthetisieren – energiegeladen, ruhig, cineastisch, minimalistisch, warm oder angespannt?
Wenn sie einen Track haben, schneiden Sie darauf: Finden Sie seinen BPM, setzen Sie die Zeitachse darauf, verschieben Sie die Aufnahmegrenzen auf seine Takte. Andernfalls synthetisieren Sie ein Bett, dessen Arrangement-Änderungen auf Ihre Schnitte im Frame landen:
python3 <skill-dir>/scripts/make_music.py music.spec.json public/music.wav
Setzen Sie einen sections-Eintrag auf jede echte Aufnahmegrenze, einen hits-Eintrag auf Ihren größten Schnitt und einen ducks-Eintrag unter jede gehaltene Zeile, die Sie gelesen statt gefühlt haben möchten. Musik bei etwa ~0.30, Effekte bei ~0.62. Wählen Sie die Stimmung danach, was das Produkt ist – ernste Themen brauchen ein ruhigeres Bett, und ein hektischer Schnitt braucht ein spärlicheres.
Phase 6 – Mit Einzelbildern prüfen, bevor Sie rendern
Dies ist die enge Schleife, und sie zu überspringen kostet Stunden.
npx remotion still <CompositionId> out/f0700.png --frame=700
Dann schauen Sie sich das PNG tatsächlich an. Rendern Sie ein Einzelbild pro Aufnahme plus eins an jedem Übergang. Prüfen Sie: Ist das Motiv im Bild, ist etwas mitten im Wort abgeschnitten, gibt es toten Raum, passt der Text.
Fügen Sie eine stille Komposition hinzu (defaultProps: { withAudio: false }), damit Einzelbilder die Audiodatei nicht benötigen.
Stimmen Sie numerisch ab, wo immer möglich. Easing-Kurven, Scroll-Distanzen, spektrale Inhalte – all dies ist berechenbar. Schreiben Sie ein Wegwerf-Python-Script, das die Kurve abtastet und ausgibt, was Sie sonst erraten würden. Es ist schneller als ein Render und es ist richtig.
Rendern Sie das vollständige Video erst, wenn die Einzelbilder richtig sind.
npx remotion render <CompositionId> out/video.mp4 --concurrency=4
Begrenzen Sie die Parallelität auf etwa 4 bei einer 16-GB-Maschine – Remotion öffnet einen Chrome-Tab pro Slot und die Voreinstellung (Kernanzahl) wird swappen.
Phase 7 – Ehrlich übergeben
Senden Sie die Datei. Sagen Sie dann klar:
- Was Sie nicht überprüfen konnten. Sie können Einzelbilder lesen; Sie können nicht beurteilen, wie sich acht Sekunden anfühlen, und Sie können das Audio nicht hören. Sagen Sie das.
- Jeden Bildschirm, den Sie rekonstruiert statt beobachtet haben – besonders bei einem zugangsgeschützten Produkt. Listen Sie sie auf und bieten Sie an, diese Schläge nachzuholen, wenn sie Zugang gewähren.
- Wo Sie eine Entscheidung getroffen haben, mit der sie möglicherweise nicht einverstanden sind.
- Wie man die Musik austauscht: Legen Sie eine beliebige WAV- oder MP3-Datei unter
public/music.wavund rendern Sie erneut. - Alles, was Sie beim Bauen in ihrem Produkt gefunden haben – einen Darstellungsfehler, ein falsches Label, einen fehlenden Zustand. Sie haben deren Benutzeroberfläche sorgfältiger gelesen als die meisten Menschen je werden. Diese Beobachtung ist oft mehr wert als das Video.
Referenzdateien
Lesen Sie diese, wenn Sie die entsprechende Phase erreichen – sie sind detailliert, und es hat keinen Wert, sie alle auf einmal zu laden.
| Datei | Wann |
|---|---|
references/discovery.md | Phase 1 – Browsen, Seiten-Triage, Zugangsdaten, Designsysteme, und Bauen von der Landingpage eines zugangsgeschützten Produkts |
references/structure.md | Phase 2 – Einzelne Erzählung vs. Kapitel, Kapitelkarten-Design, Feature-Labels schreiben, Übergänge, Reihenfolge |
references/camera.md | Aufnahmen bauen – Layout-Raum, Fokuspunkt-Kamera, Cut vs. Push vs. Morph, Komponenten isolieren |
references/motion.md | Animationsdauern, Typografie, Hook-Muster, die Frage-Reel |
references/sound.md | Sound-Design – das Pop/Swish/Whoosh-Vokabular, Zurückhaltung, Tastatur und Klicks synthetisieren |
references/music.md | Quellen vs. Synthetisieren eines Betts, Stimmung wählen, Abschnitte an Schnitte ausrichten, Mischung unter den Effekten |
references/pitfalls.md | Lesen Sie dies vor Ihrem ersten Render. Fehler, die echte Stunden kosten, jeweils mit der Lösung. |
Gebündelte Skripte
<skill-dir> unten ist das eigene Verzeichnis dieses Skills – der Pfad, der Ihnen gegeben wurde, als der Skill geladen wurde. Nehmen Sie keinen festen Installationsort an; der Skill kann persönlich installiert, als Plugin oder in ein Projekt ausgecheckt 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 passend zu Ihrem Schnitt. Gleiche Abhängigkeiten. |
assets/useCamera.ts | Der Fokuspunkt-Kamera-Hook – kopieren Sie ihn in src/hooks/ |
assets/ChapterCard.tsx | Kapitelkarte für die Kapitelform – kopieren Sie sie in src/components/ |
Die Kurzversion
Nachbauen statt aufzeichnen. Eine Geschichte, ein Artefakt – es sei denn, das Produkt ist zugangsgeschützt oder seine Funktionen sind wirklich getrennt, dann drei Kapitel mit einfachen Labels. Fundieren Sie jede Domänentatsache. Frames sind die Einheit von allem. Isolieren Sie eine Komponente, anstatt die Seite zu beschneiden. UI-Bewegungen sind 150–300ms, Kamerafahrten etwa 1s. Vier Sounds sind genug. Fragen Sie, bevor Sie Musik machen. Schauen Sie sich die Einzelbilder an, bevor Sie rendern. Sagen Sie, was Sie nicht überprüfen konnten und was Sie gefolgert haben.