Die 10 gravierendsten Fehler beim Anwendungsdesign

Die Anwendungs-Usability wird verbessert, wenn die Nutzer wissen, wie die Nutzeroberfläche zu bedienen ist und wenn diese sie durch den Arbeitsablauf leitet. Wenn man gegen die üblichen Richtlinien verstösst, verhindert man beides.

 

by Jakob Nielsen (deutsche Übersetzung) - 19.02.2008

 

Es ist schwer, einen allgemeinen Artikel über Anwendungsdesign-Fehler zu schreiben, da die allerschlimmsten Fehler gebietsspezifisch und idiosynkratisch sind. Für gewöhnlich scheitern Anwendungen, weil sie (a) das falsche Problem lösen, (b) die falschen Funktionselemente für das richtige Problem haben, oder (c) die richtigen Funktionselemente zu kompliziert sind, als dass die Nutzer sie verstehen könnten.

Jeder der drei Fehler bringt Ihre Anwendung zum Scheitern und dennoch kann ich Ihnen immer noch nicht sagen, was zu tun ist. Was ist das richtige Problem? Was sind die richtigen Funktionselemente? Welche verkomplizierenden Schnörkel können sicher von diesen Funktionselementen entfernt werden? Diese Fragen haben für jedes Anwendungsgebiet und jede Nutzergruppe spezifische und sehr unterschiedliche Antworten.

Der einzige verallgemeinerbare Ratschlag ist folgender: anstatt sich auf Ihre eigenen, besten Vermutungen zu verlassen, sollten Sie Ihre Entscheidungen auf Nutzertests gründen:

• Führen Sie Feldstudien und Tätigkeitsanalysen durch, bevor Sie entscheiden, was Ihre Anwendung tun sollte.
• Entwickeln Sie mit Ihren ersten Ideen zunächst Papierprototypen, bevor Sie sich ausführlich dem Design widmen - und definitiv bevor Sie Mittel verschwenden, um etwas einzuführen, was Sie wieder ändern müssten, sobald Sie ein Feedback von den Nutzern bekommen.
• Entwickeln Sie Ihr Design schrittweise und führen Sie viele Durchläufe mit schnellen Nutzertests durch, während Sie Ihre Funktionselemente weiterentwickeln.

Klar, die Leute wollen nicht hören, wenn ich ihnen sage, dass sie ihre Nutzeroberfläche testen müssen. Und schon gar nicht wollen sie hören, dass sie einmal ihren Allerwertesten zum Arbeitsplatz des Kunden bewegen sollte, um echten Menschen bei der Arbeit zuzusehen, die die Anwendung unterstützen soll.

Die allgemeine Vorstellung scheint zu sein, dass man wahre Programmierer nicht aus ihrem Kämmerchen herauslassen dürfe. Meine Ansicht sagt genau das Gegenteil: Niemand sollte an einer Anwendung arbeiten dürfen, ohne dass derjenige wenigstens einen Tag damit verbracht hat, einige Endnutzer zu beobachten.

(Egal was Sie machen, versprechen Sie mir wenigstens eines: Realisieren Sie nicht einfach Funktionswünsche von "Nutzerrepräsentanten" oder "Wirtschaftsanalytikern". Der beste Weg, bei der Usability etwas falsch zu machen, ist, darauf zu hören, was die Nutzer sagen, anstatt sich anzuschauen, was sie tatsächlich machen. Anforderungslisten sind immer falsch. Sie müssen aus den Anforderungen schnell einen Prototyp entwickeln, damit Sie den Nutzern etwas Konkretes zeigen können; nur so finden Sie heraus, was sie wirklich benötigen.)

Trotz alledem gibt es immer noch jede Menge allgemeiner Richtlinien für die Nutzeroberflächen von Anwendungen - und zwar so viele, dass es uns schwer fällt, die Wichtigsten davon in unserem zweitägigen Kurs unterzubringen. Hier ist meine Liste mit 10 Usability-Verstössen, die besonders übel sind und zugleich in besonders vielen Anwendungen auftauchen.

