it-swarm.com.de

Welche Fehler sollten Benutzer niemals erleben?

Ich habe diese Frage aus zwei Gründen gestellt.

  1. Nicht alle Fehler können vermieden werden. Zum Beispiel Anmeldeinformationen, die dazu führen können, dass das Programm eine unbehandelte Ausnahme auslöst, wenn die Anmeldeinformationen nicht korrekt sind.
  2. Die Verwendung von Standardfehlermeldungen kann für einen Benutzer zu verwirrend sein.

Ich frage mich, ob ich beim Übergeben von Programmfehlern zusätzliche Vorsichtsmaßnahmen treffen sollte. Welche Fehler sollten vermieden werden?

Während auf einem Punkt von Fehlern. Wie sollen Fehler an einen Benutzer übermittelt werden? Etwas sagt mir, dass zu viele Meldungsfelder einige Zeit verschwenden würden, wenn Sie zu viel auf OK klicken, was zu Frustration beim Benutzer führt. Etiketten sollten eine bessere Wahl sein?

Was ist deine Meinung?

8
HelpNeeder

Die Grundidee beim Anzeigen einer Fehlermeldung besteht darin, den Benutzer darüber zu informieren, dass ein Fehler aufgetreten ist und seine Aktionen möglicherweise nicht zu einem gewünschten Ergebnis geführt haben.

Wenn der Fehler die Wahrnehmung des Programms durch den Benutzer nicht beeinträchtigt, zeigen Sie ihn nicht an, sondern speichern Sie ihn in einem Fehlerprotokoll (zum Beispiel dauerte die Ausführung der Funktion aufgrund einiger Fehler 50% länger, aber Alle vom Benutzer durchgeführten Aktionen wurden korrekt ausgeführt.

Wenn sich der Fehler auf das Ziel des Benutzers auswirkt, teilen Sie ihm mit, dass ein Fehler aufgetreten ist, damit er ihn beheben kann. Beispielsweise konnte die Datei aufgrund eines Fehlers (falsch vom Benutzer gewählter Pfad oder eines Fehlers im Programm selbst) nicht gespeichert werden. Wenn der Benutzer das Problem beheben kann, teilen Sie ihm dies mit. Wenn der Benutzer das Problem nicht beheben kann, muss er dennoch wissen, dass die Datei nicht gespeichert wurde.

Den Workflow des Benutzers zu stören, kann ärgerlich sein, aber wenn es sich um wichtige Informationen handelt ("die Datei konnte nicht gespeichert werden) - darf der Benutzer dies nicht verpassen! Es ist also eine Entscheidung des Systemdesigners, zu entscheiden, ob der Fehler entscheidend genug ist den Benutzer zu stören.

15
Henrik Ekblom

Philosophisch glaube ich daran, Benutzer so weit wie möglich zu befähigen, was bedeutet, alle Fehlerbedingungen offenzulegen. Offensichtlich ist keine Regel absolut, und die Definition eines Fehlers ist etwas grau. Aber im Allgemeinen brauche ich einen verdammt guten Grund, um Informationen über "hinter den Kulissen" -Aktionen eines Systems zu verbergen.

Die Art und Weise, wie Sie dem Benutzer Fehler mitteilen, sollte in gewisser Weise relativ zu den Auswirkungen des Fehlers auf den Workflow des Benutzers sein. Je katastrophaler der Fehler, desto störender die Benachrichtigung. Und wenn ein Benutzer entscheidet, dass er nicht daran interessiert ist, über eine bestimmte Art von Fehler informiert zu werden, sollte er in der Lage sein, die Unterbrechung durch diese Fehlermeldung abzulehnen (solange er eine Möglichkeit hat, herauszufinden, was er hat verpasst).

Bis zu dem Punkt, dass zu viele Fehlermeldungen den Benutzer stören und nerven - ich stimme zu. Und ich glaube, der Benutzer sollte sich über ein System ärgern, das genug Fehler erzeugt, dass ihre Offenlegung störend sein könnte. Das Problem sind die Fehler, nicht die Benachrichtigung. Erschieße nicht den Boten.

Wie gesagt, dies ist ein philosophisches Thema, daher respektiere ich, dass andere Standpunkte gleichermaßen gültig sind.

3
TMiller

Ich habe mich kürzlich für ein USAA-Konto angemeldet. Wir haben unsere Scheckkarte nie bekommen. Nachdem ich die Bank angerufen und mit ihrem Vertreter gesprochen hatte, wurde mir gesagt: "Ah, ich wette, Sie haben einen Strich in die Adresse eingegeben. Unsere Website löscht alles nach dem Strich, sodass wir Ihre Scheckkarte wahrscheinlich an die falsche Adresse geschickt haben. Dies passiert alles die Zeit."

USAA nicht anzuklopfen, da ich finde, dass ihre Weboptionen und ihr Kundenservice die Konkurrenz bei weitem übertreffen, aber dies ist ein großartiges Beispiel dafür, wo es entscheidend ist, dass ein Benutzer einen Fehler sieht. Selbst wenn es sich um eine nicht entzifferbare Nachricht handelt, weiß der Benutzer zumindest, dass ein Fehler aufgetreten ist, und kann versuchen, das Problem per Telefon oder E-Mail zu beheben, bevor beispielsweise die Scheckkarte an eine andere Person gesendet wird.

Nehmen wir also an, dass es immer Fehler geben wird, und dann müssen diese Fehler in irgendeiner Form dem Endbenutzer mitgeteilt werden. Ziel ist es dann, die Fehlersprache auf die Aufgabenziele und -bedürfnisse des Endbenutzers anwendbar und verständlich zu machen.

3
DA01