QREATA / Anwendungsfälle

So nehmen Sie ein Walkthrough-Video zu einem Software-Release auf

Ein Release-Walkthrough beantwortet drei Fragen für jemanden, der das Produkt bereits nutzt: Was hat sich geändert, habe ich es schon, und was mache ich jetzt anders? Hier finden Sie ein Skript mit Zeitangaben, eine Tabelle dazu, was Sie Nutzern, Support und Vertrieb zeigen, ein Beispiel für eine geänderte Einstellung und die Checkliste, die Sie vor dem Veröffentlichen durchgehen.

Qreata für Mac testen Passt es zu Ihnen? ↓

7 Tage testen · 49 $ einmalig · kein Abo · Apple Silicon · macOS 14+ · App-Oberfläche auf Englisch

Die kurze Antwort

Ein gutes Walkthrough-Video zu einem Release dauert 2 bis 3 Minuten pro Zielgruppe und behandelt der Reihe nach: was sich geändert hat, wer es wann bekommt, den neuen Weg, einmal in normalem Tempo vorgeführt, und was sich nicht geändert hat. Veröffentlichen Sie es neben den schriftlichen Release Notes. Sie bleiben die Quelle für Versionsnummern, Limits und Details zum Rollback.

Nehmen Sie einen Walkthrough auf, wenn …

Das Release ändert, was die Leute anklicken, und sie werden danach fragen.

Ein Ablauf hat sich geändert: Ein Menü ist umgezogen, ein Schritt kam dazu, eine Voreinstellung wurde umgestellt.
Die Nutzer müssen etwas tun: migrieren, neu autorisieren, eine neue Einstellung wählen.
Support und Vertrieb müssen die Funktion sehen, bevor Kunden danach fragen.
Die Änderung lässt sich leichter zeigen als beschreiben, etwa ein neuer Editor oder ein neues Layout.

Bleiben Sie bei Release Notes, wenn …

Es gibt nichts Neues anzuklicken, oder der Bildschirm ändert sich noch einmal, bevor die Leute zuschauen.

Bugfixes, Performance-Arbeit und Sicherheitspatches. Eine Zeile in den Notes genügt.
Reine API-Änderungen. Entwickler wollen ein Changelog mit Codebeispielen.
Eine Funktion hinter einem Flag für eine kleine Gruppe. Bis zum vollständigen Rollout ist das Video veraltet.
Die Oberfläche ändert sich nach dem Freeze noch. Nehmen Sie auf, sobald sie final ist.

Skript für das Release-Video: 2,5 Minuten mit Zeitangaben

Nehmen Sie auf dem Release-Build auf, in einem Konto mit demselben Tarif und derselben Rolle wie der Zuschauer. Legen Sie die Zielgruppe fest, bevor Sie anfangen; das Skript unten ist für Endnutzer.

0:00–0:15 · Was sich geändert hat. „In Version 3.8 können Workspace-Admins festlegen, wie lange gelöschte Dateien aufbewahrt werden. Bisher waren es fest 30 Tage.“
0:15–0:30 · Wer es wann bekommt. „Ab dem 6. Oktober ist es für alle Business-Workspaces aktiv. In anderen Tarifen sehen Sie die Einstellung nicht.“
0:30–0:45 · Vorher. Zeigen Sie die alte Stelle oder das alte Limit für ein paar Sekunden, nur damit die Änderung verständlich wird.
0:45–1:50 · Der neue Weg. Führen Sie ihn einmal in normalem Tempo vor: Menü benennen, klicken, auf dem Ergebnis stehen bleiben. Enden Sie auf dem gespeicherten Zustand.
1:50–2:10 · Was sich nicht geändert hat. „Für vorhandene Dateien gilt weiter die bisherige 30-Tage-Regel, bis Sie sie ändern. Nichts wird früher gelöscht.“
2:10–2:30 · Nächster Schritt. Verweisen Sie auf die Release Notes und den Hilfeartikel und sagen Sie, wohin Fragen gehen.

Was ein Release-Video zeigen sollte, je nach Zielgruppe

Eine Aufnahme passt selten für alle. Nutzer wollen den neuen Weg. Der Support will die Sonderfälle. Der Vertrieb will den Nutzen in einem Satz. Nehmen Sie zuerst die Nutzerversion auf, dann eine kürzere Schnittfassung oder einen zweiten Take für interne Teams.