1. Nicht normgerechte Bedienelemente auf der Nutzeroberfläche

Grundelemente der Nutzeroberfläche - Befehlslinks und Schaltflächen, Radio-Buttons und Checkboxen, Scroll-Leisten, Schliessen-Kästchen und so weiter - sind die lexikalischen Einheiten, die das Vokabular der Dialoggestaltung ausmachen. Wenn Sie die Erscheinung oder das Verhalten dieser Einheiten ändern, ist das genau so, als würden Sie plötzlich fremdsprachliche Wörter in ein normales Gespräch einflechten. Det vil gøre læserne forvirrede (oder, um zum Deutschen zurückzukehren: Das wird Ihre Leser verwirren).

Aus irgendeinem Grund fallen Scroll-Leisten am häufigsten selbstgemachten Designs zum Opfer. Seit Jahren begegnen wir nicht normgerechten Scroll-Leisten in unseren Studien und fast immer führen sie dazu, dass die Nutzer einige Optionen übersehen. Auch dieses Jahr beobachten wir das wieder in den Studien, die wir gerade durchführen, um unseren Kurs "Grundlegende Richtlinien für Web-Usability" auf den neuesten Stand zu bringen. (Der verlinkte Artikel enthält Screenshots von fehlerhaften Scroll-Steuerungen).

Einige der weltbesten Interaktionsdesigner haben das Standard-Erscheinungsbild der Oberflächen-Steuerungselemente über die letzten 30 Jahre verfeinert, unterstützt von Tausenden Stunden Nutzertests. Es ist unwahrscheinlich, dass Sie übers Wochenende eine bessere Schalfläche erfinden.

Und selbst wenn Ihr selbstgemachtes Design, isoliert betrachtet, hypothetisch besser wäre als der Standard - es wird in der Echtwelt niemals isoliert gesehen. Ihre Dialog-Steuerelemente werden von Menschen genutzt werden, die jahrelange Erfahrung im Umgang mit normgerechten Nutzeroberflächen haben.

Wenn Jakobs Gesetz lautet, "die Nutzer verbringen den Grossteil ihrer Zeit auf anderen Websites", dann ist Jakobs Zweites Gesetz sogar noch kritischer: "Die Nutzer haben tausend mal mehr Erfahrung mit normgerechten Steuerungselementen als mit irgendeinem individuellen, neuen Design."

Die Nutzer werden höchst wahrscheinlich scheitern, wenn Sie von den Erwartungen an etwas so Grundsätzliches wie die Steuerungselemente einer Oberfläche abweichen. Und selbst wenn sie nicht scheitern, so werden sie doch beträchtliche Intelligenz darauf verwenden müssen, etwas zu bedienen, was eigentlich keiner längeren Überlegung bedürfen sollte. Die kognitiven Ressourcen Ihrer Nutzer sollten sich besser darauf richten, welche Anwendungsfunktionen ihnen dabei helfen können, welche Ziele zu erreichen.

1a. Sieht aus wie ein Oberflächen-Steuerungselement, ist aber gar keins

Das entgegengesetzte Problem - etwas zu haben, das aussieht wie ein Oberflächen-Steuerungselement, wenn es gar keins ist - kann die Usability sogar noch mehr einschränken. Wir sehen oft Texte und Überschriften, die wie Links aussehen (indem sie z.B. farbig oder unterstrichen sind), die man aber gar nicht anklicken kann. Wenn die Nutzer auf diese Doppelgänger klicken und nichts passiert, denken sie, die Seite sei defekt. (Also befolgen Sie bitte die Richtlinien für das Gestalten von Links.)

Ein ähnliches Problem tritt auf, wenn etwas aussieht wie eine Schaltfläche, aber keine Aktivität auslöst, oder wenn etwas wie ein Radio-Button aussieht, aber gar keine Wahl anbietet. Wir haben ein Beispiel hierfür in unserer aktuellen Studie gefunden.

