What Cognitive Walkthroughs Are & When to Use Them

Most usability testing methods treat the interface as something to be evaluated after it’s built. Cognitive walkthroughs flip that assumption entirely. They ask you to simulate the user’s thought process before a single pixel hits the screen, walking through each decision point as if you had never seen the product before. It’s a method that catches a stunning number of problems early — but only if you understand what it’s actually designed to do, and more importantly, what it isn’t.

I’m going to walk you through exactly what cognitive walkthroughs are, when they make sense, how to run one properly, and where they fall short. I’ll also compare them directly to heuristic evaluation, because that confusion trips up a lot of teams.

What is a cognitive walkthrough?

A cognitive walkthrough is a usability inspection method where evaluators walk through a task step-by-step, simulating the cognitive process a user would go through at each decision point. The question at every step is simple: can the user figure out what to do here, or not?

The method originated in the late 1980s from research by Cathleen Wharton, Jane Reid, Jakob Nielsen, and others at Bell Communications Research and the University of Copenhagen. What made it different from heuristic evaluation — which I’ll get to in a moment — was its focus on learning. Cognitive walkthrough was specifically designed to evaluate how well a system supports exploratory learning. Can a new user figure out the interface through trial and error, or will they get stuck?

The core structure involves defining a task, walking through each action required to complete it, and asking three questions at each step:

1. Will the user try to achieve the right action?
2. Will the user notice that the correct action is available?
3. Will the user associate the correct action with the effect they want to achieve?

If you answer “no” to any of these, you’ve identified a potential usability problem. You’re not just judging whether the interface looks good or follows design conventions. You’re asking whether a person who has never used this system before could figure it out through reasoning alone.

When to use cognitive walkthroughs

Cognitive walkthroughs shine in specific situations. They’re not a universal usability tool, and applying them incorrectly wastes everyone’s time.

Use them when designing new features or products. This is the method’s sweet spot. If you’re building something from scratch or adding a significant new capability, walking through the user’s mental model early catches problems that are expensive to fix later. A cognitive walkthrough done during wireframing can identify navigation confusion before developers write a single line of code.

Use them when your users are novices. If your target audience is people who have never used a product like yours before — think consumer finance apps, healthcare portals, or enterprise software being sold to first-time buyers — cognitive walkthroughs are specifically designed for this. The method assumes the user has no prior knowledge and must reason their way through. That’s exactly the scenario you’re in.

Use them when the task involves discovery. Cognitive walkthroughs are less useful for power users who already know the system and need efficiency. They’re powerful when users need to find features they didn’t know existed, navigate unfamiliar processes, or learn new concepts. An e-commerce checkout flow? Perfect candidate. A repeat user’s daily dashboard? Probably not.

Use them to evaluate onboarding flows. This is where I’ve seen cognitive walkthroughs deliver the most value in practice. Walk through what happens when someone lands on your product for the first time: Can they find the sign-up? Can they understand what the product does from the landing page? Can they complete their first meaningful action without abandoning the process? These questions map directly to the cognitive walkthrough framework.

Here’s what most articles won’t tell you: cognitive walkthroughs are poor at evaluating error handling, system performance, or the visual polish that affects perceived credibility. They also don’t account for users who bring domain expertise. A doctor using a medical interface already understands medical concepts — the cognitive walkthrough assumes zero domain knowledge, which may not reflect reality. If your users are experts in their field, supplement this method with something that accounts for their existing mental models.

How to conduct a cognitive walkthrough

Running a cognitive walkthrough isn’t complicated, but it requires discipline. The most common mistake is turning it into a casual hallway review. That’s not a cognitive walkthrough — that’s just looking at a design and sharing opinions. Here’s the actual process.

Step 1: Define the task and user profile. Start by writing down a specific task your user would want to accomplish — something concrete, like “reset your password” or “find a product that matches these criteria.” Then define who this user is. Are they a first-time visitor? Someone with no domain expertise? Be explicit. A cognitive walkthrough where you pretend to be a domain expert defeats the entire purpose.

Step 2: List the steps required. Break the task down into individual actions. “Reset your password” might become: locate the login page, find the password reset link, enter email address, check email, click reset link, enter new password, confirm new password. Each of these is a step you’ll evaluate.

Step 3: Walk through each step with the three questions. For every single step, ask: Will the user know to take this action? Will they see that this option is available? Will they understand that this action leads to their goal? Document every place where the answer is uncertain or “no.”

Step 4: Document and prioritize. Don’t just note that there’s a problem — explain why the user would fail at this step. “The ‘forgot password’ link is buried in a dropdown under the login button, so a user looking for it on their first visit won’t notice it exists.” Prioritize based on how critical the step is to task completion and how likely users are to abandon at this point.

Step 5: Iterate with different evaluators. One person walking through creates one perspective. Get at least three or four people to do it independently, then compare notes. You’ll find that different evaluators catch different problems — especially if they’re genuinely pretending to be unfamiliar users.

Nielsen Norman Group recommends keeping sessions to about 60-90 minutes for a single task. Going longer than that leads to fatigue and diminishing returns. If you have multiple tasks, break them into separate sessions.

Cognitive walkthrough vs. heuristic evaluation

