Nutzerfreundliche Fehlermeldungen erklären in einfacher Sprache, was nicht funktioniert hat, warum es passiert ist und welchen konkreten nächsten Schritt der Nutzer unternehmen kann.
Rubrik: Mediendesign & Digitale Medien · Unterrubrik: UX Writing & Content Design · Niveau: Einsteiger Synonyme / Auch bekannt als: Error Messages, Fehlertexte, Validierungsmeldungen
Was sind Fehlermeldungen?
Fehlermeldungen sind Texte, die erscheinen, wenn etwas in einem digitalen Produkt nicht wie erwartet funktioniert: ein Formularfeld ist falsch ausgefüllt, eine Verbindung schlägt fehl, eine Datei kann nicht hochgeladen werden, oder ein Passwort ist zu kurz. Sie sind die vielleicht missachteste Kategorie von Microcopy: Kleine Texte, große Wirkung – und zugleich die wirkungsvollste.
Schlechte Fehlermeldungen sind der häufigste Grund für Frustration, Abbrüche und Support-Anfragen. Gute Fehlermeldungen lösen Probleme, bevor sie zu Support-Fällen werden.
Erklärung
Das Dreisatz-Prinzip
Die meisten Experten für UX Writing empfehlen für Fehlermeldungen ein klares Dreisatz-Muster:
- Was ist passiert? – Eine kurze, neutrale Beschreibung des Fehlers.
- Warum ist es passiert? – Kontext, der dem Nutzer hilft zu verstehen.
- Was kann der Nutzer tun? – Eine konkrete, umsetzbare Handlungsempfehlung.
Nicht jede Fehlermeldung braucht alle drei Elemente – bei einfachen Validierungsfehlern reicht oft Punkt 3 allein. Bei kritischen Fehlern sollten alle drei Punkte enthalten sein.
Ton und Sprache
Keine Schuldzuweisung: Formulierungen wie „Sie haben vergessen" oder „Falsche Eingabe" wirken anklagend. Besser: „Das Passwort muss mindestens 8 Zeichen enthalten."
Kein Technojargon: Fehlercodes wie „Error 500" oder „NullPointerException" sind für Nutzer bedeutungslos. Technische Details gehören ggf. in ausklappbare Details oder Logs für Entwickler.
Keine Entschuldigungen in Reihe: Ein einzelnes „Tut uns leid" kann angemessen sein. Mehrfache Entschuldigungen wirken unaufrichtig.
Aktive Sprache: „Wir konnten keine Verbindung herstellen" ist klarer als „Eine Verbindung konnte nicht hergestellt werden."
Typen von Fehlermeldungen
Validierungsfehler (Inline): Erscheinen direkt beim Eingabefeld, sobald eine falsche Eingabe erkannt wird. Kurz, präzise, ohne Ausrufezeichen.
Systemfehler: Das Produkt selbst ist betroffen (Serverausfall, Timeout). Hier ist Ehrlichkeit wichtig: erklären, was passiert ist, und wenn möglich, wann es behoben sein wird.
Berechtigungsfehler: Der Nutzer versucht, etwas zu tun, wofür er keine Berechtigung hat. Erklären, warum – und wie er die Berechtigung erhalten kann.
Nicht gefunden (404): Die angeforderte Seite existiert nicht. Ein guter 404-Text navigiert den Nutzer weiter, statt ihn im Leeren stehen zu lassen.
Destruktive Aktionen (Bestätigung): Vor dem endgültigen Löschen oder einer nicht rückgängig zu machenden Handlung: klar benennen, was die Konsequenz ist.
Timing: Wann erscheint die Fehlermeldung?
- On Submit: Die Meldung erscheint erst nach dem Absenden des Formulars. Nutzer müssen zurücknavigieren, um Fehler zu korrigieren – frustrierend.
- On Blur: Die Meldung erscheint, sobald ein Nutzer ein Feld verlässt. Besser, weil kontextuell.
- Inline (Real-time): Die Meldung erscheint während der Eingabe. Gut für Passwortanforderungen, aber bei zu frühem Erscheinen irritierend.
Best Practice: Validierungsfehler on Blur zeigen, Erfolgsmeldungen inline, kritische Fehler on Submit oder sofort nach der fehlgeschlagenen Aktion.
Beispiele
Formulare
| Schlechtes Beispiel | Gutes Beispiel |
|---|---|
| „Ungültige E-Mail" | „Bitte gib eine gültige E-Mail-Adresse ein, z. B. name@beispiel.de" |
| „Fehler beim Speichern" | „Deine Änderungen konnten nicht gespeichert werden. Bitte überprüfe deine Internetverbindung und versuche es erneut." |
| „Pflichtfeld" | „Bitte gib deinen vollständigen Namen ein." |
Systemfehler
Schlechtes Beispiel:
„Verbindungsfehler 503. Bitte versuchen Sie es später erneut."
Gutes Beispiel:
„Gerade haben wir technische Probleme. Deine Daten sind sicher – wir arbeiten an einer Lösung. Bitte versuche es in wenigen Minuten erneut."
404-Seite
Schlechtes Beispiel:
„404 – Seite nicht gefunden."
Gutes Beispiel:
„Diese Seite gibt es leider nicht mehr. Vielleicht wurde sie verschoben oder gelöscht? [Button: Zur Startseite] [Button: Suche nutzen]"
In der Praxis
UX Writer arbeiten in der Praxis eng mit Entwicklerinnen und Entwicklern zusammen, um alle möglichen Fehlerzustände zu identifizieren und zu beschriften. Ein guter Ausgangspunkt ist ein Error Inventory: eine vollständige Liste aller Fehlercodes und -zustände im System, mit dem Ziel, jeden durch eine nutzerfreundliche Meldung zu ersetzen.
Dieser Prozess ist oft aufwändiger als gedacht, weil technische Fehler historisch gewachsen sind und in verschiedenen Systemen liegen. Die Zusammenarbeit mit dem Backend-Team ist dabei unverzichtbar.
Vergleich & Abgrenzung
Fehlermeldungen vs. Warnhinweise: Warnungen erscheinen vor einer potenziell problematischen Aktion; Fehlermeldungen reagieren auf eine bereits fehlgeschlagene Aktion.
Fehlermeldungen vs. [Empty States: Texte für leere Zustände](/wiki/mediendesign-digitale-medien/ux-writing/empty-states/): Leere Zustände entstehen, wenn noch kein Inhalt vorhanden ist (kein Fehler); Fehlerzustände entstehen durch technische Probleme oder falsche Eingaben.
Häufige Fragen (FAQ)
Soll ich technische Fehlercodes anzeigen? Nein, nicht im Haupttext. Technische Codes können in einem ausklappbaren Bereich oder im Browser-Konsolen-Log sichtbar sein – für Nutzer gehören sie nicht in die sichtbare Fehlermeldung.
Was tue ich bei unbekannten Fehlern? Sei ehrlich: „Etwas ist schiefgelaufen – wir wissen noch nicht genau warum. Bitte versuche es erneut." ist besser als eine inhaltlich falsche Erklärung.
Wie formuliere ich Fehlermeldungen für Screenreader? Fehlermeldungen müssen für Screenreader zugänglich sein (ARIA-Attribute, role="alert"). Der Text sollte vollständige Sätze enthalten, keine Abkürzungen, und die betroffene Aktion benennen.
Verwandte Einträge
- Microcopy: Kleine Texte, große Wirkung
- Formulare UX: Labels, Platzhalter, Fehlermeldungen
- Empty States: Texte für leere Zustände
- UX Writing: Schreiben für Interfaces
- Plain Language: Verständlich schreiben
Weiterführend
- Nielsen, Jakob (1994): Usability Engineering. Morgan Kaufmann. Kap. Fehlerbehandlung.
- Nolan Haims (2018): „Writing Helpful Error Messages". A List Apart. alistapart.com.
- Microsoft Writing Style Guide: „Error Messages". Microsoft Docs (Stand: 2024).
- Shopify Polaris: „Error messages". polaris.shopify.com (Stand: 2024).
- Nielsen Norman Group: „Error Message Guidelines". www.nngroup.com (Stand: 2023).
