Problem interviews vs. solution interviews: choose the next question

A problem interview investigates how someone handles a situation today. A solution interview explores how they interpret and assess a proposed approach. Both can be useful, but they answer different questions. A positive reaction to a demo cannot tell you whether the problem was important before you introduced your product.

The next method should follow the uncertainty. If you cannot describe a recent event, the current workaround, and its consequences, start there. If you already understand that workflow and need to examine a proposed change, bring a concept or prototype. If you need to know whether people can use it, give them a task rather than asking for an opinion.

Choose the method with this decision tree

Use the following as a planning tool, not a requirement to complete a fixed sequence for every feature.

1. Can we identify the person, triggering event, and current response? If not, investigate recent examples through problem interviews or observation.
2. Do we understand the consequences of that response, including whether anything needs to change? If not, reconstruct the steps and consequences before proposing a fix.
3. Is the uncertainty about what our proposal means to people? Show a concept and ask them to explain it in their own words.
4. Is the uncertainty about completing a task? Run a usability session with a realistic goal and a prototype capable of supporting it.
5. Is the uncertainty about adopting or buying? Examine the decision process and test a concrete next commitment. A favorable interview response leaves that question open.

Existing evidence can let you begin later in the tree. A team with carefully analyzed support cases and observed workflows may already know the problem. The issue is the strength and relevance of that evidence, not whether someone has performed a ritual number of interviews.

GOV.UK’s guidance distinguishes learning about people’s needs from defining a preferred solution: a need should describe the outcome or problem, not simply restate a proposed feature. Read the guidance on learning user needs.

A paired example: missed delivery exceptions

Imagine a fictional product team considering a shared queue for delivery exceptions. Its initial idea is a dashboard that brings delayed deliveries to a dispatcher’s attention. That interface is a proposal. The current problem might instead involve deciding who is allowed to promise a new delivery time.

Start with a problem interview about a specific recent exception. Here is an original script the team could adapt:

• “Think of the most recent delivery that missed its planned window. When did you first learn about it?”
• “What did you do immediately after that?”
• “Who else became involved, and what did each person need to decide?”
• “Where did the updated information go?”
• “Did any part take more effort than you expected? If so, what happened?”
• “How did you know the situation was resolved?”

Ask follow-ups using the participant’s details. If they mention messaging an account manager, ask what they needed from that person. Do not replace their story with your explanation of why dispatch software is broken.

GOV.UK’s in-depth interview guidance recommends neutral, open questions and concrete stories instead of general accounts of what should happen. That principle helps keep this conversation anchored in experience. Read the interview guidance.

Change the script when you introduce a solution

Suppose the early research suggests dispatchers lose track of exceptions while waiting for someone else’s decision. The team now has a narrower proposal: an exception card showing the outstanding decision, its owner, and the last update.

A concept conversation could ask:

• “What do you think this card is for?”
• “Which information would you need to check before acting?”
• “Where would this fit in the delivery incident you described?”
• “What would still happen outside this screen?”
• “What would make this approach unsuitable for your team?”

These questions examine interpretation and fit. They still do not show that a dispatcher can operate the interface under pressure.

For that, create a task: “This delivery will miss its window. You need the account manager to decide whether to offer a revised time. Show what you would do.” Avoid mentioning the button or field that you hope they will select.

GOV.UK defines moderated usability testing around observing people attempt specific tasks. Its task guidance calls for a believable goal without instructions that give away how to complete it. Read the usability testing guidance.

Keep evidence from each part separate

You can combine methods in one session, but record the transition. Once someone sees your concept, later descriptions may be influenced by it. You cannot return to a wholly unprompted account of their original problem in that same conversation.

Use three note sections:

Keep exact observations separate from interpretations. “Asked where to change the owner” is an observation. “The ownership model is too complex” is an explanation you may need to investigate.

If you must help a participant because the prototype is incomplete, record the intervention. The rest of the session can still be useful. It simply cannot establish that the assisted step worked without help.

Read mixed results without forcing a verdict

A participant can describe an important problem and dislike your solution. That is a reason to reconsider the approach, not to discard the original account. Conversely, someone can enjoy a polished demo for a situation they rarely encounter. That reaction does not establish urgency.

In the fictional delivery example, imagine a dispatcher likes the exception card but says only an account manager may change customer commitments. The next step is not necessarily another dashboard feature. The team needs to understand that handoff and include the relevant role in the investigation.

Use a short decision record after each round:

• Supported: What did we observe or reconstruct?
• Challenged: Which assumption did the evidence contradict?
• Unanswered: What could this method not establish?
• Next: Which person, artifact, or behavior would address the remaining question?

The most useful outcome may be a smaller proposal: clarify the pending decision and notify its owner before building a complete dispatch workspace. Good research changes the next move. It does not have to end with a yes-or-no verdict on the entire business.