Heuristische Evaluation der deutschsprachigen Wikipedia/Heuristische Evaluation/Typische Heuristiken

Leitlinien für benutzerfreundliche Oberflächen von Software nach Jakob Nielsen

Jakob Nielsen weist in seinem Werk „Usability Engineering“, im 5. Kapitel „Usability Heuristics“, auf mehrere Punkte hin, welche bei der Erstellung von Software im Hinblick auf Benutzeradaptivität beachtet werden sollten. Sie sind im Folgenden aufgeführt.

Einfacher und natürlicher Dialog

Informationen

Jede zusätzliche, oder vermeidbare Informationseinheit einer Benutzeroberfläche (BO) bedeutet zunächst eine weitere Lerneinheit oder ein weiteres Feld für Missverständnisse, gar Fehleranfälligkeit in der Bedienung. Die Benutzeroberflächen sollten so gestaltet sein, dass die Konzepte der Software mit den Konzepten des Nutzers möglichst deckungsgleich sind. (Vgl. S.115/116)

Graphisches Design und Farben

Benutzeroberflächen sollten nach den Regeln der menschlichen Wahrnehmung gestaltet werden. Dies erleichtert dem Benutzer das Verständnis der Beziehungen zwischen den „Dialogboxen“. Ebenso erleichtert die Beachtung dieser Regeln das Verständnis der Grundstruktur der Benutzeroberfläche, z.B. durch eine Trennlinie, einen Farbcode oder Abständen zwischen den Abschnitten. Daraus folgt, dass Themen oder Gegenstände, welche in keinem Zusammenhang zueinander stehen, nicht in unmittelbarer Nähe aufgeführt oder aufgelistet werden sollen. Durch Hervorhebung, kann dem Anwender das Erkennen wirklich relevanter Informationen oder Dialogelemente vereinfacht werden. Die Aufmerksamkeit wird automatisch auf die wichtige Stelle der BO gelenkt. Informationen, welche in der gewohnten Leserichtung aufgeführt sind, werden schneller wahrgenommen. In vielen Kulturen beginnt die Blickführung somit links oben. Dementsprechend wird dieser Punkt auf einer Bildschirmoberfläche zuerst wahrgenommen. Die Aufmerksamkeit eines Anwenders kann auch durch blinkende Objekte oder Großbuchstaben hervorgehoben werden. Ersteres ist jedoch nur in besonderen Fällen zu empfehlen, da das Blinken unheimlich störend sein kann. Das zweite Hilfsmittel ist auch nur bedingt zu empfehlen, da Text in Großbuchstaben ungefähr zehn Prozent langsamer gelesen wird als normaler Text.

Zusammenfassend kann man sagen, dass die drei wichtigsten Grundregeln des graphischen Designs nach Nielsen folgende sind:

Don’t over-do it.
Possible use without colors (colorblindness).
Color to categorize, differentiate, and highlight. Not to give (quantitative) information. (Vgl. 117-120)

Weniger ist mehr

Zusätzliche Information kann den Anwender von der Hauptinformation ablenken. (Vgl. S.120-123)

Sprich die Sprache des Benutzers

Die Terminologie der Benutzeroberflächen sollte die Sprache der Anwender und keine systemorientierte Sprache sein. „For example, a user interface for foreign currency transactions should not require users to specify British pounds with a code like 317, even if it is the one used internally in the system. Instead, terms like GBP or simply Pounds should be used, depending on whether the system was intended for professional currency traders or for the general public.” (Jakob Nielsen: Usability Engineering: Usability Heuristics)

Dialoge sollten die Muttersprache der Nutzer verwenden. Ebenso sollte darauf geachtet werden, dass Worte nur in ihrer gewohnten Bedeutung gebraucht werden. Die Sprache der Nutzer zu sprechen muss nicht bedeuten, dass das Vokabular der BO eingeschränkt wird. Für ein Interface einer bestimmten Domäne kann es im Gegenteil besser sein, den Wortschatz um solche spezifischen Begriffe zu erweitern und diese zu verwenden, als sich auf nichtssagende Worte zu beschränken. Die Sprache des Nutzers zu sprechen heißt auch von ihm ausgeführte Handlungen im Interface in der Rückmeldung sprachlich hervorzuheben, so etwa „…a security transactions statement should read, “You have bought 100 shares of XYZ Corp.” and not, “We have sold you 100 shares of XYZ Corp.” (Vgl. S.123-126)

