Leitfaden6 Min. Lesezeit

Changelog-Video Guide

Verwandeln Sie eine ausgelieferte Änderung in eine fokussierte Release-Geschichte.

Bereiten Sie ein Changelog-Video für eine ausgelieferte Änderung vor, mit einem fokussierten Storyboard und einer Prüfliste für den Release-Kontext.

Ansehen, wie es funktioniertDie ersten 60 Sekunden Video sind kostenlos, mit Wasserzeichen.
Bestätigen Sie Ihre E-Mail-Adresse, um es herunterzuladen.

Was macht ein Changelog-Video nützlich?

Ein Changelog-Video sollte eine ausgelieferte Änderung erklären, nicht das gesamte Produkt vorführen. Es gibt Release-Lesern eine kurze visuelle Antwort auf eine enge Frage: Wie war der frühere Zustand, was kann eine Person jetzt tun, und welches sichtbare Ergebnis folgt daraus? Die schriftliche Release-Notiz bleibt die Quelle für vollständigen Umfang, Einschränkungen und technische Details.

Diese Grenze zählt. Ein Produkt-Changelog-Video ist an eine benannte ausgelieferte Änderung und einen genannten Build gebunden. Eine breite Demo ist an einen Produktworkflow gebunden, der mehrere Fähigkeiten umfassen kann. Wenn ein Asset versucht, beides zu leisten, kann der Leser nicht erkennen, welches Verhalten neu ist, welches Verhalten bereits existierte oder ob eine ansprechende Behauptung tatsächlich Teil des Releases ist.

Bei GogoScreen verwendet ein geplanter Renderdurchlauf eine erreichbare Web-App-URL und eine Zeile, die einen Ablauf beschreibt. Das ist kein Beweis, dass eine Ausgabe existiert, dass die Funktion ausgeliefert wurde oder dass ein erster Renderdurchlauf brauchbar sein wird. Etwa einer von fünf Renderdurchläufen kann fehlschlagen oder einen erneuten Versuch brauchen. Das endgültige Release-Asset muss gegen den tatsächlichen Build und die veröffentlichte Release-Notiz geprüft werden, ein Kandidat nach dem anderen.

Wie wählen Sie die eine zu zeigende Änderung aus?

Wählen Sie eine Änderung, die bereits ausgeliefert ist und für das die Aktualisierung empfangende Publikum zählt. Sie muss mit einem kontrollierten vorbereiteten Ziel vorführbar sein und einen sichtbaren Unterschied zwischen dem früheren Zustand und dem aktuellen Verhalten haben. Wenn der Unterschied nur ein Implementierungsdetail ohne beobachtbares Ergebnis ist, erklären Sie ihn in der Release-Notiz, statt ihn in ein Video zu zwingen.

Schreiben Sie zuerst die Release-Aussage. Verwenden Sie denselben Funktionsnamen und Umfang im Storyboard, im Untertitel und im nahen Link. Verwandeln Sie eine kleine Ergänzung nicht in eine Behauptung über Leistung, Zuverlässigkeit, Sicherheit oder breitere Produktfähigkeit. Zeigen Sie keine geplante Arbeit, kein Experiment und keine Funktion, die im angegebenen Build fehlt.

Eine einzelne Änderung kann immer noch mehr als einen Bildschirm betreffen, aber jede Szene muss dieselbe Release-Aussage stützen. Wenn die Abfolge anfängt, eine andere Funktion einzuführen, halten Sie an und machen Sie diese Funktion zu einem eigenen zukünftigen Release-Asset. Der Leser sollte wissen, was sich geändert hat, nicht nur, dass das Produkt viele Oberflächen hat.

Wie sollte das Vorzustand-Aktion-Ergebnis-Storyboard funktionieren?

Der Vorzustand sollte die relevante Einschränkung oder das frühere Verhalten ohne Übertreibung herstellen. Zeigen Sie nur genug Kontext, damit ein Release-Leser versteht, warum die Änderung zählt. Die Aktion zeigt dann, wie die neue Fähigkeit benutzt wird. Das Ergebnis macht das geänderte Verhalten beobachtbar und gibt dem Asset einen klaren Abschluss.

