Denkmodelle für Technische Redakteure

Denken in ersten Prinzipien heißt, Komplexität auf ihre grundlegendsten Wahrheiten zurückzuführen, bevor Struktur, Formulierung oder Werkzeuge ins Gespräch kommen.

Technische Redakteure müssen fragen:

• Was ist an diesem Produkt, System, Prozess oder dieser Maschine tatsächlich wahr?
• Welche Annahmen übernehmen wir aus der Altdokumentation?
• Welche Aussagen beruhen auf Belegen, welche auf übernommener Gewohnheit?
• Was muss der Benutzer verstehen, bevor alles andere Sinn ergibt?
• Welche Unterscheidung ist grundlegend?
• Welche Information lässt sich aus diesem Fundament ableiten?

Denken in ersten Prinzipien schützt Dokumentation vor geerbter Verwirrung. Es verhindert, dass Technische Redakteure unklaren Input polieren, statt ihn zu hinterfragen.

Ein altes Handbuch kann viele richtige Sätze enthalten und trotzdem auf der falschen Struktur beruhen. Die Erklärung eines Fachexperten kann technisch korrekt sein und trotzdem das Prinzip überspringen, das Benutzer zuerst brauchen. Eine Handlungsanweisung kann Schritte beschreiben und trotzdem die Bedingung nicht erklären, die diesen Schritten ihren Sinn gibt.

Denken in ersten Prinzipien führt die Redakteurin zurück zur Grundebene: Was muss wahr sein, bevor diese Information klar strukturiert werden kann? Diese Frage ist so wirksam, weil Technische Dokumentation oft dann unklar wird, wenn Redakteure zu spät beginnen – mit vorhandenem Text, vorhandenen Kapiteln, vorhandenen Screenshots oder vorhandenen Vorlagen.

Professionelle Technische Redakteure verbessern nicht nur, was schon da ist. Sie erkennen die zugrunde liegende Logik.

Information Mapping heißt als Denkmodell, Komplexität in eine sichtbare Informationsstruktur zu verwandeln.

Technische Redakteure müssen fragen:

• Welche Art von Information ist das?
• Ist es ein Konzept, eine Handlung, eine Referenz, eine Warnung, eine Voraussetzung, eine Regel, eine Einschränkung oder ein Beispiel?
• Welche Information muss zuerst kommen?
• Welche Information unterstützt das Handeln?
• Welche Information unterstützt das Verstehen?
• Welche Information unterstützt Entscheidungen?
• Welche Information gehört zusammen?
• Welche Information muss getrennt werden?

Information Mapping macht Denken sichtbar. Es verhindert, dass Dokumentation zu einem Strom technisch richtiger, aber strukturell vermischter Information wird.

Ein Absatz kann gleichzeitig ein Konzept, eine Warnung, eine Voraussetzung, einen Schritt, einen Systemzustand und eine Ausnahme enthalten. Im Input von Fachexperten mag das normal sein, eine nutzbare Dokumentationsstruktur ist es nicht. Information Mapping hilft Technischen Redakteuren, diese Informationsarten zu trennen und dort zu platzieren, wo sie hingehören.

• Eine Warnung ist kein Konzept.
• Eine Voraussetzung ist kein Schritt.
• Eine Referenztabelle ist keine Handlung.
• Eine Einschränkung ist kein optionaler Hinweis.
• Ein Entscheidungskriterium ist keine Hintergrundinformation.

Wenn Technische Redakteure Information richtig zuordnen, schaffen sie die Architektur, die Benutzer brauchen, bevor sie einen einzigen Satz lesen.

Komponentendenken heißt, Information in sinnvolle Einheiten zu zerlegen, bevor das Schreiben beginnt.

Eine Technische Redakteurin muss fragen:

• Was ist die kleinste nützliche Informationseinheit?
• Welche Information gehört zusammen?
• Welche Information muss getrennt bleiben?
• Welche Inhalte sind wiederverwendbar?
• Welche Inhalte sind kontextspezifisch?
• Welche Information ist stabil, welche ändert sich?

Komponentendenken ist nicht nur in einem CCMS oder einer XML-Umgebung wichtig. Es zählt auch in einer einfachen Word-Datei oder einem SharePoint-Ordner. Ohne Komponentendenken wächst Dokumentation als langer Text. Mit Komponentendenken wird Dokumentation zu strukturierter Information.

