Martina Hartmann

Die meistgelesene Seite der Dokumentation ist entweder die beste oder die kaputteste. Die Zahl sagt nicht, welche von beidem.

🔎 In der Praxis

Eine Folie im Jahresbericht: Aufrufe der Dokumentation, deutlich über Vorjahr. Alle nicken, die Folie ist durch. Woher der Anstieg kommt, steht nirgends — ob mehr Leute die Seiten hilfreich fanden, oder ob im Frühjahr eine Funktion umgebaut wurde und seitdem alle nachschlagen müssen, wie sie jetzt geht.

💡 Die Logik dahinter

Aufrufe sind leicht zu erheben, deshalb sind sie überall. Sie zählen Zugriffe, keine Ergebnisse. Eine Seite wird geöffnet, weil jemand etwas nicht weiß. Ob die Person es danach weiß, steht in keiner dieser Zahlen. Zuverlässig zeigen steigende Aufrufe genau eins an: dass mehr Leute eine Frage hatten.

⚠️ Der blinde Fleck

Der Fehler passiert vor der Messung. Wer Aufrufe zählt, hat entschieden, dass Lesen der Zweck der Dokumentation ist. Der Zweck ist aber, dass jemand weiterkommt. Eine Seite, die in zwanzig Sekunden erledigt, wofür sie geöffnet wurde, hat ihre Sache getan — und erzeugt dabei die kurze Verweildauer, die im Bericht als schwaches Ergebnis steht.

🔄 Der Perspektivwechsel

Solange niemand ausspricht, wofür die Dokumentation zuständig ist, beantwortet das Auswertungswerkzeug die Frage. Es kennt nur eine Größe: Zugriffe. Wer Dokumentation mit Aufrufzahlen verteidigt, übernimmt diese Antwort — und liefert das Argument gleich mit, mit dem später gekürzt wird. Denn dieselbe Zahl fällt auch, wenn die Arbeit wirkt.

„Die Doku fehlt noch." Der Satz steht seit drei Wochen im Ticket. Geschrieben wäre sie an einem Vormittag.

Warum liegt sie trotzdem? Drei Kräfte arbeiten vor dem ersten Satz. Keine davon ist Zeitmangel.

Die erste: Es gibt noch nichts zu beschreiben. Die Funktion läuft, die Entscheidungen darüber stehen aus — ob das Feld verpflichtend bleibt, ob der alte Weg weiter funktioniert, wie die Sache am Ende heißt. Wer das aufschreibt, bevor es entschieden ist, schreibt es zweimal. Also wird gewartet, und Warten sieht von außen aus wie Untätigkeit.

Die zweite: Das Wissen liegt verteilt. Die Entwicklung kennt das Verhalten, der Support die Fälle, das Produktmanagement den Grund. Jede Auskunft für sich stimmt, zusammen ergeben sie kein Bild. Die Arbeit besteht darin, die Widersprüche zu finden und aufzulösen — und dafür braucht es genau die Leute, deren Kalender voll ist.

Die dritte: Was schon dasteht, stimmt nicht mehr. Im Ticket steht der Stand aus der Planung, im Konzept der von davor, im Wiki einer aus dem letzten Jahr. Bevor irgendetwas Neues entsteht, muss jemand prüfen, was davon noch gilt. Von außen sieht das aus wie Lesen. Es ist die eigentliche Recherche.

Unentschieden, verteilt, veraltet. Drei Gründe, warum eine Doku liegen bleibt — und in keinem davon kommt das Schreiben vor.

Schreiben ist der einzige Teil dieser Arbeit, der sich planen lässt. Deshalb steht er im Plan. Und alles, was länger dauert, steht nirgends.

Ein Large Language Model (LLM) klingt bei falschen Antworten genauso sicher wie bei richtigen. Das macht es nicht für alle gleich nützlich.

🔎 In der Praxis

Ein LLM beschreibt, wie eine Funktion im eigenen Projekt arbeitet. Klingt stimmig, ist falsch. Auf Nachfrage kommt eine zweite Fassung, dann eine dritte — jede so ruhig vorgetragen wie die erste. Aufgefallen ist der Fehler nur, weil die Antwort eine Stelle traf, die jemand ohnehin kannte.

💡 Die Logik dahinter

Ein LLM erzeugt Plausibilität, nicht Richtigkeit. Der sichere Ton schwankt nicht mit der Faktenlage, er ist immer da. Im Text selbst steht also nichts, was die falsche Stelle markiert. Das Signal muss von außen kommen: aus dem, was die lesende Person über die Sache schon weiß.

⚠️ Der blinde Fleck

Diese Werkzeuge gelten als große Gleichmacher — jetzt könnten alle alles. Gesenkt haben sie aber nur die Hürde fürs Erzeugen, nicht die fürs Prüfen. Wer eine Sache beherrscht, sieht sofort, wo die Ausgabe kippt. Wer sie nicht beherrscht, sieht dieselbe glatte Oberfläche und nichts, woran sich ein Fehler zeigen würde.

🔄 Der Perspektivwechsel

Damit steht das Versprechen auf dem Kopf. Am meisten nützen diese Werkzeuge denen, die ohnehin urteilen können — am wenigsten denen, für die sie angeblich gebaut sind. Wer ein LLM in einem Feld einsetzt, in dem die eigene Urteilsfähigkeit fehlt, spart keine Zeit. Sondern geht ein Risiko ein, das sich von innen nicht zeigt.

„Das steht doch in der Doku."

Stimmt. Nur ist der Text, an dem jemand hängen bleibt, nicht die Doku. Es ist der Satz im Dialogfenster — und der wird häufiger gelesen als jedes Kapitel des Handbuchs.

Die Redaktion endet trotzdem am Rand der Dokumentation. Was im Produkt selbst steht, entsteht nebenbei: in der Entwicklung, im Design, manchmal erst im Übersetzungstool.

• ❌ „Vorgang konnte nicht abgeschlossen werden."
• ❌ „Keine Einträge vorhanden."
• ❌ „Wirklich löschen?" — darunter „OK" und „Abbrechen".

Drei Sätze, an denen sprachlich nichts auffällt. Und die zusammen mehr Leute erreichen als das ganze Handbuch.

• ✅ „Der Upload ist abgebrochen: Die Datei ist größer als 20 MB. Teile sie auf oder verkleinere sie."
• ✅ „Hier erscheinen Deine Berichte. Leg mit ‚Neuer Bericht’ den ersten an."
• ✅ „Der Ordner und die 14 Dateien darin werden gelöscht. Das lässt sich nicht rückgängig machen." — darunter „Löschen" und „Abbrechen".

Solche Sätze entstehen nicht, weil jemand sorgfältiger war. Sie entstehen, weil jemand zuständig war.

Für das Handbuch gibt es eine Redaktion, eine Terminologie, eine Freigabe. Für die Sätze im Produkt nichts davon — nicht weil sie weniger wichtig wären, sondern weil das Handbuch im Redaktionssystem liegt und der Rest im Code.

Wer diese Sätze schreibt, schreibt Dokumentation — ob das in der Rollenbeschreibung steht oder nicht.

„Die merken gar nicht, was wir alles verbessern."

Doch, sie schauen nach. Release Notes sind der einzige Text aus der Dokumentation, den jemand freiwillig aufschlägt — ein Handbuch liest niemand aus Neugier, aber wenn sich etwas ändert, will man wissen, was.

• ❌ „Diverse Fehlerbehebungen und Verbesserungen."
• ❌ „Performance-Optimierungen und kleinere Anpassungen."
• ❌ „Version 4.2.1: Stabilität erhöht."

Drei Sätze, die dasselbe leisten: Sie bestätigen, dass jemand gearbeitet hat.

• ✅ „Der CSV-Export bricht bei Umlauten nicht mehr ab. Wer bisher von Hand nachgebessert hat, kann sich das sparen."
• ✅ „Die Suche findet jetzt auch Wortteile. Deine gespeicherten Suchen funktionieren unverändert weiter."
• ✅ „Die Anmeldung über den alten Link endet am 1. Oktober. Leg Dir den neuen als Lesezeichen an."

Hinter jeder dieser Zeilen steckt dieselbe Arbeit wie hinter den drei davor. Nur kommt sie an.

Wochen Entwicklung, und dann entscheidet ein Satz, ob überhaupt jemand davon erfährt. Geschrieben wird er meistens zuletzt, von der Person mit der wenigsten Zeit.

Niemand muss raten, was besser geworden ist. Es muss nur jemand aufschreiben, was sich geändert hat — und was das für die User heißt.

💬 „Moment. Das haben wir doch auch."

Konferenztag. Heute Write the Docs Berlin, remote. In einem Vortrag erzählt jemand von der eigenen Arbeit, beiläufig, als wäre nichts dabei. Und mitten im Zuhören kippt etwas: Die Sache, die dort als gelöst beschrieben wird, gibt es im eigenen Alltag längst. Nur nie als Problem geführt. Sie lief unter Aufwand. Unter „ist halt so".

Das ist der Ertrag, um den es eigentlich geht. Nicht neues Wissen — die Entdeckung, dass etwas, das man für gegeben hielt, nicht gegeben ist.

Von innen kommt man da nicht drauf. Wer jeden Tag dieselben Aufgaben löst, wird darin sicher, und was sicher ist, schaut man nicht mehr an. Der Blick verengt sich nicht durch Nachlässigkeit. Er verengt sich durch Routine.

Und genau deshalb reicht Zuschalten nicht. Was den Blick verschiebt, steht in keinem Programm. Es kommt in einem Nebensatz, in einer Antwort auf eine fremde Frage, in drei Zeilen im Chat. Wer nebenher das Postfach bedient, ist eingewählt, aber nicht dabei.

Der Satz, der etwas verändert, ist nie der lauteste. Man muss da sein, wenn er fällt.

