• Facebook
  • Google+
  • Twitter
  • XING
11.03.2012

Irritierendes Workflow-Design

Reibungslose Workflows erleichtern die Nutzung einer Applikation. Aber leider sind unangenehme Unterbrechungen nur allzu verbreitet - entweder wegen unschönem Design oder Implementierungen, die klemmen.

 

by Jakob Nielsen (deutsche Übersetzung) - 12.03.2012

 

Der Workflow ist eines der wichtigsten Elemente bei der Gestaltung von Anwendungen. Kommen die Nutzer leicht und locker durch die Erledigung ihrer Aufgabe, oder werden sie zu nervigen Umwegen oder zu umständlichen Zusatzschritten gezwungen?

Die Usability eines Arbeitsablaufs kann auf viele Arten reduziert werden, zum Beispiel wenn Sie von den Nutzern verlangen, sich von einem Schritt zum anderen alles Mögliche zu merken. (Die Belastung des Kurzzeitgedächtnisses verringern - eine nützliche Richtlinie, bei der es lohnenswert ist, sich daran zu erinnern :-)

Hier möchte ich mich auf ein verbreitetes Problem konzentrieren: die Nutzer werden davon abgehalten, dem natürlichen Ablauf ihrer Aufgabe zu folgen. Dies kann auf zwei Arten passieren: Ein schlechtes Design der Nutzeroberfläche kann die Nutzer gezielt vom Weg abbringen, oder ein Systemproblem lenkt die Aufmerksamkeit der Nutzer darauf, zuerst dieses Problem lösen, ehe sie ihre eigentliche Arbeit erledigen können.

Um den Unterschied zwischen einer schlechten Nutzeroberfläche und einem schlechten System zu erkennen, betrachten wir nun zwei Beispiele nutzerunfreundlicher Konten-Aktualisierungen.

Schlechter Arbeitsablauf: die iTunes-Anwendung von Apple

Apple iTunes für Windows ist nur so gespickt von schlechtem Design der Nutzeroberfläche, aber mein aktuelles Beispiel bezieht sich darauf, wie man die Nutzervereinbarung aktualisiert. Die Nutzer kümmern sich meist nicht um solche "Vereinbarungen" und empfinden es daher als Störung, wenn eine Website oder App sie dazu auffordert, die Änderungen zu "akzeptieren". (Ich habe "Vereinbarungen" und "Akzeptieren" in Anführungszeichen gesetzt, da die Nutzer nicht wirklich etwas vereinbaren und die unlesbaren Stapel von Juristenchinesisch nicht wirklich akzeptieren.)

Da so gut wie kein Nutzer freiwillig nach der Nutzervereinbarung sucht, taucht sie als Unterbrecher-Zwischentür auf. Solche Zwischentüren sind fast immer schlecht für die Usability, aber ich kann verstehen, warum die Anwälte die Designer der Nutzeroberfläche dazu zwingen, den Kunden dieses üble Design zuzumuten. Allerdings kann man das Design der Vereinbarung so gestalten, dass es mit akzeptablen oder mit miserablen Konsequenzen für den Arbeitsablauf einhergeht - und Apple hat sich dafür entschieden, den Nutzer leiden zu lassen.

