Consultative Discovery and Requirements Gathering Questions

Direct answer

I start broad and end narrow, then widen again to close. A broad (open-ended) question invites a story or opinion ("walk me through..."). A narrow (confirming) question checks a specific fact, rule or number that I have a reason to believe but need to verify. Broad questions find what I did not know to ask. Narrow questions pin down what matters for the checkout redesign. I switch when a theme appears or when answers go flat. A stakeholder is anyone with a stake in the outcome, such as the product owner or an engineering lead whose work checkout changes.

A shape for a 45-minute stakeholder interview

Examples of broad questions

• "Walk me through what happens today when a customer checks out."
• "What is the biggest headache with checkout from your team's side?"
• "What would make this redesign a success a year from now?"
• "What worries you about changing it?"

Examples of narrow, confirming questions

• "You mentioned payments time out. Which provider, and how often does that happen?"
• "Is guest checkout something we must keep?"
• "Which payment methods must stay in the new design?"
• "Does the same-day shipping cutoff apply to every region?"

I keep narrow questions neutral. "Don't you think guest checkout should go?" leads the answer, while "Is guest checkout something we must keep?" does not.

When to switch

• Broad to narrow: a theme repeats, or someone names a number, a rule or a dependency worth verifying.
• Narrow back to broad: an answer surprises me, answers become short and rehearsed, or I realise I am confirming my own guess.
• Different audiences: product stakeholders get more questions on goals, metrics and trade-offs. Engineering stakeholders get more on legacy limits, dependencies and what is costly to change.

Pitfalls

Going narrow too early anchors the conversation on my guess, and staying broad for the whole hour leaves me with stories and no verified facts.

Direct answer

I choose the method by asking, for each group, what I need from them, how reliable their account is, and how much of their time I can get. Executives get short one-to-one interviews on goals and success measures. System owners get interviews, documentation review and technical walkthroughs about what the systems do. Front-line users get observation plus interviews, because they do the real work. Watching people tells you things an interview cannot: the workarounds, habits and exceptions they no longer notice or mention.

Matching method to group

Sample questions for the groups that talk instead of showing

Executives (each answer changes what you prioritise):

1. "If this program has worked in 18 months, what is different, and how would you know?" Probe a vague answer: "Faster at what step, by how much, measured by whom?"
2. "Which is fixed: date, budget or scope?" The fixed one tells you what can flex.
3. "What would make you stop or reshape the program?" This reveals risk appetite.

System owners:

1. "Walk me through what happens to an order from entry to the finance ledger. Which steps are manual?"
2. "Which changes to this system take more than a month, and why?"
3. "Who else reads or writes your data, and what breaks if you change a field?"
4. "What parts of how this system is actually used do you not know?" The last one points you to the front-line observation.

Sequencing

Executives first for goals, then system owners for the landscape, then front-line observation, then a workshop to reconcile, then a survey to size what you found.

Where observation beats an interview (worked example, illustrative)

A claims team says in interview: "We enter the claim, then approve it." Watching a morning shows they print the screen, check a paper binder of exceptions, and phone the broker whenever a field is missing, then retype the answer. None of this was mentioned because it feels like part of the job. This is tacit knowledge (know-how people use but cannot easily articulate). Observation also shows:

• Workarounds such as spreadsheets beside the official system.
• Handoff delays and waiting time.
• How often exceptions really occur.
• Environment: shared devices, noise, interruptions.

