Topic-basiertes Schreiben: Das Grundprinzip verständlich erklärt

In den Beiträgen zu DITA, strukturiertem FrameMaker und Oxygen taucht ein Begriff immer wieder auf, der dort jedes Mal nur kurz gestreift wurde: topic-basiertes Schreiben. Das ist unbefriedigend, denn es ist der eigentliche Kern der ganzen Sache. Werkzeuge kann man kaufen, Standards übernehmen – aber das Denken in Topics muss man lernen, und es ist die Umstellung, an der Umstiege gelingen oder scheitern. Wer es beherrscht, kommt mit jedem Werkzeug klar; wer es nicht beherrscht, produziert auch im teuersten System weiterhin Dokumente in Bausteinverkleidung.

Die gute Nachricht: Das Prinzip ist in zehn Minuten erklärt und braucht keine einzige spitze Klammer. Die weniger gute: Es ändert die Art, wie man schreibt, und zwar spürbar. Der vertraute rote Faden – ein Kapitel führt zum nächsten, Absatz drei baut auf Absatz zwei auf, „wie oben beschrieben" – funktioniert nicht mehr, weil es kein verlässliches Oben mehr gibt. Stattdessen entstehen eigenständige Bausteine, die sich in wechselnden Zusammenhängen bewähren müssen.

Dieser Artikel erklärt das Grundprinzip, die drei Topic-Typen und die knifflige Granularitätsfrage – und danach die typischen Anfängerfehler, die jede Redaktion beim Umstieg macht, wenn sie niemand warnt.

Das Grundprinzip: Bausteine statt roter Faden

Beginnen wir mit dem, was sich ändert. Ein klassisches Dokument ist eine Reihenfolge: Es hat einen Anfang, einen Verlauf und ein Ende, und jeder Teil darf sich darauf verlassen, dass der Leser die vorherigen gelesen hat. Genau davon lebt der Schreibstil – Begriffe werden einmal eingeführt und danach vorausgesetzt, Verweise lauten „siehe oben", Kapitel bauen aufeinander auf. Das ist effizient und funktioniert hervorragend, solange das Dokument als Ganzes gelesen wird.

Nur wird es das immer seltener. Der Servicetechniker mit dem Tablet vor der Anlage liest nicht das Handbuch, sondern sucht eine Anleitung. Die Kollegin in der Online-Hilfe landet per Suchtreffer mitten im Text. Und die dritte Produktvariante braucht neunzig Prozent derselben Inhalte, nur eben in anderer Zusammenstellung. In allen drei Fällen ist der rote Faden nicht Hilfe, sondern Hindernis – er macht Inhalte abhängig von einem Kontext, den es im Moment des Lesens gar nicht gibt.

Topic-basiertes Schreiben dreht das um: Der Inhalt entsteht als Sammlung eigenständiger Bausteine – jeder zu genau einem Thema, jeder vollständig verständlich ohne Vorgänger und Nachfolger. Die Reihenfolge kommt danach, und zwar aus einer Map: einer Klammer, die Topics auswählt und in Ordnung bringt. Aus derselben Topic-Sammlung entstehen so das gedruckte Handbuch, die Online-Hilfe, die Servicekarte und die Variantenfassung – jeweils als andere Map über teils denselben Bausteinen. Der entscheidende Satz lautet: Der Kontext kommt aus der Map, nicht aus dem Nachbarabsatz.

Zwei Missverständnisse gehören gleich ausgeräumt. Erstens: Topic-basiert heißt nicht häppchenweise. Es geht nicht darum, Inhalte kürzer oder oberflächlicher zu machen – ein Topic darf drei Seiten haben, wenn die Leserfrage drei Seiten braucht. Es geht um Eigenständigkeit, nicht um Kürze. Zweitens: Topics sind kein reines Online-Thema. Aus Topics entstehen genauso gedruckte Handbücher mit durchgehendem Lesefluss – die Map sorgt für die Reihenfolge, und ein gutes Topic fügt sich darin ein, ohne seine Eigenständigkeit zu verlieren. Wer beides verwechselt, baut entweder Fragmente oder verteidigt den roten Faden gegen einen Gegner, den es gar nicht gibt.

Abb.: Derselbe Inhalt in zwei Ordnungen – links die Reihenfolge als Kontext, rechts die Map als Klammer über eigenständigen Bausteinen.