Übereinstimmung und metaphorische Sprache

Die Informationsanzeigen im Computer sollten dem Modell der Informationen der Nutzer entsprechen. So sind besonders Darstellungen räumlicher Informationen, wie Landkarten besonders schwierig. Die Welt ist rund, die Karte wie auch der Bildschirm flach. (Vgl. S. 126-129)

Minimize User Memory Load

Gerade weil wir wissen, dass Computer eine sehr große Speicherkapazität besitzen, ist es wichtig, die Nutzer nicht zu überfordern. So ist es für Anwender einfacher sich etwas zu merken, was sie gezeigt bekommen, als stets dazu gezwungen zu werden Informationen aus dem Gedächtnis abzurufen. (Vgl. S.129/130)

Konsistenz

Auf der Befehlsebene

Derselbe Befehl, dieselbe Handlung sollte immer zum selben Ergebnis führen. Die Sicherheit eines Nutzers wie auch der Mut, das innerhalb des Systems Erlernte anzuwenden nimmt in dem Maße zu, wie der Nutzer sich sicher fühlt immer einen Teil des benötigten Wissens zu haben, welches er braucht um neue Operationen in Teilen des Systems anzuwenden. (Vgl. S.132-134)

Feedback

Das System sollte dem Benutzer stets Rückmeldung darüber geben, in welchem Zustand es sich gerade befindet und in welcher Form es die gegebenen Inputs verarbeitet. Auch im Falle eines Fehlers sollte das System eine Meldung anzeigen können. So sollte das System auch positive Fehlermeldungen aufweisen können. „…the way to write the German letter ü on many keybords involves first typing the umlaut, ¨, and then typing the character that is to go under the dots. Some systems provide no visible feedback as the first part of character is typed, leading many novice users to conclude that the system does not know how to deal with umlauts. A better design would show the umlaut and then change the cursor in some way to indicate that the system was waiting for the second part of the character.” (Vgl. S.134/135)

Verzögerung der Antwort durch Bearbeitung

Rückmeldung des Systems ist dann besonders wichtig, wenn das System lange Antwortzeiten für gewisse Operationen benötigt. Schon seit vielen Jahren gibt es feste Ratschläge bezüglich Antwortzeiten:

0.1 Sekunden Antwortzeit ist in etwa die Grenze bis zu der ein Benutzer das Gefühl hat, das System reagiere unverzüglich. Dies bedeutet, dass keine besondere Rückmeldung nötig ist, außer der Darstellung des Ergebnisses über eine Anzeige in der Benutzeroberfläche.
1.0 Sekunden ist der Zeitrahmen, in dem ein Benutzer bei seinem Gedankenfluss noch nicht gestört wird, jedoch eine gewisse Verzögerung wahrnehmen wird. So wird keine besondere Rückmeldung nötig sein bei einer Verzögerung unter einer Sekunde. Beim Benutzer stellt sich dennoch das Gefühl ein, nicht direkt mit den Daten zu „arbeiten“.
10 Sekunden sind die Grenze für eine Aufrechterhaltung der Aufmerksamkeit auf die Verbindung zum System. Bei längeren Verzögerungen möchte der Benutzer andere Tätigkeiten ausführen, bis der Computer seine Verarbeitung beendet hat. So sollte eine Anzeige eingeschaltet werden, welche voraussagt wann der Computer fertig sein wird. Eine Rückmeldung ist dann besonders wichtig, wenn die Verzögerungsspanne wahrscheinlich stark variiert, da die Nutzer in diesem Fall nicht wissen können, was sie erwartet. (Vgl. S.135-137)

Systemfehler

