Fehlermeldungen schreiben: Regeln und Beispiele

Kurz gesagt

Eine Fehlermeldung ist die Stelle, an der ein Produkt im angespanntesten Moment mit dem Nutzer spricht. Er wollte etwas tun, und es hat nicht geklappt. Die einzige Aufgabe der Meldung ist, ihn wieder auf den Weg zu bringen.

Diese Seite handelt vom Text der Meldung. Wann und wo im Formular ein Fehler erscheint, beschreibe ich im Muster zum Formulardesign. Hier geht es darum, was in diese Zeile gehört.

Die Regeln habe ich aus den Leitlinien von NN/g zu Fehlermeldungen von 2023 und aus der Komponente für Fehlermeldungen im GOV.UK Design System zusammengestellt. Die deutschen Beispiele habe ich geschrieben.

Was eine Fehlermeldung sagen soll

Die neunte von Jakob Nielsens 10 Usability-Heuristiken fasst es in einem Satz zusammen. Die Meldung ist in einfacher Sprache geschrieben, enthält keinen Fehlercode, zeigt das Problem genau und schlägt konstruktiv eine Lösung vor.

Ich reduziere das auf zwei Fragen. Versteht der Nutzer beim Lesen, was passiert ist? Weiß er, was er als Nächstes tun soll? Fehlt eines davon, macht die Meldung ihre Arbeit nicht.

GOV.UK unterscheidet zwei Schreibweisen. Die Anweisung sagt dem Nutzer, was er tun soll: „Geben Sie Ihren Namen ein“. Die Beschreibung nennt die Regel: „Der Name darf höchstens 35 Zeichen haben“.

In den Beispielen von GOV.UK steht für ein leeres Feld eine Anweisung, für eine zu lange Eingabe eine Beschreibung. Sie können beides nutzen, solange Sie dabei einheitlich bleiben.

Ein weiterer Vorschlag von GOV.UK hilft: Bringen Sie die Meldung mit dem Label in Einklang. Lautet das Label „Wie viele Stunden arbeiten Sie pro Woche?“, heißt die Meldung „Geben Sie ein, wie viele Stunden Sie pro Woche arbeiten“. Sieht der Nutzer dieselben Wörter zweimal, versteht er sofort, zu welcher Frage die Meldung gehört.

Regeln für Fehlermeldungen

Unter jede Regel habe ich Quelle und Begründung geschrieben. Die vollständigen Angaben stehen am Ende der Seite.

1. Machen Sie die Meldung sichtbar. NN/g empfiehlt, Fehler in einem fetten, kontrastreichen und roten Stil zu zeigen. Farbe oder Animation sollen nicht das einzige Signal sein, weil viele Nutzer Farben schwer unterscheiden.
2. Setzen Sie die Meldung an die Quelle des Fehlers, also an das Feld. Laut NN/g hilft die Nähe, die Meldung mit dem richtigen Feld zu verbinden. GOV.UK zeigt die Meldung in Rot nach dem Fragetext und dem Hinweis.
3. Sagen Sie genau, was passiert ist. Ein allgemeiner Satz wie „Es ist ein Fehler aufgetreten“ gibt keinen Zusammenhang. NN/g verlangt, das Problem kurz und genau zu beschreiben. GOV.UK setzt auch allgemeine Meldungen wie „Dieses Feld ist ein Pflichtfeld“ auf die Liste der Dinge, die man vermeidet.
4. Sagen Sie, wie man es behebt. Nielsens neunte Heuristik verlangt, dass die Meldung konstruktiv eine Lösung vorschlägt. Auch das Kriterium 3.3.3 der WCAG 2.2 schreibt vor, einen Vorschlag zu zeigen, wenn die Korrektur bekannt ist.
5. Machen Sie dem Nutzer keinen Vorwurf. NN/g verlangt einen positiven Ton. Wörter, die andeuten, dass der Nutzer etwas falsch gemacht hat, wie „ungültig“, „unzulässig“ oder „falsch“, sollen Sie vermeiden. Auf der Liste von GOV.UK steht auch „vergessen“.
6. Schreiben Sie keine technischen Codes und internen Begriffe. NN/g sagt, Fehlercodes und Abkürzungen nur zu zeigen, wenn sie bei der Diagnose helfen. Auch GOV.UK zählt technische Ausdrücke wie „Fehler beim Senden des Formulars“ zu den Dingen, die man vermeidet.
7. Keine Entschuldigung, kein „bitte“, keine Witze. Laut GOV.UK löst „leider“ das Problem nicht, und „bitte“ klingt, als hätte der Nutzer eine Wahl. NN/g schreibt, dass ein Witz bei einem wiederkehrenden Fehler schnell alt wird.
8. Löschen Sie nicht, was der Nutzer geschrieben hat. NN/g verlangt, die Eingabe zu erhalten, damit der Nutzer korrigiert, was er geschrieben hat, statt neu anzufangen. Auch GOV.UK sagt, dass beim Anzeigen eines Fehlers kein Feld geleert wird.