Woher kommt das Prinzip eigentlich? Aus der Beobachtung, dass Leser Dokumentation praktisch nie linear konsumieren – eine Erkenntnis, die deutlich älter ist als die heutigen Werkzeuge und die auch in der Leitnorm zum Erstellen von Nutzungsinformationen ihren Widerhall findet: Informationen sollen zielgruppen- und aufgabengerecht aufbereitet sein, nicht nach der inneren Logik des Produkts sortiert. Topic-basiertes Schreiben ist die konsequente Umsetzung dieses Gedankens auf der Ebene der Bausteine. Insofern ist es weniger eine technische Mode als die handwerkliche Antwort auf eine alte Einsicht – nur dass die heutigen Werkzeuge diese Antwort erstmals sauber unterstützen.

Die drei Topic-Typen

Wenn Inhalte in Bausteine zerfallen, stellt sich sofort die Frage: nach welcher Logik? Die Antwort ist erstaunlich schlicht und stammt aus der Beobachtung, wie Leser Dokumentation benutzen: Sie kommen mit einer von drei Fragen. „Wie mache ich das?" führt zur Aufgabe – dem Handlungs-Topic mit Voraussetzungen, nummerierten Schritten und Ergebnis. „Was ist das, und warum funktioniert es so?" führt zum Konzept – der Erklärung ohne Handlungsanweisung. Und „wie lautet der Wert?" führt zur Referenz – der Nachschlage-Information in Tabellen und gleichförmigen Listen.

Diese Dreiteilung ist mehr als eine Sortierhilfe – sie ist ein Schreibwerkzeug, und ihr Wert liegt in der Trennschärfe. Wer weiß, dass er gerade eine Aufgabe schreibt, hört auf zu erklären: Die Erklärung wandert ins Konzept-Topic und wird verlinkt. Das Ergebnis kennt jeder, der schon einmal eine gute Anleitung gelesen hat – kurze, klare Schritte ohne theoretische Vorreden. Umgekehrt darf das Konzept-Topic ausführlich erklären, ohne dass jemand ungeduldig nach Schritt eins sucht. Und die Referenz darf stumpf und gleichförmig sein, weil sie zum Finden da ist, nicht zum Lesen.

Ein Nebeneffekt der Dreiteilung ist wirtschaftlich hochinteressant: Gerade Konzept- und Referenz-Topics sind die stillen Wiederverwendungs-Champions. Das Funktionsprinzip einer Baugruppe erklärt man einmal und verwendet es in fünf Handbüchern; die technischen Daten liegen als ein Baustein vor, der in Handbuch, Datenblatt und Serviceunterlage erscheint. Die Aufgaben-Topics sind meist produktspezifischer – dafür sind sie die, nach denen am häufigsten gesucht wird. Wer die Typen sauber trennt, bekommt beides: kurze, findbare Anleitungen und mehrfach genutzte Erklärungen.

Was ist mit Inhalten, die in keine Schublade passen? Die ehrliche Antwort lautet meistens: Sie passen doch, man hat sie nur noch nicht zerlegt. Der berühmte Abschnitt, der „erklärt und gleichzeitig anleitet", ist in Wahrheit ein Konzept plus eine Aufgabe, die nie getrennt wurden. Es gibt Randfälle – ein Fehlerbehebungs-Abschnitt etwa, der Symptom, Ursache und Abhilfe kombiniert –, und dafür kennen die Standards spezialisierte Typen oder man definiert eine hauseigene Variante. Für den Einstieg gilt aber: Erst mit den drei Grundtypen arbeiten, bis man sicher ist, dass ein Sonderfall wirklich einer ist. Die meisten lösen sich beim zweiten Hinsehen auf.

Abb.: Drei Typen für drei Leserfragen – die Trennschärfe ist der eigentliche Gewinn, nicht die Etikettierung.

Granularität: die schwierigste Frage

Kommen wir zur Frage, die in jedem Einführungsworkshop die meiste Zeit frisst: Wie groß ist ein Topic? Die schlechte Nachricht zuerst – es gibt keine Seitenzahl als Antwort. Die gute: Es gibt einen brauchbaren Test, und er besteht aus zwei Fragen. Erstens: Kann dieses Topic für sich allein stehen – versteht es jemand, der direkt hier einsteigt? Zweitens: Würde es jemand einzeln brauchen – gibt es einen realistischen Fall, in dem genau dieser Baustein gesucht wird? Zweimal ja bedeutet richtig geschnitten. Ein Nein bei der ersten Frage heißt: zu fein, der Baustein ist ohne Nachbarn sinnlos. Ein Nein bei der zweiten: wahrscheinlich zu grob, es stecken mehrere Themen drin.

