Usability Evaluation

Diplomarbeit von Hermann Schmidts

Einleitung:

Usability steht für eine konsequente Ausrichtung und Anpassung von Softwareprodukten auf die Bedürfnisse, Probleme und Wünsche ihrer Zielanwender. Das Usability-Labor ermöglicht eine Überprüfung der Softwarequalität und bietet einen Einblick in den Praxisfall. In Nutzertests bearbeiten Testanwender prototypische Aufgaben der zu evaluierenden Software. Dabei können durch die Messtechnik im Labor objektive Verhaltensdaten der Testanwender aufgezeichnet, sowie deren subjektive Erfahrungen im Umgang mit der Testsoftware über verschiedene Befragungstechniken (Fragebögen, Interviews etc.) erfasst werden. Das erhobene Datenmaterial dient als Grundlage der Usability-Evaluation zur schrittweisen Optimierung der Software.

Durch den Fortschritt bei Mess- und Informationstechnik verfügen heutzutage immer mehr Usability-Labore über die Möglichkeit, eine große Menge objektiver Daten unterschiedlichen Typs aus Nutzertests zu erfassen. Mit einer entsprechenden Laborausstattung können z.B. Blickbewegungen, Klickverhalten, Mausverhalten, Tastaturevents und psychophysiologische Daten einer Nutzergruppe aufgezeichnet werden. Damit kann das Nutzerverhalten während eines Tests objektiviert werden, d.h. dieses kann direkt, ohne die Gefahr subjektiver Verzerrungen aufgezeichnet werden.

Die Laborpraxis zeigt jedoch, dass der Fülle objektiver Nutzerdaten eine verhältnismäßig kleine Menge an Interpretationsansätzen zur Auswertung gegenüber steht. Einem Großteil der Daten fehlt es so an Bedeutungsgehalt und kann nicht effektiv für die Usability-Evaluation genutzt werden. Denn: Neben der aktuellen Gebrauchsqualität eines Produktes ist der Auftraggeber einer Usability-Evaluation meist noch stärker an konkreten Optimierungsmöglichkeiten interessiert. Schließlich soll eine Verbesserung der Usability die Kundenzufriedenheit und damit den Absatz des Produktes entscheidend verstärken. Demzufolge muss eine Software-Evaluation über die reine Datenbeschreibung, auf welche man beim Fehlen geeigneter Interpretationsansätze beschränkt wäre, hinausgehen, um konkrete Optimierungsmöglichkeiten eines Testsystems aufzuzeigen. Der Mangel fehlender Auswertungsstandards wiegt umso schwerer, wenn man in Betracht zieht, welch hoher Aufwand an Technik betrieben und wie viel Laborzeit investiert wird, um relativ wenige Usability-Probleme aus dem gewonnenen Datenmaterial zu extrahieren. In der Verwertung und Analyse von Messergebnissen scheint daher noch viel Potential zu liegen.

Diesen Mangel objektiver Messdaten zur Nutzung für die Usability-Evaluation bestätigt auch die Laborpraxis im Fraunhofer-Institut für Graphische Datenverarbeitung in Rostock (IGD-R). Das RealEYES-Testsystem, welches seit Ende der 90er Jahre am Fraunhofer IGD-R aufgebaut wird, ermöglicht insbesondere die Analyse objektiver Daten im Usability-Test. Das RealEYES-Testsystem ist Teil eines Konzeptes zur computerunterstützten Usability-Evaluation im Rahmen eines nutzerzentrierten Software-Entwicklungsprozesses. Das System stellt Werkzeuge zur Erhebung, Verarbeitung und Präsentation verschiedener Interaktionsdaten zur Verfügung. Damit können Resultate subjektiver Daten sinnvoll ergänzt und verifiziert werden. Testeraussagen können z.B. konkret überprüft und Indikatoren für bestimmte Usability-Probleme gefunden werden. So leistet das RealEYES-Testsystem auch einen wichtigen Beitrag zur Teil-Automatisierung von Evaluierungsprozessen. Wie die Systembezeichnung nahe legt, ist eine Hauptfunktion des RealEYES-Testsystems die Erfassung und Auswertung von Blickbewegungsdaten.

