Cognitive Walkthrough
Allgemeines   Ablauf   Entwicklung und theoretischer Hintergrund   Vergleich zu anderen Methoden  

Der Cognitive Walkthrough (im folgenden CW) ist eine Usability Inspection Technik; d. h. anstatt empirischer Benutzerdaten werden die Urteile eines oder mehrerer Gutachter herangezogen. Mehr als andere Methoden zieht diese Technik ihre theoretischen Grundlagen aus der Kognitionsforschung.

Der CW analysiert (vorgegebene) korrekte Handlungsabläufe und fragt dabei, ob diesen Abläufen tatsächlich von den Benutzern gefolgt wird. Dabei werden auch Gründe für erkannte Probleme vorgeschlagen. So soll den Produktdesignern eine Hilfestellung zur Problembehebung gegeben werden.

Im Unterschied zu den meisten anderen Techniken konzentriert sich der CW weniger auf das Interface, als mehr auf die mentalen Prozesse eines hypothetischen Nutzers. Grund dafür ist die Annahme, daß ein erfolgreiches Produkt den mentalen Fähigkeiten eines Benutzers entsprechen muß. Die Usability eines Produktes, das dem Benutzer Wissen abverlangt, das er nicht hat, kann nicht hoch sein.

Der CW betont vor allem einen bestimmten Usability Aspekt: Die leichte Erlernbarkeit der Bedienung eines Produktes. Dabei wird allerdings betont, daß dieser Punkt stark mit anderen Dimensionen (z. B. Effektivität o. Effizienz) zusammenhängt. Die Entwickler unterstellen eine Erleichterung des Lernprozesses durch den Vorgang der Exploration. Daher liegt ein Schwerpunkt der Analyse darauf, in welchem Ausmaß, ein Produkt explorierendes Lernen unterstützt.



Ablauf

Die Durchführung des CW kann in folgende Schritte unterteilt werden:
  1. Definition des Inputs
  2. Untersuchung der Handlungssequenzen für jede Aufgabe
  3. Protokollierung kritischer Informationen
  4. Revision des Interfaces

1. Definition des Inputs
Dieser vorbereitende Abschnitt umfaßt Vorarbeiten und Vorübeberlegungen auf folgenden Gebieten:

Benutzercharakteristiken:
Wer wird das zu entwickelnde System verwenden? Diese Frage kann fast beliebig detailliert beantwortet werden. Häufig kann es schon genügen, die Gruppe grob zu beschreiben: z. B. "Benutzer des Betriebssystem Windows 98". Oft ist aber auch eine genauere Differenzierung nötig und sinnvoll: z. B. "Anwender des Programms MacPaint des Betriebssystems Macintosh". Grundsätzlich sollte in dieser Phase in Betracht gezogen werden, welches Wissen die Zielgruppe voraussichtlich hat. Während der späteren Analysephase wird überprüft, ob dieses Wissen mit den Erfordernissen der Bedienung übereinstimmt.


Beispielaufgaben (Szenarien):
Während eines CW wird eine Aufgabe untersucht, deren Bearbeitung ein Produkt unterstützen soll. Die komplette Evaluation erfordert üblicherweise mehrere CWs und bezieht sich auf meherere Aufgaben. Die richtigen Aufgaben auszuwählen, ist ein entscheidender Schritt, da nur diese in die Evaluation miteinfließen.

Die ausgewählten Aufgaben sollten zwei Kriterien erfüllen: sie sollten wichtig und realistisch sein. Sie sollten also zum einen Aufgaben betreffen, die entweder häufig ausgeführt werden und/oder sich auf kritische Arbeitsaspekte beziehen; zum anderen sollten sie die wahre Natur der Arbeit der Benutzer widerspiegeln.

Generell sollte sich eine Analyse auf eine vernünftige aber repräsentative Auswahl von Aufgaben beschränken. Die Informationen zur Auswahl liefern gewöhnlich Marktstudien, Bedarfs- oder Aufgabenanalysen.


Handlungssequenzen:
Welche Folge von Aktionen ist für jede Aufgabe auszuführen? Gesucht wird eine Bediensequenz, die der Designer gerne von den Benutzern sehen würde, wenn sie eine bestimmte Aufgabe bearbeiten. Üblicherweise ist es (zumindest bei domänenspezifischen Systemen) der Entickler oder Designer, der eine korrekte Handlungsabfolge angibt.

