Most teams sprint from a vague need to a feature concept. Problem framing insists on a structured pause — observe the problem in context, understand why current solutions fail, quantify it — before any solution.
▸ Try the interactive toolProblem Framing is the disciplined process of deeply understanding a user problem before designing any solution. Where most teams move quickly from a vaguely stated need to a feature concept, problem framing insists on a structured pause: observe the problem in its real context, understand why current solutions fail, and quantify its scale before proposing anything.
The premise is that a well-framed problem is most of the solution — and a badly-framed one guarantees wasted effort no matter how good the execution. Framing forces the team to separate the problem from any particular solution, to ground it in observed reality rather than assumption, and to understand why the problem persists despite existing alternatives. That last question is where most of the insight lives.
The who and their context · the problem as an outcome they can't reach (not a missing feature) · why current solutions fail · the scale/frequency that makes it worth solving — all solution-free.
A team that skips framing solves the wrong problem efficiently — and only discovers the misframe after the solution ships and misses.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Jumping to solutions | Work starts on a feature before the problem is understood. | Framing forces understanding of the problem before any solution. |
| Problem stated as a feature | “Users need a dashboard” hides the real underlying need. | Framing separates problem from solution, keeping options open. |
| Assumed, not observed | The problem is imagined from the team's vantage, not the user's. | Framing grounds the problem in observed, real-context reality. |
| Unquantified problems | Effort spent on a rare or trivial problem. | Framing quantifies scale and frequency to justify the investment. |
Don't theorise from the office — see the problem where it actually happens, ideally via contextual inquiry. Real context reveals what users never think to mention.
Frame what the user can't achieve, not what they're missing. “Can't tell if their work is correct,” not “has no validation panel.” This keeps the solution space open.
Users already cope somehow — a workaround, a rival, doing nothing. Understanding why those fall short is where the real opportunity and insight live.
How many users hit this, how often, how painfully? Quantification separates problems worth solving from problems that merely sound compelling.
Capture the framed problem in a sentence or two, solution-free, and check it against evidence. If you can't cite where each part came from, you're still assuming.
A team received a request — “users want a reporting dashboard” — and nearly started designing one. Pausing to frame, they observed users in context and found the real problem wasn't the absence of a dashboard at all: users couldn't tell whether a process had completed successfully, and were building manual workarounds to check.
Framed as an outcome (“can't confirm a process succeeded”) rather than a feature (“no dashboard”), the solution space opened up — and the best answer turned out to be a simple status signal, far cheaper and more effective than the dashboard they'd almost built. Understanding why the current experience failed was what unlocked it.
The deliverable is a short, solution-free problem frame, grounded in evidence — the foundation an OST and experiments build on.
| Element | Weak framing | Strong framing |
|---|---|---|
| Form | Names a feature | Names an unreachable outcome |
| Source | Assumed from the office | Observed in real context |
| Why it persists | Unexamined | Explains why current solutions fail |
| Scale | Unquantified | Sized by frequency & pain |
A well-framed problem is most of the solution. The structured pause feels like a delay, but it's the cheapest possible insurance against the far more expensive mistake of solving the wrong problem well.
The highest-leverage question in framing is “why do current solutions fail?” Users always cope somehow before you arrive — with a workaround, a competitor, or simply tolerating the pain. Understanding precisely why those existing options fall short tells you what a real solution must do differently, and often reveals that the obvious feature isn't the answer. Teams that skip framing don't just risk the wrong solution; they never even see the better one, because they committed to a feature before understanding the problem it was meant to solve.
“They need X” assumes the solution. State the unreachable outcome instead.
A problem imagined from the office misses what real context reveals. Go and look.
This is where the insight lives. Always examine how users cope today and why it falls short.
An unsized problem might be rare or trivial. Quantify before investing.
A framed problem becomes the opportunities branch of the OST (Tool 03).
Observing the problem in real context (Tool 06) is the strongest input to framing.
This is the deeper, research-grounded version of Module 1's problem statement tool.
A solution-free frame keeps the solution space open for the experiments (Tools 15–19) to explore.
Take a feature request you've heard (“we need X”). Rewrite it as the outcome the user can't currently achieve — with no solution named.
Then ask the key question: how do users cope today, and exactly why does that fall short? Write down what a real solution would have to do differently.
If answering “why do current solutions fail?” reveals a cheaper or different answer than the requested feature, you've just seen why framing comes before solutioning.
Related · The Problem Statement →