Scene Anchor
Replace a vague "users find it inconvenient" with a specific person in a specific moment.
Swap "users find it inconvenient" for "what a specific person is going through at a specific moment." Abstract needs can't produce a design; concrete situations can. This is the same idea behind "jobs to be done": people don't buy products, they hire them to get something done at a particular moment.hbr-jtbd
What you'll run into:
- Everyone on the team reads the same requirement differently
- Design discussions run on "I feel," with no basis to judge
- Ask AI for a screen and it returns a generic page that fits anywhere
The problem with abstract descriptions isn't inaccuracy—it's that they're compatible with too many approaches. "Enter data faster" could mean voice input, a quick template, or automatic recognition, and each one fits the sentence. You finish building, only to find the user wanted a fourth option.
The five elements of an anchor
| Element | Example | Note |
|---|---|---|
| Who | Lao Wang, a stall vendor, fifty, on an old Android phone | Not a word like "small merchants" |
| When | Closing up at nine in the evening, under the streetlight, counting cash one-handed | The environment sets font size, button size, one-hand use |
| What they want to achieve | Knowing how much he took today | Not "bookkeeping"—bookkeeping is the means |
| Where they're stuck | A customer arrives mid-entry and he forgets where he was | This line is the product's main task |
| What they do today | Tally marks on a cigarette pack, copied over at home | The workaround is also your real competitor |
The third line is the easiest to get wrong. Users never want to "use your product"; recording, exporting, and filtering are all means. The state behind them is the end. When writing an anchor, draft "stuck at" and "what they do today" first: they're the hardest to invent, and the fastest test of whether you really know the user—an anchor you can't fill there is probably a fake one.
How to use it to decide
Once the anchor is written, it becomes a ruler. Measure every proposed solution against it:
| Candidate | Measured against the anchor | Verdict |
|---|---|---|
| Voice input | It's noisy at closing time, and he'd be embarrassed saying amounts out loud | No |
| Photo recognition | He holds loose change, not receipts; there's nothing to photograph | No |
| Big quick-amount buttons | Tap with one hand, survives interruptions, matches his common amounts | Yes |
| Auto-saved drafts | Directly fixes "I forgot where I was" — the main sticking point | Yes |
Without an anchor, all four sound reasonable, and the decision comes down to who talks loudest or who outranks whom. With an anchor, the first two eliminate themselves.
A note for AI
Put the anchor in the prompt, and what comes back shifts from a generic template to a solution with real trade-offs.
Hold onto this usage scene first; every design decision after this defers to it:
Who: [specific person, including age, device, and skill level]
When: [time, place, environment, and what else they're handling]
Wants to achieve: [the state they want, not the feature they'd use]
Stuck at: [which exact step fails, and what happens when it does]
What they do now: [their current workaround]
Based on this scene, tell me first:
1. What hard constraints this scene puts on the UI (font size,
tap targets, one-hand use, interruptibility, etc.)
2. What main task you plan to build, and why not something else
3. Which common approaches do not fit this scene
I'll confirm before you write code.
The third question is the most useful. It forces AI to make a call like "voice input doesn't fit this scene" instead of piling on every feature it can think of.