This is where I see the most confusion, even among experienced UX professionals. Both are inspection methods. Both involve evaluating an interface without testing real users. But they’re fundamentally different.

Heuristic evaluation asks: does this interface follow established usability principles? The evaluator examines the interface against a set of heuristics — Jakob Nielsen’s famous “10 usability heuristics” are the most common reference, but you can use any framework. The question is: does this login form have good error prevention? Is there consistency between this section and the rest of the app? Does the user have control over the interface?

Cognitive walkthrough asks: can a user who has never seen this before figure out what to do? It’s focused on learning and discovery, not on whether the design follows best practices. A system could follow every heuristic perfectly and still fail a cognitive walkthrough because it assumes knowledge the user doesn’t have.

Think of it this way: heuristic evaluation is like having a design critic review your work against established standards. Cognitive walkthrough is like watching someone use your product for the first time and seeing every place they get confused.

Here’s a practical comparison:

Aspect	Cognitive Walkthrough	Heuristic Evaluation
Focus	Learning, exploratory use	General usability principles
User assumption	Novice, no prior knowledge	Varies — can assume any level
Evaluator	Simulates user thinking	Acts as expert reviewer
Best for	New products, onboarding, discovery flows	Any interface, design refinement
Weakness	Ignores expert users, misses visual/performance issues	Doesn’t simulate actual user behavior

Use both. They’re complementary, not interchangeable. Run a cognitive walkthrough early when you’re building something new or targeting novice users. Run heuristic evaluation throughout the design process to catch violations of usability principles.

Best practices and common pitfalls

A few things will make or break your cognitive walkthrough sessions.

Stay in character. This sounds obvious, but it’s the hardest part. Evaluators naturally want to show they understand the interface. They skip steps they find confusing because they “just know” what to do. Fight this. Force yourself to pretend you have never seen this system before. Ask: “If I were someone who had no idea what this button did, would I click it?”

Use realistic scenarios. Don’t walk through a happy path that only exists in your head. Use actual user research to inform your task definitions. If your support tickets show that users constantly struggle to find the cancellation flow, that’s your task to walk through — not the “easy path” you designed for.

Don’t combine with other methods in the same session. I’ve seen teams try to run cognitive walkthroughs alongside heuristic evaluations or think-aloud protocols. The methodologies have different focuses, and mixing them dilutes both. Keep them separate.

Document the reasoning, not just the problem. “The button is too small” isn’t useful. “A user who has never seen this interface would not know this text input is clickable because it lacks visual affordance and the surrounding area provides no context that suggests interaction” — that’s useful. You’re building a case for change that others can evaluate.

Involve people outside the design team. Engineers, product managers, and especially stakeholders who aren’t embedded in the day-to-day product work often catch problems that designers miss. Designers develop blind spots to their own assumptions. External evaluators don’t have them.

Now, here’s an honest admission: cognitive walkthroughs are time-consuming relative to the number of problems they find. If you’re working on an established product with strong user research data, heuristic evaluation or usability testing will often give you more actionable insights per hour. Cognitive walkthroughs shine when you have a genuinely new problem space and no existing data to draw from. They’re an investment in understanding what novices will face — not a daily usability tool for every design decision.

Real-world example

To make this concrete, let’s walk through a simplified example. Imagine you’re evaluating a meditation app’s first-time experience.

Task: “Complete your first guided meditation session.”

You walk through: Opening the app → seeing the home screen → finding a meditation to try → selecting one → starting the session → using playback controls.

At “selecting one,” you encounter a grid of session cards with titles like “Morning Clarity,” “Stress Reset,” and “Deep Rest.” You ask the three questions: Will the user know to tap a card? Yes, cards are a recognized UI pattern. Will they notice this is available? Yes, the grid is prominent. But will they understand which meditation is right for them, given their stated goal of “figuring out how to use this app”? Probably not — the titles assume users already know what they want to achieve. A first-time user sees “I just downloaded this app, which one should I pick?” with no guidance.

That’s a cognitive walkthrough finding. It’s not a design flaw in the traditional sense. The interface follows all the heuristics. But it fails at helping a novice user reason their way through a decision. You’d fix it by adding a “Start here” beginner recommendation, or contextual help that guides first-time users.

Now imagine the same app evaluated via heuristic evaluation. The evaluator would note that the cards have good visual hierarchy, consistent styling, appropriate touch targets — all good. They might not catch the novice confusion because they’re evaluating against principles, not simulating a learning experience.

Both findings are valuable. They come from different methods.

Conclusion

Cognitive walkthroughs aren’t the flashiest usability method. They don’t involve real users, they can’t capture the nuance of actual behavior, and they require you to pretend you don’t know things you actually know — which is genuinely hard. But when you’re building something new, targeting people who’ve never used your category of product, or trying to understand the learning curve your design creates, there’s no substitute.

The method forces you to answer a question that’s uncomfortable for anyone who knows the product intimately: if someone saw this for the first time, could they figure it out? That’s not a question heuristic evaluation can answer. It’s not a question usability testing catches until you’ve already built something.

My recommendation: run a cognitive walkthrough early in your design process for any flow where learning matters. Keep it focused. Document the reasoning. Then run heuristic evaluation and usability testing to round out your findings. Each method catches what the others miss. Combined, they give you confidence that your design works — for real users, at every level of experience.