This is sometimes called contextual inquiry (observing and asking questions in the user's own workplace).

How to observe well

Ask permission, explain the purpose, stay long enough that people relax (people change behaviour when watched, the observer effect), take notes on what they do rather than what they say, ask "why did you just do that?" at natural pauses, and follow privacy rules for sensitive data on screens. Then use a short interview to check what you saw.

Trade-offs and pitfalls

• Observation is slow and covers few people, so use it where the work is complex or high-volume.
• Interviewing only the sponsor's nominated people.
• A workshop with executives and front-line staff together can silence the front line.
• Observing without a follow-up conversation invites misreading.

Direct answer

I rely on six techniques: open-ended questions, probing follow-ups, paraphrasing, silence, turning vague words into measures, and a closing summary. Afterwards I send a written read-back within a day, ask what I got wrong or missed, and check key claims against a second source.

The techniques, with sample phrases

A stakeholder is anyone affected by the outcome whose needs I am gathering. An open-ended question cannot be answered with yes or no. Paraphrasing means restating what you heard in your own words to check it.

I keep my questions open and neutral, not leading (a leading question is worded to suggest the answer you want, like "Wouldn't a dashboard help?") since a leading question hands the stakeholder my answer back.

Checking afterwards

1. Written read-back: within a day, send what I heard as needs, assumptions and open questions, and ask "what did I get wrong or leave out?"
2. Separate quotes from interpretation: in notes, mark what they said and what I inferred.
3. Second source: compare against another stakeholder, a document or data.
4. Open items: each unresolved question gets an owner and a date.

Worked example (illustrative)

A finance manager says: "Month-end close takes too long." I ask: "Tell me about the last close." She describes waiting for three regional approvals. I probe: "What happened after the third approval?" Then I turn the vague word into a measure: "Too long compared with what, measured from when to when?" She says from the last day of the month until reports are signed off, compared with a five-day target. I paraphrase: "So the delay is in approvals, and the clock runs from month-end to sign-off, aiming for five days." She corrects: sign-off by the controller, not the regional leads. That correction is why the read-back exists.

Trade-offs and pitfalls

• Talking over silence. A pause often brings the real answer.
• Taking notes only of what confirms my theory.
• Skipping the read-back because it feels redundant. It is the cheapest correction available.
• Using jargon the stakeholder does not use. Mirror their words.

Direct answer

"Make onboarding less confusing" is a symptom someone reported, not a problem statement. Before opening a design tool I would pin down four things: who is confused, at which step, what evidence says so, and what the business wants to change. Only then can I decide whether this is a design problem (a willing user fails because of layout, wording or flow) or something design cannot fix alone.

What to learn, and from whom

Is it a design problem? Three tests

1. Do willing, qualified users fail at a step they want to complete? If yes, it is likely a design problem.
2. Is the wrong audience arriving (say, from a campaign), so people leave whatever the screens look like? That is an acquisition or targeting problem.
3. Is the step itself wrong: a required step users do not need, a bug, a missing capability, a policy? That is a product or engineering problem. Design can still help, but making a step optional is a product decision.

Worked example (illustrative numbers)

Out of 100 sign-ups, 80 create a workspace, 45 invite a teammate, and 40 finish a first project. The biggest loss is the invite step: 80 minus 45 is 35 people. After watching recordings and calling a few of them, three different findings are possible:

• They cannot find the invite button: a design problem, fix the layout and wording.
• Solo freelancers have nobody to invite and the step is mandatory: a product decision to make it skippable, which design then carries out.
• Invitation emails land in spam: a deliverability problem for engineering.

One word, "confusing", three different owners. What I would hand back to the PM before any pixels: one paragraph, "New self-serve users in segment X drop at step Y; evidence is Z; success is a change in metric M", agreed by the PM.

Trade-offs and pitfalls

• Funnel numbers show where people leave, not why. A few conversations show why, not how many. I need both.
• One stakeholder's own confusion is an anecdote, not evidence about users.
• Skipping to a redesign risks polishing a step that should not exist.

Direct answer

I do not argue with the feature list. I write every item down, show it back to them, and then ask about the situation behind each item: when they last needed it, what it would let them do, and why that matters. I restate the outcome in their words and check it. Their features stay on the list as candidate ways to reach the outcome.

Techniques and phrasing

• Capture first: "Let me make sure I have everything you asked for." I write each feature on the board, so nothing is dismissed.
• Ask for the last time: "Walk me through the last time you needed that. What were you doing just before and just after?" A real episode tells more than an opinion.
• Ladder up gently: "And once you have that, what does it let you do?" Repeat two or three times, since each answer moves from feature to purpose.
• Avoid the defensive question: "Why do you want that?" can sound like a challenge. "Help me picture it" does not.
• Restate and check: "So the real goal is that you stop rebuilding the same weekly numbers for your director. Did I get that right?"
• Reconnect to the list: "Everything you asked for stays on the list. I will check each against that goal and tell you which I think gets you there."

Worked example (illustrative dialogue)

A regional manager asks for four things: an Excel export, a scheduled email, custom filters and dark mode.

Me: "Walk me through last Monday."
Manager: "I pulled the numbers from three screens and pasted them into a slide for my director."
Me: "And once the numbers are on the slide?"
Manager: "I stop spending two hours on it. That is the whole point."

Outcome: "Stop rebuilding the weekly numbers by hand." Now I can ask the prioritising question: "If the first release could do only one of these and you had to defend it to your director, which, and what happens in week one without the others?" The answer was the scheduled email.

Turning a requested feature into a testable hypothesis

"We believe a scheduled Monday email with the regional numbers will cut the time you spend preparing the weekly report from about two hours to under thirty minutes within four weeks, measured by a before-and-after time check." (The numbers are illustrative targets, to be confirmed with the manager.) It states who, what, a metric and a time window.

Trade-offs and pitfalls

• Sometimes the feature is the requirement. If the director only reads Excel, an export is a real constraint. Ask "is there a reason it has to be this form, such as a rule or a habit someone owns?"
• Recall is fallible and skews toward recent events (a known limit of past-incident questions, such as the critical incident technique, and a caution Nielsen Norman Group raises about asking people to remember past use). So I ask for the most recent concrete instance and check it against an artifact or a second person, here the slide the manager pasted the numbers into, rather than treating one retelling as fact.
• Do not imply you know better. Hand the list back with your reading and let them correct it.
• Coaching the every-feature-just-in-case instinct works through cost, not refusal: ask what is lost in week one without each item.