Ein Bücherregal ist kein Lernplan mehr
2026 veraltet eine reine Literaturliste schnell. Git-Workflows, automatisierte Prüfungen und generative KI gehören zur Dokumentationsarbeit, während öffentliche Styleguides laufend geändert werden. Bücher eignen sich weiterhin für längere Denkmodelle; lebende Guides sind besser für aktuelle Entscheidungen zu UI, Code, Terminologie und Verfahren.
Microsoft und Google pflegen öffentliche Leitfäden, GitHub beschreibt Content-Modelle, IBM hält Qualitätsstandards offen und Diátaxis trennt Dokumentationstypen systematisch.
Fünf lebende Guides für die tägliche Arbeit
| Quelle | Stärke | Praktische Idee |
|---|---|---|
| Microsoft | Stimme, Verfahren, UI | Einfache Sätze, aktive Form, direkte Handlungen |
| Developer Docs, globale Zielgruppe | Bedingungen vor Anweisungen; technische Entitäten als Code | |
| GitHub Docs | Nutzerziel, Artikelstruktur | Nur nötige Inhalte; passenden Content-Typ wählen |
| IBM | Qualitätsbewertung | Accuracy, completeness, clarity, organization und retrievability getrennt prüfen |
| Diátaxis | Architektur | Tutorial, how-to, reference und explanation bewusst trennen |
Dasselbe Problem in verschiedenen Traditionen
Schlechter Ausgangssatz: „Um den Vorgang erfolgreich abzuschließen, sollten Benutzer sicherstellen, dass das Repository zuvor initialisiert wurde, und anschließend auf Create klicken.“
Microsoft führt zu „Initialisieren Sie das Repository und wählen Sie Create“. Google kann die Bedingung voranstellen: „Bevor Sie Create wählen, initialisieren Sie das Repository.“ GitHub ergänzt das Ziel: „Um das Projekt zu erstellen, initialisieren Sie das Repository und wählen Sie Create.“ IBM prüft zusätzlich, ob die Voraussetzung stimmt und ein Ergebnis fehlt. Diátaxis fragt, ob der Schritt überhaupt in reference gehört oder in einen how-to.
Ein Problem nach dem anderen, aber mit echter Aufgabe
| Problem | Vergleichen | Übung | Ergebnis |
|---|---|---|---|
| Versteckte Voraussetzungen | Microsoft + Google | Ein reales Verfahren überarbeiten | Before/after + lokale Regel |
| API Reference ist zu erzählerisch | Diátaxis + Google | Fakten vom Szenario trennen | Saubere Reference + how-to |
| Uneinheitliche Begriffe | Google + Microsoft | 20 Begriffe prüfen | Mini-Glossar + Lint-Regeln |
| Wiederholte Review-Kommentare | IBM + GitHub | Maschine/Mensch trennen | Review-Checkliste |
| Schwierige Lokalisierung | Google + IBM | Zwei Seiten entwirren | Lokale Beispiele |
Aus Lesen wird Können
Beginnen Sie mit einem echten Defekt, vergleichen Sie zwei oder drei Quellen, formulieren Sie die Regel selbst, ändern Sie eine Seite und testen Sie sie mit Leser oder SME. Wiederholt sich die Lösung, gehört sie in den lokalen Styleguide oder in einen automatischen Check. Ein Lernjournal speichert Ausgangstext, Änderung und Review-Ergebnis.
Bücher, die noch tragen, und was gealtert ist
Docs for Developers (2021) liefert einen guten End-to-End-Zyklus, entstand aber vor der heutigen LLM-Welle. Developing Quality Technical Information (2014) bietet weiterhin ein starkes Qualitätsmodell, während ein Teil des Delivery-Kontexts älter ist als moderne Docs-as-Code-Prozesse. Every Page Is Page One (2013) bleibt für suchbasierte Einstiege nützlich, muss heute aber mit AI-Antworten und modernen Portalen zusammengedacht werden. The Product is Docs bleibt interessant für Zusammenarbeit im Produktteam.
Einen eigenen Styleguide aus geprüften Entscheidungen bauen
Ein externer Guide ist Referenz, kein Gesetz. Wiederholt sich eine Terminologiedebatte, treffen Sie lokal eine Entscheidung. Verwenden API-Beispiele mehrere Muster, definieren Sie eines. Speichern Sie Problem, Entscheidung, gutes Beispiel und Ausnahme.
| Feld | Beispiel |
|---|---|
| Problem | log in, login und sign in meinen dieselbe Aktion |
| Entscheidung | Für die Nutzeraktion sign in; technische Namen unverändert |
| Beispiel | “Sign in to the admin console.” |
| Ausnahme | Ein API-Feld login bleibt login |
Was Sie diese Woche tun können
Nehmen Sie eine Seite mit einem echten Leser-, SME- oder Review-Kommentar. Formulieren Sie das Problem, vergleichen Sie zwei Quellen und erstellen Sie eine before/after-Version. Zeigen Sie sie einem echten Nutzer. Eine Woche liefert so eine bessere Seite und eine geprüfte Entscheidung statt nur gelesener Kapitel.



