Release Notes schreiben, die tatsächlich gelesen werden

Release notes, die tatsächlich gelesen werden, schreibst du so: ein Eintrag pro sichtbarer Änderung, die neue Fähigkeit des Lesers zuerst, eine feste Zeile für Version und Datum und genau ein Link zu der Seite, die es erklärt. Kurz ist besser. Eine Release Note ist eine Ankündigung, kein zweites Changelog.

Die meisten Release Notes scheitern aus einem langweiligen Grund. Sie erzählen, was das Team getan hat, in der Reihenfolge, in der es das getan hat, mit den internen Namen des Teams. Der Leser will nur eines wissen: Kann ich heute etwas tun, das ich gestern nicht konnte? Schreib für diese Person, und das Format sortiert sich fast von selbst.

Warum Release Notes zum Changelog werden

Ein Changelog ist ein fortlaufendes Protokoll. Eine Release Note ist die kurze Ankündigung zu einer Version. Beide werden nach demselben Deploy von derselben Person aus derselben Ticketliste geschrieben. Sobald die Ticketliste die Gliederung wird, wird die Ankündigung zum Umsetzungstagebuch.

Keep a Changelog bringt den Unterschied auf einen Satz: Ein Changelog ist für Menschen, nicht für Maschinen, und ein ausgeschütteter Haufen Commit-Nachrichten ist keiner (keepachangelog.com, abgerufen am 2026-10-18). Derselbe Test gilt für die Release Note. Wenn ein Eintrag nur für jemanden Sinn ergibt, der den internen Namen des Dienstes schon kennt, ist er noch nicht bereit für den Leser.

Was der Nutzer nicht sieht, gehört meist ins Changelog und nicht in die Release Note.

Die vier Teile eines Release-Notes-Eintrags

Jede sichtbare Änderung beantwortet vier Fragen in dieser Reihenfolge: was sich ändert, wen es betrifft, was der Leser tun muss und wo er mehr lesen kann. Die ersten beiden sind je ein Satz. Die dritte lautet oft „nichts“, und das ist in Ordnung. Die vierte ist ein Link, kein Erklärungsabsatz.

Die Reihenfolge passt zum Überfliegen. Man liest die ersten Wörter jeder Zeile, bleibt an der Zeile hängen, die relevant aussieht, und entscheidet dann über den Klick. „Wir haben den Abrechnungsdienst refaktoriert“ gibt keinen Grund zum Anhalten.

Die Vorlage zum Kopieren

Das ist das ganze Ergebnis. Feste Kopfzeile nach oben, dann ein Block pro Änderung. Wenn dein Publikum das Format kennt, kannst du die Beschriftungen weglassen, aber nicht die Reihenfolge ändern.

## 2026-10-18 · v1.4.0

**Neu**
- Ein Produktprofil als CSV exportieren. In jedem Plan verfügbar. Nichts zu aktivieren.
  Details: /help/export-product-profile

**Verbessert**
- Verzeichnis-Einreichungen behalten das Datum der letzten Prüfung. Keine Aktion nötig.

**Behoben**
- Die Launch-Checkliste wird nach dem Neuladen der Seite nicht mehr zurückgesetzt.

**Aktion nötig**
- Wenn du vor dem 1. Oktober eine eigene Domain verbunden hast, prüfe den DNS-Eintrag erneut.
  Details: /help/custom-domain

Zwei Regeln halten die Vorlage im echten Release stabil. Version und Datum stehen in der Kopfzeile, nicht in jeder Zeile. Jeder Eintrag beginnt mit der Fähigkeit des Lesers, nicht mit dem Komponentennamen. „Ein Produktprofil als CSV exportieren“ besteht. „CSV-Exporter v2“ besteht nicht.

Was hineingehört und was draußen bleibt

Entscheide nach der Art der Änderung, nicht nach der Größe des Diffs. Ein Einzeiler, der sichtbar etwas ändert, gehört hinein. Eine Woche interner Arbeit ohne sichtbare Wirkung nicht.

Eine Preisänderung verdient eine eigene Notiz, weil sie eine Entscheidung ändert, nicht eine Ansicht. In einer Liste vergraben wird sie übersehen, und die Support-Nachricht danach kostet mehr als die zusätzliche Notiz.

Bei Sicherheit brauchst du ein Urteil. Sag, was zu tun ist und welche Versionen betroffen sind. Veröffentliche keine Reproduktionsanleitung, bevor der Fix alle erreicht hat. Wenn du den zweiten Teil nicht sicher sagen kannst, sage weniger und verlinke die offizielle Mitteilung.

Eine Release Note in mehreren Kanälen wiederverwenden