Die Regel, die nur im Kopf steht

„Meinst Du nicht, Du übertreibst es ein bisschen?" — das ist der Satz, den ich einem Sprachmodell am häufigsten schreibe.

🔎 In der Praxis

Ich habe 22 Arbeitssitzungen mit einem Modell auswerten lassen. Das häufigste Reibungsmuster war nicht, dass zu wenig kam. Es war zu viel: aufgeblähte Beschreibungen, Abschnitte, die niemand angefordert hatte, Änderungen an Dateien, um die es nie ging. Die beiden Spitzenreiter hießen falscher Ansatz und zu viele Änderungen.

💡 Die Logik dahinter

Ein Modell kennt kein Maß. Es kennt keine Vorgeschichte, keine Hausregel, keinen Umfang, der irgendwo als angemessen gilt. Es liefert, was plausibel wirkt — und plausibel ist im Zweifel mehr. Wer nichts über Grenzen sagt, bekommt keine.

⚠️ Der blinde Fleck

Einzeln sieht keine dieser Korrekturen nach einem Muster aus. Ein Absatz zu lang, ein Abschnitt zu viel, eine Datei angefasst, um die es nicht ging — jedes Mal klein, jedes Mal berechtigt, jedes Mal in zwei Minuten erledigt. Dass es immer wieder dieselben sind, fällt erst auf, wenn jemand mitzählt.

🔄 Der Perspektivwechsel

In der Auswertung stand ein Satz über mich, nicht über das Werkzeug: Meine Erwartungen an Umfang und Stil lägen in meinem Kopf und kämen erst als Korrektur heraus. Damit ist die wiederkehrende Korrektur kein Nacharbeiten, sondern ein Befund über eine fehlende Regel. Bessere Ergebnisse kommen nicht von besseren Fragen, sondern davon, dass man aufschreibt, was man ohnehin jedes Mal verlangt.

„Vor dem Update sollte ein Backup angelegt werden." Wer das schreibt, weiß meistens genau, was passiert, wenn man es nicht tut. Im Satz steht es nicht.

Modalverben verschieben eine Entscheidung. Aus einer Anweisung wird eine Empfehlung, aus einer Folge eine Andeutung. Die User sollen abwägen — bekommen aber nicht, was sie zum Abwägen brauchen.

• ❌ „Das Feld sollte ausgefüllt werden."
• ❌ „Der Dienst kann anschließend neu gestartet werden."
• ❌ „Die Konfiguration müsste angepasst werden."

Drei Sätze, drei offene Fragen: Was passiert sonst? Wozu das Ganze? Und wann gilt es für mich?

• ✅ „Füllen Sie das Feld aus. Ohne Eintrag bricht der Import ab."
• ✅ „Starten Sie den Dienst neu, damit die neue Konfiguration greift."
• ✅ „Passen Sie die Konfiguration an, wenn Sie einen eigenen Port verwenden."

Der Unterschied ist nicht Höflichkeit. „Sollte" klingt weicher, lässt die User aber allein. Der klare Satz nimmt ihnen nichts weg — er liefert nach, was offengeblieben war: die Folge, den Zweck, die Bedingung. Und er kommt ohne Modalverb aus.

Kann, sollte, müsste — drei Wörter, die offenlassen, ob überhaupt etwas zu tun ist. Wer es weiß, braucht keins davon.

Dokumentation bekommt fast nie Feedback. Außer im Ticketsystem — und dort wird es als Support-Aufwand verbucht.

🔎 In der Praxis

Eine Frage landet im Support: Wo stelle ich das ein? Die Antwort steht in der Doku, Abschnitt soundso. Der Support antwortet freundlich, verlinkt die Stelle, Ticket geschlossen, alle zufrieden. Drei Monate später dieselbe Frage von jemand anderem. Und wieder. Jedes Mal gilt der Vorgang als erledigt.

💡 Die Logik dahinter

Ein Ticket ist gelöst, wenn die fragende Person eine Antwort hat. Das ist die richtige Metrik für den Support — und die falsche für die Dokumentation. Gemessen wird die Antwort, nicht der Grund für die Frage. Wer Tickets als Aufwand zählt statt als Befund zu lesen, schließt mit jedem Ticket auch den Hinweis darauf, warum es entstanden ist.

⚠️ Der blinde Fleck

„Es steht doch alles in der Doku." Das stimmt meistens sogar. Es ist trotzdem kein Gegenargument, sondern das Ergebnis: Was User nicht finden, ist vorhanden, aber nicht verfügbar. Eine Frage, die trotz vorhandener Doku im Support landet, ist kein Lesefehler. Sie ist ein Befund über Benennung, Einstieg und Auffindbarkeit.

🔄 Der Perspektivwechsel

Niemand schreibt der Redaktion, dass Kapitel 4 unklar war. Rückmeldung entsteht fast nur dort, wo User nicht weiterkommen und deshalb fragen. Wiederkehrende Tickets sind damit das einzige belastbare Qualitätssignal, das Dokumentation bekommt — vorausgesetzt, jemand liest sie als solches. Sonst zahlt die Organisation zweimal: für das Schreiben der Doku und dauerhaft dafür, dass sie nicht ankommt.

„Das steht so nirgends." Doch. In Deiner Doku, in einem Abschnitt, den seit vier Jahren niemand mehr geöffnet hat. Der Assistent hat ihn gefunden.

Frage-Antwort-Systeme lesen kein Dokument. Sie durchsuchen einen Index über den gesamten Bestand, holen die Passagen, die dazu passen, und legen sie dem Sprachmodell nebeneinander. Sortiert wird nach Ähnlichkeit zur Frage. Nicht nach Gültigkeit.

Damit ändert sich, was ein überholter Satz anrichtet:

• ❌ „Die Zeitüberschreitung liegt standardmäßig bei 30 Sekunden."
• ❌ „Die Einstellung finden Sie unter Extras > Optionen."
• ❌ „Der Export erzeugt eine CSV-Datei."

Drei Sätze, die einmal gestimmt haben. Keiner sagt, wann.

• ✅ „Bis Version 4 lag die Zeitüberschreitung bei 30 Sekunden, seit Version 5 bei 120."
• ✅ „Seit dem Oberflächenwechsel liegt die Einstellung unter System > Erweitert."
• ✅ „Der Export erzeugt seit Version 5 eine JSON-Datei, davor eine CSV-Datei."

Früher war so ein Satz tote Last. Er lag in einem Dokument, das niemand mehr aufschlug — und wer doch darin landete, sah den Titel darüber, die Version im Kopf, das Datum in der Fußzeile. Genau das fällt weg. Der Treffer kommt ohne Seite, ohne Kopf, ohne Fußzeile. Übrig bleibt der Satz. Sonst nichts.

Veraltete Dokumentation war harmlos, solange sie jemand hätte aufschlagen müssen. Gelesen wird sie immer noch nicht. Zitiert schon. Ein Satz, der nicht sagt, wann er gilt, gilt für immer.

Barrierefreiheit prüft Sprache mit. Nur hört sie genau da auf, wo der Fließtext anfängt.

🔎 In der Praxis

Eine Prüfung auf Barrierefreiheit nimmt auch Texte auseinander: Überschriften müssen ihren Abschnitt beschreiben, Linktexte ihr Ziel, Beschriftungen ihr Formularfeld, Fehlermeldungen einen Weg aus dem Fehler. Alles verbindlich. Alles Sprachentscheidungen.

💡 Die Logik dahinter

Geprüft wird, ob sich etwas benutzen lässt. Überschriften, Linktexte, Beschriftungen sind Bedienelemente, die aus Wörtern bestehen. Sie sagen, wo es langgeht. Der Fließtext sagt, worum es geht. Kriterien hat er auch: Erklärungen für Fachbegriffe, Auflösungen für Abkürzungen, eine verständlichere Fassung bei schwer lesbaren Texten. Verbindlich sind sie nicht.

⚠️ Der blinde Fleck

Die Prüfung ist bestanden, der Text gilt als in Ordnung. Also lass Dir einen Schachtelsatz vorlesen. Nicht lesen — vorlesen. Kein Überfliegen, kein Sprung zurück zum Bezugswort, keine zweite Runde. Beim dritten Einschub hältst Du zwei Halbsätze im Kopf und wartest auf das Verb. Es kommt auch. Nur weißt Du da schon nicht mehr, wozu es gehört.

🔄 Der Perspektivwechsel

Beim Hören ist der Satz nicht schwerer geworden. Er war immer so. Beim Lesen gleicht man ihn aus: zurückspringen, überfliegen, den Bezug nachsehen. Diese Arbeit passiert nebenbei und fällt deshalb niemandem auf. Das Auge repariert den Satz. Das Ohr bekommt ihn, wie er geschrieben wurde. Der Maßstab ist damit nicht, ob ein Text die Prüfung besteht — sondern ob ein Satz beim ersten Hören verstanden wird.

Am Ende gibt es ein Foto. Eine Wand voller Zettel, Menschen, die etwas bewegt haben. Zwei Wochen später weiß niemand mehr, was auf den Zetteln stand. Das Foto gibt es noch. Und damit den Beweis, dass etwas passiert ist.

Warum halten Organisationen an Dingen fest, die nichts verändern? Drei Kräfte halten das am Laufen. Keine davon ist böser Wille.

Die erste: Was sich zählen lässt, zählt. Ein Workshop hat ein Datum, eine Anwesenheitsliste, ein Foto. Ob sich danach etwas verändert hat — dafür gibt es kein Formular.

Die zweite: Mitmachen kostet weniger als Hinterfragen. Wer fragt, ob der Teamtag etwas bringt, stellt die Arbeit anderer in Frage. Also gehen alle mit — nicht aus Überzeugung, sondern weil niemand die Person sein will, die fragt.

