Zurück zur Übersicht

Cognitive Walkthrough

Jonas Koch

Cognitive Walkthrough

Beim Cognitive Walkthrough(CW) handelt es sich um eine spezielle Form des Usability Tests die sich weniger auf die Ergebnisse empirischer Untersuchungen, also der systematischen Auswertung von Fakten, als viel mehr auf die Erkenntnisse moderner Kognitionswissenschaften stützt. Entscheidend sind beim CW nämlich die mentalen Prozesse des Nutzers, also wie gut sich dieser kognitiv mit dem Programm zurechtfindet. Im Laufe des Tests wird einem einzelnen Prüfer die durch die Designer vorgegebene Situation geschildert. Dieser versucht sich nun in die Situation eines späteren Anwenders des Programms zu versetzen und die gegebenen Aufgabenstellungen unter Berücksichtigung der Vorraussetzungen fiktiv zu lösen. Es wird dabei untersucht wie sich der Nutzer bei verschieden Zielen und Aufgabenstellungen verhalten würde. Es wird also ein simulierter, demnach rein kognitiver, Durchlauf der Anwendung hergestellt, ein Cognitive Walkthrough also. Wichtigstes Ergebnis der Tests sind Aussagen über die Erlernbarkeit der Anwendung, wie schnell bzw. leicht sich ein Benutzer den Gegebenheiten des untersuchten Programms anpasst und dessen Anwendung beherrscht. Dies wiederum stellt ein wichtiges Kriterium bei der Ermittlung der Qualität der Usabilty dar. Der CW soll dem Entwickler dabei helfen Mängel der Benutzerführung auszumachen und mehr auf die Verhaltensweisen und Anforderungen der einzelnen Nutzer eingehen zu können.
Waren bei den ersten Versionen des CW, die sich lediglich aus einer Ansammlung von Fragen zu Absicht und Aktionen des Nutzers bzw. der Rückmeldung des Systems zusammensetzten, Kenntnisse der Kognitionswissenschaften für die Auswertung der Ergebnisse noch erforderlich, bemühten sich spätere Versionen diese Anforderungen herabzusetzen wobei ein gewisses Hintergrundwissen immer noch einen Vorteil darstellt.
Der Ablauf des CW gliedert sich in den meisten Fällen in die Definition des Inputs, der Untersuchung der festgelegten Handlungssequenzen für jede Aufgabe, der Protokollierung kritischer Informationen und zuletzt der nötigen Revision des Interfaces.


Definition des Inputs

Hierbei soll die Grundsituation des Tests geklärt werden. Zuerst werden die Charakteristika der erwarteten Nutzer des Programms ermittelt um so deren Wissenstand besser einschätzen zu können. Faktoren wären z.B. der anwendungstechnische Vorwissensstand oder die Benutzung eines spezifischen Betriebssystems. Danach wird festgelegt welche Teile der Anwendung, also welche Anwendungsvorgänge im speziellen, getestet wird und in welcher Reihenfolge diese abgefragt werden sollen. Wichtig ist dabei die Auswahl der wichtigsten Teile des Programms, also der am häufigsten benutzten Elemente sowie derer die sich auf den Programmablauf kritisch auswirken können. Zu diesen Elementen sollte der Designer festlegen was für ihn eine optimale Herangehensweise an die Aufgabenstellung darstellen würde, um diese später mit dem tatsächlichen Vorgehen der Nutzer vergleichen zu können. Schließlich ist es Aufgabe der Designer das geplante Interface möglichst genau zu beschreiben um dem Prüfer einen möglichst vollständigen visuellen sowie informationellen Eindruck des Interface zu vermitteln. Falls die Implementierung des Interface zum Zeitpunkt der Durchführung des CW bereits abgeschlossen entfällt der letzte Punkt natürlich.


Untersuchung der Handlungssequenzen für jede Aufgabe

