Ein neuer Nutzer, der einem falschen Guide folgt und sein Ziel nicht erreicht, stellt keine zweite Frage. Er öffnet ein Ticket oder er geht. Diese Dynamik wiederholt sich in jedem SaaS mit monatlichem Release-Rhythmus, unabhängig von Produktqualität oder Preisniveau. Das Onboarding-Erlebnis hängt an einem einfachen Faktor: ob die Dokumentation, die neue Nutzer bei den ersten Schritten führt, noch stimmt.
Onboarding-Dokumentation hat eine besondere Eigenschaft, die sie von anderen Help-Center-Inhalten unterscheidet: sie veraltet zuerst. Weil sie UI-spezifische Schritte beschreibt, Buttons, Menüpfade, Formularfelder, trifft jede Release-Änderung Onboarding-Guides unverhältnismäßig hart. Die Folge ist vorhersehbar: neue Nutzer folgen Anweisungen, scheitern, verlieren das Vertrauen in die Dokumentation und landen im Support-Postfach.
Dieser Artikel beschreibt, was gute Onboarding-Dokumentation ausmacht, wie man sie aufbaut und, was die meisten Teams falsch machen: wie man sie aktuell hält.
Was ist Onboarding-Dokumentation?
Onboarding-Dokumentation ist der Teil des Help Centers, der neue Nutzer durch die ersten Schritte führt. Sie begleitet den Zeitraum zwischen Signup und dem ersten abgeschlossenen Kernworkflow, dem sogenannten First Value Moment. Alles, was einem neuen Nutzer in dieser Phase hilft, das Produkt ohne externe Hilfe produktiv zu nutzen, gehört zur Onboarding-Dokumentation.
Was sie von allgemeiner Produktdokumentation unterscheidet: der Ausgangspunkt. Allgemeine Produktdokumentation setzt voraus, dass ein Nutzer weiß, was er sucht. Er hat ein konkretes Feature-Problem und sucht die Antwort dazu. Onboarding-Dokumentation trifft den Nutzer, der das Produkt noch nicht kennt und noch nicht weiß, wo er überhaupt beginnen soll.
Das klingt nach einem feinen Unterschied. In der Praxis ist es der Unterschied zwischen einer Dokumentationsstruktur, die nach Features organisiert ist, und einer, die nach Nutzerzielen organisiert ist. Feature-Dokumentation fragt: "Was kann das Produkt?" Onboarding-Dokumentation fragt: "Was will ein neuer Nutzer als Erstes erreichen?" Die Antworten auf beide Fragen sind selten identisch.
Ein Beispiel: Ein SaaS-Tool für Projektmanagement hat vermutlich hunderte von Features. Die Onboarding-Dokumentation deckt davon die drei bis fünf ab, die ein neuer Nutzer braucht, um seinen ersten Workflow abzuschließen. Alles andere ist für Onboarding-Zwecke nicht relevant und sollte im Onboarding-Kontext nicht sichtbar sein.
Die fünf Arten von Onboarding-Content
Onboarding-Dokumentation ist kein einzelner Artikel. Sie besteht aus mehreren Content-Typen, die unterschiedliche Nutzerbedürfnisse in verschiedenen Momenten der Onboarding-Phase ansprechen.
Getting-Started-Guide. Das ist der Einstiegspunkt. Ein linearer Guide, der neue Nutzer Schritt für Schritt durch die Setup-Phase führt. Er endet mit dem abgeschlossenen ersten Kernworkflow. Ein guter Getting-Started-Guide ist so aufgebaut, dass ein Nutzer ihn ohne Vorkenntnisse abarbeiten kann, ohne ein einziges weiteres Dokument zu öffnen.
Erklärvideos. Für Produktschritte, die sich schwer beschreiben lassen, oder für Nutzer, die lieber sehen als lesen. Videos sind besonders nützlich für UI-Flows, die mehrere Screens durchqueren. Ihr Problem: sie veralten schnell und sind aufwendig zu aktualisieren. Wer Videos in der Onboarding-Dokumentation einsetzt, braucht einen klaren Prozess dafür, sie nach jedem UI-Release zu prüfen.
Tooltips und In-App-Guidance. Kontextuelle Hilfe, die direkt im Produkt erscheint, wenn ein Nutzer einen bestimmten Schritt erreicht. Kein separates Tab, keine Suche. Die Information erscheint genau dort, wo der Nutzer sie braucht. Tooltips ersetzen keine Help-Center-Artikel, aber sie erhöhen die Erreichbarkeit der Dokumentation erheblich.
Onboarding-Checkliste. Eine strukturierte Liste der Schritte, die ein neuer Nutzer in den ersten Tagen abschließen sollte. Checklisten geben Orientierung und erzeugen das Gefühl von Fortschritt. Produkte, die eine sichtbare Onboarding-Checkliste in der App eingebettet haben, erreichen nachweislich höhere Completion-Rates als Produkte, die den Onboarding-Fortschritt nur extern dokumentieren.
FAQ für neue Nutzer. Ein separater FAQ-Bereich, der die häufigsten Fragen in den ersten zwei Wochen beantwortet. Nicht der allgemeine FAQ des Help Centers, sondern ein spezifischer FAQ-Bereich, der auf Early-User-Fragen zugeschnitten ist. Die Grundlage für diesen FAQ sollten echte Support-Tickets aus den ersten 30 Tagen neuer Nutzer sein.
Was Onboarding-Dokumentation besonders macht
Der entscheidende Kontext: neue Nutzer kennen das Produkt nicht. Das klingt trivial, hat aber konkrete Implikationen für die Dokumentationsstruktur. Ein Nutzer, der das Produkt nicht kennt, kann einen Schritt nicht rückwärts rekonstruieren, wenn er scheitert. Er weiß nicht, ob er einen Fehler gemacht hat, ob das Produkt einen Bug hat, oder ob die Anleitung veraltet ist. Er hat keinen Referenzpunkt.
Das bedeutet: in Onboarding-Dokumentation gibt es keine "offensichtlichen" Schritte. Was für das Team, das das Produkt täglich nutzt, selbstverständlich ist, ist für einen neuen Nutzer eine potenzielle Fehlerquelle. Jede Annahme über Vorwissen ist ein Risiko.
Progressive Disclosure ist das Kernprinzip, das mit diesem Kontext umgeht. Es besagt: gib einem Nutzer genau so viele Informationen, wie er in diesem Moment braucht. Nicht mehr. Schritt 1 enthält nur die Informationen für Schritt 1. Fortgeschrittene Konfigurationsoptionen erscheinen, wenn ein Nutzer die Basis beherrscht. Links zu weiterführender Dokumentation kommen am Ende eines Abschnitts, nicht am Anfang.
Das zweite Prinzip ist die Ergebnisformulierung. Jeder Schritt einer Onboarding-Anleitung sollte explizit nennen, was der Nutzer nach Abschluss dieses Schritts erreicht hat. "Du hast jetzt deinen ersten Workspace erstellt" ist keine unnötige Bestätigung. Es ist ein Signal, das dem Nutzer zeigt, er ist auf dem richtigen Weg, was er getan hat war korrekt, jetzt kommt der nächste Schritt. Für neue Nutzer, die keinen Referenzpunkt haben, ist dieses Signal kritisch.
Das dritte Prinzip: Onboarding-Dokumentation ist nicht für Vollständigkeit optimiert, sondern für Klarheit im jeweiligen Schritt. Ein Guide, der jedem neuen Nutzer in Schritt 1 erklärt, wie er seinen Account einrichtet und dabei gleichzeitig auf vierzig weitere Features verweist, ist technisch vollständig. Aber er überfordert. Vollständigkeit ist keine Tugend bei Onboarding-Docs. Klarheit ist die Tugend.
Wie man Onboarding-Dokumentation strukturiert
Der Ausgangspunkt für jede Onboarding-Dokumentation ist die Definition des First Value Moments. Was ist der Moment, in dem ein neuer Nutzer zum ersten Mal echten Nutzen aus dem Produkt zieht? Für ein Projektmanagement-Tool könnte das das erste abgeschlossene Projekt sein. Für ein Analytics-Tool das erste erstellte Dashboard. Für ein Help-Center-Tool der erste veröffentlichte Artikel.
Sobald dieser Moment definiert ist, ergibt sich die Struktur der Onboarding-Dokumentation rückwärts: Welche Schritte muss ein Nutzer abgeschlossen haben, um den First Value Moment zu erreichen? Das sind die Schritte, die die Onboarding-Dokumentation in ihrer Kernstruktur abdeckt. Alles andere ist sekundär.
Eine bewährte Struktur für SaaS-Onboarding-Docs:
- Schritt 1: Account einrichten und konfigurieren
- Schritt 2: Das erste Projekt oder den ersten Use Case anlegen
- Schritt 3: Den ersten Kernworkflow abschließen
- Schritt 4: Das Ergebnis des Kernworkflows interpretieren oder nutzen
- Schritt 5: Nächste Schritte und weiterführende Dokumentation
Jeder dieser Schritte sollte einen eigenen Artikel haben. Die Artikel sind mit einem klaren Navigations-Element verlinkt, das den Fortschritt zeigt. Neue Nutzer sollen immer wissen, wo sie im Onboarding-Prozess stehen und wie viele Schritte noch kommen.
Zur Strukturierung gehört auch: Was gehört nicht in die Onboarding-Dokumentation? Fortgeschrittene Konfigurationen, Admin-Settings, Integrations-Details und edge cases gehören in die allgemeine Produktdokumentation, nicht in den Onboarding-Flow. Ein häufiger Fehler ist es, den Onboarding-Guide mit allem zu befüllen, was wichtig sein könnte. Das Ergebnis ist ein Guide, der wichtig aussieht, aber keinen neuen Nutzer durch die ersten Schritte führt.
Mehr dazu, wie man ein Help Center von Grund auf strukturiert, erklärt der Artikel Help Center aufbauen für SaaS.
Häufige Fehler bei Onboarding-Guides
Fünf Fehler wiederholen sich bei den meisten SaaS-Teams.
Fehler 1: Feature-Orientierung statt Ziel-Orientierung. Der Guide ist nach Features organisiert, nicht nach Nutzerschritten. Der Nutzer lernt, was das Produkt hat, aber er lernt nicht, wie er sein erstes Ziel erreicht. Feature-Dokumentation ist wertvoll, aber sie ist nicht das, was ein neuer Nutzer in den ersten Stunden braucht.
Fehler 2: Zu viele Informationen zu früh. Jeder Schritt enthält alles, was relevant sein könnte. Das Ergebnis ist ein Guide, der technisch korrekt ist, aber kognitive Überlastung erzeugt. Nutzer, die in einem Schritt zu viel Information verarbeiten müssen, brechen ab. Progressive Disclosure ist die Lösung, konsequent eingesetzt.
Fehler 3: Fehlende Ergebnisformulierungen. Der Guide beschreibt die Schritte, aber er sagt nicht, was ein Nutzer nach jedem Schritt erreicht hat. Neue Nutzer verlieren die Orientierung, weil sie nicht wissen, ob sie auf dem richtigen Weg sind.
Fehler 4: Keine Unterscheidung zwischen Onboarding-Content und allgemeiner Dokumentation. Der "Onboarding-Guide" ist in Wirklichkeit eine Sektion der allgemeinen Hilfe-Dokumentation, strukturiert wie eine Bedienungsanleitung. Neue Nutzer müssen sich durch Feature-Dokumentation navigieren, um die Onboarding-Schritte zu finden, die sie brauchen.
Fehler 5: Onboarding-Docs werden nach dem ersten Schreiben nicht mehr gepflegt. Das ist der kritischste Fehler. Wie in dem Artikel zu veralteter Dokumentation in SaaS beschrieben, veralten Onboarding-Guides besonders schnell, weil sie UI-spezifische Schritte enthalten. Jede UI-Änderung macht bestehende Onboarding-Anleitungen potenziell falsch. Ein neuer Nutzer, der einem falschen Guide folgt, kommt nicht zum Ziel und wird nicht zurückfragen.
Das Wartungsproblem: Onboarding-Docs veralten zuerst
Onboarding-Guides beschreiben UI-spezifische Schritte: Klick auf einen Button, Eingabe in ein Formularfeld, Navigation durch ein Menü. Jede UI-Änderung macht bestehende Onboarding-Anleitungen potenziell falsch. Das ist kein Randproblem. Für SaaS-Teams mit wöchentlichem Release-Rhythmus ist es die Regel.
Das klassische Fehlerbild: ein neuer Nutzer durchläuft den Getting-Started-Guide, der vor drei Monaten geschrieben wurde. Seitdem hat das Produkt vier Releases erlebt. Der Guide zeigt einen Button, der umbenannt wurde, oder ein Menü, das umstrukturiert wurde. Der Nutzer sucht einen Eintrag, der nicht mehr existiert, oder findet einen Button an einer anderen Position. Er folgt den Anweisungen korrekt und scheitert trotzdem. Das Vertrauen in die Dokumentation ist weg.
Die übliche Reaktion der meisten Teams: ein Dokumentations-Ticket im Sprint für jedes Feature, das Onboarding-Docs betrifft. In der Theorie funktioniert das. In der Praxis wird das Dokumentations-Ticket bei Zeitdruck als Erstes verschoben. Die Dokumentation läuft dem Produkt hinterher, und der Abstand wächst mit jedem Release.
Es gibt einen strukturell anderen Ansatz: Dokumentation technisch mit der Codebase zu verbinden. Wenn das Dokumentationssystem über CSS-Selektoren weiß, welches UI-Element es in einem Schritt dokumentiert hat, kann es erkennen, wenn sich dieses Element im Code ändert. Ändert sich ein Selektor-Pfad für einen Button, den ein Onboarding-Guide beschreibt, markiert das System den entsprechenden Artikel automatisch zur Überprüfung.
Der Unterschied zu screenshot-basierten Dokumentationstools ist fundamental. Screenshots zeigen den Zustand einer Oberfläche zu einem bestimmten Zeitpunkt. Wenn sich das UI ändert, zeigen sie eine Oberfläche, die nicht mehr existiert. CSS-Selektoren kennen das spezifische Element im DOM. Wenn sich das Element ändert, erkennt das System die Änderung, unabhängig davon, ob das visuelle Erscheinungsbild ähnlich aussieht.
Das ist das Problem, das HappySupport löst. HappyRecorder erfasst UI-Elemente über DOM/CSS-Selektoren, keine Screenshots. HappyAgent verbindet die Dokumentation mit dem GitHub-Repository und erkennt automatisch, welche Artikel nach einem Merge potenziell veraltet sind. Für Onboarding-Dokumentation, die step-by-step durch ein UI führt, ist das der entscheidende Unterschied: statt alles nach jedem Release manuell zu prüfen, erhält das Team nur eine Meldung, wenn sich etwas geändert hat, das Dokumentation betrifft. Wie das im Detail funktioniert, beschreibt der Artikel zu GitHub Sync für das Help Center.
Welche Rolle spielt In-App-Guidance beim Onboarding?
Ein strukturelles Problem bei Onboarding-Dokumentation: Nutzer suchen keine Hilfe, bevor sie scheitern. Sie öffnen kein Help-Center-Tab, während sie ein Formular ausfüllen. Die Dokumentation, die außerhalb des Produkts liegt, wird erst aufgerufen, wenn ein Nutzer bereits gescheitert ist. Das Vertrauen in die eigene Entscheidung ist dann schon gesunken, und die Bereitschaft, weiterzumachen, ebenfalls.
In-App-Guidance löst dieses Problem durch Positionierung, nicht durch bessere Inhalte. Die Information erscheint dort, wo der Nutzer sie braucht, zum richtigen Zeitpunkt, ohne dass er sie aktiv sucht. Das ist der strukturelle Unterschied zwischen pull-basierter Dokumentation (Nutzer muss sie suchen) und push-basierter Guidance (Dokumentation erscheint im Kontext).
In der Praxis gibt es drei Formen von In-App-Guidance, die für Onboarding relevant sind:
Produkttouren. Geführte Touren, die einem neuen Nutzer beim ersten Login die wichtigsten Bereiche des Produkts zeigen. Produkttouren sind umstritten: manche Teams schwören auf sie, andere berichten, dass Nutzer sie sofort weggklicken. Der Unterschied liegt meist im Timing. Produkttouren, die unmittelbar nach dem Signup starten, ohne dass der Nutzer verstanden hat, warum er das Produkt braucht, werden übersprungen. Produkttouren, die auf Trigger basieren (z.B. "du hast dein erstes Projekt angelegt, jetzt zeigen wir dir das Dashboard"), haben deutlich höhere Completion-Rates.
Kontextuelle Tooltips. Kleine Hinweise, die an einem UI-Element erscheinen, wenn ein Nutzer es zum ersten Mal sieht oder länger darauf verweilt. Sie erklären, was ein Element tut, ohne den Nutzer aus dem Workflow herauszureißen. Besonders effektiv an Stellen, die für neue Nutzer nicht intuitiv sind: unbekannte Icons, unerwartete Optionen, Einstellungen mit nicht selbsterklärendem Verhalten.
Onboarding-Checkliste im Produkt. Eine persistente Liste der Onboarding-Schritte, sichtbar direkt im Produkt, nicht nur im Help Center. Nutzer können ihren Fortschritt sehen und gezielt zu dem Schritt springen, den sie als nächstes abschließen wollen. Diese Form von In-App-Guidance hat einen nachgewiesenen positiven Effekt auf Onboarding-Completion-Rates.
Wichtig zu verstehen: In-App-Guidance ersetzt keine Dokumentation. Sie macht Dokumentation zugänglich. Das Inhalts-Problem löst sie nicht. Wenn die Tooltips oder Guides, die sie zeigt, veraltet sind, ist kontextuelle Guidance sogar schädlicher als keine Guidance, weil sie falsche Anweisungen mit hoher Sichtbarkeit präsentiert. Die Reihenfolge ist deshalb: zuerst die Dokumentationsqualität sichern, dann die Delivery verbessern.
Mehr dazu, wie In-App-Hilfe ohne teure DAP-Plattformen aufgebaut werden kann, erklärt der Artikel zu In-App-Hilfe ohne DAP aufbauen.
Wie man den Onboarding-Erfolg misst
Vier Metriken geben Aufschluss darüber, ob Onboarding-Dokumentation funktioniert. Sie sollten als System betrachtet werden, nicht einzeln.
Time-to-First-Value (TTFV). Zeit zwischen dem Signup und dem ersten abgeschlossenen Kernworkflow. Setzt voraus, dass das Team definiert hat, was "first value" für das eigene Produkt bedeutet. TTFV ist die direkteste Metrik für Onboarding-Qualität insgesamt. Wenn TTFV hoch ist, scheitern neue Nutzer irgendwo auf dem Weg. Gute Onboarding-Dokumentation ist einer der stärksten Hebel zur Verkürzung von TTFV. Laut dem Salesforce State of Service Report ist Self-Service-Geschwindigkeit einer der Top-Faktoren für Kundenzufriedenheit bei B2B-Software.
Onboarding-Completion-Rate. Anteil neuer Nutzer, die alle definierten Onboarding-Schritte abschließen. Eine niedrige Completion-Rate zeigt, wo Nutzer abbrechen. Wenn viele Nutzer bei Schritt 3 von 6 abbrechen, gibt es dort ein UX-Problem, ein Dokumentationsproblem oder beides. Completion-Rate allein sagt nicht, was das Problem ist. Aber in Kombination mit der nächsten Metrik gibt sie Hinweise.
Early-Ticket-Rate. Anzahl der Support-Ticket-Einreichungen in den ersten 14 Tagen pro 100 neue Nutzer. Das ist die direkteste Metrik für Onboarding-Dokumentationsqualität. Wenn die Early-Ticket-Rate hoch ist und die Tickets häufig dieselben Schritte betreffen, gibt es dort ein Dokumentationsproblem. Analysiere Early-Tickets nach Kategorie: wenn 40 Prozent der Tickets im ersten Monat die Frage "Wie richte ich X ein?" betreffen, ist X entweder nicht dokumentiert oder schlecht dokumentiert.
Activation Rate. Anteil neuer Nutzer, die innerhalb eines definierten Zeitraums (häufig 7 oder 14 Tage) mindestens einmal den Kernworkflow des Produkts abgeschlossen haben. Die Activation Rate ist der stärkste Prädiktor für langfristige Retention. Nutzer, die aktiviert werden, bleiben. Nutzer, die nicht aktiviert werden, churnen meistens still.
Ein pragmatischer Zielwert für die Early-Ticket-Rate: unter 15 Tickets pro 100 neue Nutzer in den ersten 14 Tagen. Teams, die diesen Wert unterschreiten, haben in der Regel funktionierende Onboarding-Dokumentation. Teams, die darüber liegen, haben typischerweise eines von zwei Problemen: Dokumentation ist vorhanden, aber nicht zugänglich genug, oder sie ist zugänglich, aber veraltet.
Quick-Win: Die 5 wichtigsten Onboarding-Artikel für jede SaaS-App
Wer heute anfängt, Onboarding-Dokumentation aufzubauen, kann mit diesen fünf Artikeln beginnen. Sie decken die häufigsten Fragen und die kritischsten Schritte für nahezu jede SaaS-Anwendung ab. Wie man diese Artikel schreibt und was gute Help-Center-Artikel ausmacht, erklärt der Artikel zu Wissensdatenbank-Artikel schreiben.
Artikel 1: Getting Started. Der lineare Einstiegs-Guide, der neue Nutzer vom Signup bis zum ersten abgeschlossenen Kernworkflow führt. Kein Feature-Overload, keine Abzweigungen, nur der direkte Weg zum First Value Moment.
Artikel 2: Account-Setup und Konfiguration. Alle Schritte, die ein Nutzer einmalig durchführen muss, bevor er das Produkt produktiv nutzen kann: Account-Einstellungen, Team-Einladungen, Integrationen, Billing. Diese Schritte blockieren den Start und sind häufig die häufigste Quelle für Early-User-Tickets.
Artikel 3: Erste Inhalte erstellen. Wie erstellt ein neuer Nutzer das erste Objekt im Produkt? Erstes Projekt, erste Kampagne, ersten Report, ersten Artikel. Dieser Schritt ist oft der erste Moment, in dem neue Nutzer auf UI-spezifische Hürden treffen. Hier veralten Onboarding-Docs besonders schnell.
Artikel 4: Häufige Probleme in der Onboarding-Phase. Die Top 5 bis 10 Fragen aus den ersten 30 Tagen neuer Nutzer, beantwortet in einem FAQ-Format. Dieser Artikel sollte auf echten Support-Ticket-Daten basieren, nicht auf Annahmen. Er ist auch der Artikel, der am schnellsten wächst, weil neue Ticket-Kategorien laufend hinzugefügt werden können.
Artikel 5: Nächste Schritte nach dem ersten Erfolg. Was kann ein Nutzer tun, nachdem er den ersten Kernworkflow abgeschlossen hat? Dieser Artikel führt von Onboarding zu vertiefter Produktnutzung. Er markiert das Ende der Onboarding-Phase und den Beginn der normalen Produktnutzung. Sein Ziel: Nutzer motivieren, weiterzumachen und mehr vom Produkt zu entdecken.
Diese fünf Artikel sind ein Minimum. Sie decken den kritischsten Teil des Onboarding-Zyklus ab: den Zeitraum zwischen Signup und erstem Erfolg. Für Teams, die noch keine Onboarding-Dokumentation haben, ist das der schnellste Weg, Early-Ticket-Rate zu senken und Activation Rate zu erhöhen.
Wenn du wissen willst, wie du Onboarding-Dokumentation aufgebaut und aktuell hältst, ohne ein Doku-Team zu haben, beschreibt der Artikel zu Help Center pflegen ohne Doku-Team den Ansatz, der für kleine SaaS-Teams realistisch ist.
HappySupport kombiniert DOM/CSS-basierte Dokumentation mit GitHub Sync. Neue Onboarding-Guides werden einmal erstellt und bleiben automatisch mit dem Produktstand verbunden. Wenn ein Release die UI ändert, erkennt HappyAgent welche Artikel betroffen sind, ohne dass jemand aktiv suchen muss.