Blickbewegungsdaten scheinen generell geeignet zu sein, um das Interaktionverhalten eines Nutzers abzubilden. Nach Rötting sind Augen- und Blickbewegungen Zeugen der menschlichen Aktivität; dies sowohl auf bewusster Ebene (bewusst regulierte Handlungen) sowie auf unbewusster Ebene (sensumotorische Automatismen). Für eine effiziente Nutzung dieser Verhaltensmuster zur Bestimmung der Gebrauchsqualität muss jedoch herausgefunden werden, wie das Datenmaterial mit Nutzungsproblemen, die der Nutzer während der Interaktion mit dem System erfährt (z.B. Verständnisprobleme bzgl. der Bedienelemente oder schlechte Orientierung), in Verbindung gebracht werden kann. Daraus können Interpretationsansätze abgeleitet werden, die es ermöglichen, konkrete Nutzungsprobleme mittels Blickbewegungsdaten zu identifizieren, Hinweise für deren Ursache zu erhalten und entsprechende Lösungsansätze zu entwickeln.

Seit Anfang der 90er Jahre ist eine verstärkte Publikation - vor allem aus dem englischsprachigen Raum - von Eye-Tracking-Studien festzustellen, die sich auf die Suche nach aussagekräftigen Blickbewegungsparametern konzentrieren, die zur Überprüfung der Usability einer Software eingesetzt werden können. Einen wichtigen Baustein zum praktischen Einsatz der Blickbewegungsregistrierung liefert besonders Rötting, indem er in Form einer ausführlichen Systematik eine Vielzahl von Eye-Tracking-Parameter definiert, operationalisiert sowie deren üblichen Wertebereiche angibt.

Beim Großteil der Studien zum Einsatz von Blickbewegungen für die Usability-Evaluation ist allerdings eines sehr auffällig: Es werden keine Aussagen über den Zusammenhang zwischen den in den Blickdaten zu findenden Interaktionsmustern und der subjektiv (durch die Nutzer selbst) erlebten Gebrauchsqualität getroffen. Diese Tatsache erscheint ein geeigneter Angriffspunkt dieser Arbeit zu sein, ausgehend von folgenden Überlegungen:

Usability als ergonomisches Konzept betont das Ziel, Computersysteme den menschlichen Fähigkeiten, Schwächen und Bedürfnissen einer bestimmten Nutzergruppe anzupassen. Aus dieser Perspektive kann Usability als subjektives Qualitätsmaß begriffen werden. So sei die Zufriedenstellung der Benutzer letztlich darüber entscheidend, ob die Abweichung von einem spezifischen Usability-Kriterium (z.B. die ISO-Norm 9241-12 zur ergonomischen Darstellung von Informationen, siehe Abschnitt 2.2) innerhalb eines zu evaluierenden Systems als Usability-Problem zu werten ist oder nicht. Über eine direkte Befragung von Nutzern lassen sich hauptsächlich Schlussfolgerungen über die Akzeptanz des Systems, den Grad der Zufriedenstellung und Problembereiche der Schnittstelle ziehen. Aus diesem Grund erscheint es zunächst sinnvoll, zur Identifizierung von Usability-Problemen die subjektiven Erfahrungen von Nutzern (subjektive Methoden) gegenüber mittels Messtechnik erfassten Verhaltensdaten zu bevorzugen (objektive Methoden).

Der in der modernen Usability-Forschung eingeschlagene Weg ist allerdings ein anderer. Objektive und subjektive Evaluationsmethoden stehen sich nicht konkurrierend gegenüber, sondern ergänzen sich gegenseitig. Durch diese als Mapping bezeichnete Vorgehensweise der Verknüpfung subjektiver und objektiver Nutzerdaten, können die Nachteile beider Datenerhebungsmethoden kompensiert werden. In dieser Hinsicht machen Schweibenz und Thissen deutlich, dass zwischen dem, was Testpersonen sagen, und dem, wie sie sich tatsächlich verhalten, ein gravierender Unterschied bestehen kann.