Die dritte: Wer plant, organisiert und durchführt, fühlt danach, etwas bewegt zu haben. Die investierte Energie fühlt sich an wie Wirkung. Und wer Wirkung spürt, sucht keinen Beweis, dass sie fehlt.

Nachweisbar, reibungslos, selbstbestätigend. Der Workshop ersetzt die Zusammenarbeit. Der Teamtag ersetzt das Team. Die Feedbackrunde ersetzt das Feedback.

Deshalb ändert sich nichts. Nicht weil niemand es sieht. Sondern weil der Satz, der helfen würde, der ist, den niemand als Erstes sagen will: Das hat nichts gebracht.

Mehrdeutige Sätze sind selten falsch. Sie sind nur zu wenig festgelegt.

Das ist kein Schönheitsfehler. Ein Satz, der zwei Lesarten zulässt, trifft die Entscheidung nicht — er reicht sie weiter. Die User treffen sie dann selbst: nebenbei, ohne zu merken, dass es eine war, und nicht alle gleich.

Sichtbar wird das später nie als Dokumentationsfehler. Es taucht auf als Bedienfehler, als Rückfrage, als Ticket. Der Satz bleibt dabei unverdächtig — er stimmt ja.

Die Frage beim Gegenlesen ist deshalb nicht, ob ein Satz verstanden werden kann. Sondern ob er missverstanden werden kann.

💬 „Bei Schritt vier stimmt was nicht."

Die Anleitung kommt fertig aus dem Modell. Sauber gegliedert, plausibel, in ganzen Sätzen. Der übliche nächste Griff: redigieren. Begriffe vereinheitlichen, zwei Sätze straffen, den Ton anpassen. Danach sieht der Text gut aus.

Es geht auch anders. Produkt auf, Anleitung daneben, und genau das tun, was dort steht. Nichts ergänzen, nichts stillschweigend geraderücken. Und dann zeigt sich, dass Schritt vier auf einem Ergebnis aufbaut, das Schritt drei so gar nicht liefert. Beim Lesen fällt das nicht auf. Beim Tun sofort.

Das ist der Unterschied zwischen Redigieren und Nachvollziehen. Redigiert wird der Text. Nachvollzogen wird die Sache.

Am eigenen Entwurf funktioniert das nicht. Wer eine Anleitung selbst formuliert hat, liest beim Gegenlesen nicht, was dasteht, sondern was gemeint war. Die Lücke zwischen Schritt drei und Schritt vier ist im Kopf längst gefüllt, bevor das Auge sie erreicht. Das ist keine Nachlässigkeit. Das ist nicht abstellbar.

Ein Text aus dem Modell hat diese Eigenschaft nicht. Er stammt nicht aus dem eigenen Kopf, also lässt er sich lesen wie der von jemand anderem: beim ersten Mal, ohne die stille Ergänzung. In dieser Position sitzen sonst nur die User.

Und wer eine Anleitung tatsächlich durchspielt, prüft am Ende nicht nur den Text, sondern das, was er beschreibt. Manches, was dabei auffällt, ist gar kein Dokumentationsproblem.

Der Entwurf aus dem Modell spart nicht die Arbeit des Schreibens. Er liefert etwas, das man sich selbst nicht verschaffen kann: einen Text über die eigene Sache, den man zum ersten Mal liest.

i18n, k8s, a11y – wer das liest, versteht es sofort. Oder gar nicht.

Numeronyme ersetzen Buchstaben durch Zahlen: i18n steht für internationalization – i, dann 18 Buchstaben, dann n. Effizient für alle, die den Code kennen. Für den Rest sieht es aus wie ein Tippfehler.

In technischen Texten begegnet man ihnen ständig:

• ❌ “Die a11y-Anforderungen müssen erfüllt sein.”
• ❌ “Für i18n nutzen Sie das Config-Modul.”
• ❌ “Das k8s-Cluster muss neu gestartet werden.”

Korrekt – aber nur für Eingeweihte.

Eine kurze Auflösung reicht:

• ✅ “Die Anforderungen an Barrierefreiheit (a11y) müssen erfüllt sein.”
• ✅ “Für die Internationalisierung (i18n) nutzen Sie das Config-Modul.”
• ✅ “Das Kubernetes-Cluster (k8s) muss neu gestartet werden.”

Drei Wörter mehr. Eine Hürde weniger.

Dokumentation, die nur Eingeweihte verstehen, dokumentiert nicht – sie sortiert aus.

Drei Varianten, zwei Bedingungen, eine Ausnahme — in einem einzigen Satz. Das Problem ist nicht die Grammatik. Das Problem ist die Form.

Hinter manchen Sätzen steckt eine Struktur: Varianten, die sich unterscheiden. Bedingungen, die sich ausschließen. Eigenschaften, die zusammengehören. Wer das in Fließtext presst, versteckt genau das, was User sehen müssen.

• ❌ „Standard umfasst die Basisfunktionen, Professional bietet zusätzlich Reporting und Teamverwaltung, Enterprise enthält den vollen Funktionsumfang ab 50 Personen."
• ❌ „Die Synchronisation erfolgt automatisch bei bestehender Verbindung und aktivierter Option, andernfalls manuell, es sei denn, ein Admin hat sie deaktiviert."
• ❌ „Der Export unterstützt CSV mit Sonderzeichen, PDF mit Formatierung aber ohne Links sowie XLSX mit allen Daten einschließlich Formeln."

Jeder dieser Sätze ist eine Tabelle, die sich als Absatz verkleidet hat.

• ✅ Vergleiche gehören in eine Tabelle.
• ✅ Verzweigungen gehören in eine Liste.
• ✅ Fließtext ist für das, was sich nicht zerlegen lässt.

Der Inhalt bleibt gleich. Der Unterschied ist, ob User die Struktur suchen müssen — oder ob sie sie sehen.

Nicht jede Information gehört in einen Satz. Manche wird erst lesbar, wenn sie aus dem Satz befreit wird.

Als Kind konntest Du es. „Das will ich nicht." Kein Wort zu viel, kein Zweifel, was gemeint war.

Heute sitzen erwachsene Menschen an einem einzigen Satz und bekommen ihn nicht eindeutig. Warum? Drei Kräfte arbeiten gegen die Klarheit. Keine davon ist Faulheit.

Die erste: Uns wurde etwas anderes beigebracht — und die Klarheit von früher nebenbei aberzogen. In der Schule zählt, wer ausführlich schreibt und abwägt. Im Beruf, wer diplomatisch bleibt. In beiden Welten wirkt ein kurzer, klarer Satz zu simpel. Wir lernen, richtig zu klingen. Nicht, verstanden zu werden.

Die zweite: Klarheit macht angreifbar. Wer sich festlegt, kann falsch liegen. Eine offene Formulierung lässt jeden Ausgang zu und niemanden nachträglich im Regen stehen. Das ist selten Berechnung. Öfter ist es Schutz — für die schreibende Person, nicht für die Lesenden.

Die dritte: Wer schreibt, kennt die Antwort schon. Deshalb sieht niemand die Lücke im eigenen Text — sie ist ja nur für die anderen da. Was im Kopf vollständig ist, steht auf dem Papier nur zur Hälfte, und wer den Rest ohnehin weiß, sieht die fehlende Hälfte nicht.

Aberzogen, riskant, unsichtbar. Drei Richtungen, ein Ergebnis: Unklarheit ist der bequemere Zustand. Sie kostet nichts und fällt nicht auf.

Klar zu sein ist deshalb keine Frage von Talent. Sondern die Entscheidung, sich gegen alle drei zu stellen.

Die meisten Anleitungen beginnen bei Schritt 2. Schritt 1 hat die Person, die sie geschrieben hat, längst hinter sich — und vergessen, dass es ihn gibt.

Wer eine Anleitung schreibt, sitzt schon am richtigen Ort. Eingeloggt, im richtigen Bereich, mit den passenden Rechten, die richtige Ansicht offen. Von dort aus fühlt sich „Klick auf …" wie der Anfang an. Für alle, die nicht dort sitzen, ist es die Mitte.

So sieht ein Anfang aus, der keiner ist:

• ❌ „Öffne im Adminbereich die Einstellungen." — Wie komme ich in den Adminbereich? Bin ich dafür überhaupt berechtigt?
• ❌ „Füge die Regel wie gewohnt hinzu." — „Wie gewohnt" gilt nur für die, die es schon mal gemacht haben.
• ❌ „Wähle oben rechts Dein Projekt." — In welchem Fenster, welcher Ansicht? Vorausgesetzt: Du bist längst da.

So sieht der Schritt davor aus:

• ✅ „Diese Anleitung startet nach dem Login auf der Übersichtsseite. Bist Du woanders, klick oben links aufs Logo."
• ✅ „Voraussetzung: ein Konto mit Adminrechten. Ohne die endet es bei Schritt 3."
• ✅ „Melde Dich an. Oben rechts, unter Deinem Namen, findest Du ‚Verwaltung’. Dort geht es los."

Der Schritt, der am häufigsten fehlt, ist der, den niemand mehr als Schritt wahrnimmt: an die Startlinie zu kommen. Nicht weil er schwer wäre — sondern weil er für die schreibende Person unsichtbar geworden ist. Wo Erfahrung anfängt, ist nicht, wo die User anfangen.

Eine Anleitung, die bei Schritt 2 beginnt, ist keine Anleitung. Sie ist eine Erinnerung — für alle, die es schon können.

Deine Doku gibt gerade Auskunft — in Worten, die nicht Deine sind, an jemanden, den Du nie direkt erreichst. Und sie tut es in Deinem Namen.

🔎 In der Praxis

