M

Magazine by UseTree
Gute Frage Reading Time 4 min | 26.05.2014

404 – Not found

Wer kennt es nicht!? Eine Fehlermeldung erscheint auf dem Desktop oder im Browser, gefüllt mit Text und kryptischen Zeichen und letztendlich doch nichtsaussagend. Als Handlungsmöglichkeit bleibt dann nur noch der “Ok-Button” (wobei es doch alles andere als ok ist) oder die Zurück-Funktion des Browsers. Wenn man einen glücklichen Tag erwischt hat, geht der bereits investierte Arbeitsaufwand dabei nicht komplett ins Nirvana, wodurch man wieder von vorn beginnen muss.

by Redaktion

Diese und ähnliche Situationen sind jedem Menschen, der bereits einmal einen Computer bedient hat, hinlänglich bekannt. Auch wenn sich in den letzten Jahren doch einiges getan hat, und die Arbeitsgeräte vielleicht nicht mehr direkt aus dem Fenster geworfen werden, sind wirre und  unverständliche Fehlermeldung häufig noch der Grund für Frustration und Verärgerung. Um solche Situationen zu vermeiden, bestehen seit 30 Jahren Richtlinien zur Gestaltung von Fehlermeldungen. Jakob Nielsen (von der Nielsen & Norman Group) fasst diese wie folgt zusammen:

Eine Fehlermeldung sollte …

  • ein expliziter Hinweis darauf sein, dass etwas falsch gelaufen ist. Das Schlechteste, was passieren kann, ist, wenn ein Nutzer kein Feedback bekommt und überhaupt nicht weiß, dass etwas schief gelaufen ist. Wer hat nicht schon einmal die Worte “…im Anhang zu finden” in einer E-Mail benutzt und hat diese dann ohne denselben losgeschickt!? Einige Programme weisen mittlerweile deshalb explizit darauf hin, dass dieses Schlagwort im Text verwendet, ein Anhang aber noch nicht hinzugefügt wurde.
  • in verständlicher Sprache formuliert sein. Die Zeiten der Fehlermeldungen des Formats “Error Code: 0XE0000100” mögen in den meisten Fällen vorbei sein, dennoch ist es wichtig sich darüber zu informieren, über welchen Wissenshintergrund die Nutzer-Zielgruppen verfügen und die Inhalte der Fehlermeldungen entsprechend verständlich anzupassen.
  • auf höfliche Wiese formuliert sein. Der Nutzer sollte sich nicht schuldig dafür fühlen, dass ein Fehler im System entstanden ist (zumindest nicht mehr, als er es vielleicht sowieso schon tut).
  • eine präzise Formulierung dessen sein, was das Problem verursacht. Mal ganz ehrlich, wer hat schon Zeit und Lust sich auf die Suche nach den vergrabenen Gründen einer “Syntax Error”-Meldung zu machen? Auch die Formulierung “Das gewünschte Update konnte nicht ausgeführt werden” erweist sich als unwesentlich besser. Es wird zwar expliziter dargestellt was falsch gelaufen ist, aber nicht warum! Auch hier endet das Beispiel in einer umständlichen Fehlersuche.
  • eine konstruktive Hilfestellung sein, das Problem zu lösen. Bei der Internet-Bestellung eines begehrten Artikel stößt man auf die Meldung “Lieferzeit unbekannt”. Sofort häufen sich die Fragen: Ist der Artikel ausverkauft? Kann ich den Artikel trotzdem bestellen? Wenn ja, gibt es einen Termin für die nächste Nachbestellung des Artikels? Mit einer Nachricht, wann der Artikel (voraussichtlich) wieder vorrätig sein wird oder einer direkten Kontaktmöglichkeit, an die sich gewendet werden kann, ist oftmals schon geholfen und der Nutzer zufriedengestellt.

Da sich vor allem Webseiten in ihrer Komplexität sehr stark entwickelt haben, müssen auch diese Richtlinien noch erweitert werden. Gerade für Webseiten gilt deshalb: Meldungen und Hinweise müssen sichtbar sein! Was bei Software als aufpoppendes Fenster gestaltet ist, welches erst wieder verschwindet, wenn man die entsprechende Aktion durchführt, muss bei Internetseiten durch lesbare, gut präsentierte Nachrichten/Meldungen gestaltet werden.

Generell gilt, dass so viel Arbeit des Nutzers wie möglich konserviert werden sollte. Er sollte in der Lage sein, getätigte Fehler von seinem aktuellen Stand bearbeiten und korrigieren zu können, ohne den Ablauf von vorn beginnen zu müssen.
Besonders nervig können Bestellvorgänge sein, bei denen man kurz vor Abschluss merkt, dass man einen Artikel aus Versehen 2x im Warenkorb hat. Im besten Fall kann dieser Fehler auf jeder aktuellen Seite korrigiert werden, bzw. zwischen einer vorherigen und der aktuellen Seite ohne Informationsverlust gesprungen werden. Letztendlich bezahlt man doch öfter als nötig den Preis für seinen Fehler und gibt Adresse, Zahlungsinformationen usw. erneut ein.
Deshalb sollte die Arbeit des Nutzers, die notwendig ist, um einen Fehler zu korrigieren, so weit wie möglich reduziert werden!

Diese grundlegenden Prinzipien sollten unbedingt beachtet werden, um den Nutzer bei der Fehlerbehebung zu unterstützen sowie ihm und der entsprechenden Kunden-/Nutzerhotline viel Ärgernis zu ersparen.

“syntax error: unexpected end of file”

Bildquelle: pixabay.com