by Braden Kelley and Art Inteligencia
Why Do Design Questions Beat a Requirements Document? (Short Answer)
A 40-page requirements document often fails because it freezes an assumed solution, hides tradeoffs, and treats missing human context as “out of scope.” Ten design questions beat it by forcing clarity on who is trying to succeed, what job they are hiring the experience to do, where friction and power live, and how you will know it worked in behavior — before you freeze features. Specs can follow. They should not lead.
The ten questions are: (1) Who is trying to succeed — and what does success feel like? (2) What job are they hiring this to do? (3) What happens right before and after? (4) Where does the current experience already fail? (5) What must never be true? (6) Who decides, who does the work, who gets blamed? (7) What would earn enough trust to kill the workaround? (8) How will we know it worked in behavior? (9) What will we deliberately not build? (10) If this ships poorly, what human harm are we designing for?
The Spec Is Not the Work
I have sat with teams who were proud of the document. Forty pages. Traceability. Version control. Every field named. And still nobody could say, in a sentence a frontline person would recognize, what a good Tuesday would feel like if this shipped.
That is not a writing problem. It is a design-sequence problem. Requirements documents are excellent at recording what the system should contain. They are weak at surfacing what humans are trying to get done, under what constraints, with what emotional and operational stakes. So the spec becomes a frozen guess — then a contract — then a reason not to learn.
Human-centered innovators do not ban specifications. They refuse to let the novel substitute for understanding. Ask better questions first. Write a thin spec as the receipt.
| Design question | What a 40-page spec usually misses |
|---|---|
| 1. Who succeeds — and how should it feel? | Named roles without lived stakes |
| 2. What job are they hiring this to do? | Feature lists that never name the job |
| 3. What happens before and after? | Isolated screens treated as the whole journey |
| 4. Where does it already fail (with or without dignity)? | Pain as a “usability” bullet, not a human cost |
| 5. What must never be true? | Constraints as footnotes after the solution is drawn |
| 6. Who decides, works, and gets blamed? | Workflow boxes with no power map |
| 7. What would earn trust enough to drop the workaround? | Acceptance criteria that never mention undo or trust |
| 8. How will we know it worked in behavior? | Done = signed off, not “humans finished the job” |
| 9. What will we deliberately not build? | Forty pages of yes; no real choice |
| 10. If it ships poorly, what harm lands on humans? | Risk as defects; harm as someone else’s problem |
1. Who Is Trying to Succeed — and What Does Success Feel Like for Them?
What it reveals: The actual human, not the persona slide. Functional success and emotional residue — calm, dignity, confidence, relief.
What the spec usually misses: “Users” as a bucket. Stakeholders as job titles. No one can describe what a good outcome feels like in the body, only what fields must exist on the form.
If you cannot name a specific person in a specific moment — and what “this worked” would feel like for them — you are specifying a system, not designing an experience.
2. What Job Are They Hiring This to Do — in Their Language, Not Ours?
What it reveals: The job-to-be-done, the context around it, and the competing solutions people already use — including spreadsheets, side channels, and “ask Maya.”
What the spec usually misses: Feature inventories that never name the job. Internal vocabulary that customers and employees would not use if you paid them.
People do not hire your module. They hire progress. Write the job in their words. If the sentence only makes sense inside IT or product, you are not done asking.
3. What Happens Right Before and Right After This Moment?
What it reveals: Journey continuity — handoffs, orphaned steps, the quiet “then they go back to email and re-enter everything.”
What the spec usually misses: Isolated screens treated as the whole experience. Requirements that start at login and end at submit, as if life does too.
Experience lives in the seams. A 40-page document that never maps the five minutes before and after is a novel about a doorway with no house.
4. Where Does the Current Experience Already Fail — With Dignity, or Without It?
What it reveals: Friction, workarounds, extra effort, and the places people feel stupid, trapped, or professionally exposed.
What the spec usually misses: Pain flattened into “usability” or “training issue.” No account of shame, delay, or the dignity cost of asking for help.
Human-centered design starts with how failure already feels. If you skip that, you will automate embarrassment and call it a release.
5. What Must Never Be True — the Constraints That Actually Govern Behavior?
What it reveals: Policy, risk, time, tools, staffing, compliance, and politics — the real design surface, not the wish list.
What the spec usually misses: Constraints listed as footnotes after the solution is already drawn. Then “exceptions” eat the experience in production.
Constraints are not the enemy of design. Hidden constraints are. Get them on the table before you freeze the happy path.
6. Who Decides, Who Does the Work, and Who Gets Blamed When It Breaks?
What it reveals: Decision rights, invisible labor, and accountability theater — who has power versus who has the ticket queue.
What the spec usually misses: Swimlanes that look tidy and say nothing about who can actually say yes, stop, or undo.
If the person who gets blamed cannot change the thing that failed, you have specified a trap. Design the power map, not just the process map.
7. What Would Make Someone Trust This Enough to Stop Using the Workaround?
What it reveals: Reliability, recoverability, and the bet people make with their Tuesday — “I will stop the spreadsheet when this won’t hang me out to dry.”
What the spec usually misses: Acceptance criteria with no undo, no explanation, no graceful failure, no path back to a human.
Adoption is a trust decision. Until the new way is safer than the workaround, the workaround is the real system. Your spec just hasn’t admitted it.
8. How Will We Know It Worked — in Behavior, Not in Sign-Off?
What it reveals: Experience measures you can observe: completion, effort, repeat contact, time-to-confidence, abandoned workarounds — not “requirements met.”
What the spec usually misses: Done equals documented. Success equals a steering committee signature. Humans finishing the job is someone else’s metric.
If you cannot name the behavior that changes when you win, you are managing a document, not an outcome. Sign-off is not evidence.
9. What Will We Deliberately Not Build — and Who Is Brave Enough to Say It?
What it reveals: Scope as a design choice. Tradeoffs made visible instead of smuggled in as “phase two.”
What the spec usually misses: Everything in, nothing chosen. Forty pages of yes. A backlog that is really a refusal to decide.
Innovation is subtraction with a spine. If nobody can name what you will not build, you do not have a design. You have a catalog.
10. If This Ships Poorly, What Human Harm Are We Actually Designing For?
What it reveals: Failure modes that land on customers and employees — lost time, lost money, lost dignity, lost trust — not just “defects.”
What the spec usually misses: Risk as technical. Harm as someone else’s problem. No owner for the human cost of a bad release.
Every shipped experience is a bet on someone’s Tuesday. Name the downside in human terms. Then design recovery as carefully as the happy path. That is not pessimism. That is professionalism.
How Do You Replace a Requirements Document With Design Questions?
You don’t throw away rigor. You change the sequence. Run the ten questions as a working session — 60 to 90 minutes, one critical journey, people who have actually done the work in the room (or on the call). Capture answers as evidence, not slogans. Then write a thin spec that traces every requirement back to a question you can still defend.
- Pick one journey — not the entire platform.
- Answer the ten questions in order — skip none, especially 9 and 10.
- Show the answers to the humans who live the work — if they don’t recognize themselves, you invented a document.
- Write the spec as a receipt — features only where they serve a named job, constraint, and success behavior.
- Keep a kill list — what you will not build, and the workaround you intend to make unnecessary.
Requirements should be the receipt of understanding — not the substitute for it. A 40-page document can still be useful. It just should never be allowed to go first.
Frequently Asked Questions
Why do requirements documents fail in experience design?
They often freeze an assumed solution, hide tradeoffs, and skip jobs-to-be-done, journey seams, power, trust, and felt success. The document records what the system should contain while missing what humans are trying to get done — so teams ship to the spec and still fail the experience.
What questions should you ask instead of writing a long requirements document?
Ask who is trying to succeed and how success should feel; what job they are hiring the experience to do; what happens before and after; where the current experience fails; which constraints actually govern behavior; who decides, works, and gets blamed; what would earn trust enough to drop workarounds; how you will know it worked in behavior; what you will not build; and what human harm a poor ship would create.
How do you replace a requirements document with design questions?
Run the ten questions in a 60–90 minute session on one journey with people who do the work. Capture evidence, not slogans. Then write a thin spec that traces every requirement back to those answers, including a kill list of what you will not build.
Should you still write a requirements document after asking design questions?
Yes — as a receipt of understanding, not as the starting point. A thin spec that traces features to jobs, constraints, and behavioral success is useful. A 40-page document that goes first usually becomes a frozen guess and a reason not to learn.
What is the difference between a requirements document and human-centered design questions?
A requirements document specifies system contents and sign-off criteria. Human-centered design questions specify understanding: who succeeds, what job is being done, where friction and power live, and how behavior will prove the experience worked. Questions lead; the spec follows.
Image credits: Google Gemini
Content Authenticity Statement: The topic area, key elements to focus on, etc. were decisions made by Braden Kelley, with a little help from Google Gemini and Cursor to clean up the article, add images and create infographics.
Sign up here to get Human-Centered Change & Innovation Weekly delivered to your inbox every week.