Um ein massgeschneidertes Hemd auf Liste Rouge Paris zu entwerfen, müssen Sie Ihre Masse angeben. Wie der folgende Screenshot zeigt, gibt es hier zwei verschiedene Pfade durch die Anwendung, abhängig davon, ob Ihre Masse bereits bei dem Schneider gespeichert vorliegen.

Unser Testnutzer klickte immer wieder auf die "New Customer"-("Neuer Kunde"-)Schaltfläche, um anzugeben, dass er in der Tat ein neuer Kunde sei. Leider war dieses Bildschirmelement aber gar keine Schaltfläche, sondern eine nicht anklickbare Überschrift.

Er war der einzige Nutzer, der diese Seite getestet hat, da er während einer Aufgabe auf sie stiess, in der die Nutzer sich eine Website aussuchen konnten (gewöhnlich aus einer Liste von Suchergebnissen). In diesem Fall überwand der Nutzer letztendlich die Verwirrung und fuhr damit fort, seine Masse einzugeben. Wenn wir mehr Nutzer getestet hätten, wäre wahrscheinlich ein kleiner Prozentanteil an dieser Stelle gescheitert. Jeder kleine Fehler im Dialogdesign verringert die Verwendung nur um einen kleinen Anteil, aber die meisten Oberflächen enthalten bündelweise Fehler, und die Anzahl verlorener Kunden summiert sich.

Als Nebenbemerkung: Dieser Screen verwendet auch die Radio-Buttons falsch. Theoretisch schliessen sich alle fünf Wahlmöglichkeiten gegenseitig aus, was in der Tat nach Radio-Buttons (Optionsschaltflächen) verlangt. Aber in dem Modell des Ablaufes, das die Nutzer im Kopf haben, gibt es eigentlich zwei Themen: (a) neuer oder alter Kunde, und (b) wie die Masse in ihrem eigenen Fall mitgeteilt werden können. Sie sollten einen einzelnen Satz von Radio-Buttons nur in Fällen nutzen, in denen Kunden zwischen Optionen für eine einzelne Sache auswählen können.

Im Fall oben also würde ein besseres Design so aussehen, dass die Nutzer zunächst die Frage "neuer oder bereits existierender Kunde" beantworten und dann erst die relevanten Radio-Buttons für die gewählte Option zu sehen bekommen.

2. Inkonsistenz

Nicht normgerechte Oberflächen-Steuerungselemente sind ein Sonderfall des übergreifenden Problems von inkonsistentem Design.

Verwirrung entsteht, wenn Anwendungen verschiedene Wörter oder Befehle für die gleiche Sache verwenden, oder wenn sie das gleiche Wort für mehrere Konzepte in verschiedenen Teilen der Anwendung verwenden. In ähnlicher Weise sind die Nutzer verwirrt, wenn Dinge hin und her wandern, was gegen das Prinzip der Konsistenz des Layouts verstösst.

Den gleichen Namen für die gleiche Sache an der gleichen Stelle zu verwenden, macht die Dinge einfach.

Vergessen Sie nie das Doppel-D: Differences are difficult (Unterschiede sind schwierig).

Ein anderes Beispiel aus unserer aktuellen Studie: Bei Expedia erscheint ein Pop-up-Fenster mit einem 2-Monats-Kalender, wenn die Nutzer ihr Hin- und Rückreisedatum für eine Reise eingeben. Der zusammengesetzte Screenshot unten wurde im Februar gemacht und zeigt, was passiert, wenn Sie eine Reise buchen wollen, die am 10. März beginnt und am 15. März endet.

Im zweiten Pop-up hat sich der Monat März nach links bewegt, um die rechte Spalte für den April frei zu machen. Dies mag vielleicht wie eine zweckdienliche Abkürzung wirken, da der Nutzer kaum einen Rückkehrtermin im Februar wünschen wird, wenn er im März seine Reise beginnt.

In Wirklichkeit aber sucht der Nutzer den 15. März an genau der gleichen Stelle, wo er auch im ersten Pop-up Kalender erschien: in der Spalte ganz rechts.

