it-swarm.com.de

Sollten wir versuchen, Fehlerzustände um jeden Preis zu vermeiden, oder Benutzern erlauben, sich von Fehlerzuständen zu erholen?

Heute bin ich auf eine Site gestoßen, auf der die Schaltfläche zum Senden an ein Anmeldeformular deaktiviert war, es sei denn, Sie haben den Benutzernamen und das Passwort eingegeben. Leider konnte ich die URL nicht realisieren, aber es sah so aus:

mockup

bmml source herunterladen - Wireframes erstellt mit Balsamiq Mockups

Ich habe auch gesehen, dass dieses Muster (oder vielleicht Anti-Muster) in Software-Installationsbildschirmen verwendet wird:

mockup

bmml Quelle herunterladen

Aus diesen beiden Beispielen wird die Möglichkeit eines Fehlerzustands entweder verringert oder vollständig beseitigt:

  • Im Anmeldeformular tritt der Fehlerstatus, bei dem eines oder beide Felder leer sind, niemals auf.

  • Im Beispiel der Lizenzvereinbarung wird es niemals einen Fehlerstatus geben.

Ich bin der Meinung, dass diese Art von Schnittstellen dem Benutzer kein Feedback geben. Ich würde es vorziehen, den Benutzer scheitern zu lassen und dann eine Meldung anzuzeigen, um ihn bei der Wiederherstellung zu unterstützen.

Wenn der Benutzer im Beispiel der Lizenzvereinbarung beispielsweise nicht mit deaktivierten Schaltflächen vertraut ist, kann er weiterhin auf die Schaltfläche klicken, stellt jedoch weiterhin fest, dass die Anwendung nichts tut.

Gibt es Gründe oder Gründe, solche Fehlerzustände zu verhindern?

13
F21

Die Hinzufügung eines Rollovers, der angibt, warum die Schaltfläche deaktiviert ist, würde diese verbessern, aber sie sind häufig und vollkommen in Ordnung und besser, als einen Fehler zuzulassen, wenn der Fehler nur dumm aussieht.

Kürzlich habe ich eine Beschwerde bei der BBC eingereicht. Dabei gab es eine Dropdown-Antwort auf "Haben Sie die Details der nächsten Schritte gelesen?" Mit den Optionen "Ja" und "Nein". Wenn Sie jedoch die Option "Nein" auswählen, müssen Sie lediglich "Ja" auswählen. Dies irritierte mich sehr, da das obige Muster ein besserer Weg gewesen wäre, dies anzuzeigen.

Das Scheitern hat zwei große Probleme. Erstens kann es zeit- und ressourcenintensiv sein (je nachdem, wie es gehandhabt wird), und zweitens unterbricht es den Prozessfluss des Benutzers. Das Deaktivieren von Schaltflächen ist eine gute Möglichkeit, um anzuzeigen, dass Sie noch nicht bereit sind, darauf zu klicken, und passt zu der Idee, nur Personen Dinge tun zu lassen, die Sinn machen.

Ich würde es vorziehen, den Benutzer ausfallen zu lassen und dann eine Nachricht anzuzeigen, um ihn bei der Wiederherstellung zu unterstützen.

Ich denke, das ist hier das Kernproblem. Das Versagen des Benutzers ist normalerweise falsch - es endet oft (wie in diesen Szenarien) als sehr bevormundend. Den Benutzer zum Erfolg zu führen, ist ein weitaus besserer Ansatz und wird normalerweise unterstützt. Wenn der Computer weiß, dass ich noch nicht auf "Anmelden" klicken kann, warum kann ich dann? Die Antwort lautet normalerweise "Du hasst mich" in irgendeiner Form, was keinen guten Eindruck hinterlässt.

11

Ich würde es vorziehen, den Benutzer scheitern zu lassen und dann eine Meldung anzuzeigen, um ihn bei der Wiederherstellung zu unterstützen.

Welchen Zweck erfüllt das Scheitern?

Der einzige Grund, warum Sie jemandem absichtlich das Scheitern erlauben möchten, ist, dass er es in Zukunft vermeiden kann. Aber wenn Sie Fehler vollständig beseitigen können, warum ist der Lernprozess notwendig?

Ich glaube nicht, dass Benutzer fühlen sich dumm (und ein Fehler tut dies immer, es sei denn, der Benutzer kann dem System die Schuld geben - ein ebenso unerwünschtes Ergebnis) ist im UX-Design jemals eine wünschenswerte Sache. Fehler und Wiederherstellung sind unnötige Schritte in Richtung eines Benutzers, der sein Ziel erreicht. Warum also überhaupt?

Der Grund für die Verhinderung von Fehlerzuständen ist, dass sie für den Benutzer irrelevant, behindern ihren Fortschritt und verschlechtern ihre Erfahrung indem sie entweder beleidigt werden, sich unangemessen fühlen oder das Gefühl haben, gegen die zu kämpfen Schnittstelle.

