Technisch korrekt, praktisch nutzlos.
◆ Fakten statt Floskeln
Gedanken vom 22.03.2026
Die Fehlermeldung erklärt den Fehler.
Die Dokumentation auch.
Nur weiter kommst Du trotzdem nicht.
Die Fehlermeldung erscheint: “Authentifizierungstoken abgelaufen.”
Das UI zeigt: “Fehler: Authentifizierungstoken abgelaufen.”
Du öffnest die Doku, dort steht: “Dieser Fehler tritt auf, wenn der Authentifizierungstoken abgelaufen ist.”
Drei Stationen. Dieselbe Aussage. Kein einziges Mal eine Antwort auf die eigentliche Frage: Was jetzt?
Durchgereicht, nicht erklärt.
Das System meldet einen Zustand. Das UI zeigt ihn an.
Die Doku beschreibt ihn. Niemand übersetzt ihn.
System: “Verbindung zum Server unterbrochen.”
UI: “Fehler: Verbindung zum Server unterbrochen.”
Doku: “Dieser Fehler tritt auf, wenn keine Verbindung zum Server hergestellt werden kann.”
System: “Ungültige Eingabe.”
UI: “Fehler: Ungültige Eingabe.”
Doku: “Dieser Fehler tritt auf, wenn die Eingabe nicht dem erwarteten Format entspricht.”
Weil niemand in der Kette die Perspektive wechselt, landet die Entwicklungssprache unverändert bei den Usern, die einfach nur wissen wollen, was zu tun ist. Je nach Komplexität endet das mit Frustration, Zeitverlust oder einer Support-Anfrage, die niemand gebraucht hätte.
Das wäre nicht passiert, wenn an irgendeiner Station jemand gefragt hätte:
Was müssen die User jetzt tun?
Dabei könnte bereits das UI den Richtungswechsel einleiten — und die Dokumentation ihn vertiefen.
Dieselbe Information, andere Perspektive.
Der Richtungswechsel beginnt damit, die Entwicklungsperspektive bewusst zu verlassen.
Nicht das System beschreiben, sondern die Situation der User verstehen:
Was ist passiert, was brauchen sie jetzt, was ist der nächste Schritt?
UI und Dokumentation beantworten diese Fragen auf unterschiedlichen Ebenen — aber beide aus derselben Perspektive.
System: “Authentifizierungstoken abgelaufen.”
UI: “Deine Sitzung ist abgelaufen. Bitte neu einloggen.”
Doku: “Deine Sitzung läuft nach 30 Minuten Inaktivität ab. Einfach neu einloggen — Deine Daten bleiben erhalten.”
System: “Verbindung zum Server unterbrochen.”
UI: “Keine Verbindung. Bitte Internetverbindung prüfen.”
Doku: “Prüfe Deine Internetverbindung und versuche es erneut. Besteht das Problem weiter, könnte der Server vorübergehend nicht erreichbar sein — versuche es in einigen Minuten nochmal.”
System: “Ungültige Eingabe.”
UI: “Das Datum muss im Format TT.MM.JJJJ eingegeben werden.”
Doku: “Achte auf das richtige Format: TT.MM.JJJJ — zum Beispiel 24.03.2026. Leerzeichen oder Bindestriche werden nicht akzeptiert.”
Dieselbe Information — aber diesmal aus der Perspektive derer, die wissen müssen, was zu tun ist.
Der Unterschied liegt in der Entscheidung.
Dokumentation kann kompensieren, was im UI versäumt wurde — aber es kostet die User einen Umweg. Besser ist, wenn UI und Dokumentation von Anfang an aus derselben Perspektive schreiben.
Das setzt voraus, dass jemand aufhört, das System zu beschreiben, und anfängt, die User zu fragen:
Was brauchst Du jetzt?
Dokumentation erbt, was vorher versäumt wurde.
Und ist gleichzeitig die letzte Chance, es zu korrigieren.