Gibt es für eine Aufgabe mehrere korrekte Lösungswege, so wird meist der übliche oder auch der problematischste ausgewählt.


Beschreibung o. Implementation des Interfaces:
Der letzte Schritt in dieser vorbereitenden Phase ist es, möglichst genau zu beschreiben, was der Benutzer während der einzelnen Bedienschritte zu sehen bekommt. Ist das Interface bereits implementiert, stellt das kein Problem mehr dar. Existiert jedoch nur eine Beschreibung des Produktes auf dem Papier, so müssen die Bildschirmzustände erst entworfen werden. Dabei sollten möglichst die wichtigsten Bedienelemente und releveante Einzelheiten dargestellt werden.


2. Untersuchung der Handlungssequenzen
Hier beginnt der eigentliche CW. Der Prüfer arbeitet sich durch die einzelnen Arbeitsschritte des korrekten Lösungsweges. Dabei sind für jede Aktion die Voraussetzungen und die Folgen zu bedenken. Aus diesen Überlegungen soll geschlossen werden, wie wahrscheinlich es ist, daß der typische Benutzer das Aufgabenszenarion korrekt bearbeiten kann.

Dazu können folgende Fragen hilfreich sein:

Wird der Benutzer versuchen, den richtigen Effekt zu erzielen?
Die kritische Frage an diesem Punkt ist, ob der Benutzer erreichen will, was die korrekte Aktion bewirken wird. Wenn diese Übereinstimmung nicht besteht, ist es unwahrscheinlich, daß er die richtige Aktion wählt.

Der Benutzer könnte wissen, welche Efekte erzielt werden sollen,
  • weil sie Erfahrung in der Bedienung des Systems haben oder
  • weil das System sie dazu auffordert oder
  • weil das Teil ihrer ursprünglichen Aufgabe ist.
Wird der Benutzer erkennen, daß die korrekte Aktion zur Verfügung steht?
Der Benutzer wird keine Aktion ausführen, von der er nicht weiß, daß sie ihm zur Verfügung steht.

Der Benutzer könnte wissen, daß eine Aktion zur Verfügung steht,
  • aufgrund Erfahrung oder
  • weil er eine Ausführungsmöglichkeit (Menüpunkt, Button) sieht.
Wird der Benutzer eine Verbindung herstellen zwischen der korrekten Aktion und dem gewünschten Effekt?
Falls der Benutzer das richtige will und weiß, daß er die gewünschte Aktion ausführen kann, besteht noch immer die Möglichkeit, daß er seine Absicht nicht mit der richtigen Aktion in Verbindung bringt. Für jede Aufgabe sollte der Prüfer angeben können, warum erwartet werden kann, daß der Benutzer die richtige Auswahl von Aktionen trifft.

Der Benutzer könnte eine Verbindung von Aktion und Effekt herstellen,
  • aufgrund Erfahrung oder
  • weil das Interface auf ein derartige Verbindung hinweist oder
  • weil alle anderen Aktionen weniger vielversprechend erscheinen.
Wenn die korrekte Aktion ausgeführt worden ist: wird der Benutzer den Fortschritt erkennen?
Das Produkt sollte dem Benutzer ausreichende Rückmeldung geben, so daß er beurteilen kann ob seinen Aktionen einen positiven oder negativen Effekt haben.

Der Benutzer könnte überzeugt sein, daß alles nach Plan verläuft,
  • aufgrund Erfahrung oder
  • weil er eine Systemreaktion in Verbindung zu seiner Aktion bringt.
3. Protokollierung kritischer Informationen
Der Gutachter sollte die vorher festgelegte Abfolge von Aktionen nicht abändern; auch wenn während seiner Analyse verherende Fehler auftreten, sollte er von einer bereits erfolgten Produktänderung ausgehen und den eingeschlagenen Weg fortsetzen.

Der Prüfer sollte dabei vorwiegend zwei Arten von Informationen protokollieren/festhalten: 1. Es sind alle Informationen und Kenntnisse anzugeben, die der Benutzer für bestimmte Handlungsschritte haben muß. 2. Alle Aktionen sollen aufgelistet werden, die wahrscheinlich zu einer Fehlbedienung führen. Zusätzlich sind die mutmaßlichen Gründe für diese Fehlbedienung anzugeben.

