Software-Benutzerhandbuch erstellen: Anleitung + Vorlage

Ein Software-Benutzerhandbuch ist die Anleitung für Endnutzer, die erklärt, wie man eine App installiert, einrichtet und für echte Arbeit nutzt. Die besten sind nach Aufgaben aufgebaut, nicht nach Menüs: Erste Schritte, Aufgabenkapitel mit nummerierten Schritten und passenden Screenshots, Fehlerbehebung, Referenz und ein Glossar.

Das gehört in jedes Software-Benutzerhandbuch:

1. Eine Seite „Erste Schritte“, die neue Nutzer in unter 5 Minuten zu einem nützlichen Ergebnis bringt.
2. Aufgabenkapitel mit handlungsorientierten Titeln wie „Bericht exportieren“, nummerierten Schritten und einem Screenshot pro Schritt.
3. Eine Tabelle zur Fehlerbehebung, die jedem Symptom Ursache und Lösung zuordnet.
4. Referenzseiten für Einstellungen, Tastenkürzel, Limits und Begriffe.
5. Ein Versionsstempel, der das Handbuch an das App-Release bindet, das es beschreibt.

Dieser Guide ist für Entwickler, Architekten und QA-Leads, die für ein Handbuch verantwortlich sind, aber nicht hauptberuflich Dokus schreiben. Du bekommst eine Struktur, eine Vorlage zum Einfügen, ausgearbeitete Beispiele und Screenshot-Regeln, die auch das nächste Release überstehen. Wenn du nur eine Anleitung für eine einzelne Aufgabe brauchst, fang stattdessen mit diesem Guide zu Schritt-für-Schritt-Anleitungen mit Screenshots an.

Was ist ein Software-Benutzerhandbuch?

Ein Software-Benutzerhandbuch ist die vollständige, versionierte Anleitung zu einem Produkt für die Leute, die es nutzen. Es beantwortet „Wie mache ich X?“ für jede Aufgabe, die zählt, und zwar in der Reihenfolge, in der ein neuer Nutzer ihnen begegnet.

Die Begriffe überschneiden sich. Ein Anwenderhandbuch oder User Guide ist in der Praxis dasselbe, oft als schlankere Webversion. Ein Help Center ist das Zuhause des Handbuchs im Web, ergänzt um FAQs und eine Suche. Eine Wissensdatenbank ist ein größerer Pool an Artikeln, oft vom Support auf Basis echter Tickets geschrieben.

Die Zielgruppe zählt mehr als der Name. Endnutzer brauchen Aufgaben. Admins brauchen Einrichtung, Rollen, Sicherheit und Limits. Deshalb liefern viele Teams ein Benutzerhandbuch und ein Admin-Handbuch aus, die sich ein gemeinsames Glossar teilen.

Benutzerhandbuch vs. Schulungshandbuch, SOP, README und Runbook

PDF, Web-Hilfe oder In-App-Hilfe

Wähl das Format danach, wie oft du auslieferst. Ein Handbuch, das der App hinterherhinkt, ist schlimmer als gar keins, weil Leute Schritten folgen, die nicht mehr funktionieren.

Die meisten Teams nutzen die Web-Hilfe als Quelle, exportieren pro Major-Version ein PDF und ergänzen In-App-Links zur passenden Seite. Ein Web-Handbuch sollte außerdem grundlegende Regeln zur Barrierefreiheit nach WCAG erfüllen: echte Überschriften, Alt-Text und genug Kontrast.

Was in ein Software-Benutzerhandbuch gehört

So ist ein gutes Handbuch aufgebaut, von vorne nach hinten, gruppiert nach Zweck.