Auch im Falle von Systemfehlern sollte eine Rückmeldung gegeben werden. Viele Systeme sind nicht auf solche Situationen vorbereitet und antworten einfach nicht mehr auf Fragen des Benutzers (typischerweise Einfrieren; aber auch Abbruch ohne Rückmeldung gehört hierzu). Unglücklicherweise ist keine Rückmeldung die schlechteste Form der Rückmeldung. Es überlässt dem Nutzer die Lösung der Frage was wohl schief läuft. So sollte das System unterschiedliche Meldungen darüber liefern, ob am zentralen System oder nur lokal ein Fehler aufgetaucht ist. So sollte ein gut ausgerüstetes System Auskunft geben über den wahrscheinlichen Ort wie auch den Grund des Fehlers geben. (Vgl. S.137/138)

Klar gekennzeichnete Ausstiegspunkte

Benutzer mögen nichts weniger als das Gefühl, vom Computer gefangen genommen worden zu sein. Das System sollte daher so ausgerichtet sein, dass es immer leicht ist, egal in welchem Systemzustand man sich gerade befindet, heraus zu gehen. So sollten alle Dialogfelder und Systemzustände eine Möglichkeit haben, etwas zu löschen, oder den Nutzer in den vorherigen Zustand zurück zu bringen. So können Nutzer ohne Weiteres einfach neue Felder explorieren und unerwünschte Ergebnisse oder Zustände einfach wieder rückgängig machen. Dauert ein Bearbeitungsvorgang länger als zehn Sekunden, so sollte es dem Nutzer auch möglich sein, durch ein Bedienungselement den Computer in der Bearbeitung zu unterbrechen. Diese Bedienelemente sollten für den Nutzer leicht zugänglich und optisch deutlich im Interface erscheinen. Sie sollten keinesfalls nur durch versteckte Befehle und Tastenkombinationen erreichbar sein. (Vgl. S.138/139)

Abkürzungen

Wenige Grundregeln sollen ausreichen, um eine Benutzeroberfläche bedienen zu können. Fortgeschrittene Benutzer legen jedoch großen Wert auf eine effiziente Bedienung, selbst wenn dafür eine gewisse Lernphase erforderlich sein sollte.

Gewohnte und häufig benötigte Operationen sollten daher besonders schnell mit Kürzeln bedient werden können. Typische Shortcuts sind z. B. Abkürzungen oder Tastenkombinationen. Sie schließen einen ganzen Befehl in einem Tastendruck oder einem Doppelklicken auf ein Objekt ein um gängige Operationen durchzuführen. (Vgl. S.139-142)

Gute Fehlermeldungen

Die Mitteilung von Fehlermeldungen sollte nach vier einfachen Regeln erfolgen:

Die Fehler sollten in gut verständlicher Sprache formuliert sein
Sie sollten präzise sein und nicht vage oder zu allgemein gefasst.
Sie sollten dem Nutzer auf konstruktive Weise helfen, das Problem zu lösen
Fehlermeldungen sollten nicht „anklagen“, sondern in ermutigender und höflicher Sprache auf die Fehler hinweisen. (Vgl. S.142-145)

Mitteilungen auf mehreren Ebenen

Keinesfalls sollten alle wichtigen Informationen zusammen in eine Meldung integriert werden. Besser wäre es mehrere kleine Mitteilungen aufzusetzen, die schneller gelesen werden können und die eine Verknüpfung haben zu ausführlicheren Informationen. Die Verknüpfung kann in Form eines Buttons oder eines Links in die Meldung integriert werden. (Vgl. S.144/145)

Fehlervermeidung

Besser noch als gute Fehlermeldungen wäre solchen Situationen im Voraus entgegenzusteuern. Viele dieser Situationen sind als fehleranfällig bekannt und könnten so gestaltet werden, dass der Benutzer nicht in eine solche Situation gerät. So treten gehäuft Fehler auf, wenn der Benutzer dazu aufgefordert wird etwas zu schreiben. Einen Dateinamen aus einem Menü auszuwählen wäre in diesem Fall die bessere Lösung.

Fehler können auch vermieden werden, wenn das System eine Bestätigung des Benutzers einfordert, bevor es geforderte Eingabe, ausführt. Besonders dann, wenn solche Eingaben sehr ernsthafte Konsequenzen haben können. Dennoch sollten solche Dialogboxen nicht zu häufig verwendet werden, da ein Benutzer sonst dazu neigt, die Bestätigung für die Ausführung der Eingaben automatisch abzugeben, ohne sich zuvor die Hinweise bis zum Ende durchgelesen zu haben. (Vgl. S.145/146)

