Cognitive Walkthrough: A Complete First-Use Example and Recording Template

Define what the first-time user already knows

An experienced team can navigate a confusing interface because it already knows the answer. A cognitive walkthrough makes that hidden knowledge visible. Instead of demonstrating the intended route and calling it obvious, ask what would lead a new user to each action. A label, an instruction, a familiar convention, or prior domain knowledge can support the reasoning. “They will work it out” cannot.

The example in this guide is an invented public-library website. A member has already signed in and wants more time to finish one borrowed book, River Atlas. They know which book they borrowed and understand the ordinary idea of renewing a loan. They have not used this website before and do not know its internal label “Circulation.” The exercise begins on the signed-in account overview; sign-in and password recovery are outside its scope.

In a real project, replace these assumptions with what research or service knowledge establishes about your audience. A new employee, an occasional customer, and a trained administrator may approach the same screen differently. Run separate analyses when their prior knowledge materially changes the route.

Write down the correct route before evaluating it

The team first confirms how the task works in the current design. In prototype C, the account overview contains links labeled Profile, Circulation, and Messages. Circulation opens a list of borrowed books. Each row contains a title, due date, and circular-arrow icon. Activating the icon opens a renewal dialog, and confirming the dialog returns the member to the loan list.

For River Atlas, the simulated service permits renewal. A second book, City Gardens, has a hold and cannot be renewed. That exception matters because “find the renewal control” and “understand why renewal is unavailable” are different questions. The main walkthrough follows the eligible book; a separate branch examines the held book after the main path is understood.

Lewis and Rieman distinguish knowing the action sequence from judging whether a user could discover it. Reviewers who are themselves lost in an undocumented prototype should first resolve the intended behavior. Otherwise, they risk evaluating accidental implementation gaps while claiming to have inspected the proposed design. If a necessary response has not been designed, record that missing state explicitly.

• Lewis and Rieman: Task-Centered User Interface Design, chapter 4

Use four checks to explain each judgment

NN/g’s workshop guidance organizes the analysis around four questions at every step: whether the user would pursue the needed immediate goal, notice the available action, connect that action with the goal, and recognize progress afterward. The distinction between noticing and understanding is particularly useful. A prominent icon can be easy to see while giving no reliable clue about what it does.

For this article, the worksheet uses “supported,” “concern,” and “unresolved” as note-taking labels. They are an editorial convenience, not a standardized score. A supported judgment still needs a reason. An unresolved judgment should name the missing design detail or user knowledge. Do not turn a table of favorable predictions into a percentage of people expected to succeed.

During the walkthrough, keep the current interface separate from proposed repairs. If a reviewer says “We could add a tooltip,” capture that idea for later, then return to what is visible now. A designer’s explanation of why Circulation is technically accurate does not establish that a first-time member will interpret the term correctly.

• NN/g: Running a cognitive walkthrough workshop

Walk through the account overview and the loan list

At step 1, the member has a plausible immediate goal: locate the book they have borrowed. The account overview offers three visible links. The potential failure is not an invisible control; it is the connection between “Circulation” and “My borrowed books.” Our stated member knows what renewing a book means, but we have no basis for assuming they know the library’s administrative vocabulary.

The record should therefore identify a meaning concern rather than claim that every member will fail. Some people may infer the term correctly, and others may explore the links. The walkthrough has found an assumption that deserves a clearer label or user evidence. It has not measured confusion, extra time, or abandonment.

Continue the inspection from the loan list as if the first step had succeeded. Record that assumption so later judgments are not mistaken for evidence that the entire path is discoverable. River Atlas appears by title with its due date. This supports finding the intended item. The circular-arrow icon is visible, but it could plausibly mean refresh, repeat, or renew. Position beside a loan helps establish context; it does not by itself settle the ambiguity.

If the icon has an accessible name, that is relevant to people using an assistive technology that exposes it. It does not automatically supply a visible label to a sighted newcomer. Inspect the actual interaction modes in scope. A desktop hover tooltip is also insufficient evidence for a touch user unless an equivalent explanation is available there.

