Benutzerhandbücher haben ein Imageproblem. Die meisten Teams schreiben sie, weil es eben jemand tun muss, niemand hat Freude daran, und am Ende steht ein Ordner voller Dokumente, die die Oberfläche korrekt beschreiben und trotzdem niemandem helfen.
Die Anleitungen, die funktionieren, haben eine bestimmte Gemeinsamkeit: Sie sind danach gegliedert, was der Nutzer erreichen will, nicht danach, was das Produkt enthält. Dieser eine Perspektivwechsel erklärt den größten Teil des Unterschieds zwischen Dokumentation, nach der Menschen suchen, und Dokumentation, die sie ignorieren.
Dieser Leitfaden zeigt, welche Arten von Benutzerhandbüchern sich lohnen, welche Struktur für jede funktioniert, acht Beispiele für Formate, die Sie übernehmen können, und wo schriftliche Dokumentation nicht mehr das richtige Werkzeug ist.
Jede gute Anleitungsseite hat dasselbe Grundgerüst, egal um welches Produkt es geht.
Das Wichtigste in Kürze
- Nach Aufgaben gliedern, nicht nach Menüs. Nutzer suchen nach dem, was sie tun wollen, nie nach dem Namen Ihres Features.
- Eine Anleitung, ein Ergebnis. Eine Seite, die drei Aufgaben abdeckt, findet niemand, der nach einer davon sucht.
- Ergebnis und Voraussetzungen zuerst. Nutzer müssen innerhalb von fünf Sekunden wissen, dass sie an der richtigen Stelle sind.
- Screenshots sind teuer. Jeder einzelne ist eine Wartungslast; setzen Sie sie nur dort ein, wo Worte wirklich nicht eindeutig sind.
- Bei Erstaufgaben verlieren schriftliche Anleitungen gegen In-App-Guidance. Dokumentation ist am stärksten bei Tiefe, Referenz und Troubleshooting.
- Support-Tickets sind Ihre Content-Roadmap. Die Fragen, die Nutzer stellen, sind die Anleitungen, die Sie noch nicht geschrieben haben.
Was ist ein Benutzerhandbuch?
Definition Benutzerhandbuch: ein Dokument, das jemandem hilft, eine bestimmte Aufgabe mit einem Produkt zu erledigen, geschrieben aus Sicht des Nutzers und um dessen Ziel herum aufgebaut statt um die Architektur der Software. Im SaaS-Umfeld liegen Benutzerhandbücher meist in einem Help-Center und ergänzen die Guidance im Produkt, statt sie zu ersetzen.
Die Begriffe überschneiden sich auf verwirrende Weise, deshalb lohnt es sich, genau festzulegen, was Sie gerade schreiben:
| Format | Beantwortet | Beste Struktur | Länge |
|---|---|---|---|
| How-to-Anleitung | „Wie mache ich X?“ | Nummerierte Schritte zu einem Ergebnis | 300–800 Wörter |
| Getting-Started-Anleitung | „Wie fange ich an?“ | Der kürzeste Weg zum ersten Nutzen | 500–1.200 Wörter |
| Referenz | „Was bewirkt diese Einstellung?“ | Alphabetisch oder strukturell; überfliegbar | So viel wie nötig |
| Konzeptionelle Anleitung | „Warum funktioniert das so?“ | Fließtext, Diagramme, ein durchgespieltes Beispiel | 800–2.000 Wörter |
| Troubleshooting | „Warum funktioniert das nicht?“ | Symptom → Ursache → Lösung | Kurz, pro Symptom |
Diese Arten zu vermischen, ist der häufigste Fehler in der Dokumentation. Eine How-to-Anleitung, die innehält, um die Architektur zu erklären, verliert den Leser, der es eilig hat; eine konzeptionelle Anleitung, die in nummerierte Schritte zerlegt ist, verliert den Leser, der etwas verstehen will. Entscheiden Sie vor dem ersten Satz, welche Art Sie schreiben.
Benutzerhandbuch erstellen: Schritt für Schritt
Mit der Aufgabe beginnen, in den Worten der Nutzer
Ergebnis und Voraussetzungen zuerst schreiben
Die Schritte entwerfen, während Sie die Aufgabe selbst ausführen
Bilder nur dort einsetzen, wo Worte versagen
Den Kreis schließen: Prüfung, Stolperfallen, nächster Schritt
An jemandem testen, der die Aufgabe noch nie erledigt hat
Einen Verantwortlichen und ein Prüfdatum festlegen
1. Mit der Aufgabe beginnen, in den Worten der Nutzer
Ihr Feature heißt „Segment Builder“. Ihre Nutzer suchen nach „wie schicke ich das nur an Neukunden“. Benennen Sie die Seite nach der Suche, nicht nach dem Feature; der Feature-Name kann im Text vorkommen, wo er trotzdem gefunden wird.
Die beste Quelle für diese Formulierungen ist kostenlos und liegt bereits in Ihrem Helpdesk: der exakte Wortlaut von Support-Tickets plus die Suchanfragen auf Ihrer Website. Beides verrät, wie Menschen die Dinge nennen, wenn niemand zusieht.
2. Ergebnis und Voraussetzungen zuerst schreiben
Beantworten Sie vor dem ersten Schritt zwei Fragen: Was hat der Nutzer, wenn er fertig ist, und was braucht er, bevor er anfängt (eine Berechtigungsstufe, eine verbundene Integration, ein bereits angelegtes Objekt)? Voraussetzungen, die erst in Schritt vier auftauchen, sind der Grund, warum Anleitungen auf halbem Weg abgebrochen werden und die Arbeit halb erledigt liegen bleibt.
3. Die Schritte entwerfen, während Sie die Aufgabe selbst ausführen
Schreiben Sie, während Sie die Aufgabe im Produkt erledigen, nicht aus dem Gedächtnis oder nach einer Spezifikation. Das Gedächtnis überspringt stillschweigend die Schritte, die für Sie längst automatisch ablaufen, und genau an diesen Schritten bleiben neue Nutzer hängen.
Regeln für die Schritte selbst: eine Aktion pro Schritt, das Verb zuerst („Klicken Sie“, „Wählen Sie“, „Geben Sie ein“) und die exakte UI-Bezeichnung in Fettschrift. Wenn ein Schritt ein „währenddessen“ oder ein „beachten Sie“ braucht, sind es zwei Schritte.
4. Bilder nur dort einsetzen, wo Worte versagen
Ein Screenshot für jeden Schritt wirkt gründlich und ist eine Wartungsfalle: Ihre Oberfläche ändert sich, und eine Anleitung mit fünfzehn veralteten Screenshots ist schlechter als eine ganz ohne, weil sie jetzt aktiv falsch informiert. Setzen Sie ein Bild ein, wenn das Ziel wirklich schwer zu beschreiben ist, wenn der Nutzer bestätigen muss, dass er an der richtigen Stelle ist, oder wenn das Ergebnis visuell ist. Ansonsten beschreiben Sie es in Worten.
Wenn Sie Bilder verwenden, schneiden Sie sie eng auf den relevanten Bereich zu und beschriften Sie sie. Ein Screenshot des ganzen Fensters zwingt den Leser, nach dem einen Bedienelement zu suchen, um das es im Satz geht.
5. Den Kreis schließen: Prüfung, Stolperfallen, nächster Schritt
Drei kurze Abschnitte, die in den meisten Anleitungen fehlen und den größten Teil des Nutzens liefern:
- Wie man den Erfolg prüft: das sichtbare Zeichen, dass es geklappt hat, damit der Nutzer nicht raten muss.
- Was oft schiefgeht: die zwei oder drei Fehlerbilder, die der Support am häufigsten sieht, samt Lösung.
- Die naheliegende nächste Aufgabe: wohin ein Nutzer, der gerade fertig geworden ist, typischerweise als Nächstes geht.
6. An jemandem testen, der die Aufgabe noch nie erledigt hat
Geben Sie den Entwurf einer Kollegin oder einem Kollegen außerhalb des Teams und sehen Sie zu, wie sie ihm folgen, ohne zu helfen. Jede Stelle, an der sie zögern, ist ein Fehler. Das dauert fünfzehn Minuten und findet mehr Probleme als jede interne Überprüfung, denn Reviewer lesen die Dokumentation, während das Wissen der Autoren noch mit im Raum ist.
7. Einen Verantwortlichen und ein Prüfdatum festlegen
Dokumentation veraltet still und leise. Eine Anleitung ohne namentlich benannten Verantwortlichen und ohne Prüfdatum ist nach zwei Release-Zyklen falsch, und niemand merkt es, bis ein Kunde es merkt. Zeigen Sie auf der Seite sichtbar das Datum der letzten Aktualisierung; es verrät Nutzern auch, ob sie dem Gelesenen vertrauen können.
8 Formate für Benutzerhandbücher, die sich zum Nachmachen lohnen
Eine Seite, ein Ergebnis: der kürzestmögliche Weg vom leeren Konto zum ersten echten Ergebnis. Konfiguration, Sonderfälle und Alternativen werden bewusst ausgeklammert; alles, was nicht auf dem kritischen Pfad liegt, ist ein Link, kein Absatz.
Ein aufgabenorientierter Titel, Ergebnis und Voraussetzungen ganz oben, fünf bis neun nummerierte Schritte, eine Zeile zur Erfolgsprüfung und zwei häufige Probleme. Sonst nichts.
Parallele Einstiegspunkte („Für Admins“, „Für Editoren“, „Für Betrachter“), jeder mit seinem eigenen kurzen Weg durch dasselbe Produkt. Dasselbe Feature taucht in mehr als einer Anleitung auf, jeweils anders beschrieben.
Vollständig danach gegliedert, was der Nutzer beobachtet, etwa „Mein Import ist fertig, aber es sind keine Datensätze erschienen“, nie nach der internen Ursache. Jedes Symptom verweist auf eine oder mehrere Ursachen mit einer konkreten Lösung.
Jede Option in einer überfliegbaren Tabelle: Name, Funktion, Standardwert und (die Spalte, die die meisten Teams weglassen) was passiert, wenn Sie sie nach der Einrichtung ändern.
Ein realistisches End-to-End-Szenario mit konkreten Namen und Zahlen, das zeigt, wie mehrere Features zusammenspielen, um ein echtes Problem zu lösen, und keine als Geschichte getarnte Feature-Tour.
Eine Aufnahme von 60–120 Sekunden, immer begleitet von denselben Schritten als Text auf derselben Seite.
Die Anleitung läuft direkt in der Anwendung und hebt nacheinander die echten Bedienelemente hervor, während der Nutzer die Aufgabe mit seinen eigenen Daten erledigt.
Dieselben Anweisungen wie in einem schriftlichen Benutzerhandbuch, direkt auf dem echten Bildschirm, den der Nutzer gerade vor sich hat.
Wann eine schriftliche Anleitung das falsche Werkzeug ist
Dokumentation hat einen strukturellen Nachteil, den kein noch so guter Text behebt: Der Nutzer muss das Produkt verlassen, die richtige Seite finden, die Anweisungen im Kopf behalten und zurückkommen. Bei einer Aufgabe, die er zum ersten Mal in einer unbekannten Oberfläche erledigt, geben die meisten genau in dieser Lücke auf.
| Situation | Besseres Werkzeug | Warum |
|---|---|---|
| Erstmalige Einrichtungsaufgabe | Produkttour | Führt durch die echte Oberfläche, statt sie zu beschreiben. |
| Ein Bedienelement mit unklarem Zweck | Tooltip | Beantwortet die Frage dort, wo sie entsteht. |
| Eine Abfolge erster Erfolge | Onboarding-Checkliste | Verfolgt den Fortschritt; ein Dokument kann das nicht. |
| Ein unentdecktes Feature | Hotspot | Niemand liest eine Anleitung zu einem Feature, von dem er nichts weiß. |
| Ein leerer Bildschirm | Text für den Empty State | Die Anweisung gehört dorthin, wo die Leere ist. |
| Tiefe Referenz, Sonderfälle, Admin-Konfiguration | Eine schriftliche Anleitung | Tiefe, Durchsuchbarkeit und Beständigkeit sind die echten Stärken der Dokumentation. |
Die ehrliche Arbeitsteilung: Guidance im Produkt gehört die erste Stunde, der Dokumentation alles danach. Teams, die schriftliche Anleitungen das Onboarding stemmen lassen, landen bei gründlicher Dokumentation und schwacher Aktivierung, und meist ziehen sie daraus den Schluss, die Dokumentation müsse länger werden.
Benutzerhandbücher lebendig halten
✅ Empfehlenswert
- Seiten nach Aufgaben benennen, in den Worten der Nutzer
- Ergebnis und Voraussetzungen zuerst nennen
- Schreiben, während Sie die Aufgabe ausführen
- Eine Aktion pro nummeriertem Schritt
- Einen Prüfschritt ergänzen
- Das Datum der letzten Aktualisierung sichtbar zeigen
- Support-Tickets nach fehlenden Anleitungen durchsuchen
- Die Anleitung direkt aus dem Produkt verlinken
❌ Zu vermeiden
- Das Navigationsmenü in der Struktur der Dokumentation spiegeln
- Drei Aufgaben auf einer Seite abdecken
- Jeden einzelnen Schritt per Screenshot zeigen
- Voraussetzungen in der Mitte verstecken
- In einem How-to die Architektur erklären
- Videos ohne Text-Entsprechung veröffentlichen
- Anleitungen ohne Verantwortlichen lassen
- Erwarten, dass Dokumentation die Aufgabe des Onboardings übernimmt
Lassen Sie die Daten entscheiden, was Sie als Nächstes schreiben
Drei Signale, nach Nützlichkeit geordnet: der exakte Wortlaut wiederkehrender Support-Tickets, Suchanfragen im Help-Center ohne Ergebnis und Seiten mit viel Traffic und hoher Ausstiegsrate. Das erste zeigt, was fehlt, das zweite, was die Leute zu finden erwartet haben, und das dritte, welche bestehende Anleitung versagt.
Anleitungen mit In-App-Guidance kombinieren
Das stärkste Setup ist nicht Dokumentation oder Hilfe im Produkt, sondern Dokumentation, die aus dem Produkt heraus erreichbar ist, genau in dem Moment, in dem die Frage aufkommt, während der Weg beim ersten Mal interaktiv begleitet wird.
- Führen Sie die erste Aufgabe als Tour durch. Machen Sie aus Ihren drei wichtigsten Getting-Started-Anleitungen interaktive Produkttouren und vergleichen Sie die Abschlussraten mit den schriftlichen Versionen.
- Beantworten Sie kleine Fragen direkt vor Ort. Ein Tooltip an einem verwirrenden Feld verhindert die Suche, die zur Anleitung führt, die wiederum zu einem Support-Ticket führt.
- Zeigen Sie die passende Anleitung im Kontext, statt alle auf die Startseite des Help-Centers zu schicken.
- Messen Sie, welche Guidance tatsächlich genutzt wird, mit Produktanalysen, und streichen Sie, was niemand öffnet.
- Kündigen Sie Änderungen an der Dokumentation zusammen mit Feature-Änderungen über das Ankündigungs-Widget an.
Kompassify ist eine No-Code-Digital-Adoption-Plattform für SaaS-Teams: Produkttouren, Checklisten, Tooltips, Ankündigungen, In-App-Umfragen und Analysen an einem Ort. Kostenlos für bis zu 100 monatlich aktive Nutzer, kostenpflichtige Pläne ab $129/Monat, DSGVO-konform und in der EU gehostet.
Machen Sie aus Ihrer besten Anleitung einen interaktiven Walkthrough
Nehmen Sie die Getting-Started-Seite, die Ihre Nutzer am häufigsten lesen, und lassen Sie sie stattdessen direkt in Ihrem Produkt ablaufen: ohne Code, ohne Ticket für die Entwicklung.
Kostenlos starten →Häufig gestellte Fragen
Was ist ein Benutzerhandbuch?
Ein Benutzerhandbuch ist ein Dokument, das jemandem hilft, eine bestimmte Aufgabe mit einem Produkt zu erledigen. Es ist aus Sicht des Nutzers geschrieben und um dessen Ziel herum aufgebaut, nicht um die Architektur der Software. Im SaaS-Umfeld liegt es meist in einem Help-Center und ergänzt die Guidance im Produkt, statt sie zu ersetzen. Das entscheidende Merkmal eines guten Handbuchs: Es ist nach Aufgaben gegliedert, nicht nach der Menüstruktur.
Wie schreibt man ein Benutzerhandbuch?
Beginnen Sie mit der Aufgabe in den eigenen Worten der Nutzer, entnommen aus Support-Tickets und Suchanfragen auf Ihrer Website. Nennen Sie Ergebnis und Voraussetzungen vor dem ersten Schritt. Schreiben Sie die Schritte, während Sie die Aufgabe tatsächlich im Produkt ausführen, statt aus dem Gedächtnis, mit genau einer Aktion pro nummeriertem Schritt und der exakten UI-Bezeichnung in Fettschrift. Fügen Sie Bilder nur dort ein, wo Worte wirklich nicht eindeutig sind. Schließen Sie damit ab, wie man den Erfolg prüft, was oft schiefgeht und was die naheliegende nächste Aufgabe ist. Testen Sie die Anleitung dann an jemandem, der die Aufgabe noch nie erledigt hat.
Welche Arten von Benutzerhandbüchern gibt es?
Fünf Arten sind es wert, unterschieden zu werden: How-to-Anleitungen, die die Frage „Wie mache ich X?“ mit nummerierten Schritten beantworten; Getting-Started-Anleitungen, die den kürzesten Weg zum ersten Nutzen zeigen; Referenzmaterial, das erklärt, was jede Einstellung bewirkt, und überfliegbar statt in Fließtext geschrieben sein sollte; konzeptionelle Anleitungen, die erklären, warum das Produkt auf eine bestimmte Weise funktioniert; und Troubleshooting-Inhalte, die nach Symptomen gegliedert sind. Diese Arten auf einer Seite zu vermischen, ist der häufigste Fehler in der Dokumentation.
Wie lang sollte ein Benutzerhandbuch sein?
So lang, wie die Aufgabe es erfordert, und nicht länger. Ein How-to für eine einzelne Aufgabe umfasst meist 300 bis 800 Wörter mit fünf bis neun Schritten. Eine Getting-Started-Anleitung kommt auf 500 bis 1.200 Wörter. Konzeptionelle Anleitungen können 800 bis 2.000 Wörter rechtfertigen. Referenzmaterial hat keine natürliche Länge. Die wichtige Grenze ist nicht die Wortzahl, sondern der Umfang: Eine Seite sollte ein Ergebnis abdecken, denn eine Seite mit drei Aufgaben findet niemand, der nach einer davon sucht.
Sollten Benutzerhandbücher Screenshots enthalten?
Nur dort, wo Worte es nicht leisten können. Jeder Screenshot ist eine Wartungslast, und eine Anleitung voller veralteter Bilder ist schlechter als eine ganz ohne, weil sie nach einer Änderung der Oberfläche aktiv falsch informiert. Setzen Sie ein Bild ein, wenn das Ziel schwer zu beschreiben ist, wenn der Nutzer bestätigen muss, dass er an der richtigen Stelle ist, oder wenn das Ergebnis selbst visuell ist. Schneiden Sie eng zu und beschriften Sie, statt das ganze Fenster einzufügen.
Wann ist In-App-Guidance besser als ein schriftliches Benutzerhandbuch?
Bei Aufgaben, die jemand zum ersten Mal in einer unbekannten Oberfläche erledigt. Eine schriftliche Anleitung verlangt, dass der Nutzer das Produkt verlässt, die Seite findet, die Schritte im Kopf behält und zurückkommt, und genau in dieser Lücke geben die meisten auf. Produkttouren, Tooltips, Checklisten, Hotspots und Texte für Empty States machen diesen Übersetzungsschritt überflüssig. Schriftliche Dokumentation bleibt das bessere Werkzeug für Tiefe, Referenz, Sonderfälle und Troubleshooting.
Wie hält man Benutzerhandbücher aktuell?
Geben Sie jeder Anleitung einen namentlich benannten Verantwortlichen und ein Prüfdatum, und zeigen Sie auf der Seite sichtbar das Datum der letzten Aktualisierung, damit Leser wissen, ob sie ihr vertrauen können. Koppeln Sie die Überprüfung der Dokumentation an Ihren Release-Prozess, statt sie als separates Projekt zu behandeln. Entscheiden Sie dann anhand von drei Signalen, was Sie zuerst korrigieren: wiederkehrende Support-Tickets, Suchanfragen im Help-Center ohne Ergebnis und Seiten mit viel Traffic und hoher Ausstiegsrate.
Wie entscheidet man, welche Benutzerhandbücher man als Nächstes schreibt?
Durchsuchen Sie Ihre Support-Warteschlange nach Fragen, die sich wiederholen, und verwenden Sie den exakten Wortlaut der Kunden als Seitentitel. Sehen Sie sich dann interne Suchanfragen ohne Ergebnis an, denn sie zeigen, was die Leute zu finden erwartet haben. Beides ist besser, als anhand einer Feature-Liste zu raten, weil es widerspiegelt, was Nutzer tatsächlich erreichen wollen, und nicht, was das Produkt zufällig enthält.