Diese Beobachtung zeigt, dass es sehr schwer ist, allein von Testeraussagen auf tatsächliche Nutzungsprobleme zu schließen. Das grundsätzliche Problem subjektiver Daten setzt sich aus zwei Teilen zusammen. Zum einen kann ein Teil des Verhaltens, das eine Person während der Interaktion mit einem Computersystem vollzieht, von dieser nicht bewusst verarbeitet und damit nicht verbalisiert werden, was vor allem für Augen- und Blickbewegungen gilt. Zum anderen muss immer damit gerechnet werden, dass Testeraussagen Verzerrungseffekte beinhalten. So sind z.B. die Antworten eines Testers von seinen Vermutungen über das Untersuchungsziel geleitet und entsprechen nicht seinen eigentlichen Erfahrungen (Sponsorship-Bias).

Im Gegensatz dazu schließen objektive Daten wie Blickbewegungen oder Logfiles (Maus- und Tastaturevents) subjektive Einflüsse aus und bilden das Interaktionsverhalten des Nutzers direkt ab. Der bereits erwähnte Nachteil besteht nun darin, dass der Bedeutungsinhalt der Daten nicht erfasst wird. Dieser gravierende Mangel kann allerdings durch die Kombination mit dazugehörigen subjektiven Daten ausgeglichen werden. Schon 1994 forderten Oppermann und Reiterer daher die Kombination software-ergonomischer Evaluierungsmethoden, um ganzheitliche Qualitätsurteile über eine Benutzungsschnittstelle zu erhalten. Diese Forderung motiviert besonders die Verknüpfung von subjektiven und objektiven Daten zur Evaluation einer Benutzungsschnittstelle.

Als Konsequenz der vorausgegangenen Überlegungen ergibt sich für die vorliegende Arbeit die Aufgabe, den Zusammenhang zwischen Eye-Tracking-Daten und subjektiv erlebten Nutzungsproblemen einer Testergruppe zu untersuchen, um auf diesem Weg einen Beitrag zur Validierung von Eye-Tracking-Daten zum effizienteren Einsatz in der Usability-Evaluation zu leisten.

Gang der Untersuchung:

Die Arbeit untereilt sich in einen Theorieteil A (Kap. 2-5) und einen empirischen Teil B (Kap. 6-11). Im theoretischen Teil werden die wichtigsten wissenschaftlichen Aspekte zur Mensch-Computer-Interaktion, zur Usability-Evaluation, zur Konzeptualisierung von Nutzungsproblemen und zur Anwendung von Eye-Tracking (-Parametern) umfassend erörtert. Diese münden im empirischen Teil in eine statistische Analyse des Zusammenhangs zwischen objektiven Blickbewegungsdaten und subjektiv erlebten Nutzungsproblemen.

Ausgehend von der Charakterisierung menschlicher Kommunikation werden im Kapitel 2 zum einen die Besonderheiten und Beziehungen in der Interaktion zwischen Mensch und Computer dargestellt. Zum anderen soll die Bedeutung und Durchführung von Usability-Evaluationsprozessen für die Softwareentwicklung aufgezeigt werden. Dabei wird im Besonderen ein spezielles Usability-Qualitätsmodell vorgestellt, welches die Grundlage eines modularen Vorgehens zur Überprüfung und Sicherung von Usability bildet. Hier wird auch die Nutzung von Eye-Tracking für die Usability-Evaluation anderen wichtigen Methoden gegenübergestellt. Das dritte Kapitel stellt drei unterschiedliche Konzepte zur Beschreibung von Nutzungsproblemen vor, wovon sich eines speziell auf Eye-Tracking-Parameter bezieht. Kapitel 4 beschreibt die wichtigsten Eigenschaften von Blickbewegungen und der visuellen Wahrnehmung im Hinblick auf deren Nutzen für die Identifizierung von Nutzungsproblemen. Im fünften und letzten Kapitel wird der erstellte Pool an Eye-Tracking-Parametern vorgestellt, woraus ausgewählte Parameter konkreten Nutzungsproblemen zugeordnet werden.

Im Empirie-Teil werden das methodische Vorgehen und die Ergebnisse der statistischen Überprüfung des Zusammenhangs zwischen sechs ausgewählten Parametern und vier konkreten Nutzungsproblemen ausführlich erörtert.

Inhaltsverzeichnis:

	Inhaltsverzeichnis	2