• Deckblatt. Produktname, App-Version, Datum und Zielgruppe.
• Über dieses Handbuch. Zielgruppe, Umfang und Konventionen für Labels, Tasten und Hinweise.
• Systemanforderungen. Betriebssystemversionen, Browser, Hardware, Netzwerkregeln und Konten.
• Installation und Anmeldung. Installation, Lizenz- oder SSO-Einrichtung und erste Anmeldung.
• Erste Schritte. Eine nützliche Aufgabe, die weniger als 5 Minuten dauert.
• Rundgang durch die Oberfläche. Ein Übersichts-Screenshot mit nummerierten Callouts und einer Legende.
• Aufgabenkapitel. Ein Thema pro Aufgabe, gruppiert nach Ziel.
• Fehlerbehebung. Eine Tabelle mit Symptom, Ursache und Lösung.
• Referenz. Einstellungen, Tastenkürzel, Limits und Fehlercodes.
• Glossar und FAQ. Produktbegriffe, jeder genau einmal definiert.
• Support kontaktieren. Wohin man sich wendet und was in ein Ticket gehört.
• Revisionshistorie. Was sich in jeder Version geändert hat.

Eine Beispiel-Einleitung für „Über dieses Handbuch“

Viele bleiben schon auf Seite eins hängen. Kopier das hier und setz deine Details ein:

Dieses Handbuch erklärt, wie du Acme Insights 4.2 auf Mac und Windows nutzt, um Daten anzubinden, Dashboards zu bauen und Berichte zu teilen. Es richtet sich an Analysten und Team-Admins. Aufgaben, die Admin-Rechte brauchen, sind mit Admin markiert, und Bezeichnungen der Oberfläche erscheinen fett. Wenn deine App eine andere Version anzeigt, prüf zuerst die Versionsliste auf dem Deckblatt.

Die Abschnitte auf Diátaxis abbilden

Das Diátaxis-Framework teilt Dokus danach, was der Leser braucht, in vier Arten ein. Ein Benutzerhandbuch nutzt alle vier, und wenn du sie trennst, bleiben die Seiten kurz.

Der formale Standard ist ISO/IEC/IEEE 26514. Für ein gutes Handbuch brauchst du ihn nicht, aber Teams in regulierten Branchen berufen sich oft darauf.

So schreibst du ein Software-Benutzerhandbuch in 7 Schritten

1. Leser und ihre 10 wichtigsten Aufgaben festlegen

Liste auf, wer das Handbuch liest (Endnutzer, Admins, Support-Mitarbeitende) und welche 10 Aufgaben diese Leute am häufigsten erledigen. Rate nicht. Zieh die Aufgaben aus Support-Tickets, Suchbegriffen im Help Center, Sales-Demos und QA-Testfällen, die ohnehin schon jeden Ablauf in der richtigen Reihenfolge auflisten.

Diese 10 Aufgaben werden deine ersten Kapitel. Alles andere kann bis Version 2 warten.

2. Eine aufgabenbasierte Gliederung bauen

Benenne jedes Thema nach Handlung und Objekt: „Bericht exportieren“, nicht „Das Menü Export“. Leser suchen nach dem, was sie tun wollen, nicht danach, wo ein Button sitzt.

Gruppiere Aufgaben nach Ziel (Daten anbinden, Dashboards bauen, Ergebnisse teilen), in der Reihenfolge, in der ein neuer Nutzer ihnen begegnet. Handbücher, die Menü für Menü vorgehen, sind leicht zu schreiben und schwer zu benutzen.

3. Vor dem Schreiben einen Styleguide festlegen

Ein einseitiger Styleguide verhindert, dass fünf Autoren fünf verschiedene Handbücher schreiben. Leg diese Punkte vorab fest:

• UI-Labels fett, mit exakter Groß- und Kleinschreibung. Schreib Als Entwurf speichern, wenn der Button „Als Entwurf speichern“ heißt. Der Google Developer Documentation Style Guide setzt UI-Elemente ebenfalls fett.
• Eine Regel für Verben. Der Microsoft Writing Style Guide empfiehlt „select“ (auf Deutsch meist „auswählen“), weil das für Maus, Touch und Tastatur funktioniert. Im Apple Style Guide klickst oder tippst du auf einen Button. Entscheide dich für eine Regel und bleib dabei.
• Ein Begriff pro Konzept. Wenn es auf Seite 3 ein „Workspace“ ist, ist es auf Seite 30 kein „Projekt“.
• Hinweise und Warnungen. Ein einheitlicher Look für Hinweis, Wichtig und Warnung. Setz sie sparsam ein, sonst überspringen Leser sie.
• Screenshot-Regeln. Zuschnitt, Marker, Schwärzung und Dateinamen (siehe die Standards weiter unten).