In unseren Testdurchläufen hat die inkonsistente Platzierung der Monate im zweiten Pop-up Verwirrung und Verzögerungen verursacht, aber letztendlich sind die Nutzer dahintergekommen. Wir haben nur ein paar Nutzer an dieser Seite getestet; aber wenn man solche Fehler, die fast zu einem Fehlschlag führten, in Nutzertests beobachtet, ist das für gewöhnlich ein Zeichen dafür, dass ein paar Nutzer diesen Fehler beim Nutzen der Seite wirklich machen werden.

Das falsche Rückflugdatum zu buchen kann fatale Folgen haben - die Kunden stehen am gewünschten Rückreisetag im Flughafen vielleicht ohne ein Ticket für ihren erwarteten Flug da. Wenn eine Website gute Bestätigungs-E-Mails hat, entdecken die Nutzer das Problem vielleicht noch vor dem Abflug, aber auch das bedeutet Ärger und teure Telefonate mit der Kundenbetreuung, um die Situation aufzuklären.

Selbst wenn der Kalender letztendlich korrekt benutzt wird, kostet es mehr Zeit, über das inkonsistente Design nachzudenken, als die Nutzer dadurch einsparen, dass sie nicht erst die Schaltfläche für den nächsten Monat anklicken müssen, um zu Aprilterminen zu gelangen.

Die Abkürzung durch das Verschieben der Monate erspart nur dem sehr häufigen Nutzer Zeit, da dieser lernt, diesen Teil der Nutzeroberfläche effizient zu bedienen. Demnach sollte eine Anwendung für Reisebürokaufleute wahrscheinlich das Design des Expedia-Kalenders verwenden. Eine Website, die Durchschnittsverbraucher zur Zielgruppe hat, sollte das lieber lassen.

3. Keine empfundene Funktionsgewähr

Funktionsgewähr (Affordanz; auch Angebotscharakter genannt) ist das, was man mit einem Objekt machen kann. Ein Kontrollkästchen z. B. erlaubt ein An- und Ausschalten, und bei einem Schieberegler ist es möglich, ihn auf- und abzubewegen. Eine "empfundene Funktionsgewähr" ist eine Handlung, die man schon versteht, indem man sich das Objekt nur ansieht, also noch bevor man anfängt, es zu nutzen (oder es zu berühren, falls es ein reales Gerät ist und kein Nutzeroberflächenelement). Dies wird alles in dem Buch The Design of Everyday Things (Das Design von alltäglichen Dingen) von Don Norman behandelt.

Die empfundene Funktionsgewähr ist für das Design von Nutzeroberflächen besonders wichtig, weil alle Bildflächenpixel ein Anklicken ermöglichen - auch wenn normalerweise nichts passiert, wenn man klickt. Auf einem Computerbildschirm gibt es so viele Dinge zu sehen, dass die Nutzer nicht die Zeit haben, eine Runde "Minensuchen" zu spielen und blind herumzuklicken, bis sie früher oder später etwas Ausführbares gefunden haben. (Ausnahme: Kleine Kinder erforschen manchmal gerne Bildschirme und klicken überall hin.)

Das Design von Drag-und-Drop-Techniken richtet oft Unheil an, wenn nicht klar ist, dass man etwas ziehen und wo man es wieder loslassen kann. (Oder was passieren wird, wenn man zieht und wieder loslässt.) Im Gegensatz hierzu machen einfache Kontrollkästchen und Befehlsschaltflächen es für gewöhnlich völlig offensichtlich, was man anklicken kann.

Die üblichen Anzeichen für einen Mangel an empfundener Funktionsgewähr sind:

• Die Nutzer sagen: "Und jetzt? Was soll ich hier machen?"
• Die Nutzer nähern sich noch nicht einmal dem Funktionselement, das ihnen helfen würde.
• Unmengen von Bildschirmtext versuchen, diese beiden Probleme zu überwinden. (Oder noch schlimmer, weitschweifige, mehrstufige Anweisungen, die verschwinden, nachdem man den ersten von mehreren Handgriffen durchgeführt hat.)