Modi sind zu vermeiden

Eine weitere Ursache für Fehlerquellen sind unterschiedliche Modi eines Systems. So lässt sich aus der Benutzeroberfläche oftmals nicht erkennen, in was für einem Zustand sich das Gesamtsystem befindet. Frühe Texteditoren hatten einerseits einen Einfügemodus und andererseits einen Bearbeitungsmodus. So wurden im Einfügemodus alle Tastatureingaben als Text aufgefasst, im Bearbeitungsmodus dagegen als Befehle. (Vgl. S.146-148)

Hilfe und Dokumentation

Die Benutzeroberfläche eines System sollte möglichst auch ohne zusätzliche Anleitung oder Dokumentation verwendbar sein. Da dies bei größeren Benutzeroberflächen in der Praxis oftmals nicht erreicht wird, ist ein Handbuch oder auch ein Hilfesystem erforderlich. Die Existenz solcher Hilfsmaßnahmen sollte jedoch nicht dazu führen, unnötig komplexe Oberflächen unter der Voraussetzung zu entwickeln, daß diese später durch ein Handbuch erklärt werden.

Folgende Daumenregel sollte man immer im Hinterkopf behalten: Benutzer lesen keine Handbücher.

Sogenannte „Online-Hilfe“ hat den Vorteil, kontextsensitive Hilfe anbieten zu können. Außerdem ist sie meist schneller zu finden.

Einer der wichtigsten Punkte, die eine gute Dokumentation ausmachen, ist die Qualität der Texte selbst. Das ist jedoch ein Thema für sich. Wichtig ist auf jedenfall, daß die Informationen im Text korrekt und aktuell sind (daher beispielsweise nicht die vorvorletzte Version beschreiben).

Da Dokumentation und Hilfe in der Regel nicht gelesen wird (siehe oben), d.h. wenn überhaupt in Problemfällen als Nachschlagewerk dient, sollte es eine gute Suchfunktion geben. In Handbüchern sollte insbesondere der Index nicht fehlen. (Vgl. S. 148-155)

Usability-Heuristiken für das Web (nach Keith Inston)

Keith Instone kommentiert die 10 Heuristiken von Nielsen im Hinblick auf die Anwendung dieser für ein typisches WWW-basiertes User-Interface (wie z.B. die Wikipedia).

Er erweitert die abstrakten Heuristiken um konkrete Hinweise, die in einem passenden Szenario direkt angewandt werden können.

So fordert Inston, Systeme so aufzubauen, dass sie dem Nutzer den aktuellen Status des Systems anzeigen. Das System sollte dem Nutzer immer zeigen, in welchem Zustand sich das System gerade befindet und dies auf verständliche Weise und in angemessener Zeit. So ist die Bedeutung der Anpassung an den jeweiligen Kulturkreis, für Nutzer einer Website, nicht zu unterschätzen. Die zwei wichtigsten Fragen, die demnach das System, durch seine Gestaltung, dem Nutzer beantworten sollte sind: „Wo bin ich?“ und „Wohin kann ich im nächsten Schritt weiter gehen?“. Jede Seite sollte markiert sein und darüber informieren, zu welchem inhaltlichen Abschnitt sie gehört. Links zu anderen Seiten sollten klar hervorgehoben werden. Diese Forderung ließe sich auch dem Aspekt unterordnen, dass das System der realen Welt möglichst entsprechen soll. Vermittelt uns die reale Welt doch zumindest das Gefühl uns in mehr oder weniger vertrauten Raum und Zeitsystemen zu bewegen. So auch in einer Sprachwelt, die uns nicht gar zu fremd ist. Anders gesagt, bestimmte Systemzustände sollten ohne allzu weite (Irr-)Wege oder allzu großen Aufwand wieder herstellbar sein. Inston fordert dazu auf Konsistenz zu wahren und Standards einzuhalten. Dies bezieht sich sowohl auf den Bereich der Sprache, als auch auf bestimmte Situationen oder Handlungen.

< Heuristische Evaluation | Allgemeiner Ablauf >