Jemand fragt einen KI-Assistenten: „Wie richte ich X ein?" Die Antwort kommt sofort — glatt, konkret, in ganzen Sätzen. Sie klingt sicher. Sie ist falsch. Nicht erfunden: Sie stammt Wort für Wort aus einer Stelle Deiner Doku, die zwei Deutungen zuließ. Die Person befolgt sie, es geht schief — und gibt dem Produkt die Schuld. Deinen Text hat sie nie gesehen.

💡 Die Logik dahinter

Früher hat ein Mensch Doku gelesen und selbst interpretiert: mit Kontext, mit Vorsicht, mit einer Nachfrage, wenn etwas unklar war. Ein Assistent fragt nicht nach. Er glättet. Aus „in der Regel", „sollte" und „gegebenenfalls" wird eine klare Anweisung. Deine Absicherungen verschwinden. Deine Unschärfe bleibt — und bekommt die Stimme eines Beraters, der nie zögert.

⚠️ Der blinde Fleck

Wir schreiben Doku noch für User, die mitdenken, zurückblättern, den Zusammenhang sehen. Jetzt liest zuerst eine Maschine. Sie erzählt weiter — an jemanden, der Deinen Text nie öffnet. Was ankommt, ist nicht, was Du geschrieben hast, sondern die Paraphrase davon. Jeder Satz, der nur „im Zusammenhang" stimmt, wird ohne Zusammenhang ausgeliefert.

🔄 Der Perspektivwechsel

Deine Doku ist nicht länger nur ein Dokument. Sie ist eine Quelle, die zitiert wird — in Gesprächen, in denen Du nicht sitzt, an Menschen, deren Frage nie bei Dir ankommt. Präzision ist damit keine Stilfrage mehr. Sie ist das Einzige, was die Maschine überhaupt weitergeben kann. Was Du offenlässt, füllt sie selbst. Und sie füllt es, ohne zu zögern.

Der erste Satz entscheidet, ob es einen zweiten gibt. Die meisten verschenken ihn.

Wir starten Texte mit Anlauf. Erst die Begrüßung, dann die Einordnung, dann die Meta-Ansage. Drei Sätze, die niemandem einen Grund geben, den vierten zu lesen. Da ist die Hälfte schon weg.

So klingt ein verschenkter Anfang:

• ❌ “In diesem Beitrag möchte ich einmal beleuchten, warum …”
• ❌ “Wie Ihr sicher alle wisst, ist Dokumentation ja oft …”
• ❌ “Bevor ich zum eigentlichen Punkt komme, kurz zum Kontext …”

So klingt einer, der in den zweiten Satz zieht:

• ✅ “Deine Nutzer:innen sind nicht ungeduldig. Sie sind vernünftig.”
• ✅ “Das meiste in Deiner Anleitung liest niemand. Die Frage ist nur: welchen Teil.”
• ✅ “Deine Fehlermeldung sagt, was kaputt ist – nicht, was ich jetzt tun soll.”

Ein Anfang ist kein Aufwärmen. Er ist ein Versprechen: Gleich steht hier etwas, das Deine Zeit wert ist. Wer erst warmläuft, bricht das Versprechen, bevor er es gibt.

Der erste Satz entscheidet nicht, ob Du recht hast. Er entscheidet, ob es jemand erfährt.

💬 “Ich hab in der Doku nachgeschaut. Hat nichts gebracht.”

Etwas funktioniert nicht mehr, das gestern noch lief. Vierzehn Tabs offen, ein Termin in zwölf Minuten. Irgendwann die Doku. Nicht von oben — Strg+F, ein Wort, der eine Absatz, der halbwegs passt. Überflogen. Weg.

So wird Dokumentation gelesen. Nicht neugierig, nicht der Reihe nach, nicht in Ruhe. Sondern in dem Moment, in dem etwas klemmt — unter Druck, halb genervt, auf der Suche nach genau einer Sache.

Wir schreiben trotzdem für jemand anderen. Für die Person, die sich Zeit nimmt, vorne anfängt, den Kontext aufbaut und Kapitel zwei liest, bevor sie zu Kapitel fünf springt. Diese Person gibt es nicht. Sie hat es nie gegeben.

💬 Deine Leser:in ist nie in guter Stimmung. Und sie liest nicht — sie sucht.

Das ändert alles. Nicht den Ton, den Bau. Ein Absatz, der die drei Sätze davor voraussetzt, ist für jemanden, der per Suchtreffer landet, wertlos. Ein Hinweis, der in Kapitel zwei steht und in Kapitel fünf gebraucht wird, steht am falschen Ort. Ein “siehe oben” schickt jemanden zurück, der nie oben war. Eleganter Textfluss ist für den ruhigen Lesemodus gebaut — den, den niemand hat.

Gute Dokumentation trägt jeden Absatz so, als wäre er der erste, den jemand sieht. Denn dieser eine Absatz ist alles, was von Deiner Arbeit ankommt.

Manche Begriffe sind eindeutig. Die muss niemand neu erfinden – nur respektieren. Manche lassen Spielraum. Der wird entweder geschlossen, oder er wird zur Lücke, durch die sich Show einschleicht. Nicht die Herkunft eines Wortes entscheidet über seinen Wert. Sondern der Zweck, dem es dient.

Beteiligung lässt sich einfordern. Erzeugen lässt sie sich nicht.

🔎 In der Praxis

Eine Initiative wird geplant: Termin, Format, Erwartungen — entwickelt aus der Perspektive der Planenden. Die Kommunikation geht raus. Und dann? Die Beteiligung bleibt hinter den Erwartungen zurück. Die Reaktion: nochmal erinnern, den Druck erhöhen.

💡 Die Logik dahinter

Sobald eine Initiative kommuniziert ist, gilt die Planung als abgeschlossen. Ob Menschen teilnehmen, liegt jetzt bei ihnen. Beteiligung wird als individuelle Entscheidung betrachtet — nicht als Ergebnis der Bedingungen, unter denen diese Entscheidung getroffen werden muss.

⚠️ Der blinde Fleck

Diese Logik schützt den Plan vor unbequemen Fragen: Passt der Zeitpunkt zur Lebensrealität der Eingeladenen? Sind die Erwartungen klar genug, um eine verbindliche Zusage zu geben? Fühlt es sich sicher an, abzusagen? Wer diese Fragen nicht stellt, sucht die Ursache später dort, wo sie nicht liegt — bei den anderen.

🔄 Der Perspektivwechsel

Die entscheidende Frage ist nicht: Wie überreden wir Menschen zur Teilnahme? Sondern: Was müsste gegeben sein, damit Menschen das von sich aus wollen? Wer die erste Frage stellt, sucht nach Compliance. Wer die zweite stellt, sucht nach Motiven. Das eine fordert Beteiligung ein. Das andere ermöglicht sie.

Inkonsistenz in Dokumentation fällt niemandem auf. Bis jemand scheitert. Schon im UI trägt derselbe Button an drei Stellen drei verschiedene Namen: „Speichern", „Sichern", „Save". Die Dokumentation erbt diese Verwirrung, statt sie aufzulösen. Das ist kein Stilproblem. Das ist ein Orientierungsproblem. User müssen selbst entscheiden, ob das dasselbe ist.

Aus der Praxis:

• ❌ „Klicken Sie auf ‚Speichern’." – „Bestätigen Sie mit ‚Sichern’." – „Drücken Sie ‚Save’."
• ❌ Eine Aktion wird im einen Topic als „Vorgang" bezeichnet, im nächsten als „Prozess", im dritten als „Schritt-für-Schritt-Anleitung".
• ❌ Screenshots zeigen mal die deutsche, mal die englische UI – je nachdem, welche Version beim Schreiben gerade offen war.

Das lässt sich lösen:

• ✅ UI-Bezeichnungen vereinheitlichen und in der Dokumentation übernehmen.
• ✅ Einen Begriff pro Konzept festlegen und in der gesamten Dokumentation durchhalten.
• ✅ Für jede Sprachversion der Dokumentation Screenshots aus der jeweiligen UI-Sprache verwenden.

Konsistenz ist nicht Kreativlosigkeit. Sie ist Respekt vor den Usern.

Wer konsequent dieselben Begriffe verwendet, schenkt Usern eine Gewissheit, die sich niemand erarbeiten muss: Was einmal stimmt, stimmt überall.

Das Ding hat einen Namen. Meistens sogar drei.

Dieselbe Funktion, dasselbe Konzept, dasselbe Produkt — benannt nach dem, was der jeweiligen Abteilung gerade passt. Das fällt intern lange nicht auf. Von außen sieht es aus wie Chaos.

Zum Beispiel:

• ❌ Das Feature heißt im Produkt “Dashboard”, in der Dokumentation “Übersicht” und im Support-Ticket “Startseite”.
• ❌ Sales schreibt “Kunde”, der Vertrag sagt “Auftraggeber”, das Backend kennt nur “User”.
• ❌ “Onboarding”, “Einrichtung”, “Erste Schritte” — eine Reise, drei Karten, kein gemeinsames Ziel.

Eine Bezeichnung ändert das:

• ✅ Vertrag, Produkt, Dokumentation, Support — ein Begriff. Überall.
• ✅ Wer “Dashboard” liest, findet “Dashboard” — im Tutorial, in der Fehlermeldung, im Support-Gespräch.
• ✅ Neue Mitarbeitende fragen nicht, wie etwas heißt. Sie lesen es nach. Und finden dieselbe Antwort.

Gleicher Begriff. Andere Reichweite.

Inkonsistente Terminologie ist kein Zufall. Sie ist das Ergebnis von Abstimmungen, die nicht stattgefunden haben.

Beschreiben ist bequem. Erklären ist Arbeit.

🔎 In der Praxis