Inspect the confirmation and the result separately

At step 3, the old dialog says “Continue?” with “Cancel” and “OK.” The member can see two actions, but the dialog does not name the book, describe the consequence, or show the proposed due date. Even if they correctly inferred the previous icon, they now have to assume that OK means “renew River Atlas.” A confirmation step is useful only when it communicates what is being confirmed.

For the proposed design, stipulate that the service supplies a renewal offer before confirmation. The dialog can then say “Renew River Atlas?” and “New due date: 2 November,” with buttons labeled “Keep current due date” and “Renew loan.” Show a proposed date only when the service can supply it. If the date is determined only after submission, the dialog must describe that uncertainty instead.

At step 4, prototype C returns to the list and changes a date. A careful member who remembers the previous date might infer success; another might not notice the change or know whether it was saved. The concern is feedback, distinct from the ambiguous control at step 2. A clear result could name the book and new due date, while preserving the updated date in the row for later reference.

An interrupted request creates a different state. “Renewed” is appropriate only after confirmation from the service. If the result is unknown, the interface should help the member check the current loan status without pretending that the renewal succeeded or failed. The walkthrough should include the status information actually available, not a reassuring sentence invented to make the journey appear smooth.

Take the exception branch without changing the user’s goal

Now return to the loan list and choose City Gardens, the fictional book with a hold. The member still wants more time, but renewal is unavailable in this scenario. A disabled circular arrow gives them little basis for deciding what happened: is the feature loading, is the account restricted, or is the book ineligible? A state that prevents an action still needs an explanation relevant to the user’s goal.

A proposed row could say “Renewal unavailable: another member is waiting for this book. Current due date: 20 October.” Include a support route only when it is genuinely useful, and do not imply that contacting support guarantees an override. If local policy offers a different legitimate next step, describe that policy accurately. The interface should not fabricate an alternative merely to end the walkthrough on a successful-looking screen.

This branch also tests whether the main-path repair overpromises. A permanent “Renew loan” button on every row may be easier to understand than an icon, but it must still reflect eligibility and explain unavailable states. The design objective is a comprehensible outcome for the actual conditions, not an identical button treatment in every state.

Keep the evidence, assumption, and next action in one record

The template below keeps a finding useful after the workshop. A short “fail” label loses the reason for the judgment. A long discussion transcript is difficult to act on. Capture the exact action, relevant interface cue, audience assumption, reasoning, and next check. This lets a designer propose a remedy and lets a researcher see which expectation still needs observation.

If reviewers disagree, preserve the substance of the disagreement. One may believe all members know Circulation because staff use it daily; another may have heard members say “my books.” Those are different kinds of evidence. Resolve the vocabulary question with relevant member research rather than averaging the two opinions into a confidence score.

Assign findings by their underlying cause. The icon ambiguity and vague dialog are related, but a single label change does not necessarily repair both. Conversely, the same navigation term might affect several tasks; link those records to one language decision while retaining the consequences for each journey.

Check the repair without coaching the next user

Inspect the revised journey again using the same starting knowledge and task. Confirm that labels identify the correct item, that the confirmation describes the real operation, and that success, ineligibility, and unknown status remain distinct. A repair may remove one assumption while introducing another, such as a date that looks guaranteed before the service can confirm it.

For a subsequent usability session, describe the member’s situation: “You need more time to finish River Atlas before returning it.” Do not instruct the participant to open Borrowed books and click Renew loan; those words reveal the path you need to observe. Let the participant act, then investigate what they understood from the result. Record actual observations separately from the earlier inspection predictions.

Close the walkthrough with a specific output: the inspected version and conditions, action records, proposed repairs, and unresolved questions. For this example, the central findings concern a specialist navigation term, an ambiguous icon, a vague confirmation, and weak result feedback. None requires claiming a measured completion rate. The useful outcome is a clearer explanation of where first-use learning may break and how to check the next design.

References

• NN/g: Running a cognitive walkthrough workshop
• Lewis and Rieman: Task-Centered User Interface Design, chapter 4