Fehlermeldungen sind per se nicht gut. Schließlich teilen sie mit, dass etwas schiefgelaufen ist. Doppelt ärgerlich, wenn der Nutzer nicht versteht, warum der Fehler aufgetreten ist und was er jetzt unternehmen kann. Die Reaktionen sind unterschiedlich: Der eine flucht lauthals über die Software, der andere möchte am liebsten sein Handy aus dem Fenster werden und der dritte wird die genutzte App vielleicht nie wieder öffnen. Doch obwohl Fehlermeldungen ein so hohes Frustpotential haben, werden sie in der UX Konzeption häufig vernachlässigt.

‍

Woran liegt das?

Manchmal weiß der UX Konzepter nicht wirklich, welche Fehlermeldungen auftreten können. Er geht davon aus, dass sich der Entwickler damit besser auskennt und überlässt ihm dieses Thema. Das Resultat sieht dann mit unter so aus:

‍

‍

Der Nutzer wird auf Englisch über ein Problem informiert, von dem er weder weiß, warum dieses auftritt, noch, was er dagegen tun kann. Dafür erfährt er die Backend-Bezeichnung und die Nummer des Fehlers.

Oder  der UX Konzepter beschäftigt sich zwar mit der Definition aller Fehlerfälle, ist aber nicht für das Schreiben der UI-Texte verantwortlich. Der Texter, der dafür zuständig ist, kennt die verschiedenen Fehlerfälle jedoch nicht. Mögliches Ergebnis:

‍

‍

Alle Fehlermeldungen erhalten den gleichen wenig aussagekräftigen Satz. Aber immerhin sagen wir dem Nutzer, dass es uns Leid tut.

Wie können wir das besser machen?

Zunächst einmal sollten wir jeden Fehlerfall individuell betrachten und ihm auch eine spezifische Fehlermeldung gönnen. Nur so können wir dem Nutzer wirklich sagen, was schief gelaufen ist. So also?

‍

‍

Der Nutzer erfährt, was passiert ist und ist happy? Nicht ganz. Unklar bleibt, was er denn nun tun kann. Vielleicht sollten wir das also noch ergänzen.

‍

‍

Es wäre interessant zu wissen, wie viele Nutzer diese Fehlermeldung lesen und dann tatsächlich wissen, welchen der drei Buttons sie wählen sollten.

Es kommt also offensichtlich nicht nur darauf an, was wir dem Nutzer sagen, sondern auch auf das wie. Aber halten wir zunächst fest. Effektive Fehlermeldungen zeigen folgende Informationen:

• Was lief schief und wenn möglich auch warum
• Was kann der Nutzer tun, um das Problem zu lösen

‍

Auf dem Weg zur perfekten Fehlermeldung

Wie das obige Beispiel zeigt, sollten Fehlermeldungen kurz und klar gehalten werden. Der Nutzer ist sowieso schon verärgert, dass etwas schief gelaufen ist. Jetzt will er keinen Roman darüber lesen. Das Ziel ist also: So kurz wie möglich, aber so detailliert wie nötig, damit der Nutzer alle nötig Informationen bekommt.

Wie für alle UI Texte gilt auch für Fehlermeldungen, dass wir die Sprache des Nutzers sprechen sollten. Und damit ist nicht nur die Landessprache gemeint, sondern auch, dass wir auf Fachjargon verzichten, der dem Nutzer unbekannt ist.

‍

‍

‍

In der Regel wissen wir, welche Sprache unsere Nutzer sprechen. Dann ist so ein Fehlermeldungs-Sprachkurs unnötig.

Zusätzlich kann eine freundliche und höfliche Kommunikation nicht schaden. Und unter allen Umständen sollten wir vermeiden, dem Nutzer die Schuld am Problem in die Schuhe zu schieben. Klingt logisch, passiert dennoch immer wieder.

‍

‍

So beschwert sich Word beispielsweise bei mir, dass mein Dokument zu viele Rechtschreib- und Grammatikfehler enthält, nur weil es mit den vielen Fachbegriffen nicht umgehen kann.

Dabei könnte eine Fehlermeldung sogar die Gelegenheit für einen kleinen Scherz bieten, um die Stimmung des Nutzers im grünen Bereich zu halten. Natürlich muss man dabei sehr genau darauf achten, dass der Ton zum Produkt und zur Zielgruppe passt. Aber wenn das gegeben ist, warum nicht mal so versuchen:

‍

‍

Oder sogar so, mit einer netten Grafik:

‍

Gut überlegte Fehlermeldungen können letztendlich sogar auf die Markenidentität des Produkts einzahlen. Und den Nutzer mit einem Schmunzeln, statt einem Fluch fortfahren lassen. Grund genug, dass wir UX Konzepter uns dieses Themas annehmen und Fehlermeldungen nicht nur mitdenken, sondern auch ausformulieren sollten.

‍