4. Jedes Aufgabenthema nach einem festen Muster schreiben

Jedes Aufgabenthema hat dieselben fünf Teile: ein Ziel in einer Zeile, Bevor du anfängst (benötigte Rollen, Tarife oder Daten), nummerierte Schritte mit je einer Aktion, das Ergebnis, das der Bildschirm zeigt, und einen Link zum nächsten Schritt. Die Beispiel-App in diesem Artikel hat eine englische Oberfläche, deshalb bleiben ihre UI-Labels englisch, genau wie in den Screenshots. Hier ist ein komplett ausgearbeitetes Thema zum Kopieren:

## Alert-E-Mails einrichten

Erhalte einmal am Tag eine E-Mail mit allen Berichten, deren Zahlen sich geändert haben.

**Bevor du anfängst:** Du brauchst die Rolle Editor oder Admin. Alerts gehen
an die E-Mail-Adresse in deinem Profil.

1. Geh zu **Settings** > **Notifications**.
2. Wähle unter **Frequency** die Option **Daily digest** aus.
3. Wähle **Save** aus.

**Ergebnis:** Ein grünes Banner *Settings saved* erscheint. Dein erster Digest
kommt um 08:00 Uhr in deiner Zeitzone an.

**Weiter:** [Festlegen, welche Berichte Alerts senden](choose-alert-reports.md)

Marker 2 im Bild ist Schritt 2 im Text. Ein einziger Pfeil sitzt auf dem Bedienelement, das die Aufgabe abschließt, und das E-Mail-Feld liegt unter einem deckenden Rechteck. Der oben verlinkte Guide zu Schritt-für-Schritt-Anleitungen behandelt das Schreiben von Schritten ausführlich.

5. Screenshots aufnehmen und annotieren

Nimm die Screenshots erst auf, wenn der Text steht: mit einem Demo-Konto mit Fake-Daten und in der Fenstergröße, die deine Nutzer verwenden. Schneide jedes Bild auf den Bereich zu, um den es im Schritt geht, und füg Marker hinzu, die zu den Schrittnummern passen.

6. Das Handbuch gegen den Build testen

Bitte jemanden aus dem Team, der das Thema nicht geschrieben hat, es mit einem frischen Testkonto auf dem Release Candidate durchzuspielen. Sag nichts und notier jede Stelle, an der die Person stockt, rät oder das Falsche anklickt. Jedes Stocken ist ein Bug im Handbuch.

QA-Teams können das in den Abnahmetest (User Acceptance Testing) einbauen: Nimm „Handbuchthema X befolgen“ als Testfall auf und erfasse Handbuch-Bugs neben Produkt-Bugs. Eine gute Bug-Report-Vorlage funktioniert für beides.

7. Veröffentlichen, versionieren und pflegen

Veröffentliche dort, wo Nutzer ohnehin nachsehen: im Hilfe-Menü der App, auf deiner Doku-Website oder an beiden Orten. Versieh das Deckblatt oder jede Seite mit App-Version und Datum.

Koppel Updates dann an Releases. Wenn die Release Notes eine UI-Änderung erwähnen, wird gleichzeitig ein Ticket für das Handbuch eröffnet.

Vorlage für ein Software-Benutzerhandbuch (zum Kopieren)

Füg sie in dein Doku-Repo, in Word oder in Google Docs ein. Ersetze die Platzhalter in eckigen Klammern und lösch Abschnitte, die nicht passen.

# Benutzerhandbuch [Produktname]

- **Version:** [App-Version, zum Beispiel 4.2]
- **Zuletzt aktualisiert:** [JJJJ-MM-TT]
- **Gilt für:** [Mac, Windows, Web; Editionen oder Tarife]
- **Zielgruppe:** [Endnutzer, Admins]

## 1. Über dieses Handbuch

Dieses Handbuch erklärt, wie du [Produkt] nutzt, um [wichtigste Ergebnisse] zu erreichen.
Es richtet sich an [Zielgruppe]. Aufgaben nur für Admins sind mit **Admin** markiert.
UI-Labels erscheinen **fett**. Tasten erscheinen als `Strg+S`.