Inhalt eines Release-Walkthroughs nach Zielgruppe
Zielgruppe	Länge	Muss gezeigt werden	Weglassen
Endnutzer	2–3 Minuten	Der neue Weg und was gleich bleibt	Interne Namen, die Roadmap
Support-Team	3–5 Minuten	Wer es bekommt, bekannte Limits, Fehlerzustände, wohin eskaliert wird	Die Marketing-Verpackung
Vertrieb und Customer Success	1–2 Minuten	Der Nutzen, in welchen Tarifen, ein Live-Beispiel	Details der Admin-Einrichtung
Admins und IT	3–4 Minuten	Berechtigungen, Migrationsschritte, wie man es abschaltet	Grundlagen für Endnutzer

Beispiel: eine Aufbewahrungseinstellung in Version 3.8

Das Release: Ein Filesharing-Produkt liefert eine einstellbare Aufbewahrungsdauer für gelöschte Dateien aus. Das Nutzervideo ist 2:24 lang. Es beginnt auf Einstellungen → Daten, zeigt fünf Sekunden lang die alte feste Angabe „30 Tage“, stellt dann die Aufbewahrung auf 90 Tage, speichert und endet auf dem Bestätigungsbanner.

Der Satz, der die meisten Tickets verhindert, fällt bei 1:52: „Für vorhandene Dateien gilt die 30-Tage-Regel, bis Sie sie ändern.“ Ohne ihn nehmen Admins an, die neue Voreinstellung gelte rückwirkend, und schreiben dem Support.

Die Fassung für den Support nutzt dasselbe Material und hängt 90 Sekunden an: was ein Workspace ohne Business-Tarif sieht (keine Einstellung), den Fehler, wenn die Aufbewahrung unter 7 Tage gesetzt wird, und den Eskalationskanal. Der Post zu beiden Versionen: „3.8: Einstellbare Aufbewahrung für gelöschte Dateien. Business-Tarif, Rollout ab 6. Oktober. Video (2:24). Release Notes: Link. Hilfeartikel: Link.“

Checkliste vor der Veröffentlichung eines Release-Videos

Gehen Sie sie am Tag vor dem Release durch. Ein Release-Video mit einer falschen Beschriftung erzeugt mehr Tickets als gar kein Video.

Auf dem Release-Build aufgenommen, nicht auf einem Entwicklungszweig.
Jede Beschriftung, die im Kommentar genannt wird, stimmt mit der auf dem Bildschirm überein.
Tarif, Rolle und Rollout-Datum werden laut gesagt und stimmen mit den Release Notes überein.
Der gespeicherte Endzustand ist mindestens drei Sekunden zu sehen.
„Was sich nicht geändert hat“ wird gesagt.
Keine Testdaten mit echten Namen, keine internen Tabs, keine Staging-URLs im Bild.
Das Video verlinkt auf die Release Notes, und die Release Notes verlinken auf das Video.
Jemand außerhalb des Feature-Teams hat es einmal angesehen und konnte die Schritte nachmachen.
Die Projektdatei bleibt gespeichert, bis der Rollout abgeschlossen ist.

Ein Release-Video am Abend vor dem Launch mit Qreata korrigieren

Release-Videos werden aufgenommen, bevor das Release final ist, und irgendeine Kleinigkeit verschiebt sich immer. Am Abend vor dem Launch wird die Einstellung von „Aufbewahrung“ in „Datenaufbewahrung“ umbenannt. Ihr Video von 2:24 zeigt und nennt bei 1:12 den alten Namen. In Qreata öffnen Sie das Projekt auf dem finalen Build, wählen Replace Take (im Editor das Werkzeug „Rerecord“), ziehen bei gedrückter Umschalttaste über 1:08–1:20, nehmen diese 12 Sekunden neu auf und exportieren. Der Bereich muss innerhalb eines Segments liegen und darf keinen Schnitt überqueren, und die Neuaufnahme muss die 12 Sekunden füllen: Eine kürzere wird abgelehnt, eine längere wird gekürzt. Intro, Vorher-Nachher und Schluss bleiben wie freigegeben.