Die typischen Fehlschnitte liegen an beiden Enden. Zu grob ist der Klassiker beim Umstieg: Das alte Kapitel „Wartung" wird ein Topic – zwölf Seiten mit vier Aufgaben, zwei Erklärungen und einer Tabelle. Das ist außen ein Topic und innen ein Dokument; wiederverwendbar ist daran nichts, weil man nie das ganze Paket braucht, sondern immer nur eine der Aufgaben. Zu fein ist der Fehler der Übermotivierten: Jeder Handlungsschritt wird ein eigenes Topic, jeder Absatz ein Baustein. Nach drei Monaten liegen tausend Dateien herum, die einzeln sinnlos sind, und der Verwaltungsaufwand hat den Nutzen aufgefressen.

Als Orientierung aus der Praxis: Ein gut geschnittenes Topic umfasst meist eine bis drei Seiten und beantwortet genau eine Leserfrage. Passt die Antwort auf eine halbe Seite, ist das völlig in Ordnung; braucht sie acht, lohnt der prüfende Blick, ob nicht zwei Themen zusammengewachsen sind. Und eine praktische Faustregel für Umsteiger: Im Zweifel gröber anfangen. Zwei zu grobe Topics später zu teilen ist ein Handgriff; fünfzig zu feine Bausteine nachträglich zusammenzuführen und ihre Verweise zu reparieren ist ein Projekt.

Die richtige Größe hängt zusätzlich davon ab, wofür der Bestand gedacht ist – und das darf man bewusst entscheiden. Wer stark auf Wiederverwendung über Varianten zielt, schneidet tendenziell feiner, weil kleinere Bausteine flexibler kombinierbar sind. Wer vor allem gedruckte Handbücher mit Lesefluss produziert, schneidet gröber, weil zu viele Mini-Topics den Text zerhacken. Und wer Online-Hilfe und Suche im Blick hat, orientiert sich an der Frage, die jemand tippen würde – ein Suchtreffer soll eine vollständige Antwort liefern, nicht ein Fragment. Diese Zielabhängigkeit gehört ins Konventionsblatt, damit alle nach derselben Logik schneiden.

Abb.: Die Skala von zu grob bis zu fein – der Zwei-Fragen-Test trifft die Mitte zuverlässiger als jede Seitenzahl.

Wie sich das Schreiben ändert

Wer topic-basiert schreibt, gewöhnt sich ein paar Dinge ab und andere an. Abgewöhnt werden zuerst die Kontextverweise: „wie oben beschrieben", „im vorigen Kapitel", „nachdem Sie nun wissen, dass" – all das setzt eine Reihenfolge voraus, die es nicht mehr gibt. An ihre Stelle treten echte Verweise auf benannte Topics oder, wo der Inhalt kurz genug ist, die bewusste Wiederholung. Ebenfalls abgewöhnt: die schleichende Erklärung mitten in der Anleitung. Sie wandert ins Konzept-Topic, und die Anleitung wird dadurch besser, nicht ärmer.

Angewöhnt wird dafür die Sorgfalt beim Titel. Im Dokument ist eine Überschrift eine Zwischenmarke im Lesefluss; im Topic ist der Titel das Aushängeschild – er entscheidet, ob jemand den Baustein in der Suche findet, in der Map wiedererkennt und im Trefferverzeichnis anklickt. „Allgemeines" oder „Hinweise" sind im Dokument erträglich und im Topic tödlich. Gute Topic-Titel sagen, was drin ist, und sie folgen dem Typ: Aufgaben-Titel beschreiben die Handlung, Konzept-Titel den Gegenstand, Referenz-Titel die Datenart. Diese Disziplin allein verbessert die Auffindbarkeit mehr als jede Suchkonfiguration.

Und angewöhnt wird der Blick auf Eigenständigkeit. Vor dem Speichern lohnt die Kontrollfrage: Wenn jemand nur dieses Topic sieht – fehlt ihm etwas Wesentliches? Dabei geht es nicht darum, jedes Topic mit Vorreden aufzublähen, sondern um die Grundausstattung: ein aussagekräftiger Titel, die nötigen Voraussetzungen, die relevanten Sicherheitshinweise am Ort der Gefahr statt nur im Sammelkapitel, und Verweise dorthin, wo der Zusammenhang steht. Gerade der Sicherheitspunkt ist in der Maschinendoku mehr als Stil: Warnhinweise gehören dorthin, wo die Gefahr auftritt – und wenn ein Topic einzeln in einer Servicekarte landet, muss es sie mitbringen.

