Gulf of Evaluation and its Effect on User Interface Design
Autorin: Corinna Ragutt
1. Einleitung
Der "Charme" der Achtziger- und Neunzigerjahre mit ihren blauen DOS-Boxen und Windows 3.11-Fenstern liegt lange hinter uns und mit ihnen auch die Zeiten, in denen nur eine Minderheit - hauptsächlich Informatiker und anderen Spezialisten - sich mit Computern beschäftigten. Ein Großteil der Deutschen ist inzwischen im Besitze eines Personal Computers oder hat zumindest Zugriff auf einen solchen.
Im Zuge des technischen Fortschritts und der Vermarktung für die große Masse gewinnen Aspekte wie Interface Design und Usability immer mehr an Bedeutung. Die Entwickler von Benutzeroberflächen haben die Aufgabe, sich darum zu bemühen, potentielle Unstimmigkeiten zwischen der Bedienoberfläche und den Fähigkeiten und Einschränkungen der Nutzer zu minimieren.
Bei der Erstellung benutzerfreundlicher Interfaces kann man auf Erkenntnisse, die in verschiedenen Interaktionstheorien dargelegt wurden, zurückgreifen. Unter anderem zählt dazu die Theorie des Action Cycle mit den sieben Stages of Action, die erstmals 1988 vom amerikanischen Usability-Spezialisten und Forscher der Human-Computer Interaction Donald A. Norman in "The Design of Everyday Things" (ursprünglich veröffentlicht unter dem Namen "The Psychology of Everyday Things") dargelegt wurde.[7]
Dieses Essay möchte einen Einblick in diese Theorie und den darin vorgestellten "Gulf of Evaluation" geben und desweiteren darstellen, welche Schlüsse im Hinblick auf das User Interface Design daraus gezogen werden können und welche Richtlinien folglich beim Entwerfen einer Benutzeroberfläche möglichst beachtet werden sollten.
2. Die menschliche Wahrnehmung
Um die folgenden Punkte besser zu verstehen, ist es jedoch zunächst wichtig, zu begreifen, wie der Mensch mit seiner Umwelt und mit der Maschine im Speziellen interagiert, wie er diese wahrnimmt und wie sich diese gegenseitig beeinflussen.[6]
Das Denken des Menschen umfasst drei verschiedene Vorgehensweisen, die die Grundlage für die Interaktion mit seiner Umwelt darstellen: die Deduktion, Abduktion und Induktion. Jede einzelne dieser drei Grundbestandteile besitzt eine gewisse Fehlerwahrscheinlichkeit. Trotz dieser Unzuverlässigkeiten sind sie für das Handeln des Menschen dringend notwendig, da dieser Erklärungen auf diese Weise ableitet und aufrecht erhält. Genau dieses Verhalten kann aber zu Problemen beim Dialog mit einer Maschine führen.
Wenn auf ein bestimmtes Ereignis beispielsweise eine gewisse Aktion erfolgt, dann schließt der Anwender intuitiv daraus, dass das Ereignis von der Aktion hervorgerufen wurde und erwartet, dass sich das System in einem ähnlichen Fall äquivalent verhält. Haben nun aber Ereignis und Aktion nichts miteinander gemein, kommt es beim Menschen zwangsläufig zu falschen Schlussfolgerungen und infolgedessen zu Verwirrungen und Fehlern.
Zur Gewährleistung einer guten und reibungslosen Interaktion des Menschen mit der Maschine ist es also von eminenter Wichtigkeit, darauf zu achten, dass der Anwendung, die durch den Benutzer bedient wird, ein korrektes mentales Modell zu Grunde gelegt wird, welches die Arbeitsweise des Systems widerspiegelt und somit erklärt, wie bestimmte Prozesse funktionieren.
Um das mentale Modell verstehen zu können, benötigt der Anwender keinerlei Informationen über die internen Vorgänge oder die Codierung. Es genügt, wenn das System durch sein Verhalten den Benutzer dabei unterstützt, ein korrektes mentales Modell aufzubauen und dabei die Konventionen beachtet, nach denen Menschen ihre Welt interpretieren und verstehen.
3. Der Dialog mit der Maschine
Nachdem wir nun grundlegend auf die menschliche Wahrnehmung eingegangen sind, betrachten wir im Folgenden daraus resultierend speziell den Dialog mit der Maschine noch einmal genauer.[6]
Die vier Hauptkomponenten des Dialogs bilden hier zunächst einmal der Anwender selbst, die Eingabe, die Verarbeitung durch das System und die Ausgabe. Der Zusammenhang zwischen Eingabe, Verarbeitung und Ausgabe bildet das sogenannte "EVA-Prinzip" und stellt eines der grundlegenden Prinzipien der elektronischen Datenverarbeitung dar. Es handelt sich hierbei um einen Zyklus, der sich zwischen der Ausgabe und dem Anwender wieder schließt, und bei dem dem Benutzerinterface die Aufgabe zuteil wird, zwischen dem System und dem Anwender zu interagieren und zwischen diesen beiden Seiten zu vermitteln.
Der Anwender formuliert seine Anforderungen an das System über Eingaben in das Benutzerinterface, welches diese Anforderungen in ein für das System verständliches Format übersetzt und das System dazu bringt, sich entsprechend der Eingaben selbst umzuwandeln, was als "Performance" bezeichnet wird. Wie diese Performance abläuft hängt zum einen vom System selbst ab, zum anderen aber auch von der Zielformulierung, die der Benutzer "eingegeben" hat. Mit Abschluss der Performance ist die Phase der Ausführung beendet und es folgt die so genannte Auswertephase.
Der neue Systemstatus wird dem Anwender abermals über das Benutzerinterface präsentiert, was als Ausgabe bezeichnet wird. Diese wird nun vom Anwender analysiert und interpretiert, was die Auswertungsphase abschließt und den Zyklus entsprechend schließt.
4. Norman's Action Cycle
Norman formuliert nun in seinem Modell der Seven Stages of Action, das "den Fokus auf die Perspektive des Anwenders im Umgang mit der Benutzeroberfläche als Schnittstelle" legt [10], sieben Schritte, die ein Benutzer beim Ausführen einer Bedienhandlung durchläuft:
1. Zielformulierung: Zunächst wird sich der Benutzer überlegen, welche Ziele er mit seinem Handeln verfolgt bzw. was er erreichen möchte.
- EXECUTION:
2. Intentionsformulierung: Aus den Zielen des Benutzer heraus resultieren Intentionen (Absichten), "so zu handeln, dass das Ziel verwirklicht wird."[10]
3. Handlungsspezifikation: Daraufhin wird rein gedanklich die Sequenz von Handlungsschritten spezifiziert, die für die Zielerreichnung vonnöten sind.
4. Ausführung: Erst jetzt kommt es zur tatsächlichen Durchführung der Aktionssequenz.
- EVALUATION:
5. Wahrnehmung des Systemstatus: Nach Ausführung der eigentlichen Handlung wird die Reaktion und somit der Zustand des Systems wahrgenommen.
6. Interpretation des Systemzustands: Dieser neue wahrgenommene Status des Systems wird nun interpretiert, d.h. der Benutzer wird versuchen, die vorhandenen Wahrnehmungen und Ergebnisse zu verstehen.
7. Auswertung des Ergebnisses: Im letzten Schritt vergleicht der Benutzer die aus der Handlung resultierenden Ergebnisse (also den interpretierten Systemzustand) mit seinen ursprünglichen kognitiv repräsentierten Zielen und Intentionen.
Wie oben bereits ersichtlich, können die aufgeführten Schritte gruppiert werden in die Ausführungs- und die Evaluationsphase: "So there are four different things to consider: the goal, what is done to the world, the world itself, and the check of the world. The action itself has two major aspects: doing something and checking. Call these execution and evaluation." [7, S.46; zitiert in 3] Hierbei umfasst die Execution-Phase die Stadien 2 bis 4 und die Evaluation-Phase die Stadien 5 bis 7.
5. Gulf of Evaluation
Bedeutend für unser Ziel, verschiedene Grundsätze und Richtlinien beim User Interface Design zu finden und zu erläutern, ist nun, wie zu Beginn bereits angedeutet, im Zusammenhang mit den Seven Stages of Action besonders der ebenfalls von Norman geprägte Begriff des Gulf of Evaluation - zu deutsch in etwa übersetzbar mit Kluft der Auswertung.
Diese Kluft kann, wie schon der Name sagt, in der Evaluationsphase, d.h. bei den Wahrnehmungs-, Interpretations- und Auswertungsschritten des Modells, auftreten und äußert sich in den "Schwierigleiten, die ein Nutzer hat, wenn er Darstellung und Meldungen eines Systems auf sein eigenes geistiges Modell abbilden möchte."[4] Mads Soegaard fasst Normans Vorstellung des Gulf of Evaluation dahingehend zusammen, dass dieser als Grad, in dem das System Darstellungsweisen, die direkt wahrgenommen und im Sinne der Wahrnehmungen und Absichten des Benutzers interpretiert werden können, zur Verfügung stellt, definiert werden kann.[8]
Man nehme beispielweise an, der Anwender habe versucht, (zum Beispiel über den Webbrowser) ein Dokument auszudrucken. Als er dann aber nach dem Ausführen des Druckens den Papierschacht des Druckers inspiziert, muss er feststellen, dass sein Dokument nur teilweise gedruckt wurde und Text abgeschnitten wurde. Somit decken sich die Ergebnisse bzw. seine Wahrnehmung des Status des Systems nicht mit der mentalen Repräsentation seiner Ziele, die ja darin bestanden, am Ende ein intaktes Dokument in Papierform vorliegen zu haben - eine Kluft der Auswertung ist also in diesem Fall zu beobachten.
Neben dem Gulf of Evaluation findet sich in Normans Ausführungen auch noch der Begriff des Gulf of Execution (Kluft der Ausführung), auf dem im folgenden aber nur kurz in Form einer Definition - der Vollständigleit des Modells halber - eingegangen werden soll: Unter Gulf of Execution versteht man die mitunter auch zeitintensiven und ablenkenden Schwierigkeiten, die ein Nutzer in der Execution-Phase beim Übertragen eines psychologisches Ziels in eine physische Handlung hat. Mit anderen Worten ist hiermit "die Differenz zwischen der Formulierung der zielrelevanten Aktionen seitens des Anwenders (Handlungsspezifikation) und den Aktionen, die das System erlaubt", gemeint.[10]
6. Effekte auf das User Interface Design
Wie aber kann man nun die "Gulfs", insbesondere die Kluft der Auswertung, überbrücken und somit deren Auftreten so weit wie möglich verhindern? Die Lösung genau dieses Problems ist Aufgabe der Designer eines User Interface - die kognitive Anstrengung des Nutzers muss minimiert werden. Ein gutes Design sollte folglich die Schritte des Action Cycles unterstützen und "einen bequemen Übergang zwischen den Stadien" ermöglichen.[12]
Um sich zu diesem Zweck ein Bild von der Qualität einer Benutzeroberfläche zu machen, kann man sich in Bezug auf die Evaluationsphase des Modells folgende Fragen stellen:[11]
- Ist es dem Benutzer möglich, den Systemstatus zu erkennen?
- Stellt das User Interface ausreichend Feedback zu den Folgen einer Aktion zur Verfügung?
- Ist der Benutzer in der Lage, die Systemrückmeldungen zu verstehen?
- Stellt das User Interface ausreichend Feedback für Interpretationen zur Verfügung?
- Kann der Nutzer das Geschehene mit seinen Zielen abgleichen?
Ausgehend von diesen Fragen kann man nun auf diverse Designkriterien und Richtlinien schließen, deren Befolgung sich als Hilfe bei der Umsetzung eines usergerechten Designs erweisen kann.
Eine große Rolle spielt hier das Prinzip der Sichtbarkeit. Der Benutzer soll immer leicht und schnell sehen können, welche Möglichkeiten des Handels sich ihm bieten und - im Zusammenhang mit der Auswertungsphase - welches der aktuelle Zustand ist, in dem sich das Gerät zu diesem Zeitpunkt befindet. Beispielsweise helfen "[l]esbare Texte und kontrastreiche Visualisierungen [...] den Benutzern, den Systemzustand wahrzunehmen und zu interpretieren."[12]
Ebenso muss darauf geachtet werden, dass der Benutzer laufend und unmittelbar ausreichend Systemrückmeldung (Feedback) bezüglich des Ergebnisses der Handlung erhält. Die Meldungen sollten dabei möglichst aussagekräftig, eindeutig, verständlich und vollständig sein, und nicht etwa lediglich darauf hinweisen, dass ein Problem aufgetreten sei ("An error has occured"). Je nach Häufigkeit und Komplexität/Einfachheit der Aktion kann von Fall zu Fall abgewogen werden, ob das Feedback eher auffallend und intensiv oder unauffällig ausfallen sollte. Bei manchen Meldungen mag es ausreichen, sie beispielsweise als Icon in der Statusbar in der Peripherie des Bildschirms zu platzieren (z.B. eine Nachricht über das Beenden eines Downloads oder das wiederholte Speichern einer Textdatei), Fehler und andere wichtige Hinweise sollten allerdings eher durch eine gut sichtbare Meldung und evtl. einen entsprechenden Klang auf sich aufmerksam machen. Auf jeden Fall muss klar zwischen Erfolgsmeldung, Warnung oder gar Fehlermeldung unterschieden werden können.
Dennoch sollten das Systemfeedback auf das wesentliche begrenzt werden, um den Benutzer nicht unter einer von Flut (unnötigen) Informationen zu begraben und seine Aufnahmefähigkeit überzustrapazieren.
Ein weiteres Designkriterium bezieht sich auf das Vorhandensein eines guten konzeptuellen Modells, was sich dahingehend erklären lässt, dass dem Benutzer eine kohärente Darstellung der Bedienvorgänge und Ergebnisse und außerdem ein konsistentes Systembild präsentiert werden soll. Als Beispiel ließe sich hier die Farbe und konsequent durchgeführte Unterstreichung von Links im Web anführen.[10]
Zuletzt sei noch das Prinzip des (guten) Mappings (Konzept der Abbildungen) erwähnt, bei dem Graphiken eine herausgehobene Rolle spielen. Dieses Kriterium zielt neben einem klar ersichtlichen Systemzustand, der in Beziehung zu den Bedienhandlungen steht, darauf ab, dem Nutzer Metaphern zu bieten, die für ihn eindeutig einer Funktion zuordenbar sind, wie in etwa das Symbol einer Lupe für die Suchfunktion. Hier müssen möglichst bekannte Analogien verwendet werden, damit für den Nutzer klar is, was er mit seiner Aktion bewirkt. Entsprechen nämlich die verwendeten Methaphern nicht denen des Benutzers, kann dies zu Problemen führen. In diesem Zusammenhang sei auf die starke methaphorische Bedeutung von Farben verwiesen: rot beispielsweise steht für aufgetretene Fehler, gelb in der Regel für Warnungen und grün für Erfolgsmeldungen. Um den Benutzer nicht zu verwirren, sollten derartige Konventionen beachtet werden.
7. Ausblick
Je nach System, auf dem die Anwendung dem Benutzer zur Verfügung gestellt wird, kann es unter Umständen schwierig werden, allen Kriterien gerecht zu werden - programmiert man etwa eine Anwendung für Mobiltelefone, muss man sich auf andere physische Gegebenheiten einstellen als beispielsweise beim Erstellen einer Webpage - und dort herrschen wieder andere Bedingungen als beim User Interface für eine Desktopanwendung.
Es lässt sich aber abschließend feststellen, dass sich die Systeme durch den technischen Fortschritt immer weiter angleichen und auch im Internet dank web 2.0 ganz andere Möglichkeiten gegeben sind, als noch vor ein paar Jahren (hierbei muss man allerdings davon absehen, dass die unterschiedliche Interpretation des w3c-Standards durch die Browser immer noch zu Problemen führen kann). Man kann sich in allen Bereichen ausgefeilter Graphikelemente, Sound, etc. bedienen und somit sollte es durchaus möglich sein, eine userfreundliche Oberfläche zu gestalten, die auch für den Laien leicht und verständlich bedienbar ist, wenn man sich die oben vorgestellten Prinzipien zu Herzen nimmt.
Quellen- und Literaturangaben
[1] Bellotti, Victoria, et al. Ubiquity: Making sense of sensing systems: five questions for designers and researchers. In: Proceedings of the SIGCHI conference on Human factors in computing systems: Changing our world, changing ourselves CHI '02. ACM Press, New York, 2002.
[2] Christoph, Jens. Konzeptionelle Gestaltung, Anforderungsdefinition und Validierung der Benutzungsoberfläche eines Anbaugerätes zur kommunalen Grünflächenpflege. Diplomarbeit, Universität Paderborn.
<http://adt.uni-paderborn.de/downloads/1101912714_Diplomarbeit.pdf>
[3] Griffiths, Richard. Norman's Gulfs of Execution and Evaluation. 01. Feb. 2007.
<http://www.it.bton.ac.uk/staff/rng/teaching/notes/NormanGulfs.html>
[4] Jendryschik, Michael. Was ist ein guter Standard? Ein Essay über die Designprinzipien des W3C. Einfachheit. 01. Feb. 2007.
<http://jendryschik.de/wsdev/trans/designguide/einfachheit>
(Übersetzung des folgenden Textes:
Bos, Bert. What is a good standard? An essay on W3C's design principles. Simplicity. 01. Feb. 2007.
<http://www.w3.org/People/Bos/DesignGuide/simplicity.html>)
[5] McGrane Chauss, Karen. Reader as User: Applying Interface Design Techniques to the Web. 01. Feb. 2007.
<http://english.ttu.edu/kairos/1.2/features/chauss/intro.html>
[6] Muraitis, Ausdris. Die Maschine liegt in der Natur des Menschen. In: PopScriptum 7 - Musik und Maschine, Schriftenreihe herausgegeben vom Forschungszentrum Populäre Musik der Humboldt-Universität zu Berlin. 01. Feb. 2007.
<http://www2.hu-berlin.de/fpm/popscrip/themen/pst07/pst07040.htm>
[7] Norman, Donald A. The Design of Everyday things. MIT Press, 1988.
[8] Soegaard, Mads. Gulf of Evaluation and Gulf of Execution. 01. Feb. 2007.
<http://www.interaction-design.org/encyclopedia/gulf_of_evaluation_and_gulf_of_execution.html>
[9] TSE Gmbh. Donald A. Norman - Dinge des Alltags - Gutes Design und Psychologie für Gebrauchsgegenstände - Frankfurt 1988 - Zusammenfassung. 01. Feb. 2007.
<http://www.tse-hamburg.de/papiere/internet%20und%20netze/design/Norman88.html>
[10] Wehling, Thomas. Neugestaltung einer Website am Beispiel des Instituts für Informationswirtschaft an der WU-Wien. Diplomarbeit, Wirtschaftsuniversität Wien. S.28-31.
<http://wwwai.wu-wien.ac.at/~hahsler/stud/done/Wehling/DA_Wehling.pdf>
[11] Wikipedia.org. Human action cycle. 01. Feb. 2007.
<http://en.wikipedia.org/wiki/Human_action_cycle>
[12] Witte, Marc. Interaktion und auditive Interaktionsobjekte. 01. Feb. 2007.
<http://www-cg-hci.informatik.uni-oldenburg.de/%7Eairweb/Seminarphase/MarcWitte/html/index.html>
[13] <http://www.ul.ie/~idc/hci/pp5b/norman2.ppt> 01. Feb. 2007.
[14] <http://courses.cs.vt.edu/~cs3724/summer2-03somervell/lectures/cs3724-stagesofaction.pdf > 01. Feb. 2007.