Donald Norman, ein angesehener Vertreter des Bereichs der "human computer interaction (HCI)" veröffentlichte 1988 in "The Design of Everyday Things" ein Modell zum Lösen von Problemen durch Menschen, das später als "Norman's Action Cycle" bekannt wurde. Norman`s Aktionsstufenmodell gehört zusammen mit GOMS oder dem OAI (Objekt- Aktions- Interface) zu den Interaktions- Theorien, die die Modellierung von Benutzerverhalten, Evaluierung und die Aufstellung von Richtlinien (z.B. zur Erstellung benutzerfreundlicher Interfaces) zum Ziel erklärt hat. Dieses Modell lässt sich in eine Ausführungsphase und eine Phase der Evaluierung eines Tasks unterteilen. Norman selbst nennt es ein ungefähres Modell und keine vollständige psychologische Theorie. Bei vielen Problemstellungen müssen nicht alle der sieben Einzelschritte durchlaufen werden. Im folgenden sollen diese Phasen innerhalb des "Action Cycle" spezifiziert werden.
execution:
Ausgegangen wird vom Ziel, das erreicht werden soll (1.Schritt). Daraus resultiert die Bereitschaft bzw. Intention einer Person, so zu handeln, dass durch dieses Handeln das gesteckte Ziel erreicht wird (2.Schritt). Im Anschluss werden die erforderlichen Aktionssequenzen spezifiziert (3) bevor sie schließlich ausgeführt werden (4). Die Ausführung der Aktion stellt den einzigen Schritt dar, der auf der physischen Ebene stattfindet. Die restlichen Schritte laufen auf mentaler Ebene ab. Von der Durchführung der geplanten Handlung wird sich erhofft, dass sie den Ausgangszustand der Welt dahingegen ändert, dass der Folgezustand den mentalen Repräsentationen des Ziels entsprechen.
evaluation:
Nach der Ausführung der Aktion(en) wird der Zustand der Welt wahrgenommen (5) und hinsichtlich der gestellten Erwartungen interpretiert (6). Schließlich wird verglichen, ob das Ergebnis mit den zu Beginn gestellten Ansprüchen übereinstimmt(7). Verläuft diese Evaluation erfolgreich, ist das Ziel erreicht und das Problem gelöst.
Tritt im Prozess des Durchlaufens dieses Modells ein Problem auf, in der Art, dass die mentale Repräsentation einer Person nicht den physischen Komponenten und dem Zustand der Umgebung entsprechen, wird dieses als "gulf", was soviel wie "Kluft" bedeutet, bezeichnet. Der Zyklus muss nicht mehr komplett durchlaufen werden. Es muss lediglich der bestehende "gulf" beseitigt werden und es kann von neuem evaluiert werden, ob das Ergebnis nun den Vorstellungen der ausführenden Person entspricht.
"Norman's Action Cycle" wird heutzutage hauptsächlich im Bereich von Mensch- Maschine- Interaktion verwendet, v.a. um die Entwicklung von Produkten zu simulieren. In Bereich der Mensch- Maschine- Interaktion können die "7 stages of action" nicht nur eine Hilfe bei der Planung und Strukturierung der Produktentwicklung sein, sondern auch helfen, das Design an Bedürfnisse des Users anzupassen. Es kann mithilfe der Einzelschritte u.a. kontrolliert werden, wie intuitiv das Bestimmen der Funktion des Produkts durch den Benutzer ist (1.Schritt), wie leicht die zentrale Aktion durchgeführt werden kann(4.Schritt) oder wie schnell erkannt wird, in welchem Zustand sich das System befindet. Ein folgerichtiges konzeptuelles Modell hat Vorhersehbarkeit von Aktionen innerhalb eines Systems zur Folge. Das mentale Modell von einem Gerät/ Programm entsteht durch die Interpretation der erhaltenen Aktionen und durch die sichtbare Struktur desselben Geräts /Programms ("system image"). Dem User sollte möglichst viel Sichtbarkeit gewährt werden, denn je mehr man sieht, desto verständlicher erscheint das System. Der Benutzer weiß in welchem Zustand sich das Gerät/ Programm befindet und welche er Aktionen er wahlweise ausführen kann. Außerdem sollte Wert auf genaue Zuordnungen("Mappings") zwischen den Bedienelementen und ihrem Effekt auf die Welt gelegt werden. Zusätzlich sollte auf lückenloses Feedback über die Ergebnisse der Aktionen geachtet werden.
Innerhalb der Ausführung treten "gulfs" auf(Gulf of Execution), wenn das Vorhaben der Person, die die Aktion durchführt, sich von den zulässigen Aktionen unterscheidet. Um das Ausmaß eines "Gulf of Execution" zu bestimmen, muss untersucht werden, inwieweit es das System erlaubt, die geplanten Aktionen ohne zusätzlichen Aufwand auszuführen. Um "gulfs" zu vermeiden und die Ausführung des Tasks zu erleichtern, kann z.B. ein Task in mehrere Unteraufgaben zerlegt werden. Eine weitere Hilfe ist es, Information über kritische Aspekte der einzelnen Tasks ausfindig zu machen, womöglich, indem der User in den Prozess der Dokumentierung des Projekts einbezogen wird.
Ein Gulf of Evaluation gibt an, wieviel Aufwand man betreiben muss, um den tatsächlichen Zustand des Systems zu interpretieren und zu entscheiden, ob den Erwartungen und Anfangsvorstellungen Genüge geleistet wurde. Die Evaluation kann durch ständige Tests, sowie durch erhöhte Sichtbarkeit, die Systemüberwachung möglich macht, verbessert werden.
"Gulfs" stellen den User also in jedem Fall vor erhebliche Probleme, können jedoch durch gutes Design und Testen der Usability während des Entwicklungsprozesses gering gehalten werden. Im Normalfall wird in größeren Unternehmen nicht eine einzelne Person alle Einzelschritte des Aktionsmodells abarbeiten. Vorrausgesetzt die Ergebnisse des Vorgängerschritts werden korrekt weitergereicht, ist eine Aufteilung der Arbeit nach Schritten durchaus begünstigt. "Gulfs" können auch aufgrund von fehlender oder nicht funktionierender Kommunikation zwischen den einzelnen Abteilungen oder auch aufgrund von undeutlicher beziehungsweise schlechter Dokumentation des Projekts entstehen.
Diese Punkte stellen jedoch keine direkten Nachteile des Aktionsstufenmodells dar. Es können jedoch Probleme auftreten, wenn der Anwender ein unangebrachtes Ziel formuliert, ein Fehler, der kaum durch verbessertes Design auszumerzen ist. Es kann auch vorkommen, dass vom Benutzer nicht das gewünschte Objekt gefunden wird, z.B. aufgrund wenig intuitiver Beschreibung oder Bedienelement. Dieser Makel kann demnach durch Änderungen im Design verbessert werden. Oft kann der Anwender eine Aktion nicht bestimmen oder ausführen, was wiederum auf irreführende Erklärungen oder eine wenig aussagekräftige Oberfläche zurückzuführen ist. Auch die vom System produzierten Rückmeldungen sollten deutlich und konkret sein. Unangemessene Meldungen können auch durch das Design verbessert werden.
http://www.it.bton.ac.uk/staff/rng/teaching/notes/NormanGulfs.html
http://courses.cs.vt.edu/~cs3724/summer2-03somervell/lectures/cs3724-stagesofaction.pdf
http://www.niar.twsu.edu/humanfactors/toolbox/Norman.htm
www.ul.ie/~idc/hci/pp5b/norman2.ppt
The Design of Everyday Things - Donald A. Norman
http://adorno.mi.fh-wiesbaden.de/~barth/usability/vorl/UsabilityEinfuehrungPB2.pdf