Fehlermeldungen, die weiterhelfen: UX Writing für typische Fehlerfälle

Es ist kurz vor Mitternacht, der Zug am nächsten Morgen fährt um 6:12 Uhr. Die Verbindung ist gewählt, die Kreditkarte eingegeben, der Button „Zahlungspflichtig buchen“ gedrückt. Dann erscheint ein grauer Kasten: „Es ist ein Fehler aufgetreten. Fehlercode: ERR_PAY_4021.“ Darunter ein einziger Button: „OK“.

Was jetzt? Wurde die Karte belastet? Gibt es ein Ticket oder nicht? Lohnt es sich, es noch einmal zu versuchen, oder wird dann doppelt abgebucht? Die Meldung beantwortet keine dieser Fragen. Sie dokumentiert nur, dass das System ein Problem hat, und gibt dieses Problem ungefiltert an die Person weiter, die gerade einfach nur ein Ticket kaufen wollte.

Fehlermeldungen gehören zu den meistgelesenen Texten eines Produkts, und zu den am wenigsten gepflegten. Sie entstehen oft spät, oft direkt im Code und oft ohne dass jemand aus Design oder Content sie je gesehen hat. Dabei tauchen sie genau in dem Moment auf, in dem Menschen frustriert, unsicher oder unter Zeitdruck sind. Ein guter Fehlertext kann diesen Moment entschärfen. Ein schlechter macht aus einem kleinen Problem einen Abbruch oder einen Anruf beim Support.

Dieser Artikel zeigt, was eine Fehlermeldung leisten muss, welcher Ton passt und wie gute Texte für zehn typische Fehlerfälle aussehen, jeweils mit einer Vorher-nachher-Fassung.

Warum so viele Fehlermeldungen nicht helfen

Die meisten schlechten Fehlermeldungen haben dieselbe Ursache: Sie sind aus Sicht des Systems geschrieben, nicht aus Sicht der Menschen, die es benutzen. Das System weiß, dass eine Anfrage mit dem Statuscode 500 beantwortet wurde, dass ein Token abgelaufen ist oder dass ein Pflichtfeld leer war. Also sagt es genau das. Für Entwicklerinnen und Entwickler ist diese Information wertvoll. Für alle anderen ist sie Rauschen.

Die Nielsen Norman Group (NN/g) hat das schon in ihren zehn Usability-Heuristiken festgehalten. Heuristik Nummer 9 lautet sinngemäß: Hilf Menschen, Fehler zu erkennen, zu verstehen und zu beheben. Fehlermeldungen sollen in einfacher Sprache formuliert sein, das Problem genau benennen und konstruktiv eine Lösung vorschlagen. Die 10 Usability-Heuristiken sind ein guter Prüfstein für jedes Interface, und Fehlermeldungen sind einer der Orte, an denen sie sich am schnellsten überprüfen lassen.

Fehlertexte sind ein klassischer Fall von UX Writing, also dem Schreiben von Texten, die Menschen durch ein Interface führen. Sie gehören zur Microcopy: kurze Texte wie Button-Beschriftungen, Hinweise und Meldungen, die wenig Platz haben, aber viel entscheiden. Gerade weil sie so kurz sind, zählt jedes Wort.

Was eine gute Fehlermeldung beantwortet

Eine hilfreiche Fehlermeldung beantwortet die Fragen, die sich jemand in diesem Moment stellt. Meist sind es drei, manchmal vier.

1. Was ist passiert?

Die Meldung benennt das Problem konkret. „Es ist ein Fehler aufgetreten“ stimmt zwar, sagt aber nichts. Die NN/g bezeichnet solche allgemeinen Meldungen in ihren Error-Message-Guidelines ausdrücklich als zu kontextarm. Besser ist: „Die Zahlung wurde nicht abgeschlossen.“ oder „Die Datei ist zu groß.“

2. Warum ist es passiert?