## 2. Systemanforderungen

- Betriebssysteme: [Mindestversionen von macOS und Windows]
- Browser: [Namen und Mindestversionen]
- Hardware: [RAM, Speicherplatz]
- Netzwerk: [freizugebende Domains oder Ports]
- Konten: [Lizenz, SSO, Rollen]

## 3. Installation und Anmeldung

1. [Installer besorgen]
2. [Installieren]
3. [Aktivieren oder per SSO anmelden]

## 4. Erste Schritte: [erste nützliche Aufgabe]

Ziel: [was der Leser in unter 5 Minuten erreicht hat]

1. [Schritt]
2. [Schritt]
3. [Schritt]

Ergebnis: [woran man den Erfolg erkennt]

## 5. Rundgang durch die Oberfläche

![Hauptfenster mit den nummerierten Bereichen 1 bis 6](images/ui-tour_v4.2.png)

| # | Bereich | Funktion     |
|---|---------|--------------|
| 1 | [Name]  | [Eine Zeile] |
| 2 | [Name]  | [Eine Zeile] |

## 6. Aufgaben

### 6.1 [Objekt + Verb, zum Beispiel Bericht exportieren]

Ziel: [ein Satz]

Bevor du anfängst: [Rollen, Daten, Einstellungen]

1. [Eine Aktion pro Schritt, UI-Labels **fett**]
2. [Schritt]

Ergebnis: [was der Bildschirm zeigt]

Weiter: [Link zur nächsten Aufgabe]

### 6.2 [Nächste Aufgabe]

## 7. Konzepte

### 7.1 [So funktioniert X]

## 8. Fehlerbehebung

| Symptom                | Wahrscheinliche Ursache | Lösung               |
|------------------------|-------------------------|----------------------|
| [Was der Nutzer sieht] | [Warum]                 | [Schritte oder Link] |

## 9. Referenz

### 9.1 Einstellungen

| Einstellung | Standardwert | Funktion     |
|-------------|--------------|--------------|
| [Name]      | [Wert]       | [Eine Zeile] |

### 9.2 Tastenkürzel

| Aktion   | Mac     | Windows  |
|----------|---------|----------|
| [Aktion] | [Cmd+S] | [Strg+S] |

### 9.3 Limits

[Dateigrößen, Zeilenlimits, Rate Limits, Aufbewahrungsdauer von Daten]

## 10. Glossar

- **[Begriff]:** [Definition]

## 11. FAQ

### [Eine Frage, die Nutzer stellen]

[Antwort in 2 bis 4 Sätzen]

## 12. Support kontaktieren

Sieh zuerst unter Fehlerbehebung nach. Gib in deinem Ticket die App-Version,
dein Betriebssystem, die Schritte zum Reproduzieren, das erwartete und das
tatsächliche Verhalten an, dazu einen Screenshot mit abgedeckten persönlichen
Daten.

Kontakt: [Support-URL oder E-Mail]

## 13. Revisionshistorie

| Handbuchversion | App-Version | Datum        | Änderungen               |
|-----------------|-------------|--------------|--------------------------|
| [1.0]           | [4.2]       | [JJJJ-MM-TT] | [Erste Veröffentlichung] |

In Word oder Google Docs: Nutz echte Formatvorlagen für Überschriften (Überschrift 1 für Kapitel, Überschrift 2 für Themen) statt fettem Text. Füg dann in Word oder Google Docs ein automatisches Inhaltsverzeichnis ein, das sich aktualisiert, wenn sich Kapitel ändern. Speichere die Datei in Word als .dotx-Vorlage, damit jedes Handbuch mit denselben Formatvorlagen startet.

Du brauchst ein PDF? Wandle das Markdown mit dem kostenlosen Markdown-zu-PDF-Tool um. Es kommt mit Tabellen und Codeblöcken klar. Bilder müssen über erreichbare URLs eingebunden sein, etwa als Dateien auf deiner Doku-Website.

Screenshot-Standards für Benutzerhandbücher