Es bleibt nur die Frage, ob es möglich ist, alle Fehlerzustände zu vermeiden. Möglicherweise ist dies bei bestimmten Anwendungen aufgrund anderer Einschränkungen nicht der Fall - und in diesem Fall kann es hilfreich sein, zu lernen, Fehler durch Fehler zu vermeiden. Ich glaube jedoch nicht, dass wir das Scheitern als Teil jedes Prozesses akzeptieren müssen.

Um speziell auf Ihr Beispiel einzugehen - der Grund dafür, dass es ein schlechtes Beispiel ist, ist, dass es einen Fehlerstatus durch einen anderen ersetzt. Wenn Sie befürchten, dass Benutzer durch Klicken auf eine inaktive Schaltfläche fehlschlagen könnten, entfernen Sie die Schaltfläche und suchen Sie ein anderes Steuerelement, das funktioniert. Zur Hölle, haben Sie überhaupt kein Kontrollkästchen "Ich stimme zu" - haben Sie nur eine Schaltfläche, die die gesamte Aktion ausführt.

12
dhmstark

Da es mehrere "Ebenen" der Fehlervermeidung und der Rückkopplungsschleife gibt, gibt es keine einzige Antwort auf Ihre Frage.

Sie müssen jedes Problem einzeln betrachten und das geeignete Fehlervermeidungs-/Feedbackmodell auswählen. (Ja. Und Sie sollten auch jedes Problem miteinander in Betracht ziehen.)

Fehlervermeidung :
- Option ausblenden
- Option deaktivieren
- Option aktivieren (und einen Fehler auslösen)
- Option aktivieren (und Konsequenzen ignorieren)

Manchmal ist es angebracht, Eingabefelder, Menüelemente und Schaltflächen tatsächlich auszublenden. In anderen Situationen ist es jedoch besser, die Elemente der Benutzeroberfläche anzuzeigen, aber zu deaktivieren. Wenn sie sichtbar und deaktiviert sind, muss klar sein, warum sie deaktiviert sind. Wenn dies nicht klar ist, ist es möglicherweise besser, das UI-Element zu aktivieren und ein angemessenes Feedback zu geben, wenn die Benutzer dies verwenden.

Die Aktion "Drucken" ist ein Beispiel für eine Aktion, die aktiviert werden könnte, und gibt eine Fehlermeldung aus, wenn kein Drucker verfügbar ist.

Die Aktionen "Ausschneiden" und "Kopieren" sollten immer nicht aktiviert sein, nur wenn Sie etwas ausgewählt haben, das Sie tatsächlich können Ausschneiden/Kopieren.

"Tabellenwerkzeuge" und "Bildkorrekturwerkzeuge" usw. sollten nur sichtbar sein, wenn Sie tatsächlich mit einem solchen Element arbeiten.

Feedback :
- Passives Feedback (Hinweis/Anweisung)
- Sofortiges Feedback (rechtzeitige Hinweise zu Ihrer Tätigkeit)
- Interruptives Feedback (Dialog, der Ihren Workflow unterbricht)
- Batch-Feedback (Senden Sie Informationen und erhalten Sie Feedback zu allem)

Manchmal reicht es aus, nur einige diskrete Hinweise oder Anweisungen zu geben. "Füllen Sie jedes mit *) gekennzeichnete Feld aus" oder "Keine Dezimalstellen erforderlich". In anderen Situationen kann es jedoch hilfreich sein, dem Benutzer eine klarere Nachricht zu übermitteln, den Workflow jedoch nicht zu unterbrechen. Z.B. ungültige E-Mail oder ungültige Sozialversicherungsnummer. Die wichtige Frage hierbei ist, ob die Informationen für den Benutzer in diesem Moment hilfreich sind und kein störendes Element. Sie können beim Beenden des Felds oder während der Bearbeitung durch den Benutzer validieren. Es hängt davon ab, ob. Der letztere kann aggressiv oder subtil sein. Wenn Sie eine E-Mail eingeben, müssen Sie "Ungültige E-Mail" nicht direkt nach der Eingabe des ersten Zeichens ausrufen, da der Benutzer wahrscheinlich den Rest der E-Mail-Adresse eingeben wird. Sie können warten, bis Sie wissen, dass die E-Mail wirklich ungültig ist. ZB in dem Moment, in dem er zwei @ oder ein ungültiges Zeichen eingibt.

In einigen Situationen (insbesondere bei der Kreuzungsüberprüfung) ist es möglicherweise besser, den Benutzer das Formular ausfüllen und das Formular senden zu lassen und dann eine ordnungsgemäße Fehlerliste bereitzustellen.

2