1.	Einleitung	5
1.1	Motivation & Problemstellung	5
1.2	Zielstellung	6
1.3	Inhalt	8
	Teil A - Theoretische Grundlagen	9
2.	Evaluation der Mensch-Computer-Interaktion	9
2.1	Interaktion zwischen Mensch & Computer (MCI)	9
2.1.1	Menschliche Kommunikation/Interaktion	9
2.1.2	MCI als ergonomische Disziplin	12
2.1.3	Aufgabe-Benutzer-Computer-Relation in der MCI	13
2.2	Usability	16
2.2.1	Begriff und Qualitätsmodell	16
2.2.2	Usability-Evaluation	21
2.2.3	Usability-Engineering	35
3.	Nutzungsprobleme in der MCI	42
3.1	Nutzungsprobleme als Handlungsfehler	42
3.2	Nutzungsprobleme als Transformationsproble	47
3.3	Nutzungsprobleme als Syntheseprobleme	49
4.	Charakteristika von Blickbewegungen	56
4.1	Typen von Augenbewegungen	56
4.2	Registrierung von Augenbewegungen	61
4.3	Blickbewegungen und kognitive Prozesse	63
4.3.1	Visuelle Aufmerksamkeit	63
4.3.2	Blickbewegungen und visuelle Aufmerksamkeit	66
4.3.3	Fixationen/Sakkaden und kognitive Prozesse	67
5.	Gaze-Tracking Parameter & Nutzungsprobleme	73
5.1	Parameter-Pool	73
5.2	Gaze-Tracking Parameter zur Identifizierung von Nutzungsproblemen	73
5.2.1	Erwartungsabweichung	73
5.2.2	Nicht-Erkennen	76
5.2.3	Nicht-Verstehen	79
5.2.4	Schlechte Orientierung	79
	Teil B - Empirische Bearbeitung	84
6.	Methodik	84
7.	Messinstrumente	85
7.1	Eye-Tracking-System	85
7.2	Videokonfrontation	86
7.3	Fragebögen	86
8.	Datenerhebung	88
8.1	Testsetting	88
8.2	Testapplikation	88
8.3	Testpersonen (Stichprobe)	89
8.4	Vortests	90
8.5	Versuchsablauf	91
8.5.1	Instruktion & Wiederholung	91
8.5.2	Übung zur Kennzeichnung von Nutzungsproblemen	92
8.5.3	Kalibrierung der Technik	92
8.5.4	Aufgabenbearbeitung und Eye-Tracker	93
8.5.5	Videokonfrontation	94
8.5.6	Fragebogen	97
9.	Hypothesen	98
10.	Ergebnisdarstellung	101
10.1	Problemphase vs. Nicht-Problemphase	101
10.1.1	PA Backtracks	101
10.1.2	PA Suchzeit	103
10.1.3	PA Durchschn. Sakkadenweite	103
10.1.4	PA Wiederkehrende semantische Fixationen	105
10.1.5	PA Pfadlänge	105
10.1.6	PA Übergangshäufigkeiten	107
10.2	Zusammenhangsanalyse	108
10.2.1	PA Backtracks / NP Erwartungsabweichung	108
10.2.2	PA Suchzeit; PA Sakkadenweite / NP Nicht-Erkennen	108
10.2.3	PA Wiederk. semantische Fixationen / NP Nicht-Verstehen	109
10.2.4	PA Blickpfadlänge - Übergangshäufigkeit / NP Schl. Orientierung	109
11.	Diskussion	111
11.1	Ergebnisse	111
11.2	Methodische Aspekte	114
11.2.1	Subjektive Daten aus Videokonfrontation	114
11.2.2	Statistische Verfahren	114
12.	Schlussbetrachtung	116
13.	Glossar	119
14.	Abkürzungsverzeichnis	122
15.	Abbildungsverzeichnis	123
16.	Tabellenverzeichnis	125
17.	Literaturverzeichnis	126
18.	Anhang	132

Textprobe:

Kapitel 3.3, Nutzungsprobleme als Syntheseprobleme: Nachdem in den Abschnitten 3.1 und 3.2 zwei allgemeine Konzepte zur Definition und Kategorisierung von Nutzungsproblemen in der Mensch-Computer-Interaktion vorgestellt wurden, liegt mit Schimpfky ein Ansatz vor, die Operationalisierung von Nutzungsproblemen speziell auf deren Identifizierung mittels Eye-Tracking-Daten auszurichten. Nutzungsprobleme werden dabei als Syntheseprobleme beschrieben, die dadurch charakterisiert sind, dass bei der Interaktion mit einem System über dessen graphische Benutzungsoberfläche zielrelevante Objekte (Buttons, Icons, Menüelemente etc.) vom Nutzer a) nicht erkannt oder b) nicht verstanden werden. Infolgedessen schlägt die Zielerreichung durch die vom System angebotenen Mittel fehl. Die Konzeptualisierung von Nutzungsproblemen erreicht Schimpfky über die Einbindung verschiedener Modelle und theoretischer Ansätze.

Problemtypen: Die Spezifizierung von Nutzungsproblemen in Schimpfkys Ansatz gründet zunächst auf der Kategorisierung allgemeiner Probleme nach Dörner. Das Vorhandensein einer Barriere ist nach Dörner das charakteristische Merkmal eines Problems. Die Barriere verhindert, dass ein Ausgangszustand in einen Endzustand transformiert wird. Zu dieser Transformation sind generell bestimmte Mittel notwendig, die zur Zielerreichung eingesetzt werden. Eine Systematisierung von allgemeinen Problemen erfolgt nach Dörner dadurch, dass zwischen Bekanntheitsgrad der Mittel und Klarheit der Zielkriterien unterschieden wird. Daraus ergeben sich folgende Problemtypen:

Syntheseproblem bei hoher Klarheit der Zielkriterien (hKZ) und gleichzeitig geringem Bekanntheitsgrad (gBM) der Mittel; Interpolationsproblem (hKZ/hBM); Dialektisches Problem (gKZ/hBM); Dialektisches sowie Synthese-Problem (gKZ/gBM); Für das Verständnis des Problemkonzepts nach Dörner ist es wichtig anzumerken, dass eine Barriere resp. ein Problem nur dann entstehen kann, wenn der Handelnde (hier: der Computernutzer) auch die Absicht (Intention) hat, den Ausgangszustand zu verändern. Diese Voraussetzung findet sich auch in den beiden Modellen der vorherigen Abschnitte wieder (siehe Abb. 3.2, Abb. 3.4).

Aufgaben-Struktur-Modell: Die Eingrenzung von Dörners Problemtypen auf das Syntheseproblem gründet im Ansatz von Schimpfky auf die Einführung des Aufgaben-Struktur-Modells nach Dzida. Der Begriff Aufgabe meint hier das Ereignis resp. den Prozess, um einen Ausgangszustand in einen gewünschten Endzustand zu transformieren. In Übereinstimmung mit der Theorie zur sequentiellen-hierarchischen Handlungsregulation beschreibt das Modell eine Aufgabe durch seine elementaren Komponenten, die einer Aktivität vor- und nachgeschaltet sind (siehe Abb 3.5).

Durch die Aktivitätskomponente (Activity) soll - wie bei den bereits beschriebenen Handlungsmodellen - ein Soll-Zustand erreicht werden, der hier als Ergebnis (Result) bezeichnet ist. Die Aktivität ist auf die Transformation bestimmter Eigenschaften eines Objekts gerichtet und wird unter Verwendung eines Werkzeugs (Tool) ausgeführt. In Abhängigkeit gewünschter Attribute (Merkmale) des Ergebnisses sind zusätzlich Parametereinstellungen möglich. Ein Beispiel von Schimpfky zur Nutzung einer Übersetzungssoftware von Langenscheidt verdeutlicht die Anwendung des Aufgaben-Struktur-Modells:

Angenommen die Aufgabe besteht in der Übersetzung des englischen Wortes miscellaneous ins Deutsche mit der Langescheidt-Software. Beginnt man die Betrachtung der Suchmaske, dann ist das Objekt zu Beginn die leere Eingabezeile. Um das englische Wort in die Eingabezeile eingeben zu können, wird die Tastatur benötigt, um die Anfrage zu starten, der OK Button. Tastatur und Button symbolisieren somit das Werkzeug, mit dessen Hilfe das Ergebnis (das übersetzte Wort) erzielt wird. Bei der Eingabe ist es möglich, Suchoptionen als Parameter einzustellen, z.B. Schreibungstolerante Suche oder Nur Stichwörter. Mit Hilfe dieser Parametereinstellungen kann das Suchergebnis beeinflusst werden. Ist z.B. die Rechtschreibung des zu übersetzenden Wortes falsch und wird ohne Schreibungstolerante Suche gesucht, dann findet die Software keinen entsprechenden Eintrag. Ist der Parameter Schreibungstolerante Suche aber aktiviert, liefert die Software eine Ergebnisliste mit mehreren ähnlich geschriebenen Begriffen und deren Übersetzungen.

Nach Schimpfky besteht der Vorteil des Aufgaben-Struktur-Modells darin, dass es im Gegensatz zur Handlungsregulationstheorie auch die notwendigen Voraussetzungen für die Ausführung einer zielgerichteten Handlung abbildet. Die Handlungsregulationstheorie setze voraus, dass alle für eine Operation (Aktion) erforderlichen Vorbedingungen erfüllt, sprich die notwendigen Mittel und Methoden zur Zielerreichung vorhanden sind. Dieser Prämisse folgt die Kritik, dass der Handlungsregulationstheorie somit die Unterscheidung zwischen Aufgabe und Problem (Existenz einer Barriere) fehlt, was diese zur Ableitung von Nutzungsproblemen unbrauchbar macht. Anders das Aufgaben-Struktur-Modell, welches die Vorbedingungen durch die der Aktivität vorgeschalteten Komponenten Werkzeug, Objekt und Parameter bestimme.

Motivationstheorie: Die Relevanz dieser Komponenten unterstreicht Schimpfky durch Einbindung motivationstheoretischen Überlegungen mit Verweis auf das so genannte Rubikon-Modell. Das Rubikon-Modell ist Grundlage der Handlungsmotivationstheorie von Heckhausen und Gollwitzer. Nach diesem Modell müssen vier Phasen durchlaufen werden, damit eine Handlung tatsächlich ausgeführt wird:

a) die prädezisionale Phase, in der zwischen verschiedenen Handlungszielen (Motivationstendenzen) nach Wünschbarkeit (bewertete Handlungskonsequenzen) und Realisierung (antizipierte Umsetzungswahrscheinlichkeit) ausgewählt wird. Nach erfolgter Intentionsbildung folgt b) die präaktionale Phase, in welcher die Handlung geplant wird, indem aus den in Konkurrenz stehenden Intentionen eine in Abhängigkeit von Intentionsstärke und Günstigkeit der Realisation ausgewählt wird. Nach der Intentionsinitiierung wird in c) der aktionalen Phase die Handlung ausgeführt bzw. die Intention realisiert, worauf die Intention deaktiviert wird. In d) der postaktionalen Phasen erfolgt schließlich noch ein Abgleich zwischen Handlungsergebnis und Zielsetzung.

Die ersten beiden Phasen des Rubikon-Modells stellen die motivationsgebundenen Voraussetzungen für das Ausführen einer Handlung dar. Zur Intentionsbildung müssen geeignete Handlungsziele (Motivationstendenzen) vorhanden sein. Zur Intentionsinitiierung müssen geeignete Mittel zur Realisierung vorhanden sein bzw. ausgewählt werden. Um also handeln zu können, benötigt der Handelnde (hier: der Computerbenutzer) ein Objekt, ein Werkzeug und ggf. bestimmte Parameter. Nach Schimpfky folgt daraus, dass diese Komponenten des Aufgaben-Struktur-Modells die Intentionen des Benutzers auf unterster Ebene der Handlungshierarchie repräsentieren. Damit lassen sich die Voraussetzungen für das Ausführen einer Handlung wie folgt bestimmen:

Sie sind (1) das Vorhandensein der relevanten Komponenten Objekt, Werkzeug und Parameter und (2) das Vorhandensein der durch die Komponenten des Aufgaben-Struktur-Modells repräsentierten Intentionen.

