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.
After a week of torrid voting and much passionate support, along with a lot of gut-wrenching consideration and jostling during the judging round, I am proud to announce your Top 40 Innovation Authors of 2025:
Greg Satell is a popular speaker and consultant. His first book, 
Mike Shipulski brings together people, culture, and tools to change engineering behavior. He writes daily on Twitter as 
A twenty-five year Procter & Gamble veteran, Pete has spent the last 8+ years applying insights from psychology and behavioral science to innovation, product design, and brand communication. He spent 17 years as a serial innovator, creating novel products, perfume delivery systems, cleaning technologies, devices and many other consumer-centric innovations, resulting in well over 100 granted or published patents. Find him at pete.mindmatters@gmail.com
Art Inteligencia is the lead futurist at Inteligencia Ltd. He is passionate about content creation and thinks about it as more science than art. Art travels the world at the speed of light, over mountains and under oceans. His favorite numbers are one and zero.
Dainora (a.k.a. Dee) creates customer-centric content at Viima. Viima is the most widely used and highest rated innovation management software in the world. Passionate about environmental issues, Dee writes about sustainable innovation hoping to save the world – one article at the time.
Soren Kaplan is the bestselling and award-winning author of Leapfrogging and The Invisible Advantage, an affiliated professor at USC’s Center for Effective Organizations, a former corporate executive, and a co-founder of 
Diana heads marketing at 
Jesse Nieminen is the Co-founder and Chairman at 
Arlen Meyers, MD, MBA is an emeritus professor at the University of Colorado School of Medicine, an instructor at the University of Colorado-Denver Business School and cofounding President and CEO of the Society of Physician Entrepreneurs at 
Phil McKinney is the Author of “Beyond The Obvious”, Host of the Killer Innovations Podcast and Syndicated Radio Show, a Keynote Speaker, President & CEO CableLabs and an Innovation Mentor and Coach.
Scott Anthony is a strategic advisor, writer and speaker on topics of growth and innovation. He has been based in Singapore since 2010, and currently serves at the Managing Director of Innosight’s Asia-Pacific operations.
Leo is the founder of 
Rachel Audige is an Innovation Architect who helps organisations embed inventive thinking as well as a certified Systematic Inventive Thinking Facilitator, based in Melbourne.
Dr. Ralph-Christian Ohr has extensive experience in product/innovation management for international technology-based companies. His particular interest is targeted at the intersection of organizational and human innovation capabilities. You can follow him on Twitter 
Dr. Dean Anderson and Dr. Linda Ackerman Anderson lead 
Chateau G Pato is a senior futurist at Inteligencia Ltd. She is passionate about content creation and thinks about it as more science than art. Chateau travels the world at the speed of light, over mountains and under oceans. Her favorite numbers are one and zero.
Anthony Mills is the Founder & CEO of Legacy Innovation Group (
Paul Hobcraft runs 
As an experience architect, Alain helps leaders craft customer, employee and shareholder experiences for profit, reinvention and transformation. He does this through his personal consultancy Alain Thys & Co as well as the transformative venture studio 