Die Ursache gehört nur dann in die Meldung, wenn sie beim Beheben hilft. „Die Datei ist größer als 10 MB“ ist nützlich, weil es zeigt, wo das Problem liegt. „Der Upload ist am Payload-Limit des Gateways gescheitert“ ist korrekt, hilft aber niemandem außerhalb des Entwicklungsteams.

3. Was kann ich jetzt tun?

Das ist der wichtigste Teil, und er fehlt am häufigsten. Die NN/g formuliert es deutlich: Das Problem nur zu benennen reicht nicht, die Meldung soll mögliche Lösungen anbieten. Das kann eine konkrete Anweisung sein („Wähle eine Datei unter 10 MB oder verkleinere das Bild“), ein Button für den nächsten Schritt („Erneut versuchen“) oder ein Ausweg, wenn sich das Problem nicht selbst lösen lässt („Ruf uns an, wir buchen das Ticket für dich“).

4. Was ist mit meinen Daten?

Bei allem, was mit Geld, Zeit oder eingegebenen Inhalten zu tun hat, kommt eine vierte Frage dazu: Ist etwas verloren gegangen? Wurde etwas doppelt ausgeführt? Das GOV.UK Design System, die Gestaltungsrichtlinie der britischen Regierung, empfiehlt für Seiten mit Systemfehlern genau das: zu sagen, ob die bisherigen Antworten gespeichert wurden und wie lange sie verfügbar bleiben. Ein Satz wie „Deine Eingaben sind gespeichert“ nimmt oft mehr Druck heraus als jede Entschuldigung.

Der richtige Ton

Inhalt allein reicht nicht. Dieselbe Information kann beruhigen oder verärgern, je nachdem, wie sie formuliert ist.

Keine Schuldzuweisung

„Sie haben ein ungültiges Datum eingegeben“ klingt nach Tadel. Die NN/g rät, Wörter wie „ungültig“, „unzulässig“ oder „falsch“ zu vermeiden, und begründet das mit einem bemerkenswerten Satz: Die Verantwortung für die richtige Nutzung eines Systems liegt bei denen, die es gestalten, nicht bei denen, die es nutzen. Das GOV.UK Design System geht noch weiter und listet Formulierungen wie „verboten“, „unzulässig“ oder „Sie haben vergessen“ als Wörter auf, die in Fehlermeldungen nichts zu suchen haben. Auch „gültig“ und „ungültig“ stehen auf der Liste, weil sie der Meldung nichts hinzufügen.

Statt das Problem bei der Person zu suchen, beschreibt eine gute Meldung, was gebraucht wird: „Gib ein Datum in der Zukunft ein“ statt „Ungültiges Datum“.

Ruhig statt laut

Großbuchstaben, Ausrufezeichen und Warnsymbole in Signalrot erhöhen den Puls, nicht die Verständlichkeit. „FEHLER! Pflichtfeld!“ wirkt wie ein Anschreien. Eine Fehlermeldung darf auffallen, muss aber nicht schimpfen.

Humor nur in Ausnahmefällen

Ein „Hoppla!“ oder ein witziges Bild wirkt beim ersten Mal sympathisch. Beim zehnten Mal, oder wenn gerade eine wichtige Überweisung gescheitert ist, wirkt es zynisch. Die NN/g rät von Humor in Fehlermeldungen ab, weil er sich schnell abnutzt, wenn Menschen einem Fehler häufiger begegnen. Eine Ausnahme sieht sie bei seltenen, kompletten Ausfällen: Dort kann eine Entschuldigung mit einem überraschenden Element die Enttäuschung etwas abfedern. Für den Alltag gilt: klar und freundlich, nicht witzig.

„Bitte“ und „Entschuldigung“ mit Bedacht

