Preparing for a Cognitive Walkthrough

A cognitive walkthrough is a structured usability inspection method in which evaluators simulate the step-by-step experience of a user attempting to complete a task through an interface. Unlike heuristic evaluation, which surveys an interface broadly against a checklist of design principles, the cognitive walkthrough focuses tightly on the moment-to-moment cognitive experience: what does the user notice, what do they understand, what action do they choose, and does the interface confirm that their action was correct? Because the entire validity of this method rests on accurately representing a real user's perspective, the preparation phase is not a formality — it is the foundation on which every subsequent judgment is built. Poorly prepared walkthroughs produce findings that reflect the evaluators' own expertise rather than the target users' experience, which can be just as misleading as having no evaluation at all. The preparation phase consists of four interconnected activities: defining the user profile, identifying the task sequences to be evaluated, gathering all required materials, and assembling the evaluation team.

The user profile is a precise, written description of the person whose experience the evaluators will simulate during the walkthrough. It is not a vague audience label such as "general users" or "beginners." A useful user profile specifies at least three dimensions of the target user's background:

• Domain knowledge — What does the user know about the subject matter the interface addresses? A patient using a hospital appointment-booking system may have no clinical vocabulary. A nurse using the same system would have deep domain knowledge but might still be a novice with the specific software. Domain knowledge determines whether labels, terminology, and instructions will be meaningful or opaque to the user.
• Technical familiarity — What is the user's experience with technology in general and with this type of interface specifically? A user who has never used a mobile banking app will not automatically know that swiping left reveals hidden actions, even if that pattern is common to experienced smartphone users. Technical familiarity governs which interface conventions can be assumed and which must be made explicit.
• Motivation and context of use — Why is the user performing this task, and under what circumstances? A user who is anxious, rushed, or completing a task infrequently will approach the interface differently from a calm, experienced, daily user. Motivation affects risk tolerance, willingness to explore, and response to errors.

The profile should be written down in a single, concrete document before the walkthrough begins. This matters because evaluators are almost always more expert than the users they are simulating. Without a written anchor, there is a well-documented tendency for evaluators to unconsciously drift back toward their own knowledge as they work through steps — a phenomenon sometimes called expert creep. For example, an evaluator who knows that the "hamburger" icon opens a navigation menu may automatically recognize it during the walkthrough without pausing to ask whether the simulated user would know that. A written profile that states "user has limited smartphone experience and has not encountered icon-only navigation menus" provides an explicit prompt to flag that step as a potential failure point.

User profiles do not need to be invented from scratch. They can and should be drawn from existing design artifacts such as personas developed earlier in the design process, findings from contextual inquiry or interviews, usage analytics that characterize the primary user segment, or usability test recruitment screeners. When profiles are grounded in real user research, the walkthrough findings have greater ecological validity — they are more likely to predict actual difficulties real users will encounter.

Once the user profile is established, the next preparation task is identifying the task sequences to be evaluated. A task sequence is a description of a goal the user wants to accomplish and the series of individual steps the evaluator will walk through to achieve it. Several principles govern the selection and formulation of good task sequences.

• Tasks must be written from the user's perspective, not in terms of interface controls. A task written as "click the Account Settings button, then select Notifications" is already prescribing the interface path and bypasses the central cognitive walkthrough question: would the user know to do that? The correct formulation is goal-oriented: "Turn off email notifications from the service." This framing forces evaluators to ask at each step whether the user would understand what to do next without being told.
• Each task must have a clearly defined starting point. Before the first step can be evaluated, the evaluator must know where the user begins — the home screen, a specific landing page, a point mid-workflow. Ambiguity about the starting point leads to inconsistent evaluations, particularly in team settings where different evaluators may begin from different states of the interface.
• Tasks should represent high-priority or high-frequency user goals. Because a cognitive walkthrough is time-intensive when done thoroughly, not every possible task can be evaluated. Priority should go to tasks that most users will attempt most often, tasks that involve the highest stakes if completed incorrectly (such as making a payment or deleting an account), and tasks that are new or redesigned and therefore most likely to contain unanticipated usability problems.
• Complex tasks must be decomposed into numbered sub-steps. For example, the goal "submit a support request" might decompose into: (1) locate the Help or Support section, (2) select the appropriate request category, (3) complete the required fields in the form, (4) attach any relevant files, (5) submit the form, (6) verify that a confirmation is received. Each numbered sub-step becomes a discrete unit of evaluation. This granularity is essential because a failure at step 2 may be entirely unrelated to and obscure a separate, independent failure at step 5.