Als Syntheseproblem nach Dörner kann demnach ein Handlungsproblem bezeichnet werden, wofür die Nichterfüllung dieser Handlungsvoraussetzungen ursächlich ist, indem zwar die entsprechenden Intentionen (Zielkriterien) vorhanden, nicht aber die Mittel (Objekt, Werkzeug, Parameter) zur Zielerreichung dem Handelnden vollständig bekannt sind. Ein Nutzungsproblem beim Gebrauch der Übersetzungssoftware aus obigem Beispiel entsteht also, wenn dem Nutzer das Objekt Eingabefeld und/oder das Werkzeug OK Button und/oder die Möglichkeit zu Parametereinstellungen nicht bekannt sind.

Ablaufmodell eines Dialogschrittes: Unter Verwendung eines Modells, welches den möglichen Ablauf eines Dialogschrittes in der MCI beschreibt, lassen sich in Schimpfkys Ansatz die Auslöser von Nutzungsprobleme spezifizieren. Es soll also eine Erklärung dafür geliefert werden, dass dem Nutzer die Handlungsmittel nicht bekannt sind, obwohl diese möglicherweise vom System bereitgestellt werden. Wie bereits erwähnt, fokussiert der Ansatz auf jene Probleme, die mittels Eye-Tracking identifizierbar sind.

Schimpfky führt ein Modell zum zeitlichen Verlauf eines Dialogschrittes in Anlehnung an Geis, Dzida und Redtenbacher ein. Das Modell unterteilt aus der Sicht des Benutzers einen Dialogschritt in vier Phasen. Entscheidend ist, dass diese Phasen mit verschiedenen Prozessebenen in der Mensch-Computer-Interaktion, genau genommen mit der syntaktischen (Zeichen und Regeln) und semantischen Ebene (Bedeutung der Zeichen) nach dem linguistischen Modell von Marcus & van Dam in Verbindung gebracht werden (siehe Abschnitt 2.1.1). In Bezug auf das GUI eines Computerprogramms definiert die Syntax das Informationsdesign, also die Komposition von Inhalt, Form und Farbe. Auf Basis der Syntax kann der Nutzer die präsentierten Daten zu bedeutungsvollen Informationen transformieren, diesen also eine Bedeutung geben. Damit können die vier Phasen eines Dialogschrittes wie folgt beschrieben werden:

Orientierungsphase Ein Orientierungsverhalten ist im Allgemeinen dadurch gekennzeichnet, dass die Person zunächst einfachste visuelle Reize aus der Umwelt aufnimmt und diese zur Orientierung in einen größeren, noch groben Zusammenhang bringt. Daraufhin werden die Sinneswahrnehmungen nach Auffälligkeit und Relevanz selektiert (competition for selection). Auf die MCI übertragen entspricht die Orientierungsphase der groben syntaktischen Wahrnehmung der Ist-Situation. Die Displayelemente werden (noch) nicht im Einzelnen analysiert, sondern es wird lediglich die reine Existenz dieser wahrgenommen und eine Vorauswahl getroffen, welche Informationen näher entschlüsselt werden. Für das Beispiel der Übersetzungssoftware hieße das, dass nach dem Start der Software z.B. die Position bestimmter Buttons inkl. deren Beschriftung wahrgenommen werden.

Vorbereitungsphase In der zweiten Phase wird die Handlungsausführung vorbereitet, indem die zuvor selektierten Informationen detailliert analysiert und auf semantischer Ebene dekodiert (entschlüsselt) werden. Der Benutzer vergleicht seine erwarteten mit den real existierenden Bedingungen. Für das Beispiel der Übersetzungssoftware wird in der Vorbereitungsphase etwa das Bedienelement Bibliothek semantisch analysiert, woraus sich die Entscheidung ergibt, die dadurch symbolisierte Funktion mittels Mausklick zu nutzen.

Ausführungsphase Hier wird die Benutzeraktivität ausgeführt, also das Bedienelement Bibliothek tatsächlich angeklickt.

Bewertungsphase Zum Abschluss eines Dialogschrittes wird geprüft, ob das Resultat auch tatsächlich eingetreten ist.