Hier beginnt die eigentliche Anwendung des CW. Der Prüfer versetzt sich, wie eingangs erwähnt, in die Rolle des Anwenders und arbeitet so Schritt für Schritt die Aufgabenstellungen ab. Besonderes Augenmerk wird auf folgende Punkte gelegt:
Wird der Benutzer versuchen, den richtigen Effekt zu erzielen?
Ist sich der Benutzer überhaupt über sein eigentliches Ziel bewusst, kann er also einschätzen welche Effekte nötig wären um diese zu erreichen? Ist dies nicht der Fall ist die vom Designer erwartete Herangehensweise eher unwahrscheinlich.
Wird der Benutzer erkennen, daß die korrekte Aktion zur Verfügung steht?
Hierbei geht es rein um die visuelle Identifizierung, also z.B. um die Sichtbarkeit des zu der Aktion gehörenden Buttons. Dies könnte z.B. nicht der Fall sein wenn sich der Button in einem zum Zeitpunkt der Ausführung in einem versteckten Menu befindet.
Wird der Benutzer eine Verbindung herstellen zwischen der korrekten Aktion und dem gewünschten Effekt?
Möglicherweise ist sich der Benutzer wohl des benötigten Effekts bewusst und weiß auch über die Existenz der korrekten Aktion bescheid ist aber dennoch nicht in der Lage auszumachen dass der Effekt mit eben genau dieser Aktion zu erreichen ist.
Wenn die korrekte Aktion ausgeführt worden ist: wird der Benutzer den Fortschritt erkennen?
Falls der Benutzer also alle vorangegangenen Hindernisse überwunden hat und folglich die korrekte Aktion durchgeführt hat stellt sich immer noch die Frage ob das System auch das nötige Feedback gibt, dem Benutzer also den Erfolg auch mitteilen kann. Einfachstes Beispiel hierfür wäre eine interne Aktualisierung eines Datensatz auf die jedoch keine Aktualisierung dessen grafischer Repräsentation erfolgt.


Protokollierung kritischer Informationen

Während es Durchlaufs der einzelnen Schritte ist es nun wichtig, dass der Prüfer sämtliche relevanten Informationen protokolliert. Zu diesen Informationen gehören zum einen die Beschreibung der Vorkenntnisse und Informationen die der Benutzer zum jeweiligen Zeitpunkt benötigt, zum anderen natürlich eine genaue Beschreibung sämtlicher Anwendungsvorgänge die zu einem Fehler im Programm führen bzw. nicht der Intention des Designers entsprechen. Wichtig hierbei zu beachten ist ebenfalls die Tatsache, dass sich das Protokoll rein auf die Beschreibung der Vorgänge beschränkt nicht aber konkrete Vorschläge zur Verbesserung des Interface liefern soll.


Revision des Interfaces

Falls der CW zu unerwünschten Ergebnissen geführt hat, der Prüfer also mögliche Fehlerquellen etc. in der Benutzerführung ausgemacht hat, gilt es das Design des Interface zu überarbeiten. Hilfsstellungen zu diesen Änderung können nach demselben Prinzip wie die Untersuchungen der Handlungssequenzen gegliedert werden:
Der Benutzer versucht nicht, den richtigen Effekt zu erzielen.
Ein Lösungsansatz wäre, den Nutzer über den benötigten Effekt aufzuklären oder andere Elemente des Programms so zu ändern, dass die nötige Vorgehensweise deutlicher wird
Der Benutzer erkennt nicht, dass die korrekte Aktion zur Verfügung steht.
Die logische Revision des Interface besteht darin dem Benutzer die Aktion visuell zugänglich zumachen bzw. ihn genauer auf deren Existenz hinzuweisen
Der Benutzer stellt keine Verbindung her zwischen der korrekten Aktion und dem gewünschten Effekt.
Hierbei gilt es dem Benutzer eben diese Verbindung näher zu bringen, ihn also über Konsequenzen seiner Handlungen aufzuklären.
Der Benutzer erhält keine Rückmeldung über seine (erfolgreiche) Aktion.
Wiederum besteht die einzig logische Änderung des Interface darin den Benutzer über die Konsequenzen seiner Handlungen zu informieren


Wichtig für den Nutzen des CW ist die Einsicht, dass dieser keinesfalls die Ergebnisse herkömmlicher, empirischer, Usability Tests ersetzen kann. Jedoch kann er schon in frühen Designstadien Auskunft über Qualität von Interface und Benutzerführung geben.

Quellen:
http://pcptpp030.psychologie.uni-regensburg.de/student2001/Skripten/Zimmer/u-walkthrough.html
http://www.cc.gatech.edu/computing/classes/cs3302/documents/cog.walk.html
http://jthom.best.vwh.net/usability/cognitiv.htm