Als ich einige der ersten Macintosh-Anwendungen Mitte der 80er Jahre getestet habe, waren die Nutzer oft ratlos, wenn der leere Bildschirm erschien, nachdem sie z.B. MacWrite gestartet hatten. Und jetzt? Der erste Schritt sollte sein, ein neues Dokument zu erstellen, aber dieser Befehl war auf der ansonsten deutlich sichtbaren Macintosh-Nutzeroberfläche nirgendwo zu sehen, es sei denn, man klappte zufällig das Dateifenster auf. Spätere Ausgaben dieser Anwendung öffneten mit einem leeren Dokument auf dem Bildschirm, mit einer einladend blinkenden Einfügemarke und der empfundenen Funktionsgewähr: "Hier kann man anfangen zu tippen."

3.a. Winzige Anklickziele

Dazu gehört auch das Problem, wenn die Zielobjekte fürs Anklicken so klein sind, dass die Nutzer sie verfehlen und ausserhalb der aktiven Fläche klicken. Selbst wenn sie die damit verbundene Funktionsgewähr zunächst richtig wahrgenommen hatten, änderten die Nutzer oft ihre Meinung und fingen an zu glauben, dass sie nicht ausführbar sei, weil sie dachten, sie hätten es angeklickt und nichts passiert ist.

(Kleine Klickbereiche stellen ein besonderes Problem für ältere Nutzer und für Nutzer mit motorischen Behinderungen dar.)

4. Kein Feedback

Eine der grundlegendsten Richtlinien für die Verbesserung von Dialog-Usability ist, Feedback zu geben:

• Zeigen Sie den Nutzer den Ist-Zustand des Systems.
• Sagen Sie den Nutzern, wie ihre Befehle interpretiert worden sind.
• Lassen Sie sie wissen, was gerade passiert.

Websites, die stumm bleiben, überlassen ihre Nutzer einem Ratespiel. Und oft raten sie falsch.

(Um ein Beispiel der Probleme zu sehen, die aus schlechtem Feedback entstehen, schauen Sie sich den Screenshot des Auto-Konfigurators von VW an, der gegen Ende meines letzten Artikels über unsere aktuelle Testrunde steht: Weil die Nutzer nicht erkennen konnten, welches Rad gewählt war, hatten sie Schwierigkeiten, ihr bevorzugtes Auto zu entwerfen.)

4a. Weg in die Mittagspause, ohne eine Fortschrittsanzeige zu hinterlassen

Eine Variante des Mangels an Feedback ist, wenn ein System es unterlässt, seine Nutzer darüber zu informieren, dass es längere Zeit braucht, um eine Aktion zu Ende zu führen. Die Nutzer denken oft, die Anwendung sei unterbrochen worden, oder sie fangen an, auf neue Aktionen zu klicken.

Wenn Sie den empfohlenen Grenzwerten der Reaktionszeit nicht gerecht werden können, sagen Sie das, und halten Sie Ihre Nutzer darüber auf dem Laufenden, was gerade passiert:

• Wenn ein Befehl länger als 1 Sekunde dauert, zeigen Sie den "Beschäftigt"-Cursor. Dies sagt Ihren Nutzern, dass sie sich zurückhalten und nichts anders anklicken sollten, bis der normale Cursor wieder erscheint.
• Wenn ein Befehl mehr als 10 Sekunden dauert, fügen Sie einen expliziten Fortschrittsbalken ein, vorzugsweise als prozentuale Anzeige (es sei denn, Sie können wirklich nicht vorhersagen, wie viel Bearbeitungszeit noch bleibt, bis die Aktion beendet ist).

5. Schlechte Fehlermeldungen

Fehlermeldungen sind ein Sonderfall des Feedbacks: Sie informieren die Nutzer, dass etwas schief gelaufen ist. Wir kennen die Richtlinien für Fehlermeldungen seit fast 30 Jahren und dennoch missachten viele Anwendungen sie noch immer.