Während dieser Phase ist vor allem darauf zu achten, daß nicht anstatt einer klaren Identifikation des Problems und seiner Ursachen mögliche Designalternativen angegeben werden.


4. Revision des Interfaces
Wie im Abschnitt Handlungssequenzen angesprochen, können Bedienschwierigkeiten häufig mit den erwähnten vier kritischen Fragen in Verbindung gebracht werden. Analog können die Möglichkeiten der Problembehebung organisiert werden:

Der Benutzer versucht nicht, den richtigen Effekt zu erzielen.
Mögliche Lösungsansätze hierbei sind:
  • Die Aktion könnte beseitigt werden, indem sie vom System übernommen oder mit einer anderen Aktion kombiniert wird.
  • Der Benutzer könnte darauf hingewiesen werden, welche Aktion auszuführen ist.
  • Ein anderer Teil der Schnittstelle könnte geändert werden, so daß die klarer wird, warum die Aktion auszuführen ist.

Der Benutzer erkennt nicht, daß die korrekte Aktion zur Verfügung steht.
Die Aktion kann einem offensichtlicheren Bedienelement zugewiesen werden. "Offensichtlich" kann sich hier sowohl auf einen Buttonklick, als auch auf ein (nicht sichtbares) Menü der zweiten Ebene beziehen.

Der Benutzer stellt keine Verbindung her zwischen der korrekten Aktion und dem gewünschten Effekt.
Bei derartigen Schwierigkeiten ist es nötig, daß der Entwickler genauere Kenntnis der Benutzer gewinnt, sowie darüber, wie diese ihre Aufgabe beschreiben. Die bezieht sich hauptsächlich auf die Beschriftung der Bedienelemente, die realistische Aufgabenelemente repräsentieren müssen.

Der Benutzer erhält keine Rückmeldung über seine (erfolgreiche) Aktion.
Das Feedback sollte so gestaltet werden, daß es den Benutzer informiert, daß etwas und zugleich was passiert. Dabei sollen die verwendeten Begriffe wiederum der Arbeitssituation des Benutzers entsprechen. Aus Geschwindigkeitsgründen kann es vorteilhaft sein, auf Rückmeldung zu verzichten und stattdessen direkt den nächsten logischen Arbeitsschritt der Aufgabe anzubieten.


Zweck des CW ist es, dem Designer zu erklären, ob, wo und warum das Design die Interaktion Benutzer-Produkt beeinträchtigen wird. Die Ergebnisse der Analyse sollen konkrete Informationen liefern, die den Entwickler in die Lage versetzen, durch Produktänderungen gezielt auf die erkannten Schwachstellen einzuwirken.

Da die vom Designer akzeptierte korrekte Handlungsabfolge eine Grundlage der Analyse bildet, werden deren Ergebnisse in enger Beziehung zu der Sicht stehen, die der Designer von seinem Entwurf hat. So kann ein Redesign nur unterstützt werden.


Entwicklung und theoretischer Hintergrund

Entwicklung:    Die erste Version des CW bestand aus einer DIN A 4 Seite von Fragen, die sich auf die Absichten, Ziele und Aktionen der Benutzer, sowie die Rückmeldungen des Systems bezogen.

Dieses Formular wurde grundsätzlich als hilfreich bei der Produktentwicklung betrachtet. Trotzdem hatten Entwickler ohne Grundkenntnisse in den Kognitionswissenschaften Probleme, es anzuwenden.

Um diese Probleme zu beseitigen, wurde eine veränderte zweite Version entwickelt, in der das ursprüngliche kurze Formular durch detailliertere Fragen, illustrativen Beispielen und genauen Beschreibungen angereichert wurde.

Dadurch wurde die Anwendung des CW umständlicher und die Dauer der Anwendung in die Länge gezogen.

Aus den Erfahrungen dieser beiden Versionen heraus wurde eine aktuelle dritte Version entwickelt. Diese unterscheidet sich von ihren Vorgängern hinsichtlich der praktikablen Anwendung und der erforderlichen Kenntnis in Kognitionswissenschaften.