Gathering required materials is the third preparation activity. It sounds procedural, but inadequate materials preparation is one of the most common reasons walkthroughs are conducted inconsistently or produce unreliable findings. The materials that must be assembled before the walkthrough begins include:

• A documentation template — This is a structured form or spreadsheet that evaluators complete for each sub-step of each task. At minimum, the template should capture the step being evaluated, the four standard cognitive walkthrough questions (discussed in later modules), the evaluator's judgment of success or failure at each question, and a written note explaining the reasoning. A standardized template ensures that findings from different tasks or different evaluators are recorded in comparable form and can be aggregated meaningfully afterward.
• All relevant interface screens or prototype states — The evaluator must be able to see or interact with every screen, modal, page, or state that the user would encounter during each task. If the prototype is incomplete and certain screens are missing, those steps cannot be evaluated. Attempting to evaluate from memory or imagination introduces exactly the kind of expert assumption the method is designed to eliminate.
• A firm rule against modifying the prototype during the walkthrough — When evaluators discover a problem during a walkthrough, there is sometimes an impulse to fix it immediately, especially if the design team is present. This must be resisted. Modifying the interface mid-evaluation changes the artifact being evaluated, which invalidates findings from subsequent steps and makes it impossible to reproduce the evaluation. Problems should be recorded and addressed after the walkthrough is complete.
• The written user profile, physically present — The user profile must be available as a reference document throughout the session, not merely reviewed once at the start. Evaluators should consult it at each step where there is any ambiguity about what the simulated user would or would not know.

The fourth preparation activity is assembling the evaluation team. The cognitive walkthrough can be conducted by a single evaluator or by a team, and each approach has distinct characteristics.

• Solo evaluation is practical, efficient, and widely used in both academic and professional settings. A single evaluator can complete a walkthrough without the scheduling and coordination overhead of team assembly. Solo walkthroughs are particularly appropriate when time or resources are constrained, when the interface is relatively simple, or when the goal is a rapid preliminary check before more extensive evaluation. The limitation is that one person's interpretation of the user profile and the interface may miss issues that would surface in discussion with others.
• Team evaluation introduces deliberation at each step. When two or three evaluators work through a step together, disagreements about whether the simulated user would succeed are themselves informative — they reveal ambiguity in the interface that a single evaluator might resolve confidently (and incorrectly) in either direction. Discussion also tends to surface a wider range of potential user interpretations than any single evaluator would generate alone. The trade-off is time: team walkthroughs take significantly longer per step.
• Consistency of persona and task definition across evaluators is non-negotiable in team settings. If one evaluator interprets the user profile as a complete novice and another treats the user as moderately experienced, their findings will not be comparable. Before beginning, all team members should discuss and agree on the user profile's specific implications — for instance, explicitly agreeing on what conventions the simulated user would and would not recognize.
• Evaluator selection matters. Evaluators should have sufficient familiarity with usability principles to recognize and articulate failures, but they should not be the designers who built the interface being evaluated. Designers have intimate knowledge of the intended interaction model, which makes it extremely difficult for them to genuinely simulate a naive user's perspective. When a designer conducts a walkthrough of their own design, they tend to interpret ambiguous elements charitably based on their design intent rather than on what the interface actually communicates to an uninformed user.

To make the relationships and decisions in the preparation phase concrete, the following table summarizes the key preparation components, the decisions required within each, and the consequences of inadequate preparation in that area:

Taken together, these four preparation activities establish the controlled conditions under which a cognitive walkthrough can produce reliable, actionable findings. Each activity reinforces the others: a precise user profile makes task formulation more grounded, well-decomposed tasks make the documentation template more usable, available materials make consistent evaluation possible, and a properly assembled team ensures the user profile is applied with discipline throughout. Skipping or abbreviating any one of these activities does not merely reduce the quality of the findings in that area — it undermines the validity of the entire walkthrough, because the method's power depends on every evaluator, at every step, genuinely simulating the same, accurately characterized user.