Die häufigste Missachtung der Richtlinien liegt vor, wenn eine Fehlermeldung lediglich sagt, dass ein Problem vorliegt, ohne zu erklären warum, und wie der Nutzer dieses Problem beheben kann. Solche Meldungen lassen die Nutzer hilflos zurück.

Informative Fehlermeldungen helfen den Nutzern nicht nur, ihre aktuellen Probleme zu lösen, sie können auch lehrreich sein. Normalerweise investieren die Nutzer keine Zeit, um über etwas über Funktionselemente zu lesen und zu lernen, aber sie werden die Zeit aufbringen, um eine Fehlerkonstellation zu verstehen, wenn Sie ihnen das eindeutig erklären, denn dann wollen sie ja den Fehler bewältigen.

Im Internet gibt es noch ein zweites, typisches Problem mit Fehlermeldungen: Man übersieht sie auf den meisten Webseiten, weil sie einfach im Durcheinander untergehen. Einfachere Seiten sind offensichtlich ein Weg, dieses Problem zu lösen, aber es ist auch notwendig, Fehlermeldungen auf Web-basierten Nutzeroberflächen stärker hervorzuheben.

6. Zweimal nach der gleichen Information fragen

Die Nutzer sollten eine Information nicht mehr als einmal eingeben müssen. Immerhin sind Computer doch ziemlich gut darin, sich Angaben zu merken. Der einzige Grund, warum die Nutzer etwas doppelt machen müssen, ist die Faulheit der Programmierer, die keine Lust hatten, die Antworten aus einem Teil der Anwendung in einen anderen zu übertragen.

7. Keine Standard-Voreinstellungen

Standard-Voreinstellungen helfen den Nutzern auf vielerlei Art und Weise. Vor allen Dingen können sie:

• die Interaktion beschleunigen, indem sie die Nutzer davon befreien, einen Wert eingeben zu müssen, wenn die Standardeinstellung akzeptabel ist
• anhand eines Beispiels zeigen, welche Art Antwort für die Frage angebracht wäre; und
• Neunutzer zu einem sicheren oder typischen Ergebnis führen, indem sie sie die Standardeinstellung nutzen lassen, wenn sie nicht wissen, was sie sonst tun sollen.

Weil ich Liste Rouge Paris bei Fehler Nr. 1a als schlechtes Beispiel genannt habe, dachte ich, bin ich jetzt mal nett und führe sie hier als ein gutes Beispiel an. Der Schneider bietet für Kunden, die massgeschneiderte Hemden bestellen wollen, 15 unterschiedliche Kragenstile an (unter vielen weiteren Optionen). Zum Glück bieten sie auch gute Standard-Voreinstellungen für jede der vielen Wahlmöglichkeiten an. Während unseres Tests hat sich dies als hilfreich für unseren Erstnutzer herausgestellt, weil die Voreinstellungen ihn zu den geläufigsten oder angemessensten Optionen leiteten, wenn er keine besondere Präferenz hatte.

Dialog zur Auswahl des Kragenstils bei www.listrouge-paris.com (3 von 15 Stilen abgebildet)

8. Nutzer einfach ins kalte Wasser werfen

Die meisten Web-basierten Anwendungen sind flüchtige Anwendungen, denen die Nutzer als Nebenprodukt beim Surfen begegnen. Selbst wenn die Nutzer bewusst eine neue Anwendung aufsuchen, gehen sie sie oft ohne ein konzeptuelles Modell hinein, das ihnen sagen würde, wie sie funktioniert. Sie kennen den Arbeitsablauf oder die Schritte nicht, sie kennen das erwartete Ergebnis nicht, und sie kennen die grundlegenden Konzepte nicht, mit denen sie dort umgehen müssen.

Für traditionelle Anwendungen ist dies weniger ein Problem. Selbst wenn jemand noch nie PowerPoint benutzt hat, so hat er wahrscheinlich schon mal eine Präsentation gesehen. Demnach wird ein neuer PowerPoint-Nutzer normalerweise wenigstens ein minimales Verständnis der Anwendung haben, bevor er den Icon zum ersten Mal doppelklickt.