An Screenshots scheitern die meisten Handbücher. Sie veralten, verraten Kundendaten oder zeigen den ganzen Bildschirm, obwohl der Schritt nur einen Button braucht. Nutz diese Tabelle als deinen visuellen Styleguide. Zu Bildgrößen, Tools und dem kompletten Ablauf von der Aufnahme bis zur Veröffentlichung findest du mehr im Leitfaden für Screenshots in technischer Dokumentation.

Unschärfe oder Verpixelung reichen für unkritische Details im Hintergrund. Secrets, Tokens, E-Mail-Adressen und Kundendatensätze bekommen immer das deckende Rechteck. Für Alt-Text bei Bildern wie diesen ist das W3C-Tutorial zu Bildern die Referenz.

Ein Screenshot-Tool mit den passenden Markup-Werkzeugen deckt den Großteil dieser Tabelle in einem Durchgang ab. In ScreenSnap Pro setzt das Zähler-Werkzeug nummerierte Marker der Reihe nach, sodass Marker 3 immer zu Schritt 3 passt. Pfeile, der Textmarker, Text-Callouts und ein deckend gefülltes Rechteck zum Schwärzen gehören zu denselben 17 Werkzeugen, und Hintergrund-Presets sorgen dafür, dass jedes Bild gleich aussieht. Dazu kommen OCR, Pin Screenshot, GIF-Aufnahme und Website Capture für öffentliche URLs, die in den nächsten drei Tipps vorkommen.

Wann ein GIF besser ist als ein Standbild

Nimm ein kurzes GIF, wenn die Bewegung selbst die Anleitung ist: Drag and Drop, Hover-Menüs, die verschwinden, sobald du woanders hinklickst, oder ein Ablauf, der in vier Sekunden über drei Bildschirme geht. Schneide es so eng zu wie ein Standbild, halte es unter 8 Sekunden und stell die geschriebenen Schritte daneben, denn ein GIF kann niemand durchsuchen.

Hier ist Schritt 3 aus dem Beispiel „Erste Schritte“ weiter unten als kurze Schleife. Der Schritttext steht oben in einer Beschriftungsleiste, sodass der Clip auch dann verständlich bleibt, wenn ihn jemand einzeln teilt.

Anleitungen pro Plattform: GIFs auf dem Mac aufnehmen und den Bildschirm unter Windows als GIF aufnehmen.

Exakte UI-Labels per OCR kopieren und den Referenz-Screenshot anpinnen

Labels im Text müssen Buchstabe für Buchstabe zum Build passen. Tipp „Als Entwurf speichern“ nicht aus dem Gedächtnis ab. Nimm den Dialog auf und kopier seinen Text per OCR (auf dem Mac oder mit einer beliebigen Methode für Screenshot zu Text).

Füg die kopierten Labels direkt in den Schritt ein. Format, CSV und Download stimmen dann exakt mit dem Build überein, einschließlich Groß- und Kleinschreibung.

Pinne diesen Screenshot dann an, damit er beim Schreiben über deinem Editor schwebt (Fenster im Vordergrund halten auf dem Mac oder unter Windows). So prüfst du jedes Label, ohne das Fenster zu wechseln.

Wenn das Thema fertig ist, schließ den Pin und pinne den nächsten Bildschirm an.

Lange Web-App-Seiten: ganzseitige Aufnahme per URL

Eine lange öffentliche Einstellungs- oder Statusseite passt nicht auf einen Bildschirm. Eine ganzseitige Aufnahme per URL erfasst sie in einem Bild (auf dem Mac, unter Windows).

Die Statusseite oben ist öffentlich, also kann ein Aufnahmedienst sie laden. Ein einziges Bild enthält alle 2.880 Pixel mit Uptime-Balken und Vorfallshistorie, während ein normaler Screenshot nur den oberen Teil zeigt.

Die Aufnahme per URL rendert die Seite auf einem Server. Seiten hinter einem Login, auf localhost oder in einem VPN erreicht sie deshalb nicht. Die meisten Seiten, die ein Handbuch für eine Web-App zeigt, liegen hinter einem Login. Nutz für sie die eingebaute ganzseitige Aufnahme des Browsers:

• Chrome oder Edge: Öffne die DevTools, drück Cmd+Shift+P (Mac) oder Strg+Shift+P (Windows) und führ Capture full size screenshot aus.
• Firefox: Klick mit der rechten Maustaste auf die Seite, wähle Bildschirmfoto aufnehmen und dann Gesamte Seite speichern.

Wenn der lange Teil nicht in der Seite, sondern in einem Panel scrollt, nimm das Fenster oder einen Bereich in Abschnitten auf.

Entwürfe zum Review schicken: Ein Cloud-Link ist der schnelle Weg, um für ein Bild die Freigabe einer Fachperson einzuholen. Leg die finalen Dateien in deinem Doku-Repo oder deiner Wissensdatenbank ab, denn Cloud-Links sind zum schnellen Teilen gedacht, nicht zum Hosten der Bilder im Handbuch.

Von den Machern dieser Seite

Genug von langweiligen Screenshots? Probier ScreenSnap Pro.

Schöne Hintergründe, professionelle Anmerkungen, GIF-Aufnahme und sofortiges Teilen in der Cloud, alles in einer App. Einmal 34 $ zahlen, für immer besitzen.

Preis und Funktionen ansehen

Beispiele für Software-Benutzerhandbücher

Zuerst drei Auszüge, die mit der Vorlage gebaut sind, danach drei echte Handbücher, die einen genauen Blick lohnen.

Beispiel 1: eine Seite „Erste Schritte“

## Ersten Bericht in 5 Minuten erstellen

Erhalte ein Live-Umsatzdiagramm aus den Beispieldaten, die in jedem Workspace stecken.

1. Wähle in der linken Navigation **Dashboards** und dann **New dashboard** aus.
2. Wähle **Use sample data** aus.
3. Zieh **Orders** auf die Arbeitsfläche.

**Ergebnis:** Ein Balkendiagramm der Bestellungen nach Region erscheint. Mach als
Nächstes den Rundgang durch die Oberfläche.

Der Leser bekommt schnell ein echtes Ergebnis, ganz ohne eigene Daten. Schritt 3 ist eine Ziehbewegung, also ist das die eine Stelle, an der sich ein kurzes GIF seinen Platz verdient, wie die Schleife im GIF-Abschnitt oben. Die anschließende Seite mit dem Rundgang nutzt ein Übersichtsbild mit nummerierten Callouts und einer Legende:

Beispiel 2: ein Aufgabenthema

## Bericht als CSV exportieren

Hol dir die Rohdaten hinter jedem Diagramm, um sie in einer Tabellenkalkulation zu nutzen.

**Bevor du anfängst:** Du brauchst die Rolle Editor. Exporte sind auf
100.000 Zeilen begrenzt.

1. Öffne den Bericht.
2. Wähle **Share** und dann **Export** aus.
3. Wähle unter **Format** die Option **CSV** und dann **Download** aus.

**Ergebnis:** Die Datei wird in deinem Downloads-Ordner gespeichert. Wenn **Export**
ausgegraut ist, sieh unter Fehlerbehebung nach.

Leser stoßen mitten in der Aufgabe auf Limits. Nenn sie deshalb unter „Bevor du anfängst“ und wiederhole sie im Referenzkapitel.

Beispiel 3: eine Tabelle zur Fehlerbehebung

Jede Zeile beginnt mit dem, was der Nutzer sieht, nennt eine wahrscheinliche Ursache und liefert eine Lösung mit exakten Labels.

Was du dir von 3 echten Handbüchern abschauen kannst

Blender Manual. Jede Werkzeugseite beginnt mit einem Reference-Kasten: der Modus, wo das Werkzeug liegt, und sein Tastenkürzel. Bei Extrude Region sind das Edit Mode, die Toolbar und E, gefolgt von Bildern, in denen ein einzelner Vertex und eine einzelne Kante extrudiert werden. Übernimm den Reference-Kasten, damit Leser, die die Aufgabe schon kennen, die Fakten in zwei Sekunden finden.