„Das Feld ‚Timeout’ legt den Zeitraum in Sekunden fest, nach dem die Verbindung getrennt wird." Technisch korrekt. Praktisch nutzlos. User wissen danach immer noch nicht, ob sie 30 oder 3.000 eingeben sollen – und landen im Zweifel beim Support, weil die Doku ihnen die eigentliche Entscheidung überlassen hat.

💡 Die Logik dahinter

Beschreiben verlangt nur Wissen über das Produkt: Was gibt es, wie heißt es, was tut es technisch. Erklären verlangt zusätzlich Wissen über die Situation der User: In welchem Kontext stehen sie, welches Problem wollen sie lösen, welche Entscheidung müssen sie treffen, um weiterzukommen. Das ist der Grund, warum Beschreiben schneller geht – und warum es trotzdem nicht reicht.

⚠️ Der blinde Fleck

„User wissen doch, wofür sie das brauchen." Dieser Satz entsteht selten zuerst in der Dokumentation. Er entsteht in der Entwicklung, wenn ein Feature ohne den Nutzungskontext gebaut wird – und im UI, wenn ein Feld schlicht „Timeout" heißt, ohne zu sagen, wofür der Wert eigentlich steht. Die Dokumentation erbt diese Lücke nur. Und soll sie im Nachhinein wieder schließen.

🔄 Der Perspektivwechsel

Die entscheidende Frage ist nicht: Was ist das? Sondern: Was soll ich damit tun – und unter welchen Bedingungen ergibt welcher Wert Sinn? Eine Beschreibung beantwortet die erste Frage und überlässt die zweite den Usern. Eine Erklärung beantwortet beide. Der Unterschied entscheidet, ob jemand selbstständig weiterarbeitet oder beim Support landet.

Zu viele Warnhinweise schützen niemanden. Sie trainieren das Gehirn, wegzuschauen.

Warning fatigue ist kein User-Problem – es ist ein Dokumentationsproblem. Wer jede Kleinigkeit mit „Wichtig!“ kennzeichnet, entwertet das Wort. Und wenn wirklich etwas auf dem Spiel steht, haben User längst abgeschaltet.

Solche Sätze kennen wir alle aus technischen Dokumentationen:

• ❌ „Wichtig: Bitte lesen Sie diesen Abschnitt sorgfältig.“
• ❌ „Achtung! Stellen Sie sicher, dass alle Voraussetzungen erfüllt sind.“
• ❌ „Hinweis: Diese Aktion kann nicht rückgängig gemacht werden.“

Und dann? Gleich der nächste „Wichtig!“-Block.

Was stattdessen funktioniert:

• ✅ Warnhinweis nur, wenn es tatsächlich etwas zu verlieren gibt.
• ✅ Schweregrade visuell unterscheiden – nicht alles ist gleich kritisch.
• ✅ Konkret benennen, was passiert, wenn die Person das ignoriert.

Wer alles hervorhebt, hebt nichts hervor.

Wer ständig warnt, raubt Usern die Fähigkeit zu unterscheiden, was wirklich zählt. Im entscheidenden Moment fehlt genau diese Unterscheidung.

Eine Überschrift ist kein Platzhalter. Sie ist eine Aussage.

“Einleitung”, “Allgemeines”, “Hinweise” — wer so überschreibt, hat die Struktur beschriftet, nicht den Inhalt. Das ist der Unterschied zwischen einem Schrank mit dem Etikett “Schrank” und einem mit dem Etikett “Winterjacken”. Beides stimmt. Nur eines hilft.

Lesende entscheiden in Sekunden, ob ein Abschnitt für sie relevant ist. Eine Überschrift ohne Aussage nimmt ihnen diese Entscheidung nicht ab — sie zwingt sie, trotzdem reinzulesen. Das kostet Zeit. Und es ist vermeidbar.

So sieht das aus:

• ❌ “Allgemeines”
• ❌ “Weitere Informationen”
• ❌ “Hinweise zur Verwendung”

Was stattdessen möglich ist:

• ✅ “Systemvoraussetzungen auf einen Blick”
• ✅ “Was Du vor der Installation wissen musst”
• ✅ “Diese Funktion ist nur für Admins”

Gleicher Inhalt. Aber Lesende wissen vorher, was sie erwartet — und können selbst entscheiden, ob es für sie relevant ist.

Eine Überschrift, die nicht aussagt, was folgt, ist keine Überschrift. Sie ist Dekoration.

Vollständigkeit ist das beliebteste Qualitätsmerkmal in der Kommunikation. Und das folgenreichste.

🔎 In der Praxis

Eine neue Software. Ein neues Verfahren. Ein neues Produkt. Es gibt ein Dokument dazu — vollständig, alles drin. Du öffnest es mit einer konkreten Frage. Du schließt es, ohne sie beantwortet zu haben. Nicht weil die Antwort fehlt. Sondern weil sie irgendwo zwischen Überblick, Einleitung, Hinweisen und Ausnahmen verschwunden ist.

💡 Die Logik dahinter

Der Reflex bei Komplexität ist immer derselbe: mehr erklären, besser absichern, nichts auslassen. Vollständigkeit gilt als Qualitätsmerkmal. Wer alles reinschreibt, kann nichts falsch gemacht haben. Das stimmt — für die Schreibenden. Für alle anderen bedeutet Vollständigkeit: selbst suchen, selbst filtern, selbst entscheiden, was relevant ist.

⚠️ Der blinde Fleck

Information Overload wird als Empfangsproblem behandelt. Zu viel auf einmal, zu kurze Aufmerksamkeitsspanne. Das verlagert das Problem auf die Lesenden. Die eigentliche Ursache liegt früher: bei der Entscheidung, was nicht rein muss. Diese Entscheidung ist unbequem. Sie erfordert Urteil. Also wird sie nicht getroffen.

🔄 Der Perspektivwechsel

Weglassen ist keine Vereinfachung. Es ist eine redaktionelle Entscheidung — und die schwierigste im Prozess. Wer entscheidet, was fehlen darf, übernimmt Verantwortung dafür, was bleibt. Das ist mehr Arbeit als Vollständigkeit. Und es ist die einzige, die beim Lesen wirklich ankommt.

Lange Sätze klingen nach Arbeit. Sie sind es auch — meistens unnötige.

Auf Deutsch gilt Satzkomplexität als Qualitätsmerkmal. Wer aneinanderreiht, Einschübe setzt, Bedingungen nachliefert, signalisiert: Ich habe gründlich gedacht. Was dabei entsteht, muss jemand anderes wieder entwirren.

Das sieht so aus:

• ❌ “Das System führt, nachdem Du die Konfiguration abgeschlossen und alle Pflichtfelder ausgefüllt hast, einen automatischen Neustart durch.”
• ❌ “Bitte beachte, dass diese Funktion nur dann verfügbar ist, wenn Du Dich im Admin-Modus befindest.”
• ❌ “Der Prozess, der für die Synchronisierung zuständig ist, wird gestartet, sobald Du die Schaltfläche drückst.”

Aufgeteilt:

• ✅ “Konfiguration abgeschlossen? Pflichtfelder ausgefüllt? Das System startet neu.”
• ✅ “Diese Funktion ist nur im Admin-Modus verfügbar.”
• ✅ “Drück die Schaltfläche. Der Synchronisierungsprozess startet.”

Kurze Sätze sind weniger Arbeit — beim Schreiben und beim Lesen. Niemand verliert dabei etwas. Außer der Illusion, dass Komplexität Kompetenz beweist.

Fachsprache hat eine Funktion, über die selten gesprochen wird.

🔎 In der Praxis

Im Arztgespräch fällt ein Begriff, den Du nicht kennst. Du fragst nach. Die Reaktion vermittelt Dir Ungeduld. Im Rechtsdokument stehen Konstruktionen, die Du dreimal liest, ohne sicher zu sein. Im Meeting nicken alle, wenn jemand Abkürzungen verwendet, die Du nicht kennst. Du lernst: Fragen kostet etwas.

💡 Die Logik dahinter

Fachsprache ist nicht automatisch Präzisionswerkzeug. Sie ist auch Zugangssystem. Wer die Sprache beherrscht, signalisiert Zugehörigkeit und darf mitreden. Wer sie nicht beherrscht, stellt Fragen — oder schweigt. Beides wird registriert. Das funktioniert in Arztpraxen, Gerichten, Wissenschaft und Unternehmen gleichermaßen.

⚠️ Der blinde Fleck

Ob ein Begriff wirklich notwendig ist oder nur vertraut, wird selten gefragt. Vertrautheit mit Sprache wird als Kompetenz gelesen — von denen, die sie teilen, und oft auch von denen, die sie nicht verstehen. Wer Jargon verwendet, wirkt wie jemand, der weiß, wovon er redet. Das ist kein Versehen. Es ist der Vorteil.

🔄 Der Perspektivwechsel

Verständlich zu schreiben oder zu sprechen ist kein Stilmerkmal. Es ist ein Verzicht — auf Abgrenzung, auf Zugehörigkeitssignale, auf den Schutz, den Insider-Sprache bietet. Das erklärt, warum verständliche Sprache so selten wirklich gewollt wird. Auch dort, wo alle behaupten, sie anzustreben.

Die Terminologie existierte, bevor wir Cis-Menschen sie kannten. Pride Month ist ein Kanal, über den sie alle erreichen kann.

Bevor Begriffe wie non-binary, cis oder queer – als Eigenbezeichnung – etabliert waren, fehlte nicht nur das Wort. Es fehlte der anerkannte Referenzpunkt.

Ohne Terminus kein Konzept. Ohne Konzept keine Diskussion. Ohne Diskussion keine Veränderung.

Pride-Terminologie ist kein Aktivismus-Vokabular. Es ist ein Beispiel dafür, wie Community-Konsens funktioniert – und warum gute Terminologiearbeit nie nur aus einer einzigen Quelle kommen kann.

