Schrittfolgen mit Abbruch- und Fehlerfällen schreiben

Die Aufgabe und ihren Startzustand begrenzen

Eine Schrittfolge braucht einen eindeutig beschriebenen Ausgangspunkt. Wer darf die Handlung ausführen, welche Unterlagen werden benötigt und welcher Zustand muss bereits vorliegen? Schreiben Sie diese Voraussetzungen vor den ersten operativen Schritt. Ein fehlender Zugang oder ein anderes Modell ist keine Kleinigkeit, wenn dadurch der ganze Ablauf nicht passt.

Formulieren Sie das Ergebnis als sichtbaren Zustand. „Einrichtung abschließen“ ist abstrakt; „die veröffentlichte Zielseite öffnet sich über den gedruckten Code“ lässt sich überprüfen. Ein Artikel muss nicht alle denkbaren Sonderabläufe aufnehmen. Er sollte aber klar sagen, für welche Variante er gilt und wo andere Nutzer einen passenden Weg finden.

Jeden Schritt mit einer Beobachtung verbinden

Verbinden Sie Handlung und erwartete Rückmeldung: Was wird gewählt, was sollte danach sichtbar sein und wie erkennt der Leser die richtige Auswahl? Benennen Sie Oberflächenelemente nach der tatsächlich geprüften Version. Erfinden Sie keine Schaltfläche, weil sie in ähnlichen Produkten üblich wäre.

Trennen Sie Speichern, Veröffentlichen und öffentliches Prüfen, wenn diese Zustände im konkreten System verschieden sind. Eine gespeicherte Eingabe ist dann noch keine bestätigte Live-Ausgabe. Beschreiben Sie diese Trennung anhand der vorhandenen Funktion, statt jedes Produkt mit einem angenommenen Standardablauf zu erklären.

Für die angrenzende Entscheidung hilft außerdem UX Writing: Texte, die durch eine Aufgabe führen.

Fehlerfälle vor dem Schreiben auswählen

Dieses Raster unterstützt die Auswahl relevanter Abzweigungen. Es ist eine eigene Arbeitshilfe zur Redaktion, keine universelle Sicherheitsanleitung für beliebige Tätigkeiten.

Priorisieren Sie Fehler nach ihrem Einfluss auf die Aufgabe. Ein seltenes kosmetisches Detail braucht weniger Raum als die Gefahr, das falsche öffentliche Ziel zu ändern.

Einen kontrollierten Abbruch beschreiben

Ein Abbruchpunkt soll eine konkrete Orientierung geben: welche Handlung jetzt nicht weiter ausgeführt wird, welche Beobachtung gesichert werden soll und wer die Klärung übernehmen kann. „Kontaktieren Sie den Support“ allein ist häufig zu vage. Hilfreicher sind die betroffene Kennung und die sichtbare Fehlermeldung, ohne unnötige vertrauliche Daten anzufordern.

Verlangen Sie keine Wiederholung, die unbeabsichtigt doppelte Anfragen oder Zahlungen auslösen könnte. Auch eine Rücknahme darf nur beschrieben werden, wenn sie für den konkreten Fall belegt ist. Ein allgemeiner Ratgeber kann keine sichere Wiederherstellung eines fremden Systems versprechen.

Fiktives Beispiel: eine Anleitung wird am falschen Objekt begonnen

Ein Team pflegt mehrere ähnliche QR-Kampagnen. Eine Anleitung beginnt bisher mit „Öffnen Sie die Kampagne“. Die Redaktion ergänzt nun den Abgleich von Kennung, Druckort und aktuellem Ziel. Erst wenn diese Angaben stimmen, folgt die Änderung.

Bei einer Abweichung stoppt der Ablauf vor dem Speichern. Die zuständige Person klärt das Inventar. Das zusätzliche Prüfkriterium verhindert nicht garantiert jeden Bedienfehler, macht aber den entscheidenden Zustand sichtbar. Es ist ein redaktioneller Verbesserungsvorschlag und keine behauptete automatische Sperre in der Software.

Den Test mit einem anderen Leser durchführen

Lassen Sie eine Person aus der Zielgruppe die Aufgabe anhand des Textes nachvollziehen. Notieren Sie Stellen, an denen sie raten muss oder einen anderen Zustand sieht. Ein erfolgreicher Durchlauf durch den Autor allein reicht nicht, wenn dieser fehlende Informationen aus eigener Erfahrung ergänzt.

Prüfen Sie mobil außerdem Lesereihenfolge, Beschriftung und die Position der Abbruchhinweise. Wesentliche Warnungen gehören vor die betroffene Handlung. Korrigieren Sie danach auch die kurze FAQ, damit sie nicht einen aufwendig abgesicherten Ablauf wieder auf einen pauschalen Klick reduziert.

Die zugehörige Grundlage erläutert der Leitfaden Direkte Antworten schreiben, die weiterhelfen.

Häufige Fragen.