Das GOV.UK Design System rät im Englischen sogar von „please“ und „sorry“ ab: „please“ deute eine Wahl an, wo keine ist, und „sorry“ helfe nicht, das Problem zu lösen. Im Deutschen ist ein „bitte“ oft eine Frage des Sprachgefühls und nicht falsch. Die Regel dahinter ist trotzdem nützlich: Höflichkeitsfloskeln ersetzen keine Lösung. Eine Entschuldigung passt dann, wenn wirklich das System versagt hat, etwa bei einem Serverausfall. Wenn jemand nur ein Feld vergessen hat, braucht es keine.

Konkret und knapp

Eine Fehlermeldung ist kein Handbuch. Ein bis zwei kurze Sätze reichen fast immer. Wer mehr erklären muss, verlinkt auf eine Hilfeseite. Die Faustregel des GOV.UK Design Systems lautet: positiv formulieren, auf den Punkt kommen und die Meldung einmal laut vorlesen. Wenn sie gesprochen seltsam klingt, ist sie es auch geschrieben.

Zehn typische Fehlerfälle, vorher und nachher

Die folgenden Beispiele zeigen, wie die Grundsätze in der Praxis aussehen. Sie sind bewusst aus verschiedenen Produkten gewählt: einem Onlineshop, einer Projektmanagement-App, einem Kundenportal und einer Buchungsplattform. Die Vorher-Texte sind typische Muster, wie sie in vielen Produkten vorkommen.

1. Leeres Pflichtfeld

Vorher: „Dieses Feld ist ein Pflichtfeld.“

Nachher: „Gib deine E-Mail-Adresse ein, damit wir dir die Bestellbestätigung schicken können.“

Die Vorher-Fassung sagt nur, dass etwas fehlt. Die Nachher-Fassung sagt, was fehlt, und warum es gebraucht wird. Das GOV.UK Design System empfiehlt für leere Felder eine klare Anweisung mit dem Namen des Felds, zum Beispiel „Gib deinen Vornamen ein“, statt allgemeiner Hinweise wie „Dieses Feld ausfüllen“. Wie und wann solche Meldungen in Formularen erscheinen sollten, beschreibt der Artikel Formulare, die niemand abbricht ausführlich.

2. Falsches Format

Vorher: „Ungültiges Datumsformat.“

Nachher: „Gib das Datum als TT.MM.JJJJ ein, zum Beispiel 24.12.2026.“

Ein Beispiel im richtigen Format ist oft hilfreicher als jede Beschreibung. Noch besser: Das System akzeptiert gängige Varianten wie „24.12.26“ oder „24. Dezember 2026“ und wandelt sie selbst um. Dann entsteht der Fehler gar nicht erst.

3. Anmeldung fehlgeschlagen

Vorher: „Login fehlgeschlagen.“

Nachher: „E-Mail-Adresse oder Passwort stimmen nicht. Prüf beides oder setz dein Passwort zurück.“ (mit Link „Passwort vergessen?“)

Hier gibt es einen echten Zielkonflikt. Aus UX-Sicht wäre es hilfreich zu sagen, ob die E-Mail-Adresse oder das Passwort nicht stimmt. Aus Sicherheitssicht ist genau das ein Problem: Wenn die Meldung verrät, dass eine E-Mail-Adresse im System existiert, können Angreifende gezielt nach gültigen Konten suchen. Der Testleitfaden des Open Worldwide Application Security Project (OWASP) empfiehlt deshalb einheitliche, allgemeine Meldungen für falsche Benutzernamen und falsche Passwörter. Auch die WCAG erlauben in Kriterium 3.3.3 eine Ausnahme, wenn ein Korrekturvorschlag die Sicherheit gefährden würde.

Die Lösung ist kein vager Text, sondern ein guter Ausweg: Die Meldung bleibt allgemein, bietet aber direkt den Weg zum Zurücksetzen des Passworts an.

4. Datei-Upload abgelehnt

Vorher: „Upload fehlgeschlagen.“