Eine Komponente kann ein Konzept, eine Handlungsanweisung, eine Warnung, eine Referenztabelle, ein Eintrag zur Fehlersuche, ein Sicherheitshinweis, eine Parameterbeschreibung oder eine wiederverwendbare Erklärung sein.

Es geht nicht darum, Fragmente zu erzeugen. Es geht darum, Einheiten zu schaffen, die verstanden, gepflegt, wiederverwendet und richtig platziert werden können.

Systemdenken heißt, das Produkt oder die Maschine als verbundenes Ganzes zu verstehen. Technische Redakteure dürfen nicht nur Teile dokumentieren. Sie müssen Beziehungen verstehen.

Sie müssen fragen:

• Was gehört zum System?
• Was liegt außerhalb der Systemgrenze?
• Welche Komponenten wirken zusammen?
• Welche Schnittstellen sind wichtig?
• Welche Betriebsarten verändern das Systemverhalten?
• Welche Abhängigkeiten beeinflussen die sichere Verwendung?
• Welche äußeren Bedingungen beeinflussen den Betrieb?

Ohne Systemdenken wird Dokumentation zu einer Sammlung isolierter Fakten. Mit Systemdenken kann die Technische Redakteurin erklären, wie Teile, Funktionen, Benutzer, Zustände und Prozesse zusammenhängen.

Das ist besonders wichtig bei Maschinen, integrierten Systemen, softwaregesteuerten Produkten, modularen Plattformen und Produktionslinien.

Benutzer erleben das Produkt nicht als isolierte Informationsblöcke. Sie erleben es als System.

Aufgabendenken heißt zu verstehen, was der Benutzer tun muss und unter welchen Bedingungen.

Technische Redakteure müssen fragen:

• Welche Handlung muss ausgeführt werden?
• Wer führt sie aus?
• In welcher Betriebsart?
• Unter welchen Voraussetzungen?
• In welcher Reihenfolge?
• Woran zeigt sich, dass die Handlung erfolgreich war?
• Was kann schiefgehen?
• Welche Information wird vor der Handlung gebraucht?

Aufgabendenken verhindert, dass Dokumentation zur Funktionsbeschreibung wird. Eine Produktfunktion ist noch keine Aufgabe des Benutzers. Eine Funktion ist noch keine Handlungsanweisung. Ein Knopf ist noch keine Anweisung.

Eine Technische Redakteurin muss Produktverhalten in Benutzerhandlungen übersetzen – aber nur dort, wo tatsächlich eine Handlung angeleitet werden muss. Nicht jede Tätigkeit braucht eine Schritt-für-Schritt-Anleitung. Manche Information gehört in eine Referenztabelle, eine Beschreibung der Betriebsart, eine Konzepterklärung oder ein Sicherheitskapitel.

Das Aufgabenmodell hilft zu entscheiden, welche Kommunikationsform angemessen ist.

Risikodenken heißt zu verstehen, wo unklare Information unsicher werden kann.

Technische Redakteure ersetzen keine Risikobeurteilung. Sie erfinden keine Gefährdungen. Sie entscheiden nicht allein, welche Risiken verbleiben. Aber sie müssen Risikoinformation gut genug verstehen, um sie richtig zu dokumentieren. Sie müssen fragen:

• Welche Restrisiken verbleiben?
• Welche Fehlanwendung ist vernünftigerweise vorhersehbar?
• Welche Handlungen sind verboten?
• Welche Gefährdungen entstehen aus der Betriebsumgebung?
• Welche Warnung gehört direkt vor eine Handlung?
• Welche Sicherheitsinformation gehört ins Sicherheitskapitel?
• Welche Information muss eine Grenze oder Einschränkung festlegen?
• Welche Information darf nicht als Bedienoption normalisiert werden?

Risikodenken verbindet Dokumentation mit sicherer Verwendung. Es verhindert außerdem zwei häufige Fehler:

• alle Warnungen in einem allgemeinen Sicherheitskapitel zu sammeln, wo Benutzer sie im Moment der Handlung vielleicht nicht sehen
• Warnungen überall zu wiederholen, bis sie ihre Bedeutung verlieren

