Interaction Engineering · 8 / 10

Goal-Oriented: Describe Requirements by Goals, Not Feature Lists

The first seven lessons teach you to spot good interaction; these two teach you to translate requirements for AI. The first translation principle comes from the opening methodology of About Face 4: say who the user is and what they need to finish—let AI derive the features. Hand it a list and you get a counter; tell it a scenario and you get a tool.

Goal vs. taskPersonaContextual scenarioPrompt duel
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 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.

"We call this method of studying and satisfying user goals and needs directly goal-oriented design."
Alan Cooper, About Face 4, Chapter 1. Ask for whom and why before what.
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?

Feature list vs. goal scenario Pick a side
Above is the prompt fed to AI; below is the UI it returned. Tap the side you'd actually use.
Prompt A · Feature list
// List features item by item Build an expense page with: invoice upload, amount field, category dropdown, notes, approver picker, submit button, history table, filters, export to Excel.
oa.example.com/expense
Expense management
Choose file (none selected)
Enter amount
Select ▾
Enter notes
Select ▾
Submit Reset Export Excel
HistoryAmountStatus
2026-07 Taxi¥86.00Approved
2026-06 Office supplies¥219.00Approved
Prompt B · Goal scenario
// Tell the persona and scenario User is sales rep Xiaomei, who stacks up taxi receipts at month-end. Goal: file expenses in three minutes without breaking her flow. Scenario: drag in receipt photos; the system auto-reads amount and category; she glances, confirms, taps submit, and sees "Submitted—expect reimbursement in 3 days."
oa.example.com/expense
1 Drop invoice2 Confirm3 Done
Drop invoice photos here
Batch OK; amount and category auto-detected
Taxi receipt · ¥86.00
Detected as "Transport"—tap to fix Detected
Confirm & submit
You can undo within 5 minutes after submit

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.

Warm up: goal, or task?

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.

Goal or task 0 / 6
Ask "what for?" of each line, then decide.
After all six, a summary lands here.
Personas: design for someone—write their name

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.

Xiaomei
Sales · expenses once a month
Goal: file expenses in three minutes—don't break my deal flow.
Primary persona
Lao Zhou
Finance · reviews dozens a day
Goal: spot problem claims at a glance; batch-approve the clean ones.
Secondary persona
Da Liu
Director · always on the road
Goal: multi-currency receipts—don't make me convert myself.
Secondary persona

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.

Greedy experiment: serve one more user Serving 1 person
This is Xiaomei's expense home. Each button tap stuffs in one more user's needs.
oa.example.com/expense
Expenses
Approval desk (for Lao Zhou): 23 pending · 2 flagged · batch approve · reject-reason library
FX center (for Da Liu): USD 7.18 · EUR 7.82 · JPY 0.048 · historical FX chart
Drop invoice photos here
Team report (for the manager): dept expenses this month ¥42,190 · YoY +18% · view details
Confirm & submit
Invoice archive print (for admin): bind by month · generate cover · connect printer
Right now the whole page serves Xiaomei only: drop, confirm, submit—the three-minute goal holds.
Scenarios: let the persona walk the product on paper

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.

Scenario rewriter 0 / 4
Tap each line to see feature-speak become scenario-speak. After four, you get a ready-to-use prompt.
1 Feature-speakNeed meeting-room booking with time filters
2 Feature-speakNeed calendar view and list view toggle
3 Feature-speakNeed meeting reminder push settings
4 Feature-speakNeed cancel booking and reschedule
Assembled scenario prompt
User is admin specialist Azhe. Every week he books rooms for three teams. Goal: book a usable room in ten seconds, and fix mistakes instantly. Walk the scenario: he states time and headcount; the system shows only rooms available now; after booking he glances at this week's plan; before the meeting he gets one well-timed reminder; a coworker reschedules, and he edits the same record in one step—no cancel-and-rebook. You choose UI states (loading, empty, error) and controls—whatever helps Azhe hit the ten-second goal.
Notice what every rewrite shares: the subject flips from "the system" to "a person."
Quiz: which requirement feeds AI best?
Building an "add expense" screen for a ledger app—which brief is best? Single choice
ANeed amount keypad, category grid, date picker, notes field, save button
BReference mainstream ledger apps and make an add-expense screen—make it nicer
CUser is an office worker. Goal: log one expense in five seconds while queuing for coffee. They only use a few categories—two taps should finish it
DPage in three blocks: amount on top, category in the middle, big save button at the bottom
Key Takeaways
✓

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.).