Martina Hartmann

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.