Ausgelieferte Änderung: ein benanntes Verhalten im genannten Build
Früherer Zustand: das relevante Verhalten vor dieser Änderung
Sichtbare Aktion: die Aktion, die die Änderung nutzt
Sichtbares Ergebnis: das geänderte Verhalten, das ein Release-Leser prüfen kann

Als Beispiel könnte die Struktur eine vorherige Einstellungsansicht, eine neue Auswahl oder Aktion und der resultierende Zustand sein. Der genaue Ablauf hängt von der ausgelieferten Änderung ab. Die wichtige Regel ist Kontinuität. Der Betrachter muss sehen können, dass das Ergebnis aus der Aktion folgt und zum genannten Build gehört.

Halten Sie das Storyboard klar von einer vollständigen Produkttour getrennt. Eine Tour fragt: "Was kann dieses Produkt tun?" Ein Release-Notizen-Video fragt: "Was ist an dieser Aktualisierung anders?" Ersteres kann eine Abfolge unabhängiger Workflows verwenden. Letzteres muss eine nachvollziehbare Kette von einer ausgelieferten Änderung zu einem Ergebnis bewahren.

Wie halten Release-Notizen und Untertitel das Video korrekt?

Verlinken Sie das Asset aus dem Release-Notiz-Kontext und prüfen Sie beide gemeinsam, bevor Sie es teilen. Die Notiz sollte die Version, den Umfang und jede Qualifizierung liefern, die im Clip nicht zu sehen ist. Der Untertitel sollte die Änderung mit denselben Begriffen benennen, die die Release-Notiz verwendet. Er sollte keine neue Nutzenbehauptung einführen, die die Notiz nicht stützt.

Kontrollieren Sie jedes sichtbare Label gegen die genannte Release-Version. Ein vorbereitetes Ziel kann abdriften, wenn sich Daten, Standardwerte, Navigation oder Feature-Flags ändern. Wenn die Aufnahme den Release-Zustand nicht mehr widerspiegelt, verwerfen Sie sie, selbst wenn der Schnitt klar aussieht. Genauigkeit ist wichtiger als einen fertigen Renderdurchlauf zu bewahren.

Wenn der veröffentlichte Schnitt eine hörbare generierte Sprachausgabe hat, prüfen Sie die geltende Offenlegungs- und Kennzeichnungspflicht, bevor sie verwendet wird. Ein stummer Schnitt braucht weiterhin eine Prüfung des aufgezeichneten Browserinhalts. Kein Format erlaubt Kundenanwendungen, Zugangsdaten, Kunden-URLs, Kundenmedien oder persönliche Kennungen.

Wie halten Sie die Aktualisierung knapp?

Planen Sie den Clip um die Frage herum, die ein Release-Leser beantwortet braucht. Eröffnen Sie mit dem früheren Zustand nur so lange, wie nötig ist, um die Änderung herzustellen. Zeigen Sie dann die eine Aktion, die die Aktualisierung nutzt, und den resultierenden Zustand. Enden Sie, wenn dieses Ergebnis klar ist. Diese Abfolge gibt Lesern genug Beweise, um das Release zu verstehen, ohne eine fokussierte Aktualisierung in eine Produkttour zu verwandeln.

Nutzen Sie die Release-Notiz für Material, das keine visuelle Vorführung braucht. Rollout-Umfang, technische Umsetzung, Migrationsschritte, bekannte Einschränkungen und Links zu unterstützender Dokumentation gehören in den schriftlichen Kontext, wenn sie im begrenzten Ablauf nicht klar gezeigt werden können. Diese Details neben dem Video zu halten, lässt einen Leser die Aktualisierung überfliegen, die benötigte Detailtiefe wählen und später zur relevanten Aktion zurückkehren.

