Die meisten Wissensdatenbank-Artikel werden für das falsche Publikum geschrieben. Nicht für den Nutzer, der gerade nicht weiterkommt und dessen Herzrate leicht erhöht ist. Sondern für das interne Review-Meeting, das auf Vollständigkeit prüft. Das erklärt, warum so viele Help-Center-Artikel lang, korrekt und trotzdem nutzlos sind.
Dieser Guide behandelt zwei Dinge parallel: wie man Artikel schreibt, die für Menschen funktionieren, und wie man sie schreibt, die für KI-Chatbots funktionieren. Die Anforderungen überschneiden sich stärker als man denkt. Aber es gibt einen entscheidenden Unterschied beim Punkt Struktur, der später genauer erklärt wird.
Warum die meisten Wissensdatenbank-Artikel nicht funktionieren
Ein Nutzer, der im Help Center landet, ist nicht in einem entspannten Lesemodus. Er steckt fest. Etwas funktioniert nicht so wie erwartet, eine Deadline naht, oder er hat gerade fünfzehn Minuten verloren und findet nichts. Dieser Zustand verändert, wie man liest. Lange Einleitungen werden überflogen. Konzepte ohne direkten Handlungsbezug werden übersprungen. Wenn die erste Anleitung nicht klappt, bricht man ab.
Das häufigste Muster bei schlechten Artikeln: Sie beschreiben das Feature aus Produktperspektive statt aus Nutzerperspektive. "Die Berichtsfunktion ermöglicht es dir, Daten zu exportieren und nach verschiedenen Metriken zu filtern" erklärt nichts für jemanden, der fragt: "Wie bekomme ich eine Excel-Liste aller aktiven Nutzer?" Beides beschreibt dieselbe Funktion. Nur einer davon beantwortet die Frage.
Dazu kommt das Problem mit KI-Chatbot-Retrieval. Artikel, die zu viele Themen gleichzeitig abdecken, erzeugen schlechte Chunk-Qualität. Ein Chatbot, der auf RAG aufbaut, teilt deine Dokumente in Textabschnitte auf und ruft die relevantesten davon ab. Wenn ein Artikel fünf verschiedene Workflows in einem einzigen Dokument bündelt, bekommt der Chatbot bei einer konkreten Frage oft den falschen Abschnitt, weil er die Themen nicht sauber trennen kann. Mehr dazu im Abschnitt zur KI-Optimierung.
Wie Artikel strukturiert sein müssen, damit ein KI-Chatbot sie verlässlich abruft, erklärt der Artikel zur Dokumentationsstruktur für KI-Chatbots im Detail. Hier geht es zunächst um den Schreibprozess selbst.
Die vier Artikel-Typen und wann du welchen schreibst
Nicht jede Frage braucht denselben Artikeltyp. Wer das durcheinanderbringt, schreibt Anleitungen mit zu viel Theorie oder Referenz-Artikel mit zu vielen Schritten. Die vier Typen haben unterschiedliche Strukturen, unterschiedliche Einstiegssätze und unterschiedliche Erfolgsmetriken.
How-To-Artikel
How-To-Artikel beantworten die Frage: "Wie mache ich X?" Sie sind die häufigste Kategorie in produktbezogenen Help Centers und die am häufigsten falsch geschriebene. Der Fehler: zu viel Erklärung im Anleitungsteil, zu wenige Erklärungen vor dem ersten Schritt.
Die richtige Struktur für einen How-To-Artikel:
- Ein Satz, der bestätigt, was dieser Artikel löst. Kein Marketingtext, kein Feature-Pitch.
- Optional: Zwei bis drei Sätze Kontext, die erklären, wann man diesen Weg nimmt vs. einen anderen.
- Nummerierte Schritte. Jeder Schritt ist eine Handlung, kein Konzept. Maximal ein Screenshot pro relevantem Schritt.
- Optional: Häufige Fehler am Ende, wenn bestimmte Schritte erfahrungsgemäß Probleme machen.
Was zu vermeiden ist: Schritte, die keine echten Schritte sind ("Stelle sicher, dass du angemeldet bist" als Schritt 1 ist kein Schritt), Schritte die mehrere Handlungen in einem bündeln, und Einleitungen die erklären, was die Funktion alles kann, statt direkt zum Ziel zu führen.
Troubleshooting-Artikel
Troubleshooting-Artikel beantworten die Frage: "Warum funktioniert X nicht?" Wer in einem Troubleshooting-Artikel landet, ist bereits frustriert. Die Struktur muss das berücksichtigen.
Fang mit der Fehlermeldung oder dem Symptom an, nicht mit der Ursache. "Du siehst die Fehlermeldung 'Keine Verbindung' nach der Installation" ist ein besserer Einstieg als "Verbindungsfehler können mehrere Ursachen haben." Der Nutzer erkennt sofort, ob er hier richtig ist.
Dann kommen die Lösungsoptionen in absteigender Reihenfolge nach Wahrscheinlichkeit. Die häufigste Ursache zuerst, nicht die interessanteste. Wenn es eine Diagnose-Frage gibt, die bestimmt welche Lösung zutrifft, stelle sie explizit: "Bist du auf einem Team- oder Enterprise-Plan?" Gib dem Nutzer das Werkzeug, die richtige Lösung selbst zu finden, ohne jeden Weg durchzuprobieren.
Troubleshooting-Artikel sind die wichtigsten Artikel für KI-Chatbot-Genauigkeit. Wenn ein Nutzer eine Fehlermeldung in den Chatbot tippt, muss der Chatbot genau diesen Artikel finden. Das funktioniert nur, wenn die Fehlermeldung exakt so im Artikel steht, wie der Nutzer sie sieht. Kopiere die Fehlermeldung wörtlich in die H2-Überschrift oder in die erste Zeile des Artikels. Niemals paraphrasieren.
Konzept- und Referenz-Artikel
Konzept-Artikel erklären, was etwas ist. Referenz-Artikel listen auf, was es gibt. Beide werden seltener gebraucht als How-Tos, aber sie sind die Basis für alles andere.
Ein Konzept-Artikel über "Was ist eine Workspace-Integration?" muss nicht erklären, wie man eine Integration einrichtet. Das ist ein anderer Artikel. Er muss in drei bis fünf Absätzen erklären, was eine Integration ist, wann man sie braucht, und was passiert, wenn man sie verbindet. Das Ziel ist kein vollständiges Verständnis, sondern genug Kontext, damit der Nutzer entscheiden kann, ob er das braucht.
Referenz-Artikel sind oft Tabellen oder Listen: alle verfügbaren Integrationen, alle unterstützten Dateiformate, alle Berechtigungsstufen. Diese Artikel brauchen keine Einleitung über die Funktion der Berechtigungen. Sie brauchen eine präzise Tabelle. Für das Webflow-Format müssen Tabellen immer in <div class="w-embed"> gewrappt werden.
FAQ-Artikel
FAQ-Artikel bündeln häufige Fragen zu einem Thema. Sie sind sinnvoll, wenn mehrere kurze Fragen dasselbe Feature betreffen, aber jede einzelne Frage keinen eigenen Artikel rechtfertigt.
Die häufigste Fehlentscheidung: FAQ statt How-To schreiben. "Wie aktiviere ich die Zwei-Faktor-Authentifizierung?" ist kein FAQ-Kandidat. Das ist ein How-To-Artikel. Ein FAQ-Artikel ist: "Häufige Fragen zu Abrechnungen und Rechnungen" mit fünf bis zehn Fragen, die alle thematisch zusammengehören und jeweils in zwei bis vier Sätzen beantwortbar sind.
Für KI-Retrieval sind FAQ-Artikel problematisch, wenn die Fragen zu breit gestreut sind. Wenn ein FAQ-Artikel Fragen zu Preisen, Integrationen und Datenschutz bündelt, bekommt der Chatbot immer den ganzen Artikel als Kontext, auch wenn nur eine Preisfrage gestellt wurde. Halte FAQ-Artikel thematisch eng.
Schreiben für den Nutzer im Fehlerzustand
Das Konzept des "Fehlerzustands" stammt aus der UX-Forschung, ist aber für Help-Center-Autoren genauso relevant. Ein Nutzer im Fehlerzustand hat eine erhöhte kognitive Last. Einfache Dinge werden schwieriger: längere Texte lesen, Anweisungen sequenziell folgen, Fehlermeldungen interpretieren.
Was das konkret für dein Schreiben bedeutet:
Schritt für Schritt, nicht Absatz für Absatz. Eine nummerierte Liste mit sieben Schritten ist für einen frustrierten Nutzer einfacher zu folgen als ein Fließtext, der dieselben sieben Schritte beschreibt. Die Nummerierung gibt Orientierung: "Ich bin bei Schritt 4, noch drei."
Aktive Verben, nicht nominale Wendungen. "Klick auf Speichern" ist besser als "Das Speichern der Einstellungen erfolgt über den Speichern-Button." Das klingt trivial. In einer langen Anleitung summieren sich diese Formulierungen zu echter kognitiver Mehrbelastung.
Erwartungsmanagement.** Sag dem Nutzer, was nach einem Schritt passieren soll. "Nach dem Klick öffnet sich ein Bestätigungsdialog." Wenn nichts passiert, weiß der Nutzer sofort, dass etwas nicht stimmt, statt unsicher zu sein, ob er den Schritt richtig ausgeführt hat.
**
Kurze Sätze. Die KCS-Methodik (Knowledge-Centered Service) empfiehlt für Support-Dokumentation einen Lesbarkeitsindex, der für Leser unter leichtem Stress verständlich bleibt. Das bedeutet in der Praxis: Sätze unter 20 Wörtern, keine Schachtelsätze, keine Nebensätze mit Nebensätzen.
Ein Test, ob dein Artikel im Fehlerzustand funktioniert: Lies ihn jemandem vor, der das Produkt nicht kennt. Wenn er nach dem dritten Satz fragt, "was ist damit gemeint?", ist die Stelle zu komplex für jemanden, der gleichzeitig ein Problem lösen muss.
Struktur, die funktioniert
Eine gute Artikelstruktur löst zwei Probleme gleichzeitig: Sie führt einen menschlichen Leser durch den Inhalt, und sie gibt KI-Retrieval-Systemen klare, thematisch abgegrenzte Einheiten zum Abrufen.
Der erste Satz entscheidet
Der erste Satz eines Help-Center-Artikels muss bestätigen, dass der Nutzer am richtigen Ort ist. Nicht mehr, nicht weniger. "In diesem Artikel erfährst du, wie du ein Projekt archivierst" ist ein guter erster Satz. "Die Projektverwaltung bietet viele Möglichkeiten, deinen Workspace zu organisieren" ist es nicht.
Klare H2/H3-Hierarchie
Verwende H2-Überschriften für Hauptabschnitte des Artikels. H3-Überschriften für Unterabschnitte innerhalb eines H2-Abschnitts. Niemals H3 ohne übergeordnetes H2. Niemals H4 in normalen Support-Artikeln, das ist ein Zeichen, dass der Artikel zu viele Ebenen hat.
H3-Überschriften sind die wichtigste Retrieval-Einheit für KI-Chatbots. Mehr dazu im nächsten Abschnitt. Für die Struktur gilt: Jede H3-Überschrift muss für sich allein verständlich sein. Wenn jemand nur die Überschriften liest, sollte er den Artikel-Inhalt grob verstehen.
Kurze Absätze
Drei bis fünf Sätze pro Absatz sind das Optimum. Mehr als sieben Sätze pro Absatz ist selten gerechtfertigt. Ein langer Absatz ist fast immer ein Zeichen, dass zwei verschiedene Gedanken zusammengequetscht wurden, die einen eigenen Absatz verdienen.
Bullet Lists und nummerierte Listen richtig einsetzen
Nummerierte Listen für Schritte, die in dieser Reihenfolge ausgeführt werden müssen. Bullet Lists für Aufzählungen, bei denen die Reihenfolge egal ist. Niemals Bullet Lists für Fließtext, der eigentlich Absätze sind. "Unsere Plattform bietet: Schnelligkeit, Einfachheit, Integration" ist kein sinnvoller Einsatz von Bullet Lists.
Artikel für KI-Retrieval optimieren
KI-Chatbots, die auf RAG (Retrieval-Augmented Generation) aufbauen, arbeiten mit Chunks: Textabschnitten, die aus deinen Dokumenten herausgeschnitten werden, um dem Sprachmodell als Kontext zu dienen. Die Qualität dieser Chunks bestimmt direkt, wie gut der Chatbot deine Fragen beantwortet.
Die meisten Chunking-Systeme teilen Dokumente entweder nach fester Zeichenzahl oder nach Überschriften auf. Das bedeutet: Deine H3-Überschriften werden zu natürlichen Chunk-Grenzen. Ein Abschnitt von H3 zu H3 ist eine Retrieval-Einheit.
H3 als Retrieval-Einheit
Schreib jeden H3-Abschnitt so, als könnte er allein stehen. Wenn jemand eine Frage stellt und der Chatbot nur diesen einen H3-Abschnitt als Kontext bekommt, muss die Antwort trotzdem vollständig und korrekt sein. Das heißt konkret:
- Verweise wie "wie oben erklärt" oder "wie in Schritt 3 beschrieben" funktionieren nicht, wenn der Chatbot nur diesen Abschnitt sieht
- Definiere Begriffe innerhalb des Abschnitts, nicht nur im übergeordneten H2
- Vermeide Pronomen, die sich auf Inhalte aus anderen Abschnitten beziehen
Optimale Chunk-Größe
Ein H3-Abschnitt sollte zwischen 100 und 400 Wörter lang sein. Zu kurz heißt zu wenig Kontext für das Sprachmodell. Zu lang heißt das System schneidet den Chunk trotzdem auf, und zwar nicht an einer sinnvollen Stelle.
Wenn ein H3-Abschnitt über 500 Wörter geht, ist das ein Signal, ihn in zwei H3-Abschnitte aufzuteilen. Wenn er unter 80 Wörtern bleibt, sollte man prüfen, ob er mit dem vorherigen oder folgenden Abschnitt zusammengezogen werden kann.
Schlüsselwörter in Überschriften
Der Chatbot matchat Fragen semantisch gegen Chunk-Inhalte. Eine H3-Überschrift wie "Häufige Probleme" ist schlechter abrufbar als "Fehlermeldung: Keine Verbindung zum Server." Schreib Überschriften so präzise wie möglich. Benutze dieselbe Sprache, die deine Nutzer in Tickets und im Chatbot verwenden, nicht die Sprache, die das Produkt-Team intern nutzt.
Fehlermeldungen wörtlich übernehmen
Wenn ein Artikel eine Fehlermeldung behandelt, muss die Fehlermeldung exakt so im Artikel stehen wie sie im Produkt erscheint. Ein Chatbot, der nach "Error 403: Access denied" gefragt wird, findet keinen Artikel der "Zugriffsproblem" als Überschrift hat. Der Retrieval-Mechanismus ist kein Translator. Er braucht exakte oder semantisch nahe Übereinstimmungen. Was das für die Verbindung zwischen Wissensdatenbank und KI-Chatbot bedeutet, erklärt der Artikel zur Verbindung von Wissensdatenbank und KI-Chatbot.
Templates für jeden Artikel-Typ
Hier sind die vier Basis-Templates. Kopiere sie, füll die Platzhalter aus, passe die Länge nach Bedarf an.
| Artikel-Typ | Struktur | Einstiegssatz | Optimale Länge |
|---|---|---|---|
| How-To | Intro (1-2 Sätze) → Voraussetzungen (optional) → Nummerierte Schritte → Ergebnis-Bestätigung → Häufige Fehler (optional) | "Diese Anleitung zeigt dir, wie du [Ziel] in [Produkt] erreichst." | 300–800 Wörter |
| Troubleshooting | Symptom/Fehlermeldung (H2) → Häufigste Ursache mit Lösung → Zweithäufigste Ursache → Weiteres Vorgehen wenn nichts klappt | "Du siehst die Meldung [Fehlermeldung exakt] wenn du [Kontext]." | 400–1.000 Wörter |
| Konzept/Referenz | Definition (1 Satz) → Erklärung (2-4 Absätze) → Abgrenzung zu ähnlichen Begriffen → Weiterführende Links | "[Begriff] ist [Definition in einem Satz]." | 200–500 Wörter |
| FAQ | Kurze Einleitung → Fragen als H3-Überschriften → Antwort 2-4 Sätze pro Frage → Verweis auf ausführlichere Artikel | "Hier findest du Antworten auf häufige Fragen zu [Thema]." | 5–15 Fragen, je 50–150 Wörter |
Screenshots vs. Text vs. Video: wann was
Die Entscheidung zwischen Screenshot, Text und Video ist keine Geschmacksfrage. Sie hat direkte Auswirkungen auf die Wartungskosten deiner Dokumentation.
Screenshots
Screenshots sind sinnvoll, wenn ein UI-Element schwer in Worten zu beschreiben ist, oder wenn die Position eines Elements entscheidend ist und Text das nicht klar vermittelt. Screenshots sind schlecht für Dinge, die sich häufig ändern: Button-Farben, Menü-Layouts, Dashboard-Designs.
Wenn du Screenshots verwendest, zeige nur den relevanten Bereich, nicht den gesamten Screen. Ein fokussierter Screenshot eines Dialogs veraltet langsamer als ein Full-Screen-Screenshot, weil weniger irrelevante Elemente sich ändern können. Und: Ein Screenshot ohne begleitenden Text erklärt nichts. Schreib immer einen Alt-Text und einen beschreibenden Satz darunter.
GIFs und Loom-Videos
GIFs eignen sich für kurze, wiederholbare Abläufe, die in 5 bis 10 Sekunden gezeigt werden können. Ein GIF der zeigt, wie man einen Drag-and-Drop-Bereich benutzt, ist besser als drei Screenshots desselben Ablaufs. Loom-Videos eignen sich für komplexe Workflows, die viele Schritte umfassen oder bei denen Audio-Erklärungen den Schritt deutlich einfacher machen.
Der Nachteil beider Formate: hohe Wartungskosten. Jedes Mal wenn sich die UI ändert, muss das GIF oder Video neu aufgenommen werden. Für KI-Chatbot-Retrieval sind GIFs und Videos nicht nützlich, da der Chatbot nur Text verarbeitet. Wenn du ein GIF oder Video verwendest, muss ein vollständiger Text-Equivalent vorhanden sein.
Text zuerst
Die Salesforce State of Service-Studie zeigt, dass 89 Prozent der Kunden Self-Service als erste Option bevorzugen, wenn die Informationen leicht zu finden und aktuell sind. "Leicht zu finden" und "aktuell" sind beides Argumente für text-basierte, aktuell gehaltene Artikel über Video-Inhalte, die veralten.
Die Grundregel: Text ist immer das Fundament. Screenshots und Videos sind Ergänzungen. Ein Artikel, der ohne seinen Screenshot nicht funktioniert, ist kein guter Artikel.
Wie du Artikel auf dem neuesten Stand hältst
Schreiben ist der einfachste Teil der Dokumentations-Arbeit. Das Schwierige ist, Artikel aktuell zu halten, während das Produkt sich verändert. Die meisten SaaS-Teams deployen wöchentlich oder häufiger. Laut GitLab-Daten tun das 65 Prozent aller Entwicklungsteams. Jeder Deploy kann einen bestehenden Artikel falsch machen.
Die drei Praktiken, die den Unterschied machen:
Freshness-Datum als Pflichtfeld
Jeder Artikel bekommt ein "Zuletzt überprüft"-Datum. Artikel die länger als 90 Tage nicht überprüft wurden, landen automatisch auf einer Review-Liste. Das zwingt zu regelmäßigen Durchgängen, auch wenn kein Release eine direkte Änderung ausgelöst hat. Was dabei zu prüfen ist, zeigt der Artikel zum Help-Center-Audit für veraltete Artikel.
Artikel-Produkt-Mapping
Ein einfaches Mapping: Artikel X beschreibt den Bereich "Einstellungen / Integrationen". Wenn an diesem Produktbereich etwas geändert wird, weiß das Support-Team sofort, welche Artikel zu prüfen sind. Ohne dieses Mapping passiert das Offensichtliche: niemand weiß welche Artikel betroffen sind, also prüft niemand sie. Was Documentation Decay konkret kostet, erklärt der Artikel zur veralteten Dokumentation in SaaS-Unternehmen.
Automatische Änderungserkennung
Ab einer bestimmten Produktgeschwindigkeit reicht kein manueller Prozess mehr. Wenn ein Team alle zwei Wochen deployt und 80 Artikel hat, ist das zu viel Fläche für manuelle Prüfung nach jedem Release.
HappySupport löst genau das. Der HappyAgent verbindet sich direkt mit dem GitHub-Repository. Wenn ein Entwickler einen Commit macht, der UI-Elemente verändert, erkennt HappyAgent, welche CSS-Selektoren sich geändert haben, und markiert automatisch die Artikel, die diese Elemente beschreiben. Das Team sieht in einem Content Freshness Dashboard, welche Artikel noch stimmen und welche geprüft werden müssen. Wie das im Help-Center-Kontext aussieht, erklärt der Artikel zum Help Center aktuell halten.
Der Unterschied zu pixel-basierten Recorder-Tools: HappyRecorder zeichnet keine Screenshots auf, sondern DOM-Metadaten und CSS-Selektoren. Das System kennt die strukturelle Verbindung zwischen Code und Dokumentation. Wenn ein Button-Selektor sich ändert, weiß das System welche Artikel diesen Button referenzieren. Kein Screenshot-Vergleich kann das leisten.
Qualitätscheckliste: bevor du veröffentlichst
Diese Checkliste läuft schnell durch und fängt die häufigsten Probleme ab.
| Kriterium | Was zu prüfen ist | Häufiger Fehler |
|---|---|---|
| Erster Satz | Bestätigt der erste Satz, was dieser Artikel löst? | Einleitung erklärt die Funktion statt das Ziel des Nutzers |
| Schritt-Vollständigkeit | Ist jeder Schritt eine einzelne Handlung? | Mehrere Handlungen in einem Schritt gebündelt |
| Ergebnis-Bestätigung | Weiß der Nutzer nach jedem Schritt, ob er es richtig gemacht hat? | Keine Bestätigungshinweise nach kritischen Schritten |
| Überschriften-Präzision | Sind H3-Überschriften präzise genug für KI-Retrieval? | "Häufige Probleme" statt "Fehlermeldung: Verbindung fehlgeschlagen" |
| Chunk-Unabhängigkeit | Kann jeder H3-Abschnitt allein stehen? | Verweise auf andere Abschnitte ("wie oben erklärt") |
| Fehlermeldungen | Sind Fehlermeldungen wörtlich übernommen? | Paraphrasierte oder übersetzte Fehlermeldungstexte |
| Screenshots | Sind Screenshots fokussiert und haben Text-Äquivalente? | Full-Screen-Screenshots ohne begleitende Texterklärung |
| Terminologie | Wird jeder Begriff konsistent verwendet? | "Dashboard", "Startseite" und "Hauptansicht" für dasselbe Element |
| Lesbarkeit | Sind Sätze unter 20 Wörtern? Keine Schachtelsätze? | Zu lange Sätze im Anleitungsteil |
| Freshness-Datum | Ist ein "Zuletzt geprüft"-Datum gesetzt? | Kein Datum, Artikel bleiben dauerhaft ungeprüft |
Wenn du die Checkliste durchgehst und bei einem Punkt stockst, ist das fast immer die Stelle, an der ein Nutzer im Fehlerzustand aufgibt. Besser es jetzt zu fixen als nach dem ersten Ticket.
Willst du sehen, wie das in der Praxis aussieht? Wie Support-Teams mit HappySupport Artikel schreiben, die nach einem Release noch stimmen, ohne jeden Guide manuell zu prüfen: Buch eine kurze Demo. Du bringst deinen aktuellen Help-Center-Stand, wir zeigen dir, was passiert, wenn sich dein Produkt das nächste Mal ändert.
**
Demo buchen