Nachher: „Die Datei ‚Bericht_final.pdf‘ ist 24 MB groß. Du kannst Dateien bis 10 MB hochladen. Verkleinere die Datei oder teile sie in mehrere auf.“

Die Nachher-Fassung nennt die betroffene Datei (wichtig, wenn mehrere gleichzeitig hochgeladen werden), die tatsächliche Größe, das Limit und zwei Lösungen. Ideal ist es, das Limit schon vor dem Upload neben dem Upload-Feld anzuzeigen.

5. Keine Internetverbindung

Vorher: „Network Error.“

Nachher: „Keine Verbindung zum Internet. Deine Änderungen sind auf diesem Gerät gespeichert und werden übertragen, sobald du wieder online bist.“

Bei Verbindungsproblemen ist die wichtigste Information, was mit der eigenen Arbeit passiert. Wer gerade fünf Minuten an einer Notiz geschrieben hat, will vor allem wissen, ob sie verloren ist. Kann die App offline nicht speichern, muss sie das genauso klar sagen: „Deine Änderungen sind noch nicht gespeichert. Lass dieses Fenster offen, bis die Verbindung zurück ist.“

6. Zahlung abgelehnt

Vorher: „Es ist ein Fehler aufgetreten. Fehlercode: ERR_PAY_4021.“

Nachher: „Die Zahlung wurde nicht abgeschlossen, deine Karte wurde nicht belastet. Prüf die Kartendaten oder wähle eine andere Zahlungsart. Deine Verbindung bleibt 15 Minuten für dich reserviert.“

Das ist das Eingangsbeispiel. Die Nachher-Fassung beantwortet alle vier Fragen: Was ist passiert, was bedeutet das für mein Geld, was kann ich tun, und wie viel Zeit bleibt mir. Sie funktioniert natürlich nur, wenn die Aussagen technisch stimmen. „Deine Karte wurde nicht belastet“ darf nur dastehen, wenn das System es sicher weiß. Fehlermeldungen sind deshalb keine reine Textaufgabe, sondern eine gemeinsame Aufgabe von Design, Content und Entwicklung.

7. Serverfehler

Vorher: „500 Internal Server Error.“

Nachher: „Entschuldige, gerade funktioniert bei uns etwas nicht. Deine Eingaben sind gespeichert. Versuch es in ein paar Minuten noch einmal. Wenn es eilt, erreichst du uns unter 030 1234567 (Mo bis Fr, 8 bis 18 Uhr).“

Bei einem Serverfehler liegt das Problem eindeutig beim System, hier ist eine Entschuldigung angebracht. Das GOV.UK Design System beschreibt diesen Fall als eigenes Muster: keine technischen Begriffe wie „500“, keine Floskel wie „Wir haben technische Schwierigkeiten“, dafür die Information, ob Eingaben gespeichert wurden, und wenn möglich ein alternativer Weg, etwa ein Kontakt oder ein anderer Dienst. Die Telefonnummer im Beispiel ist natürlich ein Platzhalter.

8. Seite nicht gefunden

Vorher: „404 Not Found.“

Nachher: „Diese Seite gibt es nicht (mehr). Vielleicht hat sich die Adresse geändert. Such hier nach dem, was du brauchst, oder geh zur Startseite.“ (mit Suchfeld und Links zu den wichtigsten Bereichen)

Eine 404-Seite ist eine Sackgasse, die zur Kreuzung werden kann. Ein Suchfeld, Links zu den meistbesuchten Seiten und ein Hinweis, wie man das Problem melden kann, machen aus einem Abbruch eine Umleitung. Hier ist auch etwas Persönlichkeit erlaubt, solange der Ausweg im Vordergrund steht.

9. Keine Berechtigung

Vorher: „403 Forbidden. Zugriff verweigert.“

Nachher: „Du hast noch keinen Zugriff auf das Projekt ‚Relaunch 2027‘. Bitte die Person, die das Projekt verwaltet, dich einzuladen.“ (mit Button „Zugriff anfragen“)