Bei betriebsnotwendigen Anwendungen kann man oft davon ausgehen, dass die meisten Nutzer die Anwendung bereits viele Male ausprobiert haben. Man kann auch oft davon ausgehen, dass Neunutzer etwas Einarbeitung bekommen, bevor sie allein vor der Nutzeroberfläche sitzen. Für gewöhnlich haben sie wenigstens Kollegen in der Nähe, die ihnen ein paar Hinweise bei den Grundlagen geben können. Und ein guter Chef wird seinen neu Eingestellten etwas Hintergrundinformationen dazu geben, warum sie gebeten werden, diese Anwendung zu nutzen und was sie damit eigentlich zustande bringen sollen.

Leider gelten bei den meisten Web-basierten Anwendungen keine dieser Hilfestellungen. Sie gelten noch nicht einmal für viele flüchtige Intranet-Anwendungen.

Usability leidet, wenn man die Nutzer direkt ins Innerste einer Anwendung hineinstürzt, ohne irgendein System, das ihnen eine Vorstellung davon gibt, was gleich passiert. Leider neigen die meisten Nutzer nicht dazu, eine Menge Anweisungstext vorab zu lesen, also müssen Sie ihnen vielleicht in einer kurzen Pünktchenliste etwas anbieten, oder durch ein einziges Bild, mit dessen Hilfe sie den wichtigsten Punkt der Anwendung mit einem Blick begreifen können.

Als Beispiel: unser Testnutzer, der versuchte, sich ein massgeschneidertes Hemd zu bestellen, war höchst verwirrt, als die erste Bildschirmansicht im "Create Your Shirt"-Prozess bei Hamilton Shirts ihm ein fertig entworfenes Hemd samt einer "Zum Einkaufswagen"-Schaltfläche zeigte. Dieser Screen hat zwei Metaphern miteinander vermengt: einen Konfigurator und eine Produktseite, wie sie im E-Commerce üblich ist.

Dies ist ein Fall, in dem eine Standard-Voreinstellung nicht hilfreich ist: Kunden, die ihr eigenes Hemd entwerfen wollen, werden wohl kaum ein vor-entworfenes Hemd auf der ersten Bildschirmansicht kaufen.

(Dieser Screen leidet auch an Fehler Nr. 1: nicht normgerechte Bedienelemente auf der Nutzeroberfläche. Zusätzlich zu ihrer nicht normgerechten Auswahl im Tab-Design, das nicht genügend nach Tabs aussieht, hat der Screen auch noch eine nicht normgerechte Art, durch zusätzliche Stoffmuster zu blättern. Wenn die Bedienelemente in dieser Art dargeboten werden, ist es weniger wahrscheinlich, dass die Nutzer verstehen, wie sie Stoffe auswählen können.)

Unser Testnutzer hat den Prozess, wie er sich sein Hemd auf dieser Seite entwerfen konnte, am Ende nicht verstanden und seinen Einkauf letztendlich woanders getätigt.

9. Nicht angeben, wie Informationen verwendet werden

Das schlimmste Beispiel, bei dem die Nutzer durch einen Arbeitsablauf hindurchgetrieben werden, ohne dass das Ergebnis klar ist, ist es wert, als eigener Fehler herausgegriffen zu werden: Man bittet die Nutzer, Informationen einzugeben, ohne dass man ihnen sagt, wofür man diese verwenden wird.

Ein klassisches Beispiel ist das Feld "Spitzname" (Nickname) im Registrierungsprozess für ein Forum. Viele Nutzer sind sich nicht darüber im Klaren, dass ihr Spitzname dazu benutzt werden wird, sie in ihren Beiträgen bis zum Rest der Ewigkeit zu identifizieren - also geben sie oft etwas Unpassendes ein.