Auch für die Support-Fassung fangen Sie nicht von vorn an. Qreata-Projekte enthalten mehrere Clips. Mit „Add clip“ nehmen Sie die Sonderfälle in dasselbe Projekt auf und exportieren eine zweite Version.

Kleine Einstellungen sind in einem eingebetteten Player schwer zu lesen. Ist „Auto-zoom on clicks“ eingeschaltet, setzt Qreata Zooms auf Ihre tatsächlichen Klicks. Behalten Sie den auf dem Aufbewahrungsfeld und löschen Sie die übrigen, oder fügen Sie von Hand einen Zoom auf dem Bestätigungsbanner hinzu, auf dem es keinen Klick gibt. Dauert das Speichern 20 Sekunden, stellen Sie dieses Segment auf 4-faches Tempo. Exportiert wird als MP4 (H.264) bis 4K. Material aus der Zeit vor dem Release bleibt auf Ihrem Mac, denn Aufnahme und Bearbeitung laufen lokal, brauchen kein Konto und laden nichts hoch, solange Sie nicht auf die Schaltfläche klicken.

„Captions in video“ brennt Untertitel mit Wort-Hervorhebung in die MP4-Datei ein. Das deckt Nutzer ab, die das Release-Video stumm ansehen. Eine Grenze sollten Sie einplanen: Qreata exportiert keine SRT- oder VTT-Dateien. Braucht Ihr Hoster eine Untertiteldatei, erstellen Sie sie dort. Um den Ablauf vor Ihrem nächsten Release zu prüfen, nehmen Sie sich zehn Minuten der 7-tägigen Testversion: Zeichnen Sie das Skript oben mit einer Funktion auf, die Sie letzten Monat ausgeliefert haben, ersetzen Sie dann einen 10-Sekunden-Abschnitt und achten Sie auf beide Übergänge.

Häufige Fehler in Walkthrough-Videos zu Releases

Das sind die Fehler, die den Support nach dem Launch Zeit kosten.

Eine Produkttour daraus machen. Der Zuschauer nutzt das Produkt bereits; zeigen Sie die Änderung.
Nicht sagen, wer es bekommt. Nutzer in anderen Tarifen suchen eine Einstellung, die sie nicht haben.
Auf Staging aufnehmen, mit anderen Beschriftungen oder einem sichtbaren Feature-Flag.
„Was sich nicht geändert hat“ auslassen. Genau daher kommen die meisten besorgten Fragen.
Ein Video für Nutzer, Support und Vertrieb zusammen.
Das Video ohne Link zu den schriftlichen Notes veröffentlichen, oder die Notes ohne das Video.
Das alte Video stehen lassen, wenn sich die Funktion in der nächsten Version ändert.

Fragen, die sich lohnen

Wie lang sollte ein Walkthrough-Video zu einem Release sein?

2 bis 3 Minuten für Endnutzer. Interne Versionen für Support oder Admins dürfen 3 bis 5 Minuten dauern, weil sie Limits und Sonderfälle behandeln.

Braucht jedes Software-Release ein Video?

Nein. Nehmen Sie eines auf, wenn sich ein Ablauf ändert oder Nutzer etwas tun müssen. Bugfixes, Performance-Arbeit und API-Änderungen sind in schriftlichen Release Notes besser aufgehoben.

Wann sollte ich das Release-Video aufnehmen?

Nach dem Feature-Freeze, ein oder zwei Tage vor dem Launch, auf dem Release-Build. Behalten Sie das bearbeitbare Projekt, damit Sie einen Abschnitt ersetzen können, wenn sich in letzter Minute eine Beschriftung ändert.

Was ist der Unterschied zwischen einem Release-Walkthrough und einer Produktdemo?

Ein Release-Walkthrough behandelt eine Änderung für Leute, die das Produkt bereits nutzen, in 2 bis 3 Minuten. Eine Produktdemo stellt das Produkt jemandem vor, der es gerade prüft, und dauert länger.

Kann Qreata aus dem Video Release Notes oder ein Changelog schreiben?

Nein. Qreata nimmt das Video auf, bearbeitet es und transkribiert es lokal für die Bearbeitung. Schreiben Sie die Release Notes in Ihrem eigenen Dokumentationstool.