Das Ablaufmodell zeigt demnach, dass die Ausführung des Dialogschrittes nur noch ein Abarbeiten des zuvor auf Basis syntaktischer und semantischer Verarbeitung Geplanten ist. In Schimpfkys Ansatz wird daher die Quelle von Nutzungsproblemen auf die beiden ersten Phasen der Orientierung und Vorbereitung eingeschränkt. Eine Bestätigung erfährt diese These durch Ergebnisse aus der Usability-Laborpraxis. Es hätte sich gezeigt, dass ca. 90% der Nutzungsprobleme in den ersten beiden Phasen des Modells von Geis et al. auftreten. Auf Grundlage dieser Eingrenzung lassen sich zwei Nutzungsproblemtypen während der Orientierungs- und Vorbereitungsphase bestimmen:

Nicht-Erkennen: Während der Orientierung steht die Verarbeitung zielrelevanter visueller Reize im Vordergrund. Das Nicht-Erkennen solcher Informationselemente kann folglich für ein Nutzungsproblem auslösend sein. Zwei Ursachen können dabei klassifiziert werden: Die für den Benutzer relevanten Informationen sind a) nicht vorhanden, d.h. die Erkennung der relevanten Stimuli ist von vornherein ausgeschlossen oder b) falsch kodiert, d.h. diese sind z.B. zu unauffällig oder nicht erwartungskonform.

Erwartungen bezüglich der Dialogstruktur ergeben sich aus den mentalen Modellen des Nutzers, die während der Interaktion aktiv sind. Darin eingebunden sind zum einen konkrete Nutzungserfahrungen mit ähnlichen Anwendungen und zum anderen Handlungswissen um den Ablauf ähnlicher Aufgaben. Ein Nutzer überträgt z.B. den Einkauf in einem realen Shop auf die Nutzung eines Online-Shops, was spezifische Erwartungen an die Bedienelemente und Interaktionsstruktur der Website generiert. Zu betonen ist, dass die Erwartungen des Nutzers in der Orientierungsphase lediglich der Selektion wichtig erscheinender visueller Reize dienen. Ein Nutzer erwartet z.B. fettgedruckte Überschriften, findet diese aber nicht vor.

Mit Blick auf die vorausgegangenen Konzepte von Nutzungsproblemen (NP) lässt sich bezüglich des NP des Nicht-Erkennens nach Schimpfky große Überschneidungen zu a) den Erkennensfehler nach Frese et al. (siehe Abschnitt 3.1) und b) der Handlungskluft aufgrund fehlenden Wissens des Bedienkonzepts sowie der Bewertungskluft aufgrund nicht erkennbarer Systemreaktionen nach dem Handlungsmodell von Norman feststellen (siehe Abschnitt 3.2).

Nicht-Verstehen: Der Auslöser von Nutzungsproblemen bezieht sich in der Vorbereitungsphase auf die semantische Ebene der Interaktion zwischen System und Benutzer. Sind die für die Handlung benötigten Informationen für den Nutzer nicht verständlich, so entsteht eine Nut zungsbarriere. Nach Schimpfky liegen die Ursache dafür z.B. in einer mangelnden Selbstbeschreibungsfähigkeit (verständliches Systemfeedback) oder mangelnden Erwartungskonformität (Angepasstheit an Nutzerwissen und -erfahrung) der Anwendung.

Die beim Nutzer repräsentierten Erwartungen beziehen sich im Unterschied zu den Erwartungen der Orientierungsphase auf bedeutungsvolle Inhalte. Es geht vornehmlich um die semantische Verarbeitung a) der Begrifflichkeiten (deklaratives Wissen) der Funktionselemente sowie b) der Reihenfolge der einzelnen Dialogschritte, also der Ablaufstruktur des Dialogs (Handlungswissen). Beide Wissensformen sind zu einem mentalen Modell des Nutzers über das System zusammengefügt.

Im Abgleich mit den Konzepten nach Frese et al. sowie Norman überschneidet sich die Definition des NP Nicht-Verstehen nach Schimpfky mit a) den Urteilsfehlern und Wissensfehlern nach Frese et al. (siehe Abschnitt 3.1) sowie b) der Handlungskluft aufgrund fehlender zielrelevanter Elemente und der Bewertungskluft aufgrund nicht interpretierbarer Systemaktionen nach dem Handlungsmodell von Norman (siehe Abschnitt 3.2).