Aus der Außenperspektive benannt:

• ❌ “Transsexualismus” – Pathologisierung als Ausgangspunkt
• ❌ “biologisches Geschlecht” – suggeriert, alles andere sei konstruiert
• ❌ “Störung der Geschlechtsidentität” – Diagnose statt Beschreibung

Aus der Community selbst entwickelt:

• ✅ “non-binary” – schließt eine Lücke, die andere Sprachen längst kennen
• ✅ “queer” – von Schimpfwort zur selbstbestimmten Eigenbezeichnung
• ✅ “cis” – gibt der Mehrheit einen Namen, damit “trans” aufhört, die Ausnahme zu sein

Terminologie, die von außen übergestülpt wird, beschreibt nicht – sie wertet.

Die präziseste Terminologie entsteht immer dort, wo die Betroffenen selbst das Wort ergreifen.

💬 „Was bedeutet das eigentlich genau?“

Im Meeting wird es still. Dann sagt jemand: „Na ja – du weißt schon, was wir damit meinen.“ Alle nicken. Das Gespräch geht weiter.

Der Begriff steht im Code, in der Dokumentation, in der Produktpräsentation. Seit Jahren. Alle kennen ihn. Alle sind sicher, dass alle dasselbe meinen.

Bis jemand ihn definieren muss. Und in die Runde fragt: Was genau meinen wir damit?

Es wird still. Dann reden alle gleichzeitig.

💬 Das ist keine Kommunikationslücke. Das ist terminologische Illusion.

Geteilte Unschärfe fühlt sich wie Konsens an.

Ein Begriff, den alle kennen und niemand erklären kann, ist kein Fachbegriff. Er ist ein Platzhalter.

Struktur entsteht nicht beim Schreiben. Sie entsteht davor — wenn man sich fragt, was die andere Person eigentlich braucht, um sich zu orientieren.

Wer das überspringt, lässt Lesende alleine. Wer es nicht tut, führt sie.

„Bald.“ Jeder weiß, was das bedeutet. Bis zwei Menschen herausfinden, dass sie es völlig anders definieren.

Wenn das bei “bald” passiert, ist es unangenehm. Bei “Eigenverantwortung” wird es kompliziert. Bei “zumutbar” wird es zum Konflikt.

Hinter jedem Wort steckt eine Definition, die niemand ausspricht — und die für jeden ein bisschen anders aussieht. Geformt durch Erfahrungen, Umfelder, Geschichten, die wir nie geteilt haben.

Wir reden ständig miteinander. Aber über unsere Wörter reden wir viel zu selten. Wir setzen voraus, dass das Gleiche gemeint ist — und wundern uns, wenn es kracht.

Das meiste davon wäre vermeidbar. Nicht durch mehr Reden, sondern durch präziseres. Implizite Annahmen aussprechen. Nachfragen, bevor aus Annahmen Probleme werden.

Definitionen sind keine Kleinigkeit. Sie entscheiden, ob wir einander wirklich verstehen — oder nur glauben, es zu tun.

Wer gegen Fehler schreibt, denkt in Fehlern. Wer für Klarheit schreibt, denkt in Lösungen.

Die Perspektive, aus der man an ein Dokument herangeht, prägt das Ergebnis — bevor ein einziges Wort geschrieben ist. Wer gegen Probleme dokumentiert, denkt in Problemen. Wer für Ergebnisse dokumentiert, denkt in Wegen.

Das zeigt sich nicht im einzelnen Satz. Es zeigt sich im Ganzen:

• ❌ Sicherheitshinweise als Auflistung dessen, was schiefgehen kann.
• ❌ KI-Richtlinien als Katalog unzulässiger Nutzung.
• ❌ Onboarding-Dokumentation als Liste von Fallstricken.

Der Ausgangspunkt ist derselbe. Die Frage ist eine andere:

• ✅ Sicherheitshinweise als Schritte zum sicheren Ergebnis.
• ✅ KI-Richtlinien als Entscheidungsrahmen für bewussten Einsatz.
• ✅ Onboarding-Dokumentation als Weg zum ersten Erfolgserlebnis.

Gleicher Inhalt. Andere Grundhaltung. Andere Dokumentation.

Dokumentation, die führt, fragt nicht: Was kann hier falsch laufen? Sie fragt: Wo soll diese Person danach stehen?

Wer das Symptom behandelt, macht das Problem unsichtbar. Nicht kleiner.

🔎 In der Praxis

Ein neues Tool wird eingeführt. Wie es genutzt werden soll, wer was damit entscheiden darf, was dokumentiert werden muss – offen. Jemand im Team fängt an, Fragen zu sammeln, Antworten auszuprobieren, Ergebnisse zu teilen. Alle sind dankbar. Es läuft.

💡 Die Logik dahinter

Gut gemeintes Einspringen funktioniert. Genau das ist das Problem. Solange jemand das Symptom behandelt, muss niemand das Problem lösen. Die Verantwortung liegt zwar weiterhin dort, wo sie hingehört – sie wirkt nur nicht mehr.

⚠️ Der blinde Fleck

Was wie Unterstützung aussieht, ist Kompensation. Wer einspringt, schützt nicht das Team – sondern die Führung davor, handeln zu müssen. Die Konsequenzen bleiben. Sie kommen nur später, leiser, und dann meistens ohne eindeutige Ursache.

🔄 Der Perspektivwechsel

Das Problem sichtbar zu machen ist unbequemer als das Symptom zu behandeln. Aber es ist verantwortungsvoller. Nicht weil Unterstützung falsch ist – sondern weil manche Entscheidungen an der richtigen Stelle getroffen werden müssen. Wer das Symptom behandelt, übernimmt Verantwortung. Wer das Problem benennt, zeigt, wo sie fehlt.

Abgehakt ist nicht dasselbe wie verstanden. Ob jemand danach handeln kann, hat niemand gefragt.

🔎 In der Praxis

Schulung absolviert. Handbuch gelesen. Einweisung erhalten. In vielen Organisationen gilt damit eine Sache als erledigt – unabhängig davon, was danach passiert. Das Ergebnis sind Menschen, die glauben, vorbereitet zu sein. Und Organisationen, die glauben, sie vorbereitet zu haben. Beides muss nicht stimmen.

💡 Die Logik dahinter

Inhalte, die nicht für die Person gebaut sind, die sie konsumiert, übertragen kein Wissen. Sie übertragen das Gefühl von Wissen. Der Unterschied zeigt sich nicht beim Konsumieren – er zeigt sich im Ernstfall. Dann nämlich, wenn jemand handeln muss und merkt, dass das, was sie gelernt hat, nicht zu der Situation passt, in der sie sich befindet.

⚠️ Der blinde Fleck

Der Haken am Ende einer Schulung misst, ob jemand etwas konsumiert hat. Er misst nicht, ob jemand danach handeln kann. Oft ist das auch nicht seine Aufgabe. Compliance-Rahmenwerke fordern Nachweise – keine Kompetenz. Wer den Haken setzt, erfüllt die Anforderung. Was danach passiert, ist eine andere Frage – und wird erst dann gestellt, wenn etwas schiefgeht.

🔄 Der Perspektivwechsel

Der Maßstab für guten Inhalt ist nicht Vollständigkeit. Und nicht Konsumierbarkeit. Der einzige Maßstab, der zählt: Kann die Person danach das tun, wofür der Inhalt gedacht war? Wenn nicht, war der Haken das Ziel – nicht das Wissen.

Expert:innenwissen ist kein Vorteil beim Erklären. Es ist das Hindernis.

Wer etwas gebaut hat, weiß zu viel. Nicht zu wenig. Die Schritte, die selbstverständlich sind, werden übersprungen. Die Begriffe, die erklärt werden müssten, werden vorausgesetzt. Das Wissen sitzt so tief, dass es unsichtbar wird — auch für die Person, die es hat.

Das zeigt sich in der Praxis:

• ❌ “Stellen Sie sicher, dass die Abhängigkeiten korrekt konfiguriert sind.” — welche Abhängigkeiten?
• ❌ “Wählen Sie den passenden Modus.” — passend wofür?
• ❌ “Das System verhält sich wie erwartet.” — was wird denn erwartet?

Wer die richtigen Fragen stellt, schreibt anders:

• ✅ “Bevor Sie starten: Diese drei Pakete müssen installiert sein.”
• ✅ “Modus A für Einzelnutzung, Modus B wenn mehrere Personen gleichzeitig zugreifen.”
• ✅ “Nach dem Speichern erscheint die grüne Bestätigungsmeldung.”

Gleiches Thema. Anderer Ausgangspunkt.

Die beste Dokumentation schreibt nicht, wer am meisten weiß. Sie schreibt, wer gelernt hat, die richtigen Fragen zu stellen.

Deine Struktur sagt den Leuten bereits, was wichtig ist – noch bevor sie das erste Wort gelesen haben.

🔎 In der Praxis

Die Warnung steht nach dem Schritt, der den Fehler auslöst. Die Ausnahme, die auf die Mehrheit zutrifft, steckt eingeklappt unter “Weitere Informationen”. Die Überschrift heißt “Allgemein” — darunter steht die Bedingung, ohne die der Rest nicht gilt. Niemand hat sich dabei etwas gedacht. Genau das ist das Problem.

💡 Die Logik dahinter

Struktur ist nie neutral. Was zuerst steht, bekommt Gewicht. Was eine Überschrift bekommt, wirkt wichtig. Was im Fließtext verschwindet, wird übersehen — unabhängig davon, wie relevant es ist. Jede Strukturentscheidung ist eine Aussage darüber, was zählt. Auch wenn sie niemand bewusst getroffen hat.

⚠️ Der blinde Fleck