„Verweigert“ und „verboten“ klingen nach Regelverstoß, obwohl meist nur eine Einladung fehlt. Die Nachher-Fassung erklärt die Situation neutral und bietet einen Weg an, der das Problem tatsächlich löst.

10. Sitzung abgelaufen

Vorher: „Session expired. Please log in again.“ (und alle Eingaben sind weg)

Nachher: „Du warst eine Weile inaktiv und wurdest zur Sicherheit abgemeldet. Melde dich wieder an, deine Eingaben im Antrag sind gespeichert.“

Abgelaufene Sitzungen sind besonders ärgerlich, weil sie oft genau dann zuschlagen, wenn jemand lange an etwas gearbeitet hat. Der Text kann hier nur so gut sein wie das System dahinter: Am besten warnt das Interface vor dem Ablauf und bietet an, die Sitzung zu verlängern. Die WCAG verlangen im Kriterium 2.2.1 („Timing Adjustable“) grundsätzlich, dass Menschen Zeitlimits ausschalten, anpassen oder verlängern können, mit Ausnahmen etwa für Echtzeitvorgänge.

Wo und wie die Meldung erscheint

Der beste Text hilft nicht, wenn ihn niemand sieht oder wenn er an der falschen Stelle steht.

Nah am Problem

Die NN/g empfiehlt, Fehler dort anzuzeigen, wo sie entstanden sind. Eine Meldung direkt am betroffenen Feld oder Element wird schneller mit dem Problem verbunden als ein Sammeltext am oberen Seitenrand. Bei langen Formularen ergänzt eine Zusammenfassung oben die Meldungen am Feld, ersetzt sie aber nicht. Das GOV.UK Design System empfiehlt dabei, in der Zusammenfassung und am Feld denselben Text zu verwenden.

Passend zur Schwere

Nicht jeder Fehler braucht ein Dialogfenster, das alles blockiert. Ein Tippfehler in der Postleitzahl ist ein Hinweis am Feld. Ein fehlgeschlagener Speichervorgang ist ein deutlich sichtbares Banner. Nur wenn wirklich nichts mehr geht oder Daten verloren gehen könnten, ist ein modaler Dialog gerechtfertigt. Die NN/g nennt das die visuelle Schwere an die Auswirkung anpassen.

Lange genug sichtbar

Kurze Hinweise, die nach wenigen Sekunden von selbst verschwinden (oft „Toasts“ genannt), sind für Erfolgsmeldungen praktisch. Für Fehler sind sie riskant: Wer gerade woanders hinschaut oder langsamer liest, verpasst die Meldung, und die Information ist weg. Fehler, auf die jemand reagieren muss, sollten deshalb stehen bleiben, bis sie behoben oder bewusst geschlossen wurden.

Für alle wahrnehmbar

Fehlermeldungen müssen auch für Menschen funktionieren, die nicht sehen, Farben anders wahrnehmen oder mit der Tastatur navigieren. Die NN/g betont, Fehler nie allein über Farbe oder Animation zu kennzeichnen. Ein roter Rahmen braucht immer einen Text und am besten ein Symbol dazu.

Die Web Content Accessibility Guidelines (WCAG) machen dazu klare Vorgaben:

• 3.3.1 Fehlererkennung (Stufe A): Wird ein Eingabefehler automatisch erkannt, muss das betroffene Element benannt und der Fehler in Textform beschrieben werden.
• 3.3.3 Fehlerempfehlung (Stufe AA): Sind Korrekturvorschläge bekannt, müssen sie angeboten werden, es sei denn, das gefährdet die Sicherheit oder den Zweck des Inhalts.
• 4.1.3 Statusmeldungen (Stufe AA): Meldungen, die ohne Fokuswechsel erscheinen, müssen für assistive Technologien wie Screenreader erkennbar sein, zum Beispiel über eine Live-Region mit role="alert" oder role="status".