GIMP User Manual. Das Handbuch ist direkt mit der App verdrahtet. Drück F1, während der Mauszeiger über einem Dialog oder Menüeintrag liegt, und GIMP öffnet die passende Handbuchseite (Context Help). Jede Seite endet außerdem mit einem Link „Report a documentation error“. Übernimm beides: Verlinke jeden Bildschirm deiner App mit seinem Handbuchthema und gib Lesern einen schnellen Weg, eine falsche Seite zu melden.

Visual Studio Code Docs. Die Seiten sind Markdown-Dateien in einem öffentlichen GitHub-Repo, und Leser können Änderungen vorschlagen. Jede Seite behandelt ein Feature, mit Screenshots dort, wo die Oberfläche zählt. Übernimm das Docs-as-Code-Modell: Das Handbuch liegt neben dem Code und wird mit dem Release ausgeliefert.

Tools zum Schreiben und Veröffentlichen eines Benutzerhandbuchs

Das eine beste Tool gibt es nicht. Es hängt davon ab, wer schreibt und wie oft du auslieferst.

Einen breiteren Vergleich findest du in dieser Übersicht der Tools für Prozessdokumentation oder in den Guides zu Scribe-Alternativen und Tango-Alternativen.

Keins dieser Tools macht von sich aus gute Screenshots. Ein Screenshot-Tool ist bei allen die Ebene für Aufnahme und Markup: aufnehmen, annotieren, als PNG exportieren und einfügen. Genau dort passt ScreenSnap Pro hin. Es generiert keine Schrittanleitungen automatisch wie Scribe oder Tango und hostet keine Dokus.

Das Handbuch nach jedem Release aktuell halten

Ein Handbuch stimmt am Tag des Releases und beginnt am nächsten Morgen abzudriften. Die Lösung ist eine Checkliste, die bei jedem Release läuft, plus ein Screenshot-Inventar: eine Zeile pro Bild, mit der App-Version, auf der es aufgenommen wurde.

Die Release-Checkliste:

1. Den Diff der Release Notes lesen. Liste umbenannte Labels, verschobene Buttons, neue Bildschirme und entfernte Features auf.
2. Das Screenshot-Inventar prüfen. Markiere jede Zeile, die der Diff berührt, als „neu aufnehmen“, „neu“ oder „ausmustern“.
3. Geänderte Bildschirme neu aufnehmen. Gleicher Demo-Tenant, gleiche Fenstergröße, gleiche Aufmachung.
4. Labels im Text korrigieren. Durchsuche das Handbuch nach jedem alten Label.
5. Den Versionsstempel hochzählen. Füg eine Zeile in der Revisionshistorie hinzu.
6. Feedback und Suchbegriffe auswerten. Suchen ohne Treffer und „Nicht hilfreich“-Stimmen zeigen auf schwache Themen.

Wenn dein Team einen Changelog führt, zeigen diese Changelog-Beispiele Formate, mit denen Schritt 1 schnell geht.

Häufige Fehler in Software-Benutzerhandbüchern

• Eine Feature-Tour statt Aufgaben. „Das Menü Berichte“ sagt, was es gibt, nicht, wie man eine Aufgabe erledigt.
• Vollbild-Screenshots. Das Ziel ist nur ein winziger Punkt, und andere Apps rutschen ins Bild.
• Veraltete Screenshots. Ein einziges veraltetes Bild lässt Leser an jedem Schritt drumherum zweifeln.
• Labels, die nicht zur Oberfläche passen. Wenn im Text „Exportieren“ steht und auf dem Button „Herunterladen“, ist das Vertrauen weg.
• Keine Fehlerbehebung. Leute öffnen das Handbuch, wenn etwas kaputt ist.
• Kundendaten in Screenshots. Echte Namen, E-Mail-Adressen und Tokens in einem öffentlichen Handbuch sind ein Datenleck.
• Handbücher nur als Video. Videos sind schwer zu durchsuchen und teuer zu aktualisieren. Setz sie neben geschriebene Schritte, nicht an ihre Stelle.

Häufig gestellte Fragen

Wie schreibt man ein Software-Benutzerhandbuch?

