Problem Framing

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

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?"