Der beste Fehler ist der, der gar nicht erst auftritt. Klare Strukturen, verständliche Beschriftungen und sinnvolle Defaults helfen, Fehlbedienungen zu vermeiden. Lassen sich Fehler nicht verhindern, entscheiden zwei Dinge darüber, ob Nutzer weiterkommen: wo und mit welcher Komponente der Fehler erscheint und wie er formuliert ist.

---

Best Practices

• Vermeide Fehler schon im Design, zum Beispiel durch klare Beschriftungen und sinnvolle Defaults.
• Zeige Fehler dort, wo sie entstehen oder wo der erwartete Inhalt wäre.
• Nenne eine Lösung oder biete einen Ausweg an, zum Beispiel "Erneut laden".
• Wähle die Darstellung passend zum Umfang des Fehlers.
• Bleibe sachlich: keine Schuldzuweisungen und keine Entschuldigungen.
• Formuliere kurz und positiv. Das hilft Nutzern, schnell zu handeln.

---

Fehlermeldungen anzeigen

Beim Laden von Inhalten

Beim Laden können Fehler auftreten, zum Beispiel wenn ein Service nicht erreichbar ist oder ein Timeout entsteht. Beende in diesem Fall den Ladezustand, damit Nutzer sehen, dass sie nicht weiter warten müssen.

Die Fehlermeldung erscheint dort, wo der erwartete Inhalt wäre. Für größere Bereiche wie LayoutCards‍ oder Sections‍ eignet sich eine IllustratedMessage‍ mit status="danger". Sie zeigt deutlich, dass der Inhalt aktuell nicht verfügbar ist, und bietet idealerweise eine Handlung an, zum Beispiel einen Button‍ mit der Beschriftung "Erneut laden".

Für kleinere, abgegrenzte Elemente wie Tabellen- oder Listenzeilen eignet sich ein AlertText‍. So bleibt der Kontext erhalten und der Fehler betrifft nicht die ganze Table‍ oder List‍.

Um Fehler auf kleine Bereiche zu begrenzen, nutzen wir im mStudio Loading und Error Boundaries. Sie kapseln technische Fehler ab und sorgen für konsistentes Feedback.

Bei ungültigen Eingaben

Zeige das Feedback direkt am Form Control, damit Nutzer sofort erkennen, was sie anpassen müssen. Details stehen unter Formular (Mit Validierung)‍.

Bei fehlgeschlagenen Aktionen

Aktionen, die einen Request an das Backend senden, können aus technischen Gründen, wegen Kommunikationsproblemen oder fehlender Berechtigungen fehlschlagen. Dafür eignet sich ein Modal‍ mit einer IllustratedMessage‍ mit status="danger". Sie erklärt kurz den Grund, sofern er für Nutzer relevant ist, und bietet einen Ausweg an, zum Beispiel die Aktion erneut auszuführen.

Schlägt eine Aktion erst später fehl, nachdem sie zunächst erfolgreich an das Backend übermittelt wurde, eignen sich Notifications‍ besser. Ein typisches Beispiel ist das Registrieren einer Domain. Mehr dazu steht im Informationskonzept‍.

---

Fehlermeldungen formulieren

Die allgemeinen Regeln zu Anrede und Satzlänge stehen im Sprach-Guide‍. Dort steht auch, dass eine passive Schreibweise in Ordnung ist, wenn ein System handelt. Das trifft bei Fehlermeldungen oft zu. Für sie gilt zusätzlich:

Kurz formulieren und Lösung nennen

Schreibe so kurz wie möglich, aber so lang wie nötig. Oft reicht es, nur die Lösung zu nennen. Gibt es mehrere mögliche Ursachen, beschreibe, wie sich die wahrscheinlichste beheben lässt.

Schuldzuweisungen vermeiden

Beschreibe, was passiert ist, und nicht, was der Nutzer falsch gemacht hat. Ein Fehler ist an sich schon frustrierend.

Nicht entschuldigen

Formuliere Fehlermeldungen sachlich und fachlich. Entschuldigungen lenken vom Wesentlichen ab und lassen Fehler größer wirken.

Positiv formulieren

Konzentriere dich auf die Lösung und darauf, was als Nächstes möglich ist. Verzichte nach Möglichkeit auf negativ besetzte Begriffe wie Fehler, Problem, fehlgeschlagen, falsch oder ungültig. Bei Systemfehlern ohne direkte Lösung gelingt das nicht immer.

Allgemein formulieren

Formuliere eher allgemein als zu spezifisch. Details wie Dateinamen oder Ordner finden Nutzer meist an anderer Stelle in der Oberfläche.