Als ein weiteres Beispiel: wir haben einmal eine E-Commerce Website getestet, die ihre Nutzer mit der Aufforderung konfrontierte, ihre Postleitzahl anzugeben, noch ehe diese sich die Produktseiten ansehen konnten. Das hat bei vielen Nutzern Widerstreben ausgelöst und sie haben die Seite aus Angst um ihre Privatsphäre wieder verlassen. Die Menschen hassen neugierige Websites. Eine alternative Gestaltung funktionierte viel besser: Es wurde erklärt, dass die Website den Standort des Nutzers kennen müsse, damit die Versandkosten für die in Frage kommenden, besonders schweren Produkte genannt werden könnten.

10. Systemzentrierte Funktionselemente

Zu viele Anwendungen stellen ihre schmutzige Wäsche zur Schau, indem sie Funktionselemente anbieten, die eher die interne Sicht des Systems auf die Daten widerspiegelt als das Nutzerverständnis des Problemraums.

In unserer aktuellen Studie wollte eine Nutzerin ihre Vorsorge-Ersparnisse unter verschiedenen Finanzanlagen, die der Plan ihrer Firma anbot, neu verteilen (z. B., mehr in Rentenpapiere und weniger in Aktien zu investieren). Sie dachte, sie hätte dies korrekt ausgeführt, aber in Wirklichkeit hatte sie nur die Zuweisung von zukünftigen Zuwächsen ihres Vorsorgekontos geändert. Ihre bestehenden Investitionen blieben unverändert.

Was die Anlagenfonds-Firma angeht, so werden neue Investitionen und aktuelle Investitionen unterschiedlich gehandhabt. Zukünftige Zusätze umverteilen bedeutet, dass man die Fonds ändert, die gekauft werden, wenn der Arbeitgeber Geld auf das Konto überweist. Bestehende Investitionen umverteilen bedeutet, dass einiges des Aktienbesitzes in bestehenden Investmentfonds verkauft und der Ertrag verwendet wird, um Anteile anderer Fonds zu kaufen.

Was sind hier die Haupterkenntnisse?

• Unsere Testnutzerin unterschied nicht zwischen neuem und altem Geld; sie wollte einfach ihre Vorsorge-Ersparnisse nach ihrer überarbeiteten Investmentstrategie verteilt haben.
• Selbst Nutzer, die diese Unterscheidung zwischen neuem und alten Geld verstehen, möchten ihre Vorsorge-Ersparnisse vielleicht dennoch lieber als eine Einheit behandeln, anstatt unterschiedliche Entscheidungen für neues und altes Geld zu fallen (und verschiedene Anweisungen zu erteilen).

Es wäre wahrscheinlich besser, ein herausragendes Funktionselement anzubieten, mit dem man die Verteilung des gesamten Kontos ändern kann, und gestaffeltes Anzeigen für Experteneinstellungen zu verwenden, um den Nutzern, die die detailliertere Unterscheidung zwischen den zwei Gattungen an Geld machen wollen, auch dies zu ermöglichen.

Bonus-Fehler: Zurücksetzen-Schaltfläche in Webformularen

Dieser Fehler bezieht sich auf Webformulare, aber weil so viele Anwendungen voll von Formularen sind, werde ich ihn hier erwähnen: Es ist fast immer falsch, eine Zurücksetzen-Schaltfläche in Webformularen zu haben.

Die Zurücksetzen-Schaltfläche löscht die gesamten Eingaben des Nutzers und setzt das Formular wieder zurück in seine ursprüngliche Form. Die Nutzer würden das nur dann wollen, wenn sie wiederholt das gleiche Formular ausfüllen mit gänzlich unterschiedlichen Angaben, was auf Websites fast niemals der Fall ist. (Callcenter-Agenten sind eine Sache für sich.)

Wenn Sie es den Nutzern leicht machen, ihre gesamte Arbeit mit einem einzigen Klick zu zerstören, widerstösst das gegen eins der grundlegenden Usability-Prinzipien, nämlich die Arbeit eines Nutzers zu respektieren und um fast jeden Preis zu schützen. (Deshalb braucht man Bestätigungsdialogfenster für die meisten destruktiven Aktionen.)

 

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