Auch der Sprachstil profitiert, und zwar messbar. Weil jedes Topic für sich stehen muss, verschwinden die weichen Übergangsformeln, mit denen Dokumente ihre Kapitel verbinden – und übrig bleibt die Sache selbst. Wer zusätzlich auf konsistente Terminologie achtet, bekommt einen doppelten Effekt: Der Leser findet dieselbe Benennung überall, und die Übersetzung erkennt Wiederholungen im Translation Memory, was direkt in der Rechnung des Dienstleisters sichtbar wird. Topic-Denken und Terminologiearbeit gehören deshalb zusammen; wer beides gleichzeitig angeht, verstärkt jeden Effekt des anderen. Das gilt übrigens auch für die Bildseite: Eine Abbildung, die nur im Zusammenhang des Nachbarkapitels verständlich ist, hat dasselbe Problem wie ein kontextabhängiger Text.

Ein letzter Punkt zum Denkwechsel, der viele überrascht: Topic-basiertes Schreiben macht Lücken sichtbar. Im Fließtext lässt sich mit einem geschickten Übergang überbrücken, dass eine Aufgabe nie vollständig beschrieben wurde – im eigenständigen Topic fällt das sofort auf, weil die Schrittfolge dort endet, wo das Wissen endete. Das ist unangenehm und wertvoll zugleich: Die Umstellung fördert regelmäßig Inhaltslücken zutage, die jahrelang niemandem aufgefallen sind. Wer damit rechnet, plant Zeit für inhaltliche Nacharbeit ein – und bekommt eine bessere Dokumentation, nicht nur eine anders sortierte.

Die Map: wo die Ordnung wohnt

Wenn Topics eigenständig sind, stellt sich die berechtigte Frage: Wer sorgt dann noch für Zusammenhang? Die Antwort ist die Map – und sie verdient mehr Aufmerksamkeit, als sie in Einführungen meist bekommt. Die Map ist die Klammer, die aus Bausteinen eine Publikation macht: Sie wählt aus, welche Topics enthalten sind, legt ihre Reihenfolge und Verschachtelung fest und liefert damit das, was im Dokument die Gliederung war. Der Unterschied ist entscheidend: Die Gliederung war Teil des Dokuments, die Map ist ein eigenes, austauschbares Artefakt. Dieselben Topics tragen so beliebig viele Publikationen – Handbuch, Kurzanleitung, Servicekarte, Variantenfassung –, ohne dass ein Inhalt doppelt existiert.

Praktisch heißt das, dass ein Teil der Redaktionsarbeit von der Textebene auf die Map-Ebene wandert. Eine neue Produktvariante zu dokumentieren, bedeutet dann nicht mehr, ein Handbuch zu kopieren und anzupassen, sondern eine neue Map zu bauen: bekannte Topics einhängen, die abweichenden neu schreiben, fertig. Das ist der Moment, in dem der ganze Aufwand sich auszahlt – und gleichzeitig der Moment, in dem Disziplin wichtig wird: Maps wollen genauso gepflegt sein wie Topics, mit klaren Namen und der Regel, dass Publikationsvarianten über Maps entstehen und nicht über kopierte Topics.

Und noch ein Gewinn steckt in dieser Trennung: Die Map macht Struktur sichtbar. Man sieht auf einen Blick, welche Aufgaben eine Publikation abdeckt, wo Erklärungen fehlen und welche Bausteine mehrfach genutzt werden. Wer aus der Dokumentwelt kommt, unterschätzt das leicht – dort ist die Struktur im Text vergraben. Auf der Map-Ebene wird sie zum Arbeitsgegenstand, über den man diskutieren, den man umstellen und dessen Lücken man erkennen kann, bevor ein Leser sie findet. Reviews mit Fachabteilungen laufen deshalb oft zuerst über die Map: Ist alles drin, stimmt die Reihenfolge, fehlt eine Aufgabe?

Die typischen Anfängerfehler

Jede Redaktion macht beim Umstieg dieselben sechs Fehler – die gute Nachricht ist, dass man sie kennt und damit vermeiden kann. Fehler eins sind die verwaisten Kontextverweise, die aus der Dokumentwelt mitwandern: „wie oben beschrieben" steht nach der Migration in vierzig Topics und zeigt nirgendwohin. Fehler zwei ist das Kapitel-Topic: Alte Gliederungspunkte werden eins zu eins zu Bausteinen – außen Topic, innen unverändert Dokument. Der Fix ist derselbe wie beim Schnitt: nach Leserfragen sortieren, nicht nach alter Gliederung.