Was ein Release-Leser braucht	Wohin es gehört	Warum
Der frühere Zustand, die Aktion und das sichtbare Ergebnis	Das Video	Nur eine Browserabfolge zeigt, wie die Änderung geschieht
Die Version und der Rollout-Umfang	Die Release-Notiz	Der Clip kann nicht zeigen, aus welchem Build er stammt
Migrationsschritte und bekannte Einschränkungen	Die Release-Notiz	Sie können in einem begrenzten Ablauf nicht klar gezeigt werden
Technische Umsetzung	Die Release-Notiz	Sie hat kein beobachtbares Ergebnis, das aufgenommen werden kann

Ein knappes Asset lässt sich auch leichter in eine Changelog-Liste einordnen. Sein Eröffnungsbild und Untertitel sollten dieselbe Änderung benennen wie die angrenzende Release-Notiz. Eine Person, die von einer Benachrichtigung, einem Release-Archiv oder einer Produktseite kommt, sollte den Clip verstehen können, ohne anzunehmen, dass jede aktuelle Fähigkeit in diesem Release neu ist.

Release-Prüfliste

Führen Sie diese Kontrollen gegen den genauen Kandidaten und die Release-Notiz durch. Die Prüfliste ist ein Vorbereitungswerkzeug, kein Beweis, dass die Arbeit abgeschlossen ist.

Die genannte Änderung ist in der genannten Release-Version ausgeliefert.
Der Vorzustand stellt das relevante frühere Verhalten korrekt dar.
Eine Aktion zeigt, wie die ausgelieferte Änderung benutzt wird.
Das Ergebnis ist sichtbar und folgt aus dieser Aktion.
Die Release-Notiz, der Untertitel, die Funktionsformulierung und der Versionskontext stimmen überein.
Das Asset wird nicht zu einem allgemeinen Produktüberblick und führt keine andere Funktion ein.
Kein Kundenmaterial, keine Zugangsdaten, keine Kunden-URL, keine Kundenmedien und keine persönliche Kennung erscheinen.
Untertitel und jede hörbare generierte Sprachausgabe werden für die beabsichtigte Veröffentlichungsbehandlung geprüft.
Aufnahmedatum, Build, Prüfer, abgelehnter Versuch, erneuter Versuch und unterzeichnete Entscheidung werden vermerkt.

Bevor Sie beginnen

Was sollte ein Changelog-Video abdecken?

Decken Sie eine ausgelieferte Änderung ab, durch einen klaren Vorzustand, die durch die Änderung ermöglichte Aktion und das sichtbare Ergebnis. Die Release-Notizen bleiben der vollständige faktische Vermerk.

Wie wähle ich eine ausgelieferte Änderung aus?

Wählen Sie eine ausgelieferte Änderung, die für das beabsichtigte Publikum zählt und in der genannten Release-Version mit sicheren vorbereiteten Daten gezeigt werden kann. Verwenden Sie keine geplante Arbeit.

Wie unterscheidet sich ein Changelog-Video von einer Produktdemo?

Ein Changelog-Video erklärt, was sich gegenüber einem früheren Zustand geändert hat. Eine allgemeine Demo erklärt breiter, wie ein Produkt funktioniert. Beides zu vermischen macht den Release-Kontext weniger genau.

Was sollte vor dem Teilen geprüft werden?

Kontrollieren Sie die Formulierung der Release-Notiz, den Build, die Vorzustand-Aktion-Ergebnis-Abfolge, den Untertitel, den Datenschutz, eine hörbare Sprachausgabe, sofern verwendet, und einen Vermerk über jeden erneuten Versuch.

Fügen Sie eine URL ein, beschreiben Sie einen Ablauf und erhalten Sie ein Demovideo Ihrer Webanwendung.

Die ersten 60 Sekunden Video sind kostenlos, mit Wasserzeichen. Bestätigen Sie Ihre E-Mail-Adresse, um das Video herunterzuladen.

Preise ansehen Leitfäden lesen