Technisch heißt das: Die Fehlermeldung wird über aria-describedby mit dem Feld verknüpft, das Feld bekommt aria-invalid="true", und nach dem Absenden eines Formulars springt der Fokus zur Fehlerzusammenfassung. So hört auch jemand mit Screenreader, was schiefgelaufen ist und wo.

Der beste Fehler ist der, der nicht passiert

So wichtig gute Fehlertexte sind: Jede Fehlermeldung ist ein Zeichen dafür, dass das Interface eine Person in eine Sackgasse geschickt hat. Die NN/g unterscheidet, angelehnt an Don Norman, zwei Arten von Fehlern. Slips (Ausrutscher) passieren, wenn jemand eigentlich das Richtige vorhat, aber versehentlich etwas anderes tut, etwa auf den falschen Button tippt. Mistakes (Irrtümer) entstehen, wenn das Ziel oder Verständnis nicht zur Situation passt, also wenn das mentale Modell der Person nicht dem entspricht, wie das System funktioniert.

Beide lassen sich oft verhindern, bevor eine Meldung nötig wird:

• Nachsichtige Eingaben: Telefonnummern mit Leerzeichen, IBANs mit oder ohne Abstände, Datumsangaben in verschiedenen Schreibweisen akzeptieren und selbst normalisieren.
• Einschränkungen statt Verbote: Ein Datumsfeld, in dem vergangene Tage gar nicht auswählbar sind, braucht keine Meldung „Datum liegt in der Vergangenheit“.
• Vorschläge machen: Erkennt das System einen wahrscheinlichen Tippfehler wie „gmial.com“, kann es fragen: „Meinst du gmail.com?“ Die NN/g empfiehlt, Korrekturen so einfach wie möglich zu machen, etwa durch auswählbare Vorschläge.
• Rückgängig statt Rückfrage: Eine „Rückgängig“-Option nach dem Löschen ist oft angenehmer als ein Dialog „Wirklich löschen?“, den viele ohnehin reflexartig bestätigen.
• Bestätigen, wo es zählt: Bei Vorgängen mit rechtlichen oder finanziellen Folgen verlangt WCAG-Kriterium 3.3.4, dass Eingaben rückgängig gemacht, geprüft oder vor dem Abschicken bestätigt werden können.

Fehlertexte im Team systematisch verbessern

Fehlermeldungen lassen sich selten mit einem einzelnen Ticket reparieren. Sie sind über das ganze Produkt verstreut, oft in Code, Backend und Drittanbieter-Diensten. Ein paar Schritte helfen, sie in den Griff zu bekommen.

Bestandsaufnahme machen. Sammle alle Fehlertexte an einem Ort, zum Beispiel in einer Tabelle mit Spalten für Auslöser, aktuellen Text, Häufigkeit und Verantwortliche. Viele Teams sind überrascht, wie viele verschiedene Formulierungen für dasselbe Problem existieren.

Nach Häufigkeit priorisieren. Nicht jeder Fehler ist gleich wichtig. Logs und Analytics zeigen, welche Meldungen am häufigsten erscheinen und wo danach abgebrochen wird. Dort lohnt sich die Überarbeitung zuerst. Auch das Support-Team weiß meist genau, welche Meldungen zu Anrufen führen.

Eine Vorlage festlegen. Ein einfaches Muster sorgt für Einheitlichkeit: Was ist passiert, was bedeutet das, was ist zu tun. Dazu ein paar Regeln zu Ton und Wortwahl, etwa „kein ungültig, kein Fehlercode im Haupttext, immer ein nächster Schritt“. Gehört das Produkt zu einem Design System, sind Fehlertexte dort gut aufgehoben.

