Most design thinking projects do not fail in ideation. They fail in the define phase, quietly, weeks before anyone notices. The workshop produces energy, the wall fills with ideas, and every one of them is a competent answer to a badly framed question. The problem statement is the single artefact that decides whether the next three months of work matter. This guide covers what a design thinking problem statement actually is, the four components it must contain, five formats and when to use each, worked before-and-after examples, and a scoring test you can apply before committing a team.
The short answer: A design thinking problem statement is a single sentence that names a specific user, their unmet need, and the insight that explains why the need exists — without naming a solution. The most reliable format is the point-of-view statement: [User] needs a way to [need] because [insight]. Write it after synthesis, not before research. Then convert it into two or three “How Might We” questions to open ideation. If your statement contains a feature, a technology or a department name, it is a solution in disguise and needs rewriting.
Why problem statements are the highest-leverage artefact in the process
Organisations are broadly competent at solving problems and broadly poor at choosing them. Thomas Wedell-Wedellsborg surveyed 106 C-suite executives across 91 private and public-sector organisations in 17 countries for his Harvard Business Review article on problem diagnosis, and found that 85% agreed their organisations were bad at diagnosing problems, while 87% agreed the flaw carried significant costs. Fewer than one in ten said they were unaffected.
That is the whole case for spending disproportionate time on the define phase. Every downstream activity — ideation, prototyping, testing, build, launch — inherits the framing. A poorly framed problem does not announce itself. It produces perfectly reasonable work that solves something nobody was struggling with.
The pattern Wedell-Wedellsborg identifies is worth naming precisely, because it is the exact failure mode design thinking is built to prevent: managers switch into solution mode fast, without checking whether they understand the problem. Speed feels like competence. It is usually the most expensive thing in the room.
What a problem statement is not
Four things get mistaken for problem statements, and all four will sink a project:
- A business objective. “Increase mobile app adoption by 20% this financial year.” This is a target. It tells you what success looks like for the organisation, not what is wrong for a person.
- A requirement. “The onboarding journey must support Aadhaar-based eKYC.” This is a specification. Someone has already decided the answer.
- A complaint. “Customers say the process is confusing.” This is raw data, unsynthesised. Which customers, confused by what, and why does that confusion exist?
- A solution wearing a question mark. “How can we build an AI chatbot for customer support?” The most common of the four, and the most damaging, because it looks like a question.
The four components of a design thinking problem statement
A statement that works contains four things. Three appear in the sentence; the fourth sits alongside it.
| Component | What it does | Test it must pass |
|---|---|---|
| User | Names a specific person or segment, described by situation rather than demographics | Could you walk into a room and identify who qualifies? “Millennials” fails. “First-time home-loan applicants earning under ₹8 lakh who have no formal credit history” passes. |
| Need | States what the user is trying to achieve, as a verb, not as a product | Rewrite it as a noun and it should break. “Needs a way to understand what documents are still missing” passes. “Needs a document checklist feature” fails. |
| Insight | Explains why the need exists and is currently unmet — the surprising part | Would this have been obvious before research? If yes, you have not synthesised, you have summarised. |
| Constraint (held alongside) | Names the non-negotiable boundaries: regulatory, budget, timeline, technical | Does it constrain the solution space without prescribing a solution? |
The insight is where most statements collapse. Teams write a user and a need, then fill the “because” clause with a restatement of the need. Customers need a faster checkout because checkout is slow. That is a loop, not an insight. A real insight names a tension, a workaround, a compensating behaviour or a belief the user holds that the organisation did not know about.
Compare:
- Loop: Branch customers need shorter queues because queues are long.
- Insight: Branch customers need to know how long they will wait before they commit to joining the queue, because most arrive during a lunch break they cannot extend, and an unpredictable wait is more costly to them than a long one.
The second reframing opens an entirely different solution space — one that includes wait-time transparency, appointment slots and off-peak nudges, and does not require hiring more tellers.
Five formats, and when to use each
There is no single correct template. There are five that recur in practice, each suited to a different kind of project.
| Format | Structure | Best for | Weakness |
|---|---|---|---|
| Point of view (POV) | [User] needs a way to [need] because [insight] | The default. Product, service and journey work after qualitative research | Can feel narrow for systemic or organisational problems |
| How Might We (HMW) | How might we [action] for [user] so that [outcome]? | Opening ideation immediately after a POV is agreed | Too easy to write prematurely, before evidence exists |
| Jobs to be Done | When [situation], I want to [motivation], so I can [expected outcome] | Category-level or competitive problems where the “user” switches between very different solutions | Underweights emotional and social dimensions unless deliberately included |
| Problem statement canvas | Structured fields: user, context, current behaviour, pain, impact, constraint, success measure | Enterprise and regulated environments where a sentence will not survive a governance review | Slower; risks becoming a document nobody reads |
| 5W+H framing | Who, what, where, when, why, how much | Operational and process problems with measurable current-state data | Descriptive rather than generative; needs a POV afterwards |
A practical sequence for most projects: use 5W+H to structure what you already know, run research, synthesise into a POV, then generate three to five HMW questions from it. The canvas is the version you take to a steering committee.
Seven steps to write one
1. Do not write it first. A problem statement written before research is a hypothesis. Label it as such, hold it loosely, and expect to discard it. Teams that skip this labelling spend the research phase collecting confirmation.
2. Gather raw evidence, not summaries. Interviews, observation, service safaris, support-ticket analysis, journey shadowing. The rule that matters: the team writing the statement must have been in the room for at least some of the research. Statements written from a research deck inherit the deck’s assumptions.
3. Synthesise before you frame. Cluster observations into themes. Look for contradictions between what people say and what they do — that gap is almost always where the insight lives.
4. Draft at least five candidate statements. First drafts converge on the obvious. Force volume, then choose. If everyone in the room writes the same statement independently, you have found a shared assumption, not an insight.
5. Interrogate the “because.” For each candidate, ask “why is that true?” three times. If the answer chain terminates in something the organisation already knew, the framing is not yet sharp.
6. Widen and narrow deliberately. Take your best statement and write one version broader (remove a constraint) and one narrower (add a specific context). Ask which version, if solved, would create most value. Wedell-Wedellsborg’s core point applies here: the aim is not to find the “real” problem but to see whether there is a better problem to solve.
7. Pressure-test with an outsider. Someone who was not in the research. If they cannot restate the problem back to you accurately in one sentence, it is not yet written.
Worked examples: before and after
These are illustrative reframings of the kinds of problems that arrive at the start of an engagement. The “before” column is how the problem is usually handed over.
| Sector | Before (as briefed) | After (design thinking problem statement) |
|---|---|---|
| Retail banking | “We need to redesign the account-opening app screens.” | Salaried first-time account holders need a way to know which step will fail before they start it, because they attempt onboarding in short gaps during the working day and treat any unexplained rejection as a permanent no. |
| Public utility | “Customer complaints about billing are up 30%.” | Households on estimated meter readings need a way to reconcile a bill against their own sense of usage, because a bill they cannot explain feels like a dispute they cannot win, and they escalate rather than pay. |
| Employee experience | “Engagement scores dropped; we should run a wellbeing programme.” | Second-year engineers need a way to see what progression actually requires, because promotion criteria are communicated verbally by managers who interpret them differently, and ambiguity reads as favouritism. |
| Healthcare | “Patients aren’t using the follow-up portal.” | Post-discharge patients need a way to ask one small question without booking an appointment, because their real uncertainty arrives on day three at home, and the portal assumes they know which specialty to route it to. |
| B2B SaaS | “Churn is high in the SMB segment. Build more features.” | SMB admins who inherited the tool from a departed colleague need a way to establish what it is currently doing for their business, because renewal lands before they have any evidence of value, and the safest decision under uncertainty is to cancel. |
| Government service | “Uptake of the scheme is below target. We need a campaign.” | Eligible first-time applicants in semi-urban districts need a way to confirm they qualify before assembling documents, because a failed application costs them a day of lost wages and they will not risk it twice. |
Notice what each “after” statement does: it makes the cost of the current experience visible from the user’s side, and it names a behaviour the organisation can verify. Notice also that none of them mention an app, a portal, a chatbot or a campaign.
The scoring test
Before a statement leaves the define phase, score it. Anything below 14 out of 21 goes back for a rewrite.
| # | Criterion | Question | Score 0–3 |
|---|---|---|---|
| 1 | Specificity of user | Could we recruit five people who match this description tomorrow? | |
| 2 | Need is a verb | Is the need an action the user is trying to take, not an object they want? | |
| 3 | Insight is non-obvious | Would this have surprised us before research? | |
| 4 | Solution-free | Does it avoid naming any feature, channel or technology? | |
| 5 | Evidence-linked | Can we point to specific research that supports each clause? | |
| 6 | Actionably scoped | Could a team make meaningful progress on this in one quarter? | |
| 7 | Consequential | If we solve this, does something the organisation cares about move? |
Criteria 3 and 7 are the two most often failed, and they fail in opposite directions. A statement can be beautifully insightful and commercially irrelevant. It can also be commercially urgent and completely uninformed. You need both. This is the same discipline we apply to backlog items through the Evidence Gate in our guide to design thinking for agile software development — nothing proceeds without stated evidence.
From problem statement to How Might We
The POV closes the define phase. The HMW opens ideation. The conversion is mechanical, but the scoping is not.
Take the utility billing example. From one POV you can generate HMWs at three different altitudes:
- Too narrow: How might we redesign the bill layout? (A solution with a question mark. Ideation will produce eleven layouts.)
- Too broad: How might we improve the customer relationship? (Unfalsifiable. Ideation will produce a strategy deck.)
- Right: How might we help a household verify a bill against its own experience of usage, before it decides to dispute it? (Generative and bounded. Ideation will produce meter-reading prompts, usage comparisons, in-bill explanations, pre-emptive alerts and self-service adjustments.)
Generate three to five HMWs per POV at that middle altitude, then let the team vote. If ideation produces variations on one theme, your HMW was too narrow. If it produces things you cannot compare against each other, it was too broad.
Eight mistakes that show up repeatedly
- Writing the statement before the research. It becomes the thing research is used to justify. Countermeasure: write and date the pre-research hypothesis explicitly, so the team can see later whether it changed.
- The stakeholder’s problem in the user’s mouth. “Customers need to adopt the new portal.” No customer needs that; the organisation does. Countermeasure: ask whether the user would recognise the need as theirs.
- A “because” clause that restates the need. The loop described earlier. Countermeasure: three whys, applied to the because clause alone.
- Demographic users. “Gen Z”, “SME owners”, “millennials” — these are marketing segments, not behavioural ones. Countermeasure: describe the user by situation and constraint instead.
- Committee-written statements. Every stakeholder adds a clause; the result is a paragraph that offends nobody and directs nothing. Countermeasure: one named author, feedback from the group, final decision by the author.
- Skipping the constraint conversation. The team ideates freely, then discovers in week six that regulation forbids the whole direction. Countermeasure: capture constraints in writing during framing, and mark each as hard or negotiable.
- Freezing the statement. A problem statement is a best current hypothesis, not a contract. Countermeasure: schedule one explicit review after the first prototype test.
- No success measure attached. The statement is agreed, but nobody has said what would count as movement. Countermeasure: pair every statement with one behavioural measure — a rate, a completion, a time — that would change if you were right.
Six of these eight are organisational rather than methodological. That is consistent with what we see across engagements: teams rarely lack the technique. They lack the operating conditions in which honest framing is safe, which is why psychological safety is so often the real precondition.
Templates you can copy
Point of view[Specific user, described by situation] needs a way to [verb + object] because [insight about why this is currently hard or unmet].
How Might We
How might we [enabling action] for [user] so that [outcome the user would recognise]?
Problem statement canvas — for governance and steering reviews
| Field | Content |
|---|---|
| User | Who, described by situation |
| Context | Where and when this occurs |
| Current behaviour | What they do today, including workarounds |
| Pain and cost | What it costs them, in their terms |
| Business impact | What it costs the organisation, quantified where possible |
| Insight | Why the gap exists |
| Constraints | Hard and negotiable boundaries |
| Success measure | The one behavioural metric that would move |
| Evidence | What research supports each claim above |
Frequently asked questions
What is the difference between a problem statement and a point of view statement in design thinking?
In practice they are used interchangeably. “Point of view statement” is the term from the Stanford d.school tradition and refers specifically to the user–need–insight sentence produced at the end of the define phase. “Problem statement” is the broader term and may include a canvas, a 5W+H framing or a business-facing version. If someone asks for a problem statement in a design thinking context, the POV sentence is what they mean.
How long should a design thinking problem statement be?
One sentence. If it needs two, the second is usually a constraint or a success measure and belongs alongside the statement rather than inside it. Length is a symptom: statements grow when a team has not converged on a single insight and is preserving several.
Should the problem statement include metrics?
Not inside the sentence, but always attached to it. Embedding a target inside the statement (“reduce drop-off by 20%”) anchors ideation to incremental fixes. Pair the statement with one behavioural success measure recorded separately.
Can you write a problem statement without user research?
You can write a hypothesis. You cannot write a defensible problem statement, because the insight clause is precisely the part that research produces. Teams under time pressure should run five to eight interviews rather than none; the marginal value of the first five conversations is far higher than of the next fifty.
Who should write the problem statement?
One named author, drawing on a session with the people who were in the research. Design, product and an engineering or operations representative at minimum. Group authorship produces compromise language; group critique of a single author’s draft produces sharpness.
How do I know if my problem statement is too broad?
Two signals. First, ideation produces ideas you cannot meaningfully compare against each other. Second, no single team could act on it within a quarter. If either is true, add a context constraint — a specific moment, channel or user situation — and re-test.
What if stakeholders reject the reframed problem?
That is usually informative rather than obstructive. It typically means the reframing has moved the problem outside the sponsor’s span of control. Two options: bring the statement back within their authority and note the wider problem as a dependency, or escalate the framing to someone whose remit covers it. What does not work is quietly reverting to the original framing and proceeding.
Where to start
If you take one thing from this guide, take the interrogation of the “because” clause. Everything else in the define phase is scaffolding around that single question: why does this need exist and remain unmet? A team that can answer it with evidence has a problem worth solving. A team that cannot has a preference, and preferences do not survive contact with users.
Write five candidates. Kill four. Attach one measure. Then go and build something.
Humane Design helps organisations frame the problems worth solving before committing budget to solving them. Explore our design thinking learning services, systems thinking programmes and design thinking consulting. You may also find our blueprint for solving complex and modern business problems and our new product discovery process guide useful, or browse our case studies to see reframing applied at scale.