Die Liste der Wörter, die GOV.UK vermeidet, ist englisch. Ich wende dieselbe Logik auf die deutschen Entsprechungen an: „ungültig“, „fehlerhaft“, „vergessen“, „bitte“, „leider“, „hoppla“.

Beispiele für Fehlermeldungen

Unten steht für die häufigsten Fehlerarten je eine schlechte und eine gute Meldung. Die guten folgen immer demselben Muster: zuerst Regel oder Anweisung, bei Bedarf ein Beispiel.

• Leeres Feld

  Schlecht Dieses Feld ist ein Pflichtfeld.

  Gut Geben Sie Ihren Namen ein.

• Falsches Format

  Schlecht Ungültige Telefonnummer.

  Gut Geben Sie die Telefonnummer mit 10 bis 13 Ziffern ein, zum Beispiel 0151 23456789.

• Zu lang

  Schlecht Zeichenlimit überschritten.

  Gut Der Benutzername darf höchstens 20 Zeichen haben.

• Datum in der Vergangenheit

  Schlecht Falsches Datum!

  Gut Der Termin muss nach dem heutigen Tag liegen.

• Keine Auswahl

  Schlecht Bitte wählen Sie eine Option.

  Gut Wählen Sie eine Versandart.

• Datei

  Schlecht Upload failed (413).

  Gut Die Datei darf höchstens 10 MB groß sein. Wählen Sie eine kleinere Datei.

Eine Anmerkung zum „zum Beispiel“ beim Telefon. GOV.UK sagt, ein Beispiel, das schon im Hinweistext auf dem Screen steht, in der Fehlermeldung nicht zu wiederholen. Setzen Sie das Beispiel nur in die Meldung, wenn es im Hinweis fehlt.

Auch die Anrede gehört zur Meldung. Entscheiden Sie einmal, ob Sie „Sie“ oder „du“ schreiben, und halten Sie es in jeder Meldung gleich. Ein Formular, das oben siezt und im Fehler duzt, wirkt, als hätten zwei Teams daran geschrieben.

Übung: eine schlechte Meldung umschreiben

Auf jeder der vier Karten wird eine Regel verletzt. Schreiben Sie Ihre eigene Fassung und vergleichen Sie sie mit dem Vorschlag. Die Etiketten zeigen, welche Regel behoben ist.

Übung: umschreiben

1 E-Mail-Feld

Schlecht Aktuelle Fassung

E-Mail

!Fehler: Ungültige Eingabe.

anna.schmidt@gmail

Schreiben Sie zuerst selbst (optional)

Gut Vorgeschlagene Fassung

E-Mail

!Fehler: Am Ende der E-Mail-Adresse scheint etwas zu fehlen. Geben Sie die Adresse im Format [email protected] ein.

anna.schmidt@gmail

• Behoben: Sagt, was passiert ist
• Behoben: Sagt, wie man es behebt
• Behoben: Kein „ungültig“

2 Feld Geburtsdatum

Schlecht Aktuelle Fassung

Geburtsdatum

!Fehler: ERR_422: date_parse_failed

31.02.1990

Schreiben Sie zuerst selbst (optional)

Gut Vorgeschlagene Fassung

Geburtsdatum

!Fehler: Das Geburtsdatum muss ein echtes Datum sein. Der Februar hat höchstens 29 Tage.

31.02.1990

• Behoben: Kein technischer Code
• Behoben: Deutsch und einfach
• Behoben: Sagt, was passiert ist

3 Feld Passwort wiederholen

Schlecht Aktuelle Fassung

Passwort (wiederholen)

!Fehler: Die Passwörter stimmen nicht überein! Bitte passen Sie besser auf.

••••••••

Schreiben Sie zuerst selbst (optional)

Gut Vorgeschlagene Fassung

Passwort (wiederholen)

!Fehler: Die beiden Passwörter sind nicht gleich. Geben Sie hier das erste Passwort noch einmal genau so ein.

••••••••

• Behoben: Kein Vorwurf
• Behoben: Kein „bitte“ und kein Ausrufezeichen
• Behoben: Sagt, wie man es behebt

4 Feld Lieferadresse

Schlecht Aktuelle Fassung

Fehler: Es ist ein Fehler aufgetreten.

Lieferadresse

Hinterhaus, 3. Stock links, bei Familie Müller klingeln, Paket bitte ...

Schreiben Sie zuerst selbst (optional)

Gut Vorgeschlagene Fassung

Lieferadresse

!Fehler: Die Adresse darf höchstens 200 Zeichen haben. Im Moment sind es 214.

Hinterhaus, 3. Stock links, bei Familie Müller klingeln, Paket bitte ...

• Behoben: Steht am Feld
• Behoben: Sagt, was passiert ist
• Behoben: Sagt, wie man es behebt

Auf jeder Karte steht eine schlechte Meldung der Art, die ich in echten Produkten oft sehe. Schreiben Sie zuerst Ihre eigene Fassung in das Feld und drücken Sie dann „Vorschlag zeigen“. Die Etiketten zeigen, was behoben ist. Die Beispielmeldungen habe ich für diese Seite geschrieben. Ist JavaScript aus, sind beide Fassungen offen.