Fang mit deinen Lesern und ihren 10 wichtigsten Aufgaben an und bau dann eine aufgabenbasierte Gliederung mit handlungsorientierten Titeln. Leg einen Styleguide fest und schreib jede Aufgabe mit nummerierten Schritten und einem Screenshot pro Schritt. Teste das Handbuch auf dem Release Candidate, veröffentliche es mit Versionsstempel und aktualisiere es bei jedem Release.

Was ist ein gutes Beispiel für ein Benutzerhandbuch?

Gute öffentliche Beispiele sind das Blender Manual, das GIMP-Benutzerhandbuch und die Visual Studio Code Docs. Jedes ist um Aufgaben oder Werkzeuge herum aufgebaut, nutzt Visuals dort, wo die Oberfläche zählt, und ist an eine Version gebunden.

Welche Arten von Handbüchern gibt es?

Gängige Arten sind Software-Benutzerhandbücher, Admin- und Installationshandbücher, Schulungshandbücher für Mitarbeitende, SOPs, Servicehandbücher für Reparaturen und Runbooks für Engineers in Rufbereitschaft. Sie unterscheiden sich vor allem durch ihre Leser.

Wie erstelle ich mein eigenes Handbuch?

Kopier die Vorlage oben in Word, Google Docs oder eine Markdown-Datei. Schreib zuerst die Seite „Erste Schritte“ und deine 5 wichtigsten Aufgaben, füg Screenshots hinzu und lass dann jemanden das Handbuch mit einem frischen Konto durchspielen.

Was ist das Standardformat für ein Benutzerhandbuch?

Die meisten folgen dieser Reihenfolge: Deckblatt mit Version, Über dieses Handbuch, Anforderungen, Installation, Erste Schritte, Aufgaben, Fehlerbehebung, Referenz, Glossar und Support. ISO/IEC/IEEE 26514 ist der formale Standard, aber eine konsequent aufgabenbasierte Struktur zählt mehr.

Gibt es eine Handbuch-Vorlage für Word?

Die eingebauten Vorlagen von Word passen selten zu Softwarehandbüchern. Füg die Vorlage aus diesem Artikel in Word ein, wende die Formatvorlagen Überschrift 1 und Überschrift 2 an, füg ein automatisches Inhaltsverzeichnis ein und speichere das Ganze als .dotx-Vorlage.

Mit welchem Programm erstellt man Benutzerhandbücher am besten?

Das hängt von deinem Team und deinem Release-Tempo ab. Word oder Google Docs passen zu kleinen Handbüchern, MkDocs oder Docusaurus zu Engineering-Teams, MadCap Flare zu großen Handbüchern in mehreren Formaten und Wissensdatenbank-Plattformen zu Help Centern, die vom Support getrieben sind.

Wo finde ich das Benutzerhandbuch?

Sieh zuerst im Hilfe-Menü der App nach, denn es verlinkt meist auf das aktuelle Handbuch. Probier danach die Doku- oder Support-Website des Herstellers oder such nach dem Produktnamen plus „Benutzerhandbuch“.

Wo kann ich Benutzerhandbücher kostenlos herunterladen?

Softwarehersteller veröffentlichen ihre Handbücher kostenlos auf ihren eigenen Doku- oder Support-Websites, oft mit einem PDF pro Version. Nutz die Website des Herstellers und nicht die Handbuchsammlungen von Drittanbietern, denn die können veraltet sein.

Die erste Version noch diese Woche ausliefern

Warte nicht auf ein vollständiges Handbuch. Liefere die Seite „Erste Schritte“, deine 5 wichtigsten Aufgaben und eine Tabelle zur Fehlerbehebung aus, alle mit dem aktuellen Versionsstempel. Ergänze dann jedes Mal ein Thema, wenn der Support dieselbe Frage zum zweiten Mal beantwortet.

Wenn dein Handbuch viele annotierte Screenshots braucht, erledigt ScreenSnap Pro Aufnahme, nummerierte Marker, Schwärzen mit deckenden Rechtecken und GIFs in einer App. Es ist ein einmaliger Kauf für 34 $: 1 Lizenz für 2 Computer, Mac oder Windows. Zu den Preisen.