Einmal schreiben, dann den Behälter ändern, nicht die Fakten. Die Changelog-Seite behält alle Einträge. Die Meldung in der App behält die Einträge für die aktuelle Ansicht. Die E-Mail behält den Eintrag, der eine Entscheidung ändert. Ein Verzeichnis- oder Community-Post behält den Eintrag, den ein neuer Leser ohne Kontext versteht.

Hier entstehen oft zwei Versionen der Wahrheit. Halte Datum und Versionsnummer überall identisch. Wenn das Changelog sagt, v1.4.0 sei am 18. Oktober erschienen, kann die E-Mail nicht „diese Woche“ schreiben, ohne irgendwo das Datum zu nennen.

Wo Release Notes kaputtgehen

Die Fehler sind vorhersehbar, und jeder hat ein sichtbares Symptom.

1. Die Notiz ist ein Commit-Log. Symptom: Dienst-, Branch- oder Ticketnamen. Fix: von der Ansicht des Lesers rückwärts neu schreiben.
2. Jede Version ist „spannend“. Symptom: dieselben drei Adjektive jeden Monat. Fix: Adjektiv löschen, Verb behalten.
3. Die Notiz kommt nach dem Support-Postfach. Symptom: Nutzer fragen vor der Veröffentlichung, warum sich etwas geändert hat. Fix: mit der Version veröffentlichen, nicht nach den Beschwerden.

Es gibt einen vierten Fehler, der schwerer zu sehen ist: eine Änderung ankündigen, die niemand findet. Wenn die neue Fähigkeit hinter drei Menüs liegt und die Notiz nicht sagt wo, ist sie korrekt und nutzlos. Ergänze den Pfad, einen Screenshot oder einen Link auf die Seite, die den Pfad zeigt.

Was wir nicht gemessen haben

Wir haben nicht gemessen, ob bessere Release Notes die Retention, Upgrades oder das Support-Volumen verändern. Keine öffentliche Studie, die wir prüfen konnten, isoliert diesen Effekt, und wir erfinden keine. Was wir sagen können, ist enger: Eine Notiz in der Reihenfolge des Lesers liest sich schneller, und ein Eintrag mit Aktionszeile erzeugt weniger Antworten der Art „und was mache ich jetzt?“. Das ist ein Schreiburteil, kein Messergebnis.

Häufige Fragen

Wie lang darf eine Release Note sein?

So lang wie die sichtbaren Änderungen es verlangen, und nicht länger. Eine Änderung kann drei Zeilen brauchen. Zehn Änderungen passen auf einen Bildschirm, wenn jeder Eintrag ein Satz ist. Wenn die Notiz ein Inhaltsverzeichnis braucht, ist sie wahrscheinlich eine Changelog-Seite, keine Ankündigung.

Brauche ich für jeden Deploy eine Notiz?

Nein. Schreibe eine für jede Version, die ein Leser bemerken kann. Ein Deploy ohne sichtbare Änderung braucht keine. Ein Deploy, der eine Button-Beschriftung ändert, schon, weil es jemand bemerken und an seinem Gedächtnis zweifeln wird.

Helfen Release Notes bei SEO oder KI-Antworten?

Sie können helfen, aber nicht wegen des Wortes „Release“. Eine datierte Seite, die Funktion, Plan und Aktion nennt, ist eine gute Zielseite für alle, die später nach der Funktion suchen. Eine Seite mit Versionsnummern ohne Funktionsnamen gibt einer Suchmaschine sehr wenig. Wir haben keinen Zitatzuwachs gemessen, also ist das ein strukturelles Argument, kein Versprechen.

Wo soll die Notiz stehen?

Eine kanonische URL pro Version, mit dem Datum auf der Seite und in der URL, wenn das System es erlaubt. Veröffentliche die Kurzfassung in den Kanälen, die sie brauchen, aber der Link zeigt weiter auf die kanonische Seite. Fünf Kopien mit fünf Daten sind fünf Quellen der Wahrheit.

Nächster Schritt

Nimm das letzte Release und schreibe einen Eintrag in der Vier-Teile-Reihenfolge neu. Wird er kürzer und konkreter, funktioniert die Vorlage. Wird er länger, erklärst du wahrscheinlich die Umsetzung statt der Fähigkeit.

Release Notes sind ein Eingang in den Content-Workflow. Dasselbe leserzentrierte Umschreiben gilt für das Content-Brief, das du einem Autor gibst, und dieselbe Kanallogik gilt, wenn du eine Produktbeschreibung für jeden Kanal anpasst. Wenn die Notiz fertig ist, veröffentliche sie dort, wo das Produkt lebt, und halte den Content-Workflow an einem Ort, damit das nächste Release nicht auf einer leeren Seite beginnt.