Fehlercodes nicht abschaffen, sondern verstecken. Für den Support können Codes wertvoll sein. Sie gehören aber nicht in den ersten Satz. Ein kleiner Zusatz wie „Wenn du uns kontaktierst, nenn bitte den Code PAY-4021“ am Ende der Meldung erfüllt denselben Zweck, ohne zu verwirren.

Gemeinsam schreiben. Die Entwicklung weiß, welche Fehler technisch möglich sind und was das System über ihre Folgen sicher sagen kann. Design und Content wissen, wie das für Menschen klingen muss. Gute Fehlermeldungen entstehen, wenn beide früh zusammenarbeiten, nicht erst, wenn die Texte schon im Code stehen.

Mit echten Menschen testen. Fehlerfälle werden in Usability-Tests oft übersprungen, weil der Prototyp nur den Idealweg abbildet. Baue gezielt Fehler in Testszenarien ein und beobachte, ob die Teilnehmenden ohne Hilfe weiterkommen.

Fazit

Eine Fehlermeldung ist der Moment, in dem ein Produkt zeigt, ob es auf der Seite der Menschen steht, die es benutzen. „Es ist ein Fehler aufgetreten“ sagt im Grunde: Das ist jetzt dein Problem. Eine gute Meldung sagt dagegen: Das ist passiert, so geht es weiter, und um deine Daten musst du dir keine Sorgen machen.

Der Weg dorthin ist überschaubar. Benenne konkret, was passiert ist. Biete immer einen nächsten Schritt an. Sag, was mit Eingaben, Geld oder Zeit passiert ist. Verzichte auf Schuldzuweisungen, Fachjargon und Alarmstimmung. Zeig die Meldung dort, wo das Problem liegt, und so, dass alle sie wahrnehmen können. Und dann prüfe, welche Fehler sich ganz vermeiden lassen.

Ein guter Einstieg ist überraschend klein: Nimm die fünf häufigsten Fehlermeldungen deines Produkts und schreib sie mit den Beispielen aus diesem Artikel neu. Der Unterschied wird im Support und in den Abbruchraten oft schneller sichtbar als erwartet.

Checkliste

• Die Meldung benennt konkret, was passiert ist, ohne Fachjargon und Fehlercode im Haupttext.
• Sie enthält immer einen nächsten Schritt: eine Anweisung, einen Button oder einen Kontakt.
• Bei Geld, Daten oder Fristen sagt sie, was gespeichert, belastet oder reserviert ist.
• Der Ton ist ruhig und sachlich, ohne Schuldzuweisung, Großbuchstaben oder Ausrufezeichen.
• Wörter wie „ungültig“, „unzulässig“ und „verboten“ kommen nicht vor.
• Humor gibt es nur in seltenen Ausnahmefällen, nie bei Geld oder Datenverlust.
• Login-Fehler bleiben aus Sicherheitsgründen allgemein, bieten aber einen Ausweg an.
• Die Meldung steht nah am Problem, ihre Gestaltung passt zur Schwere des Fehlers.
• Fehler verschwinden nicht von selbst, bevor jemand reagieren konnte.
• Fehler werden nicht nur über Farbe vermittelt und sind für Screenreader zugänglich.
• Häufige Fehler werden durch nachsichtige Eingaben, Vorschläge und Rückgängig-Funktionen vermieden.
• Alle Fehlertexte sind gesammelt, nach Häufigkeit priorisiert und folgen einer gemeinsamen Vorlage.

Quellen

• Nielsen Norman Group: Error-Message Guidelines (Tim Neusesser, Evan Sunwall)
• Nielsen Norman Group: 10 Usability Heuristics for User Interface Design
• Nielsen Norman Group: Preventing User Errors: Avoiding Unconscious Slips (Page Laubheimer)
• GOV.UK Design System: Error message
• GOV.UK Design System: There is a problem with the service pages
• W3C: Understanding Success Criterion 3.3.3 Error Suggestion
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2
• OWASP Web Security Testing Guide: Testing for Account Enumeration and Guessable User Account