Struktur wird oft als Formatierungsfrage behandelt — als letzter Schritt, nachdem der Inhalt steht. Dabei ist sie eine Inhaltsentscheidung. Und noch etwas: Schlechte Struktur fällt selten als Strukturproblem auf. Sie fällt auf als Verwirrung, als Fehler, als Support-Ticket.

🔄 Der Perspektivwechsel

Struktur ist kein Behälter für Inhalte. Sie ist selbst ein Inhalt. Wer das versteht, fängt nicht mit dem Schreiben an — sondern mit der Frage: Was muss zuerst gesehen werden?

Vage Sprache ist keine schlechte Gewohnheit. Sie ist Methode.

Niemand schreibt versehentlich so, dass hinterher nichts an einem hängen bleibt. Das braucht Übung.

• ❌ „Es ist nicht auszuschließen, dass unter bestimmten Umständen Optimierungspotenzial besteht."
• ❌ „Das Thema befindet sich aktuell in der internen Abstimmung."
• ❌ „Diesbezüglich werden die nächsten Schritte zeitnah kommuniziert."

Das klingt professionell. Es sagt nichts.

• ✅ „Das ist ein Problem. Wir lösen es bis Ende des Monats."
• ✅ „Wir haben noch keine Entscheidung. Das dauert noch bis Ende der Woche."
• ✅ „Du hörst bis Freitag von uns."

Kein Können-Problem. Ein Wollen-Problem.

Klare Sprache schützt die Lesenden. Vage Sprache schützt die Schreibenden.

Die einen fürchten KI. Die anderen winken ab. Beide haben dasselbe Problem.

🔎 In der Praxis

Die einen fragen, ob ihr Job noch sicher ist. Die anderen winken ab – ihr Handwerk, ihre Expertise sei zu komplex, zu menschlich für eine Maschine. Beide setzen voraus, dass KI an dieselben Grenzen stößt wie wir. Das tut sie nicht. Wer dem Thema ausweicht, verliert dabei etwas Unwiederbringliches: die Zeit, in der man noch selbst entscheiden kann, was dieses Werkzeug für die eigene Arbeit bedeutet.

💡 Die Logik dahinter

KI verändert nicht nur, was möglich ist. Sie verändert, wie man an Dinge herangeht. Ein Werkzeug, das nicht schläft, nicht ungeduldig wird und auf dieselbe Frage aus zehn verschiedenen Blickwinkeln antwortet, je nachdem wie man es anspricht. Das verändert nicht nur, was man produziert, sondern was man überhaupt erst in Angriff nimmt.

⚠️ Der blinde Fleck

“Das kann KI nicht” ist keine stabile Aussage. Ihr Verfallsdatum rückt schneller näher, als man denkt. Das bedeutet nicht, unkritisch zu sein. Es bedeutet, zu verstehen, wie das Werkzeug funktioniert – nicht oberflächlich, sondern tief genug, um einschätzen zu können, was man ihm anvertrauen kann und was nicht.

🔄 Der Perspektivwechsel

Wer noch fünf Jahre oder mehr im Berufsleben vor sich hat, kommt an dieser Auseinandersetzung nicht vorbei. Nicht als Pflicht, sondern weil es Perspektiven eröffnet, die ohne dieses Werkzeug schlicht nicht zugänglich wären. KI ersetzt kein Urteilsvermögen, kein Domänenwissen, keine Erfahrung. Aber sie verändert, was damit möglich ist. Wer das ignoriert, entscheidet sich nicht für Stabilität – sondern dafür, den Anschluss zu verlieren.

💬 „Wir meinen doch dasselbe.“

Zwei Personen im selben Meeting, beide sagen „Nutzer:innen“ – und meinen etwas völlig anderes.

Person A denkt an Menschen, die täglich mit dem System arbeiten – Administrator:innen, die Workflows konfigurieren, Rechte vergeben, Fehler beheben. Person B denkt an Endkund:innen, die einmal im Monat eine Rechnung herunterladen.

Beide haben recht. Beide reden aneinander vorbei. Und weil beide nicken, merkt es niemand. Noch nicht.

Ein Feature geht live, das technisch funktioniert – aber an der eigentlichen Zielgruppe vorbeizielt. Dokumentation hätte die Lücke schließen können. Übersetzen, was das Produkt nicht leistet. Aber auch das setzt voraus, dass jemand weiß, für wen geschrieben wird. Wenn der Begriff nie geklärt wurde, schreibt die Dokumentation für dieselbe Phantomzielgruppe wie das Entwicklungsteam. Nutzende schlagen die richtige Anleitung auf – und kommen nicht weiter, weil sie nie gemeint waren. Tickets häufen sich. Lösungen laufen ins Leere.

Dann heißt es: Kommunikationsproblem.

💬 Aber es war nie ein Kommunikationsproblem.

Der Begriff stand im Raum, alle haben ihn benutzt, niemand hat ihn geklärt. Was wie ein menschliches Missverständnis aussieht, ist fast immer ein terminologisches Versäumnis – still, unsichtbar, und mit langer Wirkung.

Wer Begriffe nicht definiert, überlässt die Definition dem Zufall.

„Schreib, wie du sprichst.“ Gemeint als Befreiung. Oft das Gegenteil.

Wer schreibt, wie er spricht, schreibt wie sein Team spricht. Mit dem Slang, den alle kennen – nur die User nicht. Was im Daily klingt wie Präzision, wird in der Doku zur Barriere.

In technischen Teams klingt das so:

• ❌ “Defaultmäßig ist die Option deaktiviert.”
• ❌ “Das Feature ist aktuell noch nicht ausgerollt.”
• ❌ “Einfach mal neu starten.”
• ❌ “Das triggert dann den nächsten Schritt.”

Der Wechsel ist unspektakulär:

• ✅ “Die Option ist standardmäßig deaktiviert.”
• ✅ “Das Feature ist in dieser Version noch nicht verfügbar.”
• ✅ “Starte die Anwendung neu.”
• ✅ “Der nächste Schritt startet automatisch.”

Andere Sprache. Gleiche Information.

Dokumentation richtet sich nicht ans Team. Sie richtet sich an alle, die nicht im Raum waren.

„Context Engineering“ klingt nach neuem Berufsfeld. Es ist Informationsarchitektur – nur für eine andere Zielgruppe.

Die Erkenntnis dahinter: Ein LLM reagiert nicht auf den einzelnen Prompt, sondern auf alles, was gleichzeitig im Kontext steht. Rollendefinitionen, Dokumente, Beispiele, Einschränkungen. Wer das gezielt gestaltet, bekommt andere Ergebnisse.

Technische Redakteur:innen kennen das seit Jahrzehnten – nur hieß es anders: selektieren, strukturieren, priorisieren, damit die richtige Person zur richtigen Zeit die richtige Information bekommt.

Schlechter Kontext für ein LLM sieht genauso aus wie schlechte Dokumentation für Menschen:

• ❌ “Schreib etwas über das Produkt.”
• ❌ “Fass das zusammen.”
• ❌ “Erkläre das für unsere Nutzer.”

Mit Kontext ändert sich alles:

• ✅ “Du bist technische Redakteurin. Fass dieses Release-Dokument in 3 Sätzen für Endnutzer:innen zusammen – keine Fachbegriffe, keine Versionsnummern.”
• ✅ “Schreib eine Fehlermeldung für Fall X. Zielgruppe: nicht-technische Nutzer:innen. Ton: sachlich, lösungsorientiert.”
• ✅ “Überarbeite diesen Abschnitt nach folgendem Styleguide: […]”

Gleiche Technologie. Anderer Kontext. Anderes Ergebnis.

Context Engineering als neue Disziplin zu feiern setzt voraus, dass man Technische Dokumentation bisher für Schreibarbeit gehalten hat.

Technische Schulden in der Dokumentation fallen nicht auf — bis sie jemanden treffen.

Veraltete Inhalte bleiben, weil sie niemand meldet. Lücken wachsen, weil niemand Zeit hat.

Jede nicht aktualisierte Seite macht die nächste wahrscheinlicher. Dokumentationsschulden akkumulieren still — und verzinsen sich.

Das kennen alle, die mit gewachsener Dokumentation arbeiten:

• ❌ Ein Funktionsname hat sich geändert. In der Doku steht noch der alte.
• ❌ Ein Prozess wurde vereinfacht. Die Anleitung beschreibt noch fünf Schritte mehr.
• ❌ Ein Feature wurde entfernt. Die Dokumentation erklärt es noch.

Die Schulden wachsen nicht dort, wo die Entscheidungen getroffen werden. Sie landen bei denen, die die Dokumentation benutzen müssen.

Was den Unterschied macht:

• ✅ Änderungen an Dokumentation werden aktiv kommuniziert — nicht still deployed.
• ✅ Veraltete Inhalte werden als Schulden sichtbar gemacht — nicht versteckt.
• ✅ Dokumentationspflege folgt einem System — nicht dem Zufall.

Schulden verschwinden nicht, wenn man sie ignoriert. Sie werden teurer.

Wer Dokumentation als Produkt versteht, versteht auch: Qualität ist keine Eigenschaft eines ersten Entwurfs. Sie ist das Ergebnis konsequenter Pflege.

„Optimiert.“ Was heißt das eigentlich?

Manche Wörter klingen professionell – und sagen nichts. Wörter, die du garantiert schon mal gelesen (oder selbst geschrieben) hast.

Die gute Nachricht: Du musst nicht auf Klarheit verzichten, um professionell zu klingen. Du musst nur konkret werden.

Verständlichkeit schlägt Buzzwords. Immer.

Dokumentation ist ein Produkt im Produkt. Nur wird sie selten so behandelt.

🔎 In der Praxis

