Automatisierte Release-Notes aus Commits und Screenshots: ein einfacher Ablauf, um kleine PR-Notizen und UI-Schnappschüsse in klare Changelogs mit weniger manueller Nachbearbeitung zu verwandeln.
Release-Notes sind eine dieser Aufgaben, die alle nützlich finden, die aber oft ans Ende der Woche geschoben werden, wenn die Energie niedrig ist. Nach ein paar hektischen Sprints werden sie zu einem hastigen Absatz oder ganz übersprungen.
Ein Teil des Problems ist das Timing. Die Details stecken in Commits, PR-Threads und kurzen Chatnachrichten. Wenn du dich später an den Changelog setzt, versuchst du dich daran zu erinnern, warum eine Änderung wichtig war, wem sie geholfen hat und was ein Nutzer tatsächlich bemerkt.
Es gibt auch eine Sprachbarriere. Entwickler schreiben Dinge wie „refactor auth middleware“ oder „fix race in cache“, aber Nutzer wollen hören „Anmelden ist zuverlässiger“ oder „Seiten laden schneller bei langsamer Verbindung“. Technische Arbeit in nutzerverständliche Sprache zu übersetzen erfordert Fokus und fällt schwer beim ständigen Kontextwechsel.
Formatdrift macht es noch schlimmer. Eine Woche schreibst du Aufzählungen, die nächste Absätze. Die eine Person fügt Emojis hinzu, die andere schreibt Ticket-IDs. Mit der Zeit wirkt das Changelog weniger vertrauenswürdig, weil Leser es nicht schnell überfliegen oder Releases vergleichen können.
Die gute Nachricht: Die meisten Rohdaten erzeugt ihr schon. Eine kurze PR-Beschreibung plus ein oder zwei UI-Snapshots enthalten meist alles, was ihr braucht. Das Ziel ist kein Roman, sondern konsistente, nutzerfreundliche Notes mit weniger manuellem Aufwand.
Ein einfacher Ansatz funktioniert am besten:
Um Release-Notes zu erhalten, die sich konsistent anfühlen, sei klar über die Eingaben, die du bereits hast. Die meisten Teams sitzen auf vielen Details – sie sind nur verstreut.
Ein Commit ist die kleinste Einheit: ein technischer Eintrag dessen, was sich im Code geändert hat. Commit-Nachrichten sind nützlich, um Arbeit nachzuverfolgen, sagen aber oft nur „fix lint“ oder „refactor header“, was für Kunden wenig hilfreich ist.
Eine PR (Pull Request)-Beschreibung ist die Brücke. Sie erklärt, warum die Änderung existiert, was Reviewer prüfen sollten und was sich aus Produktperspektive geändert hat. Für automatisierte Release-Notes sind PR-Beschreibungen oft das beste Rohmaterial, weil sie in klarer Sprache verfasst werden können, ohne lang zu sein.
Issue-Titel (oder Ticket-Titel) geben einen zusätzlichen Hinweis: sie benennen das Problem, das gelöst wird. Wenn PRs Issues referenzieren, ergibt sich ein sauberer Faden von „gemeldetem Problem“ zu „geliefertem Fix“.
Ein UI-Snapshot (Screenshot oder kurzes annotiertes Bild) ist ein visueller Beleg dafür, was der Nutzer tatsächlich sieht. Er ist keine Dekoration, sondern Beweis und Kontext.
Outputs für Release-Notes teilen sich in der Regel in zwei Typen:
Verschiedene Zielgruppen lesen diese Notes aus unterschiedlichen Gründen. Kunden wollen wissen, was sich für sie geändert hat. Support muss wissen, was zu erwarten ist und was sie Nutzern sagen sollen. Sales und Customer Success suchen nach Neuheiten, die erwähnenswert sind. Interne Teams brauchen ein Protokoll dessen, was geliefert wurde und was eventuell kaputtgehen könnte.
Screenshots sind am nützlichsten, wenn sie drei Dinge ermöglichen: bestätigen, dass die Änderung echt ist, an die exakten Bezeichnungen und Button-Texte erinnern und ein Vorher/Nachher zeigen, das Text nicht ersetzen kann.
Ein gutes Changelog dreht sich weniger ums Schreiben als ums Sortieren. Wenn die Struktur bei jedem Release gleich bleibt, kannst du kleine PR-Notizen in Release-Notes verwandeln, ohne das Format jedes Mal neu zu überdenken.
Wähle 4 bis 6 Kategorien, die dem Vokabular deiner Nutzer entsprechen. Zu viele Kästchen verlangsamen und erzeugen eine „Sonstiges“-Sammlung.
Ein praktisches Set ist:
„Admin“ ist nützlich, wenn Änderungen Owner, Abrechnung, Rollen oder Einstellungen betreffen. Ist euer Produkt Entwickler-orientiert, könnt ihr es durch „API“ ersetzen. Haltet die Namen stabil, damit Leser wissen, wo sie nachschauen müssen.
Zieh eine klare Linie zwischen nutzergerichteten und internen Änderungen. Eine einfache Regel: Wenn ein Nutzer es bemerken, danach suchen oder sich darauf verlassen könnte, gehört es in die Release-Notes. Reines Refactoring, Dependency-Updates oder Logging-Änderungen bleiben draußen, sofern sie Verhalten nicht ändern.
Wählt ein Satzmuster und bleibt dabei. Das verhindert, dass PR-Beschreibungen zu Mini-Essays werden und hält die finalen Notes gut scanbar.
Ein verlässliches Muster ist:
Was sich geändert hat + wer betroffen ist + wo es zu finden ist.
Beispiel: „Zwei-Faktor-Login für Workspace-Owner in den Einstellungen hinzugefügt.“ Selbst wenn ihr den Ton später anpasst, bleibt die Rohangabe konsistent.
Ein kleines Glossar hilft mehr als die meisten Teams erwarten. Entscheide dich für einen Begriff pro wichtigem Konzept und vermeide Synonyme (z. B. immer „Arbeitsbereich“, nicht manchmal „Project“ und manchmal „Team Space“). Konsistente Wortwahl lässt das Changelog wie eine Stimme klingen, nicht wie fünf.
Der einfachste Weg zu automatisierten Release-Notes ist, jede PR als kleine, nutzerorientierte Story zu behandeln. Wenn jemand außerhalb deines Teams den PR-Titel lesen und verstehen kann, was sich geändert hat, bist du schon weit.
Beginne mit dem PR-Titel. Mach ihn zu einem klaren Satz in einfacher Sprache, fokussiert auf das Ergebnis, nicht die Implementierung. Vergleiche „Add caching layer to search“ mit „Search results load faster“. Der zweite Titel kann direkt in ein Changelog übernommen werden.
Halte die PR-Beschreibung kurz (2 bis 5 Zeilen), aber gib jeder Zeile eine Aufgabe:
Tags helfen später beim Sortieren der Wochen-Änderungen. Nutze konsistente Klammern wie [UI], [API], [Billing], [Performance]. Ein bis zwei Tags reichen. Zu viele verwandeln sich in Rauschen.
Füge eine einzelne „User impact“-Zeile hinzu, die wie ein Release-Note lesbar ist. Beispiel: „Admins können jetzt Rechnungen als CSV exportieren.“ Diese Zeile ist Gold, wenn du in Zeitdruck Updates zusammenstellst.
Screenshots gehören in die PR-Beschreibung nur, wenn die UI sich verändert hat. Nutze ein Before- und After-Bild, eng auf den veränderten Bereich zugeschnitten. Wenn nichts Sichtbares geändert wurde, lass die Screenshots weg und schreibe stattdessen einen zusätzlichen Satz, der den Unterschied erklärt.
Hier ist ein einfaches PR-Beschreibungs-Muster, das du in deine Vorlage kopieren kannst:
[UI] Faster search results
Intent: Reduce wait time on the search page.
User impact: Everyone sees results in under 1 second for common queries.
Edge cases: Empty search now shows “Try a different keyword”.
Screenshots können Stunden sparen beim Schreiben von Release-Notes, aber nur, wenn sie leicht zu finden und zu verstehen sind. Ein Haufen Bilder namens „Screenshot 12“ wird schnell zur Mehrarbeit.
Beginne mit einem einfachen Namensschema, damit du später suchen kannst. Eine Option ist YYYY-MM-DD_area_feature_state. Zum Beispiel: 2026-01-14_billing_invoices_empty.png. Wenn jemand fragt: „Wann haben wir diesen Screen geändert?“, kannst du in Sekunden antworten.
Capturiere den Zustand, der die Story erzählt. Der „Happy Path“ ist nicht immer der hilfreichste. Wenn ein Release Verhalten ändert, zeige den Moment, an dem ein Nutzer es bemerkt.
Ziele 1 bis 3 Screenshots pro Änderung an. Am nützlichsten sind in der Regel:
Halte Annotationen sparsam. Wenn das Bild Hilfe braucht, füge einen Pfeil oder eine Markierung hinzu. Vermeide Textabsätze im Bild. Erläutere stattdessen in der PR-Beschreibung, damit die Erklärung im Changelog wiederverwendbar ist.
Wo du Screenshots speicherst, ist genauso wichtig wie was du aufnimmst. Lege sie neben die PR (oder in einen gemeinsamen Ordner) und füge die PR-ID in den Dateinamen oder die Bildunterschrift ein. Beispiel: „PR-1842: updated checkout error message.“
Eine kleine Gewohnheit, die sich auszahlt: Wenn du UI-Text, Abstand oder Kontrast änderst, füge eine einzeilige Notiz wie „Verbesserter Button-Kontrast für bessere Lesbarkeit“ hinzu. Diese Zeile wird oft ohne zusätzliche Umschreibung zur sauberen Release-Note.
Du brauchst kein ausgefeiltes System für verlässliche Release-Notes. Du brauchst eine kleine Gewohnheit: Jede gemergte PR sollte eine kurze, nutzerorientierte Notiz enthalten, und jede UI-Änderung sollte einen passenden Screenshot haben.
Wähle ein Release-Fenster (zum Beispiel Montag bis Freitag). Ziehe gemergte PR-Titel und -Beschreibungen aus diesem Fenster in ein Draft-Dokument. Hat eine PR keine klare Beschreibung, rate nicht — bitte die Autorin oder den Autor, eine Zeile hinzuzufügen, solange der Kontext frisch ist.
Ordne Screenshots den PRs zu, die die UI geändert haben. Ein Screenshot pro sichtbarer Änderung reicht in der Regel. Beschrifte sie so, dass sofort klar ist, was sie zeigen (Before/After hilft bei subtilen Unterschieden).
Dann mache einen kurzen Cleanup-Durchgang:
Schließe mit einer schnellen Review ab. Teile den Entwurf mit Support oder Produkt und stelle eine Frage: „Würde ein Kunde verstehen, was sich geändert hat und warum es wichtig ist?“ Wenn die Antwort nein ist, vereinfache die Formulierungen oder füge einen kleinen Kontext hinzu.
Statt „Refactored permissions middleware“ schreibe zum Beispiel: „Du kannst jetzt Team-Rollen in der Einstellungsseite verwalten.“
Commits, PR-Notizen und Screenshots sind für Teamkollegen geschrieben. Release-Notes sind für Nutzer. Die Aufgabe ist Übersetzung, nicht Copy-Paste.
Ein paar Regeln beim Formulieren halten jeden Eintrag klar:
Konsistenz ist wichtiger als perfektes Wording. Wählt eine Zeitform (die meisten Teams nutzen Vergangenheit: „Fixed“, „Improved“, „Added") und bleibt dabei. Nutzt die gleiche Großschreibung. Wenn Features benannt werden, folgt einem Muster, z. B. „Feature-Name (Bereich)" wie "Saved views (Reports)". Solche kleinen Regeln verhindern, dass das Changelog unordentlich wirkt.
Wenn etwas Nutzer unterbricht, sage es klar und gib den nächsten Schritt an. Lass die technische Ursache weg.
Beispiel: „API-Keys, die vor dem 10. Jan erstellt wurden, funktionieren nicht mehr. Erstelle einen neuen Key unter Einstellungen - API keys."
Füge eine „Known issues“-Sektion nur hinzu, wenn Nutzer wahrscheinlich darauf stoßen. Halte es kurz und gib, wenn möglich, eine Umgehung an.
Beispiel: „Known issue: CSV-Export kann bei sehr großen Berichten timeouts verursachen. Workaround: nach Datumsbereich exportieren."
Screenshots sollten ihren Platz verdienen. Füge eines hinzu, wenn es Nutzern hilft, ein neues Control, einen verschobenen Button oder einen neuen Screen zu erkennen. Halte Screenshots intern, wenn die Änderung klein ist (Spacing, Farben, kleine Copy-Edits) oder die UI sich wahrscheinlich vor dem nächsten Release noch ändert.
Die meisten Release-Note-Probleme tauchen eine Woche nach dem Shipping auf. Jemand fragt: „War diese Änderung beabsichtigt?“ und du gräbst dich durch PRs, Screenshots und Chats. Wenn du automatisierte Release-Notes dauerhaft nützlich halten willst, vermeide die Fallen, die Notes schwer lesbar und wenig vertrauenswürdig machen.
Diese Muster führen am meisten zu Rework:
Kleine UI-Änderungen werden oft übersehen. Ein umbenannter Button, ein verschobenes Menü oder ein neuer Empty State verwirren Nutzer mehr als ein Backend-Refactor. Wenn sich ein Screenshot geändert hat, erwähne es kurz. Eine einfache Zeile wie „Der Export-Button wurde nach oben rechts in die Tabelle verschoben“ spart viel Nachfragen.
Ein kurzes Beispiel: Du lieferst ein neues Billing-Page-Layout und verschärfst zugleich, wer Rechnungen bearbeiten darf. Wenn du nur „Improved billing page“ notierst, gehen Admins davon aus, dass sonst nichts geändert wurde. Besser: Eine Zeile zur Layout-Änderung, eine zur Rollenänderung mit Namensnennung der Rolle.
Gute Release-Notes sind nicht länger — sie sind klarer und altern gut.
Gute Release-Notes beantworten drei Fragen schnell: Was hat sich geändert, wo sieht man es und für wen ist es relevant. Mach vor dem Veröffentlichen einen letzten frischen Blick.
Lese jeden Eintrag wie ein Nutzer, nicht wie ein Build-Verantwortlicher. Wenn du raten musst, was gemeint ist, schreibe um.
Nach der Checkliste mach eine schnelle „Übersetzungs“-Lesung. Ersetze interne Begriffe (Ticket-IDs, Komponenten-Namen, Feature-Flags) durch Begriffe, die Nutzer erkennen. Wenn ein Feature gestaffelt ausgerollt wird oder nur in bestimmten Plänen verfügbar ist, sag das deutlich.
Lass eine Person außerhalb der Entwicklung drüber lesen. Das kann eine Gründerin, Support, Sales oder ein Freund sein. Wenn sie nicht innerhalb von 10 Sekunden „Was hat sich geändert?“ beantworten kann, ist der Text noch zu nah an der PR.
Beispiel: „Improved settings modal state handling" wird zu „Einstellungen werden jetzt zuverlässig gespeichert, auch wenn du zwischen Tabs wechselst."
Ein kleines Team liefert in einer Woche 12 PRs: 4 UI-Anpassungen, 2 Bugfixes, der Rest sind kleine Refactors und Tests. Sie wollen automatisierte Release-Notes, die sich trotzdem wie von Hand geschrieben lesen.
Statt bis Freitag zu warten, sammeln sie Eingaben während der Arbeit. Jede PR enthält eine „user-facing note“-Zeile und, falls die UI sich geändert hat, ein Before/After-Screenshot. Die Screenshots liegen neben den PR-Notizen (immer am selben Ort), sodass niemand später im Chat suchen muss.
Am Freitag scannt eine Person die PR-Notizen und gruppiert ähnliche Änderungen. Vier kleine UI-Anpassungen werden zu einer Nutzer-Notiz, drei interne Refactors fallen raus, weil Nutzer sie nicht interessieren.
So sieht das veröffentlichte Wochen-Changelog nach Gruppierung und Umschreibungen aus:
Die Umschreibungen sind der Ort, an dem die meisten Teams Zeit zurückgewinnen. Aus „Refactor billing-summary component, rename prop, update tests" wird „Verbessertes Layout und Beschriftungen auf der Billing-Seite für klarere Totale." Aus „Fix N+1 query in projects list" wird „Dashboard lädt schneller, wenn du viele Projekte hast."
Screenshots verhindern Verwirrung bei Wortänderungen. Wenn ein Button-Label von „Archive" zu „Deactivate" wechselt, macht das Bild sofort klar, was Nutzer sehen; Support muss nicht raten, auf welchem Screen die Note basiert.
Der größte Unterschied zwischen „wir haben’s einmal versucht" und Release-Notes, die bleiben, ist eine kleine Routine. Gib für jedes Release-Fenster eine verantwortliche Person und einen festen 30-Minuten-Slot im Kalender. Mit Besitzer und Zeitbox wird es nicht länger jedermanns Problem.
Mach die PR-Vorlage und Screenshot-Regeln zur normalen Arbeit, nicht zu einem Spezialprozess. Fehlt in einer PR die user-facing-Zeile oder der Before/After-Snapshot, ist es nicht nur „Feinschliff" — es fehlen Informationen.
Ein leichtes Draft-Dokument ist ein guter Habit-Builder. Halte einen fortlaufenden Entwurf für das aktuelle Release und aktualisiere ihn, während PRs gemergt werden, solange der Kontext frisch ist. Der Release-Tag wird dann zum Editieren, nicht zum Schreiben von Grund auf.
Ein einfacher Rhythmus, der gut funktioniert:
Wenn das Formatieren zu lange dauert, baue einen kleinen internen Draft-Generator. Er kann PR-Text lesen, deine Vorlagenüberschriften anwenden und einen sauberen Entwurf ausgeben, der nur noch leichtes Editieren braucht. Fang klein an: Gruppierung nach Überschrift und Einfügen von Screenshot-Untertiteln reicht oft schon.
Wenn du so einen Generator per Chat prototypen willst, ist Koder.ai (koder.ai) eine Option. Du kannst schnell mit dem Prompt und dem Ausgabeformat iterieren und dann den Quellcode exportieren, wenn du ihn intern weiter pflegen willst.
Verwende PR-Titel und PR-Beschreibungen als Hauptquelle, weil sie meist das "Warum" und die Nutzerwirkung enthalten. Commits sind gut, um Code-Änderungen nachzuvollziehen, lesen sich für Kunden aber selten sinnvoll.
Schreibe den Titel in verständlicher Sprache und fokussiere dich auf das Ergebnis, das ein Nutzer bemerkt. Wenn er mit minimaler Bearbeitung in ein Changelog kopiert werden kann, erfüllt er seinen Zweck.
Kurz und einheitlich: was sich geändert hat, wer betroffen ist und wo man es findet. Das vermeidet vage Einträge und macht jede Zeile später gut scannbar.
Wählt 4 bis 6 stabile Kategorien, die Nutzer wiedererkennen, z. B. New, Improvements, Fixes, Security und Admin. Dieselben Buckets jedes Mal reduzieren Formatdrift und beschleunigen das Sortieren.
Alles, was ein Nutzer bemerken, sich darauf verlassen oder danach suchen könnte, gehört in die Nutzer-Notes. Pure Refactors, Dependency-Bumps und Logging-Änderungen bleiben im internen Changelog, sofern sie kein Verhalten ändern.
Füge Screenshots nur hinzu, wenn die UI sich geändert hat und das Bild Verwirrung reduziert — z. B. verschobener Button, geänderter Text oder neuer Schritt im Flow. Ein klares Bild (oder ein Before/After-Paar) reicht meist.
Nutze ein konsistentes, durchsuchbares Namensschema mit Datum und Produktbereich. Ergänze die PR-ID im Dateinamen oder in der Bildunterschrift, damit du die Änderung schnell zurückverfolgen kannst.
Nenne zuerst die Auswirkung und sage dann, was Nutzer tun müssen. Vermeide technische Erklärungen — sag konkret, wo die Einstellung liegt oder welche Aktion nötig ist.
Nur wenn Nutzer wahrscheinlich darauf stoßen sollten. Kurz, ehrlich und hilfreich. Wenn es eine Umgehungslösung gibt, führe diese direkt an, damit Support und Nutzer handeln können.
Behandle jeden gemergten PR als kleine, nutzerzentrierte Story, sammle dann die PR-Notizen für ein definiertes Fenster und gruppiere sie in deine festen Kategorien. Tools können beim Drafting helfen, aber ein kurzer Mensch-Check bleibt wichtig, um Duplikate zu entfernen und Formulierungen an die Sicht der Nutzer anzupassen.