Comparing the Cognitive Walkthrough to Other
Walkthroughs
The primary characteristic that links all types
of walkthroughs are the reliance on the tasks that the users would perform
as a basis for the evaluation. That which differs amongst the various
walkthroughs is the way in which these tasks are used to inspect the interface
and provide useful information. The cognitive walkthrough (CW) as
mentioned focuses on a cognitively based problem solving model that focuses
on how users develop goals, chooses and execute actions, and integrate
their background knowledge into their goal structure. This approach
is different from the pluralistic approach that relies on real users to
develop action sequences and provide feedback about interface design.
The pluralistic walkthrough uses a different composition
of evaluators that tends to blend some actual users, designers, and usability
experts. In contrast, the CW team is composed of actual designers,
implementors, and occasionally usability specialists into the analyst team.
Also, the pluralistic walkthrough has the participants write down their
anticipated action strategy for a given task as they are presented with
each screen of the system. After this is done, all the representative
users voice their concerns and ideas while the other team members (mostly
the designers) note the responses. The designers then subsequently
raise other important issues that were perhaps not discussed by the users
themselves. Only at the end, if some important usability issues have not
been addresses does the usability specialist provide input into the process.
The format for the pluralistic walkthrough is very similar to that of a
focus group whereby issues are raised, discussed, and presumably solved
by drawing on the various experiences of all the group members.
Although this walkthrough views the entire team as evaluators, the users
are responsible for developing the action sequences and for bringing out
usability problems. It does however require a basic understanding
of the cognitive problem solving process but this can be learned and implemented
by anyone interested in evaluating the system. The pluralistic walkthrough
often leads to unique problems and solutions as it draws from the strengths
of all the potential groups of people involved in the design, including
users, designers, and usability personnel. This walkthrough method
is often regarded as an early concept test or a software test. Refer
to Bias (1994) for a detailed description of the pluralistic walkthrough.
The advantage of the CW over the pluralistic walkthrough
is that there exists no need for actual users in the process. The
CW relies on the detailed user profile provided in the preparation phase
as a basis for understanding how the tasks will interact with the user's
background knowledge. This approach is conceptually consistent with
the premise of the CW because by having the team develop a user profile,
it forces the analysis to focus on what the design team believes the user
population to be and therefore emphasizes appropriately what the designers
have wanted to focus on. The hazard with this approach is that, what
if the user profile is wrong? This would lead to an ineffective CW
and would not draw out the usability problems that should be addressed
for the real target group. This is where the designers should draw
on the experience of outside resources, such as the marketing personnel,
in order to develop an accurate user profile and understand what the users
are really like.
The CW also stems from the same roots as another
type of walkthrough, the programming walkthrough. The objective of
the programming walkthrough is to design a programming language using the
general attributes of the language as a starting point and elaborating
the goals, subgoals, and actions required to accomplish a specific programming
task. Although both the CW and the programming walkthrough focus
on goals, subgoals, and actions as the fundamental units of analysis, their
applications are very different. Nevertheless, each walkthrough stems
from the same basic premise, that is focusing on the tasks to inspect the
target object (interface / programming language). For more information
on programming walkthroughs, refer to Bell et al. (1994).
Return to main page