Dokumentation entsteht nach dem Produkt – als Beschreibung von etwas, das bereits existiert. Sie hat einen eigenen Lebenszyklus, eigene Qualitätskriterien, eigene Entscheidungen. Ein technisch einwandfreies System, dessen UI Fragen offen lässt, ist ohne brauchbare Dokumentation für die Menschen, die damit arbeiten müssen, ein schlechtes Produkt.

💡 Die Logik dahinter

Jedes Produkt braucht Menschen, die verstehen, was Nutzer:innen brauchen, was priorisiert werden muss und was kommuniziert werden muss – und was nicht. Diese Entscheidungen treffen nicht die, die das Produkt bauen. Die Entscheidungen treffen die, die es verantworten.

⚠️ Der blinde Fleck

Dokumentation wird als Beschreibung behandelt, nicht als Entscheidung. Dabei steckt in jeder Dokumentation eine Reihe von Entscheidungen: Was ist relevant? Für wen? In welcher Tiefe? In welcher Reihenfolge? Diese Entscheidungen prägen, ob ein Produkt für die Menschen nutzbar ist, die damit arbeiten müssen.

🔄 Der Perspektivwechsel

Dokumentation zu verantworten bedeutet, dieselben strategischen Entscheidungen zu treffen wie für jedes andere Produkt. Wer sind die Nutzer:innen? Was brauchen sie – und was nicht? In welchem Format, in welcher Tiefe, in welchem Umfang? Das sind keine redaktionellen Fragen. Das sind Produktentscheidungen. Dokumentation ist kein Anhang. Sie ist ein Produkt – mit allem, was das bedeutet.

Ein LLM stolpert über dieselben Stellen wie Menschen.

Überall liest man: AI-optimized content, LLM-friendly structure, KI-kompatible Dokumentation. Als hätte KI neue Anforderungen mitgebracht. Hat sie nicht. Sie hat die alten sichtbar gemacht.

Was ein Sprachmodell verwirrt, verwirrt auch Menschen:

• ❌ Inkonsistente Terminologie: mal “Hinzufügen”, mal “Bestätigen”, mal “Übernehmen” für die gleiche Aktion
• ❌ Fehlender Kontext: ein Schritt erklärt, was zu tun ist, aber nicht wann oder warum
• ❌ Ambiguität: “Klicken Sie auf die entsprechende Schaltfläche”

Das verwirrt nicht erst seit KI. Das hat immer verwirrt.

Was ein Sprachmodell versteht, verstehen auch Menschen:

• ✅ Konsistente Begriffe: durchgehend, vorhersehbar, ohne Überraschungen
• ✅ Klarer Kontext: wer macht was, wann, unter welchen Bedingungen
• ✅ Eindeutige Referenzen: “Klicken Sie auf ‘Speichern’ oben rechts”

KI-Kompatibilität ist kein Feature. Sie ist das Mindestmaß dessen, was Dokumentation immer hätte leisten müssen. Wer jetzt für KI optimiert, holt nach, was längst Standard sein sollte.

Dokumentation für „die Zielgruppe“ zu schreiben ist verlockend einfach.

Keine schwierigen Entscheidungen, keine Konflikte, kein Aufwand für Analyse. Das Problem: Diese Zielgruppe existiert nicht.

Jede Anleitung erreicht Menschen mit unterschiedlichem Wissensstand, unterschiedlichen Rollen, unterschiedlichem Zeitdruck — und unterschiedlichen Erwartungen daran, was eine Information leisten soll.

Wer das ignoriert, vereinfacht nicht die Arbeit. Er verlagert den Aufwand nur — direkt zu den Lesenden.

Die homogene Zielgruppe ist keine Arbeitsgrundlage. Sie ist eine Vereinfachung, die wir uns selbst erlauben.

Alle sagen: „Gib dem LLM mehr Kontext.“ Niemand fragt: „Ist es der richtige?“

Der häufigste Fehler beim Arbeiten mit LLMs ist nicht zu wenig Kontext – sondern Kontext, der irrelevant, widersprüchlich oder veraltet ist. Mehr hilft nicht, wenn es in die falsche Richtung führt.

Was passiert dann? Das LLM gewichtet alles gleich, weil es nicht unterscheiden kann, was wichtig ist. Alte Informationen überschreiben neue. Widersprüche erzeugen Halluzinationen. Die Antwort wird vage, weil sie allen Informationen gleichzeitig gerecht werden will.

• ❌ 200-Seiten-Handbuch für eine Einzelfrage → LLM sucht die Antwort zwischen irrelevanten Kapiteln

• ✅ Die drei relevanten Seiten → klare Grundlage

• ❌ API-Dokumentation Version 2.0 und 3.5 gleichzeitig → LLM mischt deprecated und aktuelle Methoden

• ✅ Nur die aktuell genutzte Version → eindeutige Basis

• ❌ Firmengeschichte + Produktkatalog + Organigramm für eine Support-Anfrage → LLM verliert sich in Details

• ✅ Nur die Produktinformationen zur konkreten Anfrage → fokussierte Antwort

Die Frage ist nicht, was relevant sein könnte, sondern was definitiv relevant ist – und zur Lösung des Problems beiträgt.

Guter Kontext funktioniert wie gute Dokumentation: So viel wie nötig, so wenig wie möglich.

Qualität schlägt Quantität. Immer.

Füllwörter kosten Aufmerksamkeit. Und die ist endlich.

Das Gehirn filtert — aber es will das nicht tun müssen.

„Starten Sie das System neu, nachdem Sie die Konfiguration gespeichert haben.“ Leute starten neu. Ohne zu speichern.

Gegen die Leserichtung formulierte Anweisungen werden in Leserichtung befolgt. Was zuerst im Satz steht, wird zuerst getan – unabhängig von “nachdem”, “sobald” oder “bevor”.

Typische Fehlerquellen:

• ❌ “Starten Sie das System neu, nachdem Sie die Konfiguration gespeichert haben.” → System wird neu gestartet. Konfiguration weg.
• ❌ “Klicken Sie auf ‘Weiter’, sobald der Upload abgeschlossen ist.” → Klick auf ‘Weiter’. Upload bricht ab.
• ❌ “Schließen Sie das Fenster, nachdem Sie die Datei gelöscht haben.” → Fenster zu. Datei unzugänglich. Fehler.

Menschen folgen der Leserichtung. Immer.

Chronologisch formuliert:

• ✅ “Speichern Sie die Konfiguration. Starten Sie dann das System neu.”
• ✅ “Warten Sie, bis der Upload abgeschlossen ist. Klicken Sie dann auf ‘Weiter’.”
• ✅ “Löschen Sie die Datei. Schließen Sie dann das Fenster.”

Falsche Reihenfolge führt zu falschen Handlungen.

Gute Dokumentation beschreibt nicht nur richtig – sie verhindert Fehler.

💬 „Die Dokumentation war super hilfreich!“

💬 „Diese Anleitung hat mir den Tag gerettet!“

💬 „Danke für die klare Fehlermeldung!“

Wann hast Du das zuletzt gehört? Vermutlich nie.

Gute Dokumentation ist wie gute Luft – man bemerkt sie nur, wenn sie fehlt.

Niemand lobt die Anleitung, die funktioniert hat. Aber jeder erinnert sich an die, die es nicht tat. Je besser wir sind, desto unsichtbarer wird unsere Arbeit.

Das ist das Paradox: Exzellenz bedeutet Unsichtbarkeit.

Dabei steckt hinter dieser Unsichtbarkeit oft die präziseste Arbeit. Jedes Wort abgewogen, jede Struktur durchdacht, jede Zielgruppenperspektive eingenommen.

Stille Expertise schafft reibungslose Erlebnisse – auch wenn niemand klatscht. 👏

Mehr Dokumentation ist nicht bessere Dokumentation.

Viele Redaktionen dokumentieren aus Reflex: Was möglich ist, wird erklärt. Jede Funktion bekommt eine Seite. Jeder Parameter eine Tabelle. Vollständigkeit als Ziel.

Das Ergebnis: Nutzer finden nichts mehr.

Was als umfassende Dokumentation gedacht ist:

• ❌ Getting Started mit 20 Screenshots für eine 3-Klick-Aufgabe
• ❌ Feature-Übersichten mit allen Optionen statt der wichtigsten
• ❌ Troubleshooting-Listen mit 50 Fehlermeldungen ohne Priorisierung

Das Problem ist nicht zu wenig Information. Das Problem ist zu viel Rauschen.

Dokumentation, die fokussiert:

• ✅ Getting Started mit den 3 kritischen Schritten – Details verlinkt
• ✅ Feature-Übersicht mit den 5 wichtigsten Use Cases – Rest optional
• ✅ Troubleshooting mit den 3 häufigsten Problemen – andere durchsuchbar

Weniger Text, mehr Orientierung.

Gute Dokumentation ist nicht vollständig. Sie ist relevant.

Verneinungen in Anleitungen werden nicht gelesen. Sie werden missverstanden.

Unter Zeitdruck verarbeitet das Gehirn “nicht” schlechter als alles andere im Satz. Was bleibt, ist die Handlung – nicht die Warnung davor.

Aus Software-Dokumentationen kennt das jede:r:

• ❌ “Klicken Sie nicht auf ‘Weiter’, bevor die Konfiguration abgeschlossen ist.”
• ❌ “Dieses Feld nicht leer lassen.”
• ❌ “Den Browser während des Updates nicht schließen.”

Niemand liest das falsch. Aber viele handeln falsch.

Der Wechsel ist simpel:

• ✅ “Schließen Sie die Konfiguration ab, dann klicken Sie auf ‘Weiter’.”
• ✅ “Pflichtfeld – bitte ausfüllen.”
• ✅ “Update läuft – Browser geöffnet lassen.”

Gleicher Inhalt. Andere Wirkung.

Gute Dokumentation beschreibt nicht, was falsch ist – sie zeigt, was richtig ist.