Fehler drei ist die Typen-Vermischung: Die Aufgabe beginnt mit drei Absätzen Theorie, während der Leser Schritt eins sucht. Fehler vier sind nichtssagende Titel – der Klassiker „Allgemeines", der zuverlässig zum Sammelbecken für alles wird, was niemand einordnen wollte. Fehler fünf ist der Zerlegungsrausch mit seinen tausend Dateien. Und Fehler sechs, der subtilste: Wiederverwendung auf Verdacht. Da wird alles vorsorglich so gebaut, dass es überall passen könnte – mit dem Ergebnis, dass Texte blass und allgemein werden und ein Beziehungsgeflecht entsteht, das niemand mehr überblickt. Die Faustregel dagegen ist simpel: wiederverwendet wird, was zweimal gebraucht wurde, nicht was vielleicht irgendwann zweimal gebraucht werden könnte.

Wie erkennt man diese Fehler im laufenden Betrieb, bevor sie sich vervielfachen? Am zuverlässigsten mit einer kleinen Review-Routine für neue Topics in den ersten Monaten: zwei Minuten pro Baustein, drei Fragen – Steht der Typ fest und wird er eingehalten? Ist der Titel aussagekräftig? Funktioniert das Topic isoliert? Diese Prüfung durch eine zweite Person fängt die typischen Muster ab, solange der Bestand klein ist, und trainiert nebenbei das ganze Team. Nach etwa einem Vierteljahr sitzt die Denkweise, und die Routine kann auf Stichproben zurückgefahren werden.

Abb.: Sechs Fehler, die jede Redaktion beim Umstieg macht – wenn niemand vorher warnt.

Der Einstieg: üben ohne Werkzeug

Das Beste am topic-basierten Schreiben ist, dass man es üben kann, bevor irgendein System im Haus ist – und genau das ist der empfohlene Weg. Schritt eins ist die Analyse des Bestands mit dem Textmarker: zehn typische Seiten nehmen und markieren, welcher Abschnitt welche Leserfrage beantwortet – Aufgabe, Konzept, Referenz. Man sieht sofort, wo Typen vermischt sind, und hat die erste Version des eigenen Informationsmodells in der Hand.

Schritt zwei ist das Umschreiben eines einzelnen Kapitels nach Topic-Logik – noch in Word, noch ohne XML: Aufgaben herauslösen, Erklärungen in eigene Abschnitte, Referenzdaten in Tabellen, Kontextverweise auflösen, Titel schärfen. Der Aufwand liegt bei ein bis zwei Tagen, und das Ergebnis ist erstaunlich lehrreich: Meist stellt sich heraus, dass der Inhalt dabei kürzer wird, weil Redundanzen sichtbar werden, die im Fließtext niemandem auffielen. Schritt drei ist die Verabredung des Konventionsblatts – welche Typen, welche Granularitätsregel, welche Titelkonventionen –, und damit steht das Fundament für jeden späteren Werkzeug- oder Systemschritt.

Ein Wort zum Team, denn die Umstellung ist auch eine kulturelle. Erfahrene Autoren haben jahrelang gelernt, elegante Übergänge zu bauen und Spannungsbögen über Kapitel zu spannen – topic-basiertes Schreiben nimmt ihnen dieses Handwerk teilweise weg und fühlt sich anfangs kleinteilig an. Es hilft, den Gewinn früh sichtbar zu machen: die kürzere Anleitung, die einmal gepflegte Erklärung, die neue Variante ohne Kopierarbeit. Und es hilft, den Denkwechsel gemeinsam zu machen statt per Rundmail – ein halber Tag mit Textmarker und echten Bestandsseiten überzeugt zuverlässiger als jede Methodenschulung mit Beispielen aus fremden Branchen.

Für die Praxis heißt das auch: Nicht jeder Bestand muss vollständig umgeschrieben werden. Der pragmatische Weg ist die schrittweise Überarbeitung entlang der normalen Änderungszyklen – was ohnehin angefasst wird, wird dabei topic-gerecht geschnitten; was ruht, bleibt vorerst, wie es ist. Nach zwei bis drei Release-Runden ist der aktive Teil des Bestands umgestellt, ohne dass je ein Projekt aufgesetzt wurde. Das dauert länger als eine Migration am Stück, kostet dafür kaum Sonderaufwand – und für viele mittelständische Redaktionen ist genau das der einzige Weg, der neben dem Tagesgeschäft realistisch bleibt.

