A cognitive walkthrough is a usability inspection method in which evaluators — not real users — step through a task in an interface and ask a fixed set of questions at every action a first-time user would have to take. Instead of asking "is this interface pretty?" or "is this expert-efficient?", the method asks a narrower question: could someone who has never seen this screen before figure out what to do next, and would they know their attempt worked? That focus makes it a learnability test you can run on a paper sketch, a wireframe, or a half-built prototype.
The method rests on a theory of exploratory learning: people often skip manuals and tutorials and instead learn a system by looking at the screen, forming a goal, scanning for something that looks like it matches that goal, acting, and then interpreting the feedback. The walkthrough questions mirror that loop. Understanding this theoretical basis matters in this course because it tells you why the questions are worded the way they are, and it keeps you from drifting into generic opinion-giving when you evaluate a classmate's prototype.
It also helps to see where cognitive walkthrough sits among other inspection methods. Heuristic evaluation, for example, is also expert-driven and cheap, but it sweeps broadly across an interface against a list of principles, while a walkthrough drills narrowly into one task sequence from a novice's point of view. As you watch, note three things: the specific questions asked at each step, the assumption that the user is new to the system, and how the output differs from what a heuristic review produces.
A short overview from Nielsen Norman Group defining the cognitive walkthrough as a task-based usability inspection technique aimed at evaluating learnability. Based on its title and description, it should explain what the method is for, how evaluators walk through a task step by step on behalf of a first-time user, and the kinds of questions asked along the way. Expect a compact, example-driven treatment rather than a deep theoretical lecture.
This is the most directly on-topic video for the subtopics "What Is a Cognitive Walkthrough?" and "Learnability as the Primary Focus," and NN/g is a long-standing authority in applied usability practice.
This video walks through how to run a heuristic evaluation: systematically reviewing a product against established usability principles to surface potential usability and experience problems. It covers the practical process an evaluator follows and the kind of issue list the method produces.
It gives you the comparison case for the subtopic "Cognitive Walkthrough vs. Other Inspection Methods" — same family of expert inspection, but broad principle-checking rather than a narrow novice-task simulation.
A chapter-style lecture on cognitive aspects of human-computer interaction, including the distinction between experiential cognition (actions needing little mental effort) and reflective cognition (actions requiring deliberate thought, comparison, and decision-making). It situates attention, perception, and thinking within interface design.
It supplies the underlying cognitive-psychology vocabulary behind the "Core Theoretical Basis: Exploratory Learning" subtopic, helping you reason about what a first-time user is actually doing mentally at each walkthrough step.
Together these videos build the conceptual base the module's outcomes depend on. The NN/g walkthrough video introduces the method's purpose and step-by-step questioning structure, supporting MO1 and preparing you to actually run a walkthrough on a prototype for MO2. The cognitive aspects lecture explains the mental processes a novice user goes through, which is what lets you judge whether a step is genuinely hard rather than merely unfamiliar — directly useful when you assess severity and user impact for MO3. The heuristic evaluation video clarifies by contrast what a cognitive walkthrough is and is not, so that the issues you document in MO2 stay task- and learnability-focused instead of becoming a general critique list.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
A cognitive walkthrough is only as good as the preparation behind it. Before you step through an interface asking the four guiding questions, you need four things in place: a clear picture of who the user is, a concrete set of tasks that user would realistically attempt, the materials that let you simulate each step (prototypes, screens, wireframes, or a working build with a defined action sequence), and a small evaluation team with assigned roles such as facilitator, scribe, and evaluators.
These preparation steps matter because the walkthrough simulates a specific person's thinking at each action. If the user profile is vague, you cannot judge whether a label would make sense to them or whether they already have the background knowledge the interface assumes. If the task sequence is not written out as a correct series of actions in advance, the evaluation drifts into general opinion rather than a structured, repeatable analysis you can document and defend.
The videos below come from Nielsen Norman Group, a long-established usability consultancy. None of them is a cognitive walkthrough tutorial, so treat them as supporting background. While watching, map what you see onto the preparation steps: how a persona sharpens your user definition, how an expert inspection method is set up and staffed, and what usability qualities you will ultimately be looking for when you judge whether a step succeeds or fails.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
A cognitive walkthrough is a structured usability inspection method in which an evaluator steps through a task the way a first-time user would, one action at a time, and asks a small set of questions at each step. The method focuses on learnability: whether someone who has never used the interface before can figure out what to do next without training or documentation. Because you simulate the user's reasoning rather than recruit participants, a walkthrough can be run early, cheaply, and repeatedly on sketches, wireframes, or working prototypes.
The operational heart of the method is the four-question framework applied at every action in the task sequence. Question 1 asks whether the user will try to achieve the right goal at this point. Question 2 asks whether the user will notice that the correct action is actually available on screen. Question 3 asks whether the user will recognize that this visible control is the one that advances their goal, which is often a labeling and wording problem. Question 4 asks whether, after acting, the user will understand the feedback well enough to know they made progress. A "no" at any question is a documented usability failure, and the question that failed tells you what kind of fix is needed.
As you watch the videos below, pay attention to how the evaluator defines the task and the correct action sequence before asking any questions, how a user persona or assumption set shapes the answers, and how failure stories are written down so they can later be rated for severity. Notice also how the same questioning logic shows up outside interface design, which is a good sign that you have understood the underlying idea rather than memorized four sentences.
This is the core overview video for the method: a short explanation from Nielsen Norman Group of what a cognitive walkthrough is, that it is a task-based usability inspection technique, and that its specific purpose is evaluating learnability for first-time users. Expect it to cover how you define tasks and the correct action sequence in advance, and how an evaluator walks each step asking the guiding questions about goals, visible actions, recognizing the right control, and interpreting feedback. It should also indicate when in a design process this method is worth using.
It is the most direct match to this topic, coming from the usability consultancy most associated with inspection methods, and it frames all four evaluative questions in the context of a single step-by-step procedure.
This video presents three ways to pretest a survey, one of which is a cognitive walkthrough used with target users to check whether questions are understood as intended. It contrasts that with mechanical testing and other checks, showing where each approach catches different kinds of problems. The walkthrough portion illustrates the method applied to wording and comprehension rather than to screens and buttons.
It reinforces Question 3 in particular, since recognizing an action as correct is largely a matter of whether labels and wording match the user's mental vocabulary, and it shows the questioning technique transferring to a different artifact.
This short video distinguishes research goals, research questions, and hypotheses and explains how each one focuses a user research study. It covers why a clearly stated goal comes before the questions you ask, and how vague goals lead to unfocused findings. The framing is general to user research rather than specific to inspection methods.
It supports Question 1 by sharpening what a "goal" actually is, which is exactly the distinction you need when deciding whether a simulated user would form the right goal at a given step, and it helps you set up a defensible task scenario before you begin walking through it.
Together these videos build the recall needed for MO1 by naming the method, its task-based setup, and the guiding questions asked at each action step. The main NNgroup walkthrough video gives you the procedure you will actually execute on a peer or self-developed prototype for MO2, while the research goals video helps you define the task and user assumptions precisely enough that your documented failures are credible. The survey testing video extends the same questioning logic to wording and comprehension, which feeds MO3 by helping you judge whether a given failure is a cosmetic labeling issue or a blocker that prevents task completion, and therefore how to prioritize revisions.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
A cognitive walkthrough is only as useful as the record it leaves behind. As you step through each action in a task and ask the guiding questions — will the user know what to do, will they notice the control, will they understand the feedback — the moments where the answer is "no" or "probably not" are your failure points. This topic is about recognizing those moments, naming them precisely, and writing them down in a form that another designer can act on.
A failure point is more than "this screen is confusing." It is a specific breakdown at a specific step, tied to a cause: the user cannot form the right goal, cannot find the control, cannot connect the control to their intention, or cannot tell from the feedback that they made progress. Categorizing failures by type keeps your findings diagnostic rather than vague, and a consistent documentation template (step number, expected action, what fails, why, evidence, proposed fix) makes your results comparable across evaluators and reusable later in the design cycle.
The last piece is severity. Not every failure deserves the same attention, and a list of twenty undifferentiated problems gives a development team no guidance. As you watch the videos below, pay attention to the criteria used to rate severity, the language used to describe a problem without blaming the user, and the distinction between findings produced by inspection methods like the walkthrough and findings produced by testing with real users.
A short Nielsen Norman Group video on assigning severity ratings to design issues found in usability studies or heuristic evaluations. It explains the small set of criteria evaluators typically weigh — such as how many users are affected, how much the issue impedes task completion, and whether it is a one-time or persistent obstacle — and how those criteria combine into a priority ranking. The focus is on reporting findings so that teams know what to fix first.
This is the most direct match for the "Distinguishing Severity Levels" subtopic and for turning a raw list of failure points into a prioritized set of recommendations; NN/g is the standard reference source for usability evaluation practice.
A five-minute NN/g video covering common mistakes made when talking to users, including leading rather than probing, over-explaining, and filling silence in ways that distort what the participant tells you. It contrasts neutral probing questions with questions that plant an answer. The emphasis is on gathering evidence that reflects the user's actual experience rather than the researcher's assumptions.
The same discipline of neutral, non-leading language applies when you write failure descriptions — describing the observable breakdown instead of asserting your preferred explanation keeps your documentation credible and useful.
This video distinguishes user testing from usability testing, two terms that are frequently confused, and explains what question each method is designed to answer. It situates both within the broader UX research process and discusses when a team would choose one over the other.
Knowing what usability testing does and does not tell you clarifies the place of an inspection method like the cognitive walkthrough, and helps you label your findings honestly as predicted failure points rather than observed user behavior.
Together these videos reinforce the documentation and prioritization half of the module. The severity-rating video supports MO3 directly by giving you explicit criteria for ranking findings by user impact, and it supports MO2 by showing what a finished, reportable issue entry should contain. The interviewing video models the precise, non-leading language that makes failure descriptions written during a walkthrough defensible, again serving MO2. The user-testing-versus-usability-testing video frames where inspection methods such as the cognitive walkthrough sit among evaluation approaches, which supports MO1 by helping you recall why the method's guiding questions are structured as predictions about user reasoning rather than observations of users.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
In this topic you move from learning the cognitive walkthrough to actually running one. You will take three prototypes created by your peers, choose representative tasks for each, step through those tasks as an evaluator, and record where a first-time user would likely hesitate, choose the wrong control, or fail to recognize that progress was made. The walkthrough is done from the user's perspective, not the designer's, so a large part of the work is setting aside what you already know about how the interface is "supposed" to work.
Evaluating peer work also brings practical and ethical considerations. You are commenting on an interface, not on a classmate, so findings should be specific, evidence-based, and tied to the walkthrough's guiding questions rather than to personal taste. Comparing results across three prototypes helps you see patterns: issues that appear everywhere often point to a hard interaction problem, while issues unique to one prototype usually point to a design decision that can be revised.
The videos below come from Nielsen Norman Group, a long-standing usability research and consulting firm. None of them is specifically about cognitive walkthrough, so treat them as transferable craft: how expert inspection methods are organized and consolidated, how to surface a user's reasoning out loud, and when verbalization methods break down. While watching, look for the parts you can carry directly into your own evaluation — independent evaluation before discussion, merging duplicate findings, phrasing issues clearly, and knowing the limits of each technique.
This short video walks through the procedure for running a heuristic evaluation, an expert inspection method closely related to the cognitive walkthrough. Based on its chapter markers, it covers evaluating independently, works through an example, and then explains how to consolidate the issues multiple evaluators find into a single list before summarizing the process.
It models the overall workflow of an inspection-based evaluation — inspect, record, consolidate, report — which maps directly onto conducting walkthroughs on three prototypes and then comparing and reporting findings. NN/g is an authoritative source for usability inspection methods, so the guidance is reliable.
This video explains the think-aloud technique: what it is, why asking people to verbalize their thoughts is useful, and how a facilitator explains it, reinforces the behavior, and prompts without leading. It focuses on practical facilitation moves for keeping a participant talking about what they expect and notice.
A cognitive walkthrough asks you to reason aloud about what a user would be thinking at each step, so the prompting and verbalization habits shown here sharpen how you articulate and document per-step reasoning on each peer prototype.
This video addresses situations where thinking aloud does not work well, particularly with work-domain experts whose knowledge is automatic and hard to verbalize. It points to alternatives such as retrospective testing, expert walkthroughs, and interviews as ways to recover the reasoning behind user actions.
It names expert walkthroughs as a legitimate alternative method and clarifies when evaluator-driven inspection is appropriate, which helps you justify using a cognitive walkthrough on peer prototypes and understand its boundaries.
Together these videos reinforce the module outcomes from complementary angles. The heuristic evaluation video supports MO1 and MO2 by showing the disciplined sequence of an inspection method — evaluating independently, documenting issues, then consolidating them — which is the same rhythm you will follow when running walkthroughs on three peer prototypes and writing the report. The think-aloud video strengthens MO2 by improving how you surface and record step-by-step user reasoning rather than vague impressions. The final video supports MO3 by clarifying when verbalization-based data is unreliable and expert inspection is the better choice, helping you weigh the credibility and impact of findings when prioritizing which design revisions matter most.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
A cognitive walkthrough produces a pile of raw observations: at step 4 the user would not know the "Submit" control exists, at step 7 the feedback message does not confirm success, and so on. On its own, that list is not very useful to a design team. The real work of this topic is turning those individual breakdowns into something a designer can act on — grouping related failures into patterns, judging which ones matter most, writing recommendations that are specific enough to implement, and presenting them in a way that invites collaboration rather than defensiveness.
This topic also asks you to be honest about what the method can and cannot tell you. A cognitive walkthrough is an analytic, expert-driven inspection built around a specific task and an assumed user. It does not measure how long real people take, how they feel, or what they do when they wander off the happy path. Knowing those limits keeps your report credible and helps you say clearly which claims are evidence-based predictions and which would need user testing to confirm.
As you watch the videos below, pay attention to three things: how severity is decided (and on what criteria), how problems can be classified at different levels of scale, and how the social side of delivering findings — framing, context, and the kind of feedback you ask for — changes whether your recommendations actually get used. Note that these videos are drawn from usability testing and heuristic evaluation contexts; the reporting and prioritization practices transfer directly to cognitive walkthrough results.
A short Nielsen Norman Group explainer on assigning severity ratings to design issues found in usability studies or heuristic evaluations. It walks through the small set of criteria evaluators typically use to rate a problem's seriousness, so that a long list of findings can be ordered by importance rather than by the order they were discovered.
Severity rating is the mechanism that turns a flat list of walkthrough failures into a prioritized set of revisions, and NN/g is the standard professional source for how those ratings are defined and applied.
This video focuses on the communication side of UX work: how to set the stage with stakeholders before you present, what context to provide, and how to ask for the kind of feedback you actually need. It treats a presentation as a structured conversation rather than a one-way report.
It speaks directly to the "Presenting Findings to Designers" subtopic, giving concrete framing tactics for sharing walkthrough results so that designers engage with the problems instead of defending the design.
An overview of user pain points organized into three categories — interaction level, journey level, and relationship or organizational level — with examples of how problems range from small friction to large systemic issues. It gives a vocabulary for describing the scale and scope of a usability problem.
The three-level framing is a practical tool for synthesizing scattered walkthrough findings into patterns and for explaining to stakeholders why some issues are isolated fixes while others point to a deeper design problem.
Together these videos carry the module from documentation to decision-making. The severity-rating video supports MO3 most directly, giving you explicit criteria for ranking the issues you identified during your walkthrough so revisions can be sequenced by impact rather than convenience. The pain-points video supplies a classification scheme for grouping the issues you documented under MO2 into patterns at the interaction and journey levels, which is the first step toward meaningful prioritization. The feedback video addresses the final link in the chain: once you have recalled the method's guiding questions (MO1) and applied them to a peer or self-developed prototype, your findings only create value if designers and stakeholders can receive them productively.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.