Problem Framing

Concept of the skill

Reframing a stated problem before solutions are committed — surfacing assumptions, separating symptoms from root needs, converting feature-request briefs into problem statements, and aligning a team on the problem before design proceeds.

Coverage

Problem framing covers the practices that move a team from a vague request, complaint, or feature brief to a sharply articulated problem statement that does not pre-commit to a solution. Core techniques include the How Might We reformulation (popularized by IDEO and the Stanford d.school), the point-of-view statement (<user> needs <need> because <insight>), jobs-to-be-done problem articulation (Clayton Christensen, Tony Ulwick), assumption mapping to surface what a team is taking on faith, and 5 Whys style symptom-to-need laddering when a presenting issue masks a deeper one. The UK Design Council's Double Diamond names this entire phase Discover → Define, and treats the transition from divergent discovery to convergent problem definition as a distinct skill from solutioning.

The practice draws a hard line between three things that beginners conflate: a symptom (an observed irritant), a problem (a structured statement of an unmet need), and a solution (a proposed intervention). A brief that says "add notifications" is a solution; "users miss time-sensitive updates" is a problem; "I keep forgetting to renew my license" is a symptom. Reframing techniques surface which level the team is operating at and explicitly demote solutions back to problems before ideation begins.

A separate body of methods addresses problems that are already solutions in disguise. Tim Brown's HBR essay (2008) and the Stanford d.school bootleg argue that the biggest single failure mode in human-centered work is solving the wrong problem confidently. Tools like the 5 Whys, assumption laddering, and the inversion technique (asking what would make the problem worse) are designed to expose where a brief embeds an unexamined causal claim.

Philosophy of the skill

Problem framing exists because solutions are cheap to imagine and expensive to build — and the cost of building the wrong solution dwarfs the cost of spending another day on the question. The discipline insists that ambiguity at the top of the funnel is not a bug to be eliminated by acting quickly; it is a signal that more discovery is needed. A well-framed problem is narrow enough to act on, broad enough to admit several solutions, and honest about which user it serves.

The practice is opinionated about language. "How might we" is not interchangeable with "how do we" — the conditional voice keeps possibility open. A point-of-view statement that names a solution ("users need a dashboard") has framed nothing; one that names a need ("users need to know whether they are on track without opening the app") has. Framing rewards precision over poetry: every word in the problem statement should be defensible against the question "what evidence supports this word being here?"

Verification

• The problem statement can be read aloud in one sentence without naming a specific solution, feature, or technology.
• At least one assumption in the original brief has been promoted to an explicit, testable claim — not silently accepted.
• A reader who did not attend the framing session can identify the user, the need, and the insight that motivates the need.
• The team can articulate at least two materially different solutions that would satisfy the problem statement — confirming the frame is not solution-shaped.
• The "5 Whys" or equivalent laddering has been applied at least once to the presenting symptom, and the team agrees the chosen level is the right altitude to act on.
• The how-might-we is neither too narrow (admitting only the obvious solution) nor too broad (admitting solutions the team cannot ship).

Do NOT Use When

• A specific software component is failing and the question is "where in the code does this break" — use problem-locating-solving for bug localization.
• A production incident is in progress and the team needs to triage a failure — use diagnosis.
• The problem is fully understood and the next action is generating solution concepts — go directly to ideation.
• There is no research evidence yet about the user or context, only opinions in the room — gather primary input first via user-research, then return to framing with data.
• The task is decomposing a single known task into UI steps — use task-analysis instead of journey-spanning framing.
• The "problem" is an internal engineering modeling exercise (event flows, bounded contexts) — use event-storming or conceptual-modeling.