Interview notes are full of complaints, workarounds, preferences, and half-finished thoughts. The hard part is not collecting more words. It is deciding which words describe a problem worth investigating.
A useful problem statement stays close to what the participant experienced. It names the context, the obstacle, and the consequence without pretending that one interview proves a universal truth. It also avoids smuggling a favorite feature into the problem.
Start with moments, not themes
Broad labels such as “scheduling,” “collaboration,” or “onboarding” can help organize notes, but they are not yet problems. Look for a specific moment when the participant tried to do something and could not complete it as expected.
Useful source fragments often contain:
- a situation: “When a client asks to move a call…”
- a behavior: “I open three calendars and compare them manually.”
- a consequence: “I sometimes confirm a time before checking the shared room.”
- a workaround: “I leave the message unanswered until I return to my desk.”
Copy the exact note or add a timestamp before interpreting it. A problem statement that cannot be traced to source material is easy to overstate.
Keep the solution out of the problem
“Users need a one-click rescheduling button” sounds precise, but it already chooses a solution. The underlying problem might be conflicting availability, missing room information, slow approvals, or uncertainty about who can change the booking.
Try replacing the proposed feature with the behavior it is meant to improve:
- Solution-shaped: Users need a smart calendar button.
- Problem-shaped: Coordinators cannot confirm a changed meeting time while away from their desk because the relevant calendars and room status are separate.
The second version leaves room for several possible responses. That is useful at the research stage.
Use four parts: context, obstacle, consequence, evidence
A compact problem statement can answer four questions:
- Context: Who is trying to do what, and when?
- Obstacle: What gets in the way?
- Consequence: What happens because of that obstacle?
- Evidence: Which notes or timestamps support the statement?
Add scope when it matters. “For coordinators working across shared rooms” is more honest than “for everyone who schedules meetings.” If the interview did not establish frequency or severity, leave those claims out.
Worked example: a fictional scheduling interview
The following example is fictional. Imagine an interview with Sam, an office coordinator, produced these notes:
06:12 — “If a client changes the time while I’m commuting, I can see my calendar but not the shared-room calendar.”
08:40 — “I usually wait until I reach my laptop. If I answer from my phone, I might promise a room that is already taken.”
12:05 — “It happens a few times in a busy month, not every day.”
A first draft might say:
Office coordinators need better mobile scheduling.
That is too broad. “Better” is undefined, “mobile scheduling” hints at a solution, and the statement loses the consequence.
A stronger draft is:
When a client requests a time change while Sam is away from a laptop, she cannot check both personal availability and the shared-room calendar in one place. She delays the reply or risks confirming a room that is unavailable. This appeared at 06:12 and 08:40; the interview did not establish that it happens daily.
This version is narrower and less dramatic. That is a strength. It shows what is known, what happened, and what remains uncertain.
Test the statement against the notes
Read the draft sentence by sentence and ask:
- Can each factual phrase be linked to a note or timestamp?
- Did the participant describe the consequence, or did the writer infer it?
- Does the statement describe one person, one segment, or an unsupported universal claim?
- Does it include words such as “always,” “never,” or “everyone” that the evidence cannot support?
- Could the problem be solved in more than one way?
This is the same discipline used when separating observed behavior from claims in product demo notes: preserve what was seen, label interpretation, and keep unanswered questions visible.
Look for a counterexample
One confirming quote is not enough to close the question. Search the same interview for moments that weaken the draft.
Suppose Sam also said, “For internal meetings, I can usually move the call without checking a room.” That counterexample narrows the problem to client meetings that require shared space. It does not invalidate the earlier observation; it improves the scope.
If the notes contain no counterexample, write that the scope is still untested. Do not replace missing evidence with confidence.
Turn uncertainty into the next interview question
A good problem statement should create a useful next question. For the fictional example, the team might ask:
- Who else needs to approve a room change?
- How often does delayed confirmation affect the client?
- Does the obstacle appear only while commuting, or in other mobile situations?
- What information does Sam check before confirming?
Write neutral questions that do not assume the problem is already proven. The guide to follow-up questions from interview notes shows how to turn ambiguous fragments into answerable prompts.
Copy-ready template
Context:
Obstacle:
Consequence:
Source notes or timestamps:
Scope supported by the evidence:
Counterexample or uncertainty:
Next question:Begin with three source-linked observations from one permitted interview. Draft one statement, remove any built-in feature idea, and mark one uncertainty. The goal is not to sound certain. It is to make the evidence useful enough for the next decision.