Präzise Platzierung von Warnungen hängt von präzisem Risikodenken ab.

Variantendenken heißt zu verstehen, was sich ändert und was stabil bleibt.

Technische Redakteure müssen fragen:

• Welche Information gilt für alle Varianten?
• Welche Information gilt nur für ein Produkt, eine Option, eine Kundenkonfiguration oder eine Betriebsart?
• Welche Unterschiede sind technisch?
• Welche Unterschiede betreffen das Vorgehen?
• Welche Unterschiede sind sicherheitsrelevant?
• Welche Inhalte können wiederverwendet werden?
• Welche Inhalte müssen getrennt werden?

Ohne Variantendenken verdoppelt sich Dokumentation und driftet auseinander. Mit Variantendenken können Technische Redakteure gemeinsame Information stabil halten und variable Inhalte isolieren.

Das ist wichtig bei Produktfamilien, modularen Maschinen, kundenspezifischen Konfigurationen, Softwareversionen, regionalen Anforderungen und verschiedenen Publikationskanälen.

Variantendenken ist nicht nur eine Werkzeugfunktion. Es ist eine Art, Veränderung zu sehen.

Metadatendenken heißt, Information Bedeutung zuzuweisen, damit sie gefunden, gefiltert, gepflegt, wiederverwendet und gesteuert werden kann.

Technische Redakteure müssen fragen:

• Welche Art von Information ist das?
• Wer ist die Zielgruppe?
• Für welches Produkt, welche Variante, Version oder Konfiguration gilt sie?
• Zu welchem Lebenszyklusstatus gehört sie?
• Ist sie sicherheitsrelevant?
• Ist sie wiederverwendbar?
• Gilt sie für alle Märkte?
• Welche Abhängigkeiten müssen nachverfolgt werden?

Metadaten sind keine Dekoration. Sie sind Information über Information.

Auch wenn es kein formales Metadatensystem gibt, brauchen Technische Redakteure Metadatendenken. Sie brauchen mentale Etiketten, die ihnen helfen zu verstehen, was ein Stück Information ist und wie es sich im gesamten Dokumentationsbestand verhalten soll.

Denken in Publikationslogik heißt zu verstehen, wie Information zu einem stimmigen Liefergegenstand wird.

Technische Redakteure müssen fragen:

• Welche Information gehört in welches Ergebnis?
• Welche Reihenfolge unterstützt das Verstehen?
• Welche Inhalte müssen zusammen erscheinen?
• Welche Abhängigkeiten sind wichtig?
• Welche Varianten müssen aufgenommen oder ausgeschlossen werden?
• Welcher Kanal verändert die Struktur?
• Welche Information gehört in das Handbuch, die Online-Hilfe, die Kurzanleitung, das Sicherheitskapitel, die Servicedokumentation oder das Schulungsmaterial?

Publizieren ist nicht nur Exportieren. Es ist die Logik, Information zu einer nutzbaren Form zusammenzusetzen. Ein Dokumentationsbestand kann richtige Topics enthalten und trotzdem scheitern, wenn die Publikationslogik schwach ist.

Der Benutzer nutzt keine isolierten Inhaltsmodule. Der Benutzer nutzt das Ergebnis.

Klarheitsdenken heißt, Komplexität in verständliche Information zu verwandeln, ohne sie ungenau zu machen.

Technische Redakteure müssen fragen:

• Was muss der Benutzer zuerst verstehen?
• Welche Begriffe müssen einheitlich sein?
• Welche Unterscheidungen müssen sichtbar bleiben?
• Welche Information kann vereinfacht werden?
• Welche Information darf nicht vereinfacht werden?
• Welche Reihenfolge unterstützt das Verstehen?
• Welche Formulierung verhindert Mehrdeutigkeit?
• Welche Struktur verringert die kognitive Last?

Klarheit ist keine Kosmetik. Klarheit ist das Ergebnis richtigen Denkens.

• Ein Satz kann grammatisch richtig und trotzdem unklar sein.
• Eine Handlungsanweisung kann vollständig und trotzdem verwirrend sein.
• Eine Warnung kann formal korrekt und trotzdem schlecht platziert sein.

Klarheitsdenken bringt Struktur, Formulierung, Reihenfolge und den Blick auf den Benutzer zusammen.