Die Autoren bemerken dazu:

We believe that the method now is accessible to everyone regardless of their formal training and that the tediousness and lengthy evaluation time concerns have been remedied.
(Lewis & Wharton, 1997, p. 724)
Es wird hier versucht, die Methode leicht anwendbar für Personen ohne großes Hintergrundwissen in den Kognitionswissenschaften zu gestalten. Trotzdem wird aber darauf hingewisen, daß dieses Hintergrundwissen beim Einsatz der Methode von Vorteil sein kann - wie es auch bei der Heuristischen Evaluation der Fall ist.


Theorie: Der CW basiert auf Theorien zum explorierenden Lernen und Problemlösen. Problemlösestrategien fördern die Entdeckung der korrekten Aktionen; Lernmechanismen speichern eine Repräsentation der korrekten Aktionen zusammen Zielen und Kontext ab.

Der CW soll Entwicklern helfen, Interfaces zu entwickeln, die solche Problemlöseprozesse unterstützen und es dadurch dem Benutzer erleichtern, notwendige Handlungsabfolgen für seine Aufgabe zu erkennen. Zu diesem Zweck simuliert der CW quasi eine typische Art von Problemlöseverhalten: die Means-End-Analyse. Dies ist eine Problemlöseheuristik, die eine neue Aktion danach auswählt, um wieviel sie die Distanz zum Ziel verringert.

Ähnlich wird im CW ein Ziel formuliert, eine Aktion ausgewählt und als Ergebnis der Aktion das Ziel modifiziert. Die nächste Aktion wird aufgrund der Zielrepräsentation und der verfügbaren Aktionen ausgewählt; Einfluß nehmen auf diese Auswahl auch Training und Erfahrung.


Vergleich zu anderen Methoden

Usability Tests:    Es wird nicht empfohlen, im CW einen Ersatz für eine empirische Usability Überprüfung zu sehen. Er kann jedoch bereits in frühen Designstadien eingesetzt werden, wenn ein Benutzertest noch nicht durchführbar ist.

Werden beide Methoden anhand einer fertigen Systemimplementation verglichen, so werden über den CW weniger Probleme identifiziert, was die Entwickler des CW dem komplexen Zusammenspiel von Design, Benutzerwissen, Aufgabendetails und Zufallseinflüssen zuschreiben. Sie weisen aber auch darauf hin, daß die geringeren Durchführungskosten für einen CW die Verantwortlichen nicht hindern sollten, einen nötigen Usability Test durchzuführen.


Heuristische Evaluation: Lewis & Wharton (1997) gestehen der Heuristischen Evaluation zu, mehr Probleme zu identifizieren als der CW. Das liegt ihrer Meinung nach daran, daß die Heuristische Evaluation einen breiteren Ansatzpunkt wählt und alle Aspekte eines Interfaces berücksichtigt, während sich der CW darauf konzentriert, wie bestimmte Elemente des Interfaces zusammenwirken, um den Benutzer bei der Durchführung seiner Aufgabe zu unterstützen. Dabei gehen sie von einer Form der Heuristischen Evaluation aus, die keine Aufgabenszenarien einsetzt.

Ein weiterer Unterschied liegt darin, daß die Heuristische Evaluation die Charakteristiken der Benutzerschnittstelle ins Blickfeld rückt, der CW aber mentalen Prozesse der Benutzer zum Gegenstand hat. Es wird vermutet, daß bestimmte Usability Probleme leichter durch die letztere Herangehensweise erkannt werden.

Auch hier wird nicht empfohlen, Heuristische Evaluation durch CW zu ersetzen; vielmehr wird dazu geraten, beide Techniken kombinieret einzusetzen. So könnte Heuristische Evaluation eine aufgabenunabhängige allgemeine Analyse des Produktes liefern, während in einem CW bestimmte Schlüsselaufgaben genauer untersucht werden.

Usability
Usability - Vorbemerkungen
Usability - Definition
Usability Engineering
Usability Engineering - Ziele
Usability Tests
Usability - Kosten
Usability Inspection
Heuristische Evaluation
Cognitive Walkthrough
Literatur


weiter: Literatur
zurück: Heuristische Evaluation