Understanding the Ask

Discover what the user actually needs before requirements are formalised. Users often state solutions, not problems — explore intent, context, and constraints until the underlying need is clear, then hand off to creating-briefs.

Skip the full workflow when the request is already specific with stated outcomes, or the task is trivial with obvious intent.

Workflow

Step 1 — Capture the initial statement

Establish the surface request and basic context with open-ended questions:

• "What are you looking to create or achieve?"
• "Who will use this?"
• "Where does this fit in your current work?"

Capture what they think they need — don't probe why yet. Prefer "what" and "how" openers; "why" can feel defensive.

Step 2 — Explore intent and motivation

Don't literally ask "why" five times; invite elaboration:

• "What's driving this need right now?"
• "What would having this enable you to do?"
• "What happens if we don't address this?"

When the user proposes a specific solution, probe for the outcome behind it: "I need a comprehensive API reference" → "What would that reference enable your team to do?"

Premature-solutioning signals: specific tools before the problem is defined; fixation on a deliverable type; "we need X" without "because Y"; features before outcomes. Redirect: "Before we discuss how, can we clarify what problem that solves?" Some solution talk is fine — just make sure problem context exists first.

Stop when you reach fundamental goals or constraints (typically 3–5 exchanges): the user articulates a clear outcome, you understand the consequence of not solving it, and the need — not just the proposed solution — is clear.

Step 3 — State your understanding

Reflect back at key moments — after exploring intent, before brief creation, when uncertain about something specific — not after every statement:

"Let me state back what I understand:

• Problem: [what's not working or missing]
• Outcome: [what success looks like]
• Constraints: [limitations, boundaries, must-haves]
• Audience: [who will use this]

Have I understood correctly? What have I missed?"

Iterate until the user confirms.

Step 4 — Verify readiness

Ready to hand off when:

• [ ] The problem fits in one clear sentence
• [ ] The desired outcome is understood — not just the requested deliverable
• [ ] You know what success looks like and how the user will know it's solved
• [ ] You know why this matters now, who is affected, and who decides
• [ ] Scope boundaries are known (what's in, what's out)
• [ ] Understanding was stated back and confirmed; no contradictions remain

If not ready — concepts still unclear, the user keeps correcting you, significant aspects feel assumed — return to Step 2 and probe the unclear areas.

If ready, hand off to creating-briefs: the problem, desired outcome, audience, constraints, and success vision. Done well, it can formalise requirements without re-exploring intent.

Common traps

• Accepting ambiguous language — "comprehensive", "good quality", "user-friendly" mean different things to different people. Probe: "Covering all edge cases, or just common scenarios?"
• Mistaking symptoms for causes — "the documentation is unclear" is a symptom; the cause may be missing examples, wrong audience level, or stale content. Keep probing.