Inhaltsverzeichnis
Ich fahre ein modernes Elektroauto. Per App kann ich es von überall steuern: Fenster öffnen, Klimaanlage starten, die Hupe betätigen – aus 800 Kilometern Entfernung. Das fühlt sich an wie Zukunft. Bis ich etwas im Handbuch nachschlagen will. Dann lande ich auf einer 900-seitigen PDF-Datei. Auf dem Smartphone. Willkommen zurück in den 90ern.
Ich sage das nicht, um meinen Autohersteller zu ärgern. Ich sage es, weil dieses Erlebnis symptomatisch ist für einen Widerspruch, der mir in meiner täglichen Arbeit immer wieder begegnet: auf der einen Seite hochentwickelte digitale Produkte, digitale Zwillinge, IoT-Anbindungen, KI-gestützte Dienste. Auf der anderen Seite Dokumentation, die strukturell aus einer Zeit stammt, als das Internet noch jung war.
PDF: Zuverlässig, aber strukturell blind
Ich will PDF nicht verteufeln. Es ist universell lesbar, einfach zu versenden, druckfertig. Für viele Anwendungsfälle ist es nach wie vor sinnvoll. Aber es hat ein grundlegendes Problem: Es ist für das Lesen gemacht, nicht für das Interagieren.
Was das konkret bedeutet, zeigt mein Autobeispiel gut. Von den 900 Seiten meines Handbuchs betreffen vielleicht 600 tatsächlich mein Fahrzeug. Die restlichen 300 beschreiben Ausstattungsoptionen, die in meinem Auto gar nicht verbaut sind. Ich scrolle also durch Inhalte, die mich nichts angehen – oder der Hersteller pflegt dutzende Dokumentvarianten, eine für jede Ausstattungskombination.
Dazu kommt: Die Navigation im PDF ist linear. Inhaltsverzeichnis oder Volltextsuche – das sind die einzigen Wege. Für ein 900-seitiges Dokument auf dem Smartphone ist das schlicht nicht zeitgemäß.
Und dann ist da noch das, was ich das „Semantik-Problem“ nenne. Die meisten Technischen Redakteur:innen arbeiten heute mit einem CCMS (Component Content Management System). Sie modularisieren Inhalte, klassifizieren Topics und pflegen Metadaten. Das ist gute, solide Arbeit. Aber im PDF-Output ist das alles weg. Die Struktur, die Klassifikation, die Vernetzung – einfach verschwunden. Was bleibt, ist ein flaches Dokument.
Das hat übrigens direkte Konsequenzen für KI-Projekte. Wer seinen KI-Bot mit PDF-Dateien füttert und sich dann wundert, warum die Antworten ungenau sind, sollte genau hier ansetzen. Ein Sprachmodell kann nur so präzise sein, wie die Struktur der Daten, die es bekommt. Semantisch angereicherte HTML-Topics sind für KI-Systeme deutlich besser verwertbar als flache PDF-Seiten. In unserem letzten Blogartikel haben wir genau das erklärt: Topics und KI in der Technischen Redaktion.
Was HTML wirklich kann – vier Beispiele aus der Praxis
Ich möchte aber gar nicht so abstrakt über Formate reden. Deshalb lieber vier konkrete Situationen, die ich aus Kundenprojekten kenne.
Wartungsanleitung direkt in der Maschine
Eine Wartungsanleitung liegt irgendwo auf Seite 276 des Wartungshandbuchs. Die Maschine meldet: „Wartungsintervall in 5 Stunden.“ Was passiert? Die Servicetechnikerin oder der Servicetechniker sucht das Handbuch, schlägt nach, findet die Seite – wenn es gut läuft.
Mit HTML geht das anders. Das entsprechende Topic wird direkt ins HMI-System (Human-Machine-Interface, also die Bedienoberfläche der Maschine) eingebunden. Die Maschine kennt ihren Betriebsstundenzähler, weiß, welches Wartungsintervall ansteht, und zeigt die passende Anleitung direkt im Maschineninterface an. Kein Suchen, kein Blättern. Die Abstimmung mit den Entwickler:innen ist dabei überschaubar: Man einigt sich auf das Ausgabeformat – in der Regel HTML – und ein Zuordnungsverfahren über IDs und exportiert die relevanten Topics aus dem CCMS. Der Rest ist Automatisierung.
Gefahrstoffverzeichnis auf dem Smartphone
Ein Kunde aus dem Bereich Kälte- und Klimatechnik hatte eine fünfseitige Tabelle mit Gefahrstoffen – Lacken, Kältemitteln, Reinigungsmitteln. Die Tabelle arbeitete mit Abkürzungen wie „H222“ – einem Hazard Statement, das erst in einer separaten Legende aufgelöst wurde. Auf dem Smartphone war das schlicht nicht nutzbar.
Unsere Lösung: Wir haben jede Tabellenzeile als eigenständigen Datensatz behandelt und daraus eine durchsuchbare HTML-Liste gebaut. Wer auf dem Smartphone „Propan“ eingibt, bekommt sofort den vollständigen Eintrag – mit Gefahrensymbolen, ausgeschriebenen Gefahrenhinweisen und direkten Links zum Sicherheitsdatenblatt des Herstellers. Keine Legende, kein Springen, keine Abkürzungsrätsel. Alles an einem Ort.
Mehrsprachige Anleitung für ein MRI-System
Bei einem Hersteller medizinischer Bildgebungssysteme lief die Bedienoberfläche der MRI-Geräte auf Englisch – das medizinische Personal wollte die Anleitung aber in der eigenen Sprache lesen. Verständlich: Wenn jemand nicht genau versteht, was er oder sie tut, können Menschen zu Schaden kommen.
Die HTML-Lösung: Die Sprache der in der Anleitung erwähnten UI-Texte lässt sich unabhängig von der Sprache der Anleitung umschalten, in der Regel wird hier Englisch eingestellt. Das klingt simpel. Aber versuchen Sie das mal mit PDF.
Digitaler Produktpass aus dem CCMS
Der Digitale Produktpass (DPP) ist ein Thema, das viele Unternehmen in der EU in den nächsten Jahren beschäftigen wird. Die Idee: Zu jedem Produkt soll ein strukturierter, maschinenlesbarer Datensatz verfügbar sein – mit Informationen zu Herkunft, technischen Daten, Betriebsanleitungen, Wartungshistorie und mehr.
Was viele noch nicht realisiert haben: Ein Großteil dieser Informationen liegt bereits im CCMS. Produktbeschreibungen, Betriebsanleitungen, Wartungshinweise, Bestellnummern – das ist Redaktionsalltag. In HTML lassen sich diese Inhalte mit Daten aus anderen Quellen zusammenführen: aus dem ERP-System, aus dem digitalen Zwilling des Geräts, aus Stammdatenbanken. Das Ergebnis ist eine dynamisch generierte Produktseite, die alle relevanten Informationen an einem Ort bündelt – und sich bei Bedarf täglich aktualisiert. Ein PDF kann das strukturell nicht leisten.
Die Daten sind oft alle da
Wenn ich mit Teams spreche, betone ich immer: Der Weg zu HTML-Ausgabe ist kürzer, als er aussieht. Wer bereits mit einem CCMS arbeitet, hat die Voraussetzungen im Wesentlichen erfüllt. Modularisierter Content, Metadaten, Klassifikationen – das ist das Fundament.
Was fehlt, ist oft nur der letzte Schritt: den Output-Kanal zu wechseln. Statt PDF auszuspielen, HTML zu liefern. Bei SCHEMA ST4 heißt das: OMD– statt PLD-Layout. Und sich dabei mit den Kolleg:innen abzustimmen, die HMI-Systeme, Produktkonfiguratoren oder Webportale betreuen – denn die brauchen genau das, was Technische Redakteur:innen ohnehin produzieren.
Wir haben bei doctima ein Reifegradmodell entwickelt, das dabei hilft, den eigenen Stand einzuschätzen. Die Kernaussage: Wer standardisiert, modularisiert und klassifiziert, ist für HTML-Ausgabe gut aufgestellt. Wer dagegen versucht, KI-Projekte auf Basis von PDF-Dateien aufzubauen, wird feststellen, dass die Ergebnisse enttäuschen – weil die Semantik fehlt, die ein KI-System für präzise Antworten braucht.
Immer noch PDF? Ja, aber …
Ich sage nicht, dass PDF morgen abgeschafft werden sollte. Es hat seinen Platz. Aber als Standardantwort auf die Frage, wie Dokumentation im Jahr 2026 aussehen soll, reicht es nicht mehr. HTML ist semantisch, modular, vernetzt und interaktiv. Es passt sich dem Gerät an, lässt sich in andere Systeme einbinden, ermöglicht Feedback und Nutzungsstatistiken – und macht Dokumentation zu einem aktiven Teil des Produkterlebnisses statt zu einem Anhang. Mein Elektroauto verdient auf alle Fälle eine bessere Anleitung. Und die Nutzenden Ihrer Produkte wahrscheinlich auch.
Wie sieht es bei Ihnen aus – haben Sie schon erste Schritte in Richtung HTML-Ausgabe gemacht, oder stehen Sie noch vor der Entscheidung? Ich freue mich auf den Austausch.
