Cognitive Walkthrough

Meetings held over a design draft mostly ended in traded impressions. One person says the button doesn't stand out, another says there's too much text. Five people produce five reactions, and none of them tells you what to fix first.

The larger problem is that the person who built the screen never gets stuck in it. They already know what each button does, so no amount of clicking through their own work surfaces what a newcomer would run into.

A usability test answers the question, but it requires recruiting people. Finding five participants who match the criteria routinely takes two weeks, and the design has to be settled this week. That's where Pagedeck was when Noa redrew the invite screen: development was scheduled to start the following Monday.

A cognitive walkthrough was built to fill that gap. Instead of bringing in users, it simulates the way a user thinks. You move through the screens one step at a time, ask the same questions at every step, and record every place where the answer breaks down.

Start by writing the task as a single sentence. "Evaluate the invite screen" is not a task. "Invite a colleague to a document without knowing their email address" is. Unless the destination is specific, there's no way to tell when someone has wandered off the path.

1. Fix the task, and write down who is performing it. The answers for the same screen differ depending on whether this is someone who signed up today or someone six months in. Reviews usually assume the person who knows nothing.
2. Write out the correct path as discrete steps. Following the clicks in order usually produces six to ten of them. If a user flow already exists, take the route straight from it.
3. Answer four questions at each step. Does the user know what they are trying to do right now? Is the means of doing it visible on screen? Can they recognize that this control connects to what they want? After they act, can they tell whether it worked?
4. Record each answer as yes or no, and add one line of reasoning to every no. Something like: "Step 3, question three, no — the button says Share while the user is looking for a person to invite, so they don't connect the two."
5. When the pass is done, start with the steps where the no answers cluster. If three reviewers wrote no to the same question at the same step, that is the first thing to repair.

A session runs with three to five people and finishes inside 90 minutes. One person reads the steps aloud, another writes down the answers. The designer can sit in, but the rule is no defending. The moment "there's an explanation right here" enters the room, the view shifts from the user who doesn't read the explanation back to the person who wrote it.

A prototype or even a wireframe is enough. Nothing has to actually work: if the screen order and the wording are decided, the four questions can be answered.

It fits best on flows people pass through exactly once. Signup, onboarding, the first payment, connecting an account — places where users get no chance to build familiarity. In those flows the assumption that the second attempt goes better doesn't hold, so a single blocked step turns straight into a drop-off.

It also fits before anything is built. Finding the problem after development is expensive to fix; finding it while only the screen order exists usually costs one wording change. It is also the fallback when there is neither time nor budget to recruit users.

The places it doesn't fit are equally clear. On screens that expert users touch daily, all four questions come back yes. What those people feel as a problem is efficiency — how many extra clicks something takes — and that never registers here. Visual quality and speed are invisible to this method too.

There are two limits. The first is that the reviewers already know the correct path. Pretending not to know is not the same as not knowing, so the findings sometimes match where real users get stuck and sometimes don't. The second is that it says nothing about how many people get stuck. It produces a list of problems with no frequencies attached, so which of them costs the most has to be checked later against a moderated test or drop-off numbers.

"We don't have time to recruit this round, so let's do a walkthrough pass."

Proposing that the team trace the thinking themselves instead of bringing users in.

"Everyone answered no at step 3. I think the button label has to change first."

The problems cluster at one step, so that is where the work starts.

"That's a defense — let's just log it as a no and keep moving."

Stopping the designer's explanation from clouding the reviewing perspective.

At Pagedeck, Noa books this session the day before a new flow goes to engineering. Theo sits in to see which steps will be awkward to build, and Sofia joins because she's the one explaining these screens to customers and knows where the questions come from.

Mia doesn't fix everything on the resulting list. She splits it into what gets handled now and what waits, and the deciding factor is how many people pass through that step. A problem at step 2, which everyone hits right after signup, gets fixed this round; one that appears only deep in settings stays on the list.

The most common misreading is that this replaces usability testing. Both look for places people get stuck, so the substitution feels reasonable. But what this method produces is a list of places that look likely to block someone, while a usability test produces a recording of someone actually blocked. Teams that treat the first as the second ship because the walkthrough turned up nothing, then call in users only after drop-off appears somewhere nobody predicted. The order runs the other way: filter cheaply with the walkthrough, then confirm what's left with people.

Assuming it's the same as everyone clicking through together is the other one. It looks similar from outside the meeting room, so the thought is natural. The difference is that the four questions are forced at every step. Left to themselves, people comment on whatever catches their eye, and a step that passes in silence is quiet because nobody consciously looked at it, not because it's fine. Run without the questions, an hour yields a handful of impressions.