walkthrough

Walkthrough

Announce at start: "I'm using the humane:walkthrough skill to attempt this task as the person who has it."

Inspection asks whether an interface obeys principles. Reaction asks how words land. Neither asks the question that decides whether the product works: can this person, with this goal, get through?

A walkthrough answers that by attempting the task — one concrete task, one concrete person, one step at a time — and recording exactly where the attempt would break.

When to invoke — and when not

Reach for this when you have a task and something to attempt it on.

You want	Skill
Can someone complete this task?	this skill
Does the interface violate usability principles?	nielsen-heuristics
How does this copy land with strangers?	respondent-panel
Would an expert stakeholder object to this document?	persona-review
Did the change actually improve things?	before-after (feed it these results)

Do not run this on a spec or a description. A walkthrough needs something to operate. If all you have is a document, nielsen-heuristics design-risk mode is the honest substitute — say so and switch.

Step 1 — Derive the task from the corpus, not from the interface

The most common way this method fails is walking the flow the designer built instead of the job the person has. Guard against it by taking the task from outside the interface.

1. Read <corpus_root>/<slug>/jtbd.json — corpus_root is the setup setting, default ~/jtbd; read the configured value, not the default. Prefer a task derived from an odi.outcomes[] entry — those already carry a stage (one of define/locate/prepare/confirm/execute/monitor/modify/conclude) and a touch (the surface it lives on). An underserved outcome (high importance, low satisfaction) is the highest-value thing you can walk.
2. Write the task as the person's goal, in their words, with no interface nouns in it. "Find out what I spent on models last week" — not "open the billing dashboard and apply a date filter." If your task statement names a button, you have already assumed the answer.
3. Name the actor and their entry state. Who they are, what they already know, what they have already done, where they arrive from, on what device. Use the corpus actor and jtbd.situation. First-time and returning users walk different paths through the same screens — pick one and say which.
4. State the success condition — the observable thing that is true when the job is done. This is what "task success" is measured against, and it must be decided before the walk.