Wir nehmen einen typischen Fall an und stellen uns vor, dass eine Nutzerin die installierten Apps auf ihrem iPhone aktualisieren will. Der Arbeitsablauf ist wie folgt:

  1. Sie wählen "Apps" im Menü der Datentypen.
  2. Sie klicken auf "Suche nach Updates" in der gegenüberliegenden Ecke des Bildschirms (ein Beispiel für schlechtes Design nach dem Fitts'schen Gesetz - aber es gibt hier noch deutlich grössere Fische).
  3. Sie sehen die Liste der Apps durch, die sich geändert haben. Lästig.
  4. Sie klicken auf "Alle verfügbaren Updates downloaden" (in der dritten Ecke des Bildschirms, damit wir sicherstellen, dass unsere Maus jeden Tag genug Auslauf bekommt.)
  5. Sie werden durch von der Zwischentür "Nutzervereinbarung" UNTERBROCHEN.
  6. "Ich stimme zu."
  7. Sie lesen eine schön formulierte - aber sinnlose - Nachricht: "Bitte versuchen Sie es erneut."
  8. Beginnen Sie wieder mit Schritt 1. Grrrrr!

Natürlich sollte jeder Designer im Anfängerstadium wissen, dass Schritt 7 zurück zum unterbrochenen Arbeitsablauf führen sollte. Computer beherrschen diese Sache mit der Erinnerung ziemlich gut, so dass sich das System durchaus daran erinnern könnte, was der Nutzer vor der Unterbrechung tun wollte. Mit anderen Worten: Schritt 7 sollte die Fortsetzung des Downloads sein, der in Schritt 4 angefragt wurde.

Ja, es erfordert ein bisschen mehr Programmieraufwand, um den Computer dazu zu bringen, sich diese Information zu merken. Aber man sollte meinen, dass die am höchsten bewertete Firma am Aktienmarkt einen Programmierer zur Verfügung hätte, der diesen kleinen Schritt zu einem verbesserten Nutzererlebnis erledigen kann.

Unerträglicher Arbeitsablauf: Wechsel der Versandapotheke

Mein zweites Beispiel betrifft den Wechsel meiner Krankenversicherung zu einer neuen Versandapotheke. Das Unternehmen hat alle möglichen Nachrichten (physisch und elektronisch) an die Nutzer geschickt, um sie über den bevorstehenden Wechsel zu informieren, und sogar versprochen, dass die laufenden Rezepte der Patienten automatisch von der alten an die neue Apotheke transferiert würden. So weit, so gut; davon abgesehen, dass die Nutzer Veränderungen an sich nicht mögen und es deshalb besser gewesen wäre, den Wechsel ganz zu vermeiden.

Problem: Als ich mich auf der neuen Website einloggen wollte, hat das System mich nicht erkannt.

Was könnte wichtiger sein als die Möglichkeit, sich einzuloggen? Wenn man diesen Schritt nicht vollziehen kann, wird alles andere irrelevant.

Ein oder zwei Wochen später hat das Unternehmen es endlich auf die Reihe bekommen und seine Kunden konnten auf die neue Website zugreifen. Seitdem funktioniert es - auf dem zu erwartenden mittelmässigen Niveau.

Programmierfehler oder schlechtes Design?

Warum regt mich das Versagen von iTunes mehr auf als die Website der Apotheke, wenn doch letztere viel schlimmer war und den Arbeitsablauf völlig zerstört hat, statt ihn nur zu erschweren?

Die Website der Apotheke litt unter einem einmaligen Software-Fehler (Bug), während der Fall iTunes ein permanent schlechtes Interaktionsdesign darstellt.

Fehler können jedem passieren. Auch mir unterläuft von Zeit zu Zeit der eine oder andere Fehler. Grosse, komplexe und unternehmenskritische Software ist besonders anfällig für Programmierfehler und es ist nur vernünftig, der Fehlerbeseitigung ausreichend Zeit im Projektplan einzuräumen, bevor man die Software auf seine Kunden loslässt. Solange die Fehler zügig beseitigt werden, sehe ich das Problem nicht als allzu schwerwiegend an.

Natürlich ist aus Sicht der Nutzer alles schlecht, was die Website daran hindert zu funktionieren. Ob die Menschen eine falsche Funktion erwischen oder eine richtige, die aber gerade nicht funktioniert, macht aus ihrer Sicht keinen Unterschied. Ergebnis = Versagen in beiden Fällen.

Dies ist eine gute Gelegenheit, an den Unterschied zwischen Nutzeroberfläche und Nutzererlebnis zu erinnern. Was wir gestalten, ist die Nutzeroberfläche: Bildschirminhalte, Fehlermeldungen, Formulare, Befehle etc. Aber die Nutzer erleben das System als Ganzes und es besteht aus dem Design und aus den Implementierungen gleichermassen (sowie aus vielen anderen Komponenten wie langsamen Verbindungen, die die Antwortzeiten ruinieren können und das Nutzererlebnis genauso herabsetzen wie ein schlechtes Design).

Per Definition ist die Usability ein Qualitätsmerkmal des gesamten Nutzererlebnisses. Als solches wird sie bestimmt durch Design und Implementierung - und sogar durch Angelegenheiten der Systemadministration wie der Auswahl des Hosting-Providers.

Jeder Fehler verdient es daher, kritisiert zu werden und die Fehlerbeseitigung ist eine kluge Investition in höhere Qualität. Robuste Programmierung ist normalerweise besser für die Usability als die Jagd nach den neuesten Glitzerfunktionen, die dann wieder zusätzliche Versagensrisiken heraufbeschwören.

Schlussendlich nervt mich ein schlechtes Nutzererlebnis mehr, wenn es vom schlechten Design der Nutzeroberfläche herrührt, als ein simpler Fehler. Im Fall von iTunes hat sich jemand hingesetzt und die Seite geschrieben, welche die Nutzer anweist, es noch einmal zu versuchen, nachdem das System sie unterbrochen hat. Es ist also bekannt, dass das Design des Arbeitsablaufs den Nutzern eine zusätzliche Last aufbürdet. Dass dieses schlechte Design über Jahre in der Software vorhanden ist, ist der eigentliche Grund, warum ich es so kritisiere.

 

© Deutsche Version von Jakob Nielsens Alertbox. Institut für Software-Ergonomie und Usability AG. Alle Rechte vorbehalten.

Kommentare auf diesen Beitrag

    Keine Kommentare

Kommentar hinzufügen

Die mit * gekenzeichneten Felder sind zwingend auszufüllen