Goal-Oriented: Describe Requirements by Goals, Not Feature Lists
Telling AI "Xiaomei needs to file expenses in three minutes" beats "need upload, form, buttons" by a mile. Duel two prompts, then practice rewriting a feature list into a scenario
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Goal-Oriented: Describe Requirements by Goals, Not Feature Lists”?
Telling AI "Xiaomei needs to file expenses in three minutes" beats "need upload, form, buttons" by a mile. Duel two prompts, then practice rewriting a feature list into a scenario
Turn taste into a behavior the product can repeat. The useful outcome is not a nice opinion. It is a visible rule, a small example, and a way to tell when the experience falls below the bar.
Capture one before-and-after example that shows the quality bar without extra explanation.
Polish that improves the surface while leaving the user's uncertainty untouched.
When briefing AI, most people's first move is a feature list: "need upload, need a form, need export." It looks professional, but it skips the most important info: together, who are these features helping finish what? AI can only execute item by item—every item lands, yet nobody's problem gets solved.
About Face 4, Chapter 1, makes this the foundation of the methodology: interaction design studies user goals first, then derives features from goals. Cooper stresses that goals and tasks are different: a goal is the expected end state; a task is only a middle step toward it. Goals stay stable for decades (file the expense, let the boss know you're done); tasks swap every few years (paste receipts → photo OCR). Brief by tasks and AI gives you an electronic version of the old task; brief by goals and it gets a chance to delete the task itself.
Alan Cooper, About Face 4, Chapter 1. Ask for whom and why before what.
Same expense tool: left feeds AI a feature list, right feeds a persona and scenario. Below are two prompts and the UIs they return. Don't peek at the verdict—pick: which side would you use once a month?
Batch OK; amount and category auto-detected
Detected as "Transport"—tap to fix Detected
One detail: Prompt B never names a control, yet the output has drag-and-drop, auto-detect, and undo—none of which were on A's list. Features grow from goals; give AI enough soil and it will fruit on its own.
To brief by goals, you first have to recognize them. One test, from Chapter 1: a goal is the end state; a task is a step toward it. Ask "what is this for?"—if you can still answer, it's a task; if you can't (it is the answer), it's a goal. Six lines—judge each.
A goal needs an owner. Chapter 3's tool is the persona: distill a real user into a concrete person with a name, a job, and a goal, and let every design trade-off answer to them. Cooper hammers one point: each screen serves one primary persona. Try to please everyone and the UI becomes a counter with a bit of everything—everyone who arrives has to hunt first.
Secondary needs can ship—but only tucked in a corner that doesn't crowd the primary. Doubt it? The experiment below shows what "a little for everyone" costs.
With persona and goal in place, Chapter 4's last tool is the contextual scenario: no tech, no control names—write like a story how this person reaches the goal end to end. Once written, must-have features vs. pure fantasy float up on their own. That's also the best format for AI: it can read a story, and invent the missing parts.
Below is a typical feature list—four lines of "must have X." Tap each to see what it looks like in scenario language.
Goals are destinations; tasks are steps: if "what for?" still has an answer, it's a task. Brief by goals so AI gets a chance to delete surplus tasks entirely.
One screen serves one primary persona: tuck secondary needs in a corner. A UI that tries to care for everyone ends up smooth for no one.
Best format for AI is a scenario: persona + goal + an end-to-end story. Let it derive controls and states; you only check whether the goal was met.
One-line template: "User is ____. Goal is ____. Walk the scenario: ____. You decide UI details—whatever helps the user hit the goal."
Source: Original to Xiaoshan Academy's Interaction Engineering series; goal-oriented design, personas, and contextual scenarios adapted from About Face 4: The Essentials of Interaction Design, Chapters 1, 3, and 4 (Alan Cooper et al.).
Turn the feeling in “How feature lists fool you” into a judgment
“When briefing AI, most people's first move is a feature list: "need upload, need a form, need export." It looks professional, but it skips the most important info: together, who ar…” points out that AI has lowered the bar for making something usable. The skill readers need is noticing what is wrong and turning that feeling into an actionable requirement.
Watch the user's next action, not just the surface
Turn “About Face 4 , Chapter 1, makes this the foundation of the methodology: interaction design studies user goals first, then derives features from goals.” into observable questions: does the user know what happened, what to do next, and how to recover from an empty or failed state? Does the hierarchy make the important information visible first?
Pretty is not the same as usable
Apply “One-line template: "User is ____.” to a second screen or flow. Record one moment of hesitation and the user action after the change; observable behavior is stronger evidence than polish alone.
From “How feature lists fool you” to “Duel · Same requirement, two prompts”
“How feature lists fool you” grounds the problem in “When briefing AI, most people's first move is a feature list: "need upload, need a form, need export." It looks professional, but it skips the most important info: together, who are these features helping finis…”. “Duel · Same requirement, two prompts” then moves it toward “Same expense tool: left feeds AI a feature list, right feeds a persona and scenario. Below are two prompts and the UIs they return. Don't peek at the verdict—pick: which side would you use once a month”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
For experience work, turn abstract impressions into user actions: did the person understand the state, find the next step, recover from an error, and want to continue?
- “How feature lists fool you”: When briefing AI, most people's first move is a feature list: "need upload, need a form, need export." It looks professional, but it skips the most important info: together, who are these features helping finis…
- “Duel · Same requirement, two prompts”: Same expense tool: left feeds AI a feature list, right feeds a persona and scenario. Below are two prompts and the UIs they return. Don't peek at the verdict—pick: which side would you use once a month
- “The closing point”: With persona and goal in place, Chapter 4's last tool is the contextual scenario : no tech, no control names—write like a story how this person reaches the goal end to end. Once written, must-have features vs…
The final “The closing point” brings the discussion to “With persona and goal in place, Chapter 4's last tool is the contextual scenario : no tech, no control names—write like a story how this person reaches the goal end to end. Once written, must-have features vs…”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.