Fazit

Topic-basiertes Schreiben ist keine Technik, sondern eine Denkweise: Inhalte entstehen als eigenständige Bausteine zu genau einer Leserfrage, und der Zusammenhang kommt aus der Map statt aus der Reihenfolge. Drei Typen – Aufgabe, Konzept, Referenz – geben den Schnitt vor, der Zwei-Fragen-Test die Größe, und die sechs bekannten Anfängerfehler lassen sich vermeiden, wenn man sie kennt. Der Lohn sind kürzere, findbare Anleitungen, mehrfach genutzte Erklärungen und die Voraussetzung für alles, was danach kommt – von der Variantensteuerung bis zur Mehrkanal-Ausgabe. Und weil das Prinzip werkzeugunabhängig ist, ist es die einzige Investition in diesem Themenfeld, die garantiert nicht veraltet.

Der beste erste Schritt kostet einen Nachmittag und kein Budget: zehn Seiten, drei Textmarker, ein Kapitel umschreiben. Wer das getan hat, weiß mehr über die eigene Doku als nach jeder Werkzeug-Demo. Wenn du dabei Unterstützung willst – vom Modell-Workshop über Konventionen bis zur schrittweisen Umstellung des Bestands: Genau dabei unterstütze ich dich gern; die Details findest du auf der Beratungsseite zur Technischen Dokumentation.

Häufige Fragen zum topic-basierten Schreiben

Was genau ist ein Topic?

Ein eigenständiger Informationsbaustein zu genau einem Thema, der ohne Vorgänger und Nachfolger verständlich ist. Er beantwortet eine Leserfrage vollständig – „Wie tausche ich den Filter?", „Wie funktioniert die Absaugung?", „Welche Anschlusswerte gelten?" – und trägt alles Nötige dafür mit sich: aussagekräftiger Titel, Voraussetzungen, relevante Sicherheitshinweise. Die Reihenfolge und der größere Zusammenhang entstehen erst in der Map, die Topics auswählt und ordnet.

Welche Topic-Typen brauchen wir?

In der Technischen Dokumentation kommt man mit drei Typen weit: Aufgabe für Handlungen (Voraussetzungen, nummerierte Schritte, Ergebnis), Konzept für Erklärungen und Zusammenhänge, Referenz für Nachschlage-Informationen in Tabellen und Listen. Der Typ folgt aus der Leserfrage, nicht aus der Länge. Der eigentliche Gewinn ist die Trennschärfe: Wer eine Aufgabe schreibt, hört auf zu erklären – die Erklärung wandert ins Konzept-Topic und wird verlinkt.

Wie groß sollte ein Topic sein?

Es gibt keine gültige Seitenzahl, aber einen brauchbaren Test: Kann das Topic für sich allein stehen, und würde es jemand einzeln brauchen? Zweimal ja heißt richtig geschnitten. In der Praxis landen gut geschnittene Topics meist bei ein bis drei Seiten. Für Umsteiger gilt: im Zweifel gröber anfangen – zwei zu grobe Topics später zu teilen ist ein Handgriff, fünfzig zu feine zusammenzuführen ein Projekt.

Was passiert mit unseren Querverweisen?

Kontextverweise wie „wie oben beschrieben" oder „im vorigen Kapitel" funktionieren nicht mehr, weil es kein verlässliches Oben gibt – sie werden aufgelöst. An ihre Stelle treten echte Verweise auf benannte Topics oder, wo der Inhalt kurz ist, die bewusste Wiederholung. Bei der Migration ist das einer der wichtigsten Nacharbeitspunkte: Konvertierte Bestände sind voll von verwaisten Kontextverweisen, die im neuen Zusammenhang ins Leere zeigen.

Brauchen wir für Topics zwingend DITA?

Nein. Topic-basiertes Schreiben ist eine Denkweise und funktioniert werkzeugunabhängig – in DITA ebenso wie in Help-Authoring-Werkzeugen, die von Haus aus in Topics und Inhaltsverzeichnissen denken, und sogar als reine Schreibdisziplin in der Dokumentwelt. DITA fügt Standardisierung, maschinelle Prüfbarkeit und systematische Wiederverwendung hinzu; ob sich dieser Schritt lohnt, ist eine eigene Rechnung, die der Beitrag zur DITA-Frage im Mittelstand aufmacht. Das Denken in Topics lohnt sich in jedem Fall zuerst.