Bei der vierten Karte liegt das eigentliche Problem im Ort der Meldung. Ein allgemeiner Hinweis oben im Formular versteckt in einem langen Formular das problematische Feld. Im Vorschlag steht die Meldung direkt über dem Feld und nennt die aktuelle Zahl der Zeichen.

Fehler des Nutzers oder Fehler des Systems?

Die Beispiele bis hier betrafen die Eingabe des Nutzers. GOV.UK nutzt die Komponente für Fehlermeldungen nur dafür. Gibt es ein Problem mit dem Dienst selbst oder wird eine Seite nicht gefunden, nutzt GOV.UK eigene Muster.

GOV.UK sagt außerdem, die Fehlermeldung nicht zu verwenden, um „Sie sind nicht berechtigt“ oder „Sie haben keinen Zugriff“ zu sagen. Das sind keine Eingabefehler. Es braucht eine Seite, die dem Nutzer erklärt, was er tun kann.

Auch NN/g empfiehlt, die Form der Meldung nach der Wirkung des Fehlers zu wählen. Für Probleme, die wenig Interaktion verlangen, genügt ein bedingt angezeigtes Label, ein kurzer Hinweis oder ein Banner. Ein modales Fenster verlangt Aufmerksamkeit und eine Lösung; heben Sie es für schwere Fehler auf.

Auch wenn der Server ausfällt, gelten dieselben zwei Fragen. Schreiben Sie statt „500 Internal Server Error“: „Ihre Zahlung ist nicht durchgegangen, Ihre Karte wurde nicht belastet. Versuchen Sie es in ein paar Minuten noch einmal.“ Im Checkout will der Nutzer als Erstes wissen, was mit seinem Geld passiert ist.

Meine Notiz

Die Fehlermeldung, die ich in Audits am häufigsten sehe, ist „Es ist ein Fehler aufgetreten“. Dieser Satz ist meist der Standardtext, den die Entwicklung stehen gelassen hat. Niemand hat beschlossen, ihn zu schreiben.

Deshalb führe ich Fehlermeldungen in der Designdatei als eigene Liste. Für jedes Feld zähle ich die möglichen Fehler auf und schreibe zu jedem einen Satz. Die Entwicklung übernimmt diese Liste, und kein Standardtext geht live.

GOV.UK schlägt noch einen Schritt vor: Messen Sie, wie oft eine Meldung erscheint. Diese Daten helfen, Inhalte zu verbessern, einen A/B-Test zu machen oder den Ablauf neu zu gestalten.

Bei einer Meldung, die oft erscheint, muss man für mich zuerst auf die Frage schauen. Auch Nielsens fünfte Heuristik sagt, dass besser als eine gute Fehlermeldung ein sorgfältiges Design ist, das das Problem von vornherein verhindert.

Einen letzten Test schlägt auch GOV.UK vor: Lesen Sie die Meldung laut vor. Einem Kunden würden Sie von Angesicht zu Angesicht nicht „Ungültige Eingabe“ sagen. Auf dem Screen auch nicht.

Hinweis zur Barrierefreiheit

Das Kriterium 3.3.3 Fehlerempfehlung (Error Suggestion) der WCAG 2.2 gehört zur Stufe AA. Wurde ein Fehler automatisch erkannt und ist eine Korrektur bekannt, muss der Vorschlag dem Nutzer gezeigt werden. Die einzige Ausnahme: Der Vorschlag würde die Sicherheit oder den Zweck des Inhalts gefährden.

Das W3C erklärt den Zweck des Kriteriums so: Nur den Fehler zu melden, kann Menschen mit kognitiven oder Sehbeeinträchtigungen ohne Lösung lassen. Wissen sie nicht, wie sie das Problem beheben, brechen sie das Formular vielleicht ab.

GOV.UK setzt vor die Meldung ein unsichtbares Präfix „Error:“ und schreibt, dass man es in einer anderen Sprache ändern kann. Auf deutschen Seiten nutze ich „Fehler:“. Wie ich ein Formular von Anfang bis Ende prüfe, beschreibe ich im Ratgeber zur Barrierefreiheitsprüfung, alle Kriterien im WCAG-Ratgeber.

Checkliste

Die Fehlermeldungen eines Screens prüfe ich vor dem Release mit dieser Liste. Wenn ich die Meldungen Ihres Produkts durchsehen soll: Der UX Audit deckt das ab.

• Die Meldung steht am fehlerhaften Feld.
• Der Fehler wird nicht nur über Farbe gezeigt, sondern auch mit Text und Icon.
• Die Meldung sagt, was passiert ist.
• Die Meldung sagt, wie man es behebt.
• Kein Fehlercode, kein Englisch, kein technischer Begriff.
• Die Wörter „ungültig“, „fehlerhaft“, „vergessen“, „bitte“ und „leider“ kommen nicht vor.
• Die Meldung nutzt dieselben Wörter wie das Label.
• Die Anrede ist in allen Meldungen gleich.
• Nach dem Fehler steht noch da, was der Nutzer geschrieben hat.
• Der Standardtext „Es ist ein Fehler aufgetreten“ steht nirgends mehr.