Definition
Problem framing is the act of deciding, in writing, what problem a piece of work is actually addressing — for whom, in what situation, and what would count as better. A frame is not a summary of a request. It is a boundary drawn around a solution space, and every solution a team can reach lies inside it. Frame the work as "users want a bulk export button" and the team will design a button. Frame it as "people need their data somewhere else in order to finish a task we do not support" and the team can consider export, an integration, or supporting the task directly. Both frames are truthful descriptions of the same complaint. They lead to different products, different costs, and different outcomes.
Why It Exists
Framing exists as an explicit practice because teams consistently solve the first problem they are handed, and the first problem handed to them is usually a symptom described by whoever noticed it. A sales lead reports lost deals and proposes a feature. Support sees repeated tickets and proposes a tooltip. Each has seen something real and each has already compressed it into a solution. Without a framing step, that compression is never examined, and the team's entire range of options is set by someone who was not trying to set it. Framing also protects against a quieter failure: work that is busy and well-executed but cannot be evaluated, because nobody wrote down what success would look like before building began.
Examples
- →"Add a dashboard" reframed as "managers cannot tell whether their team is behind until the weekly meeting" opens options including alerts, a digest email, or changing when data is captured.
- →"Users abandon signup at step three" reframed as "people are asked for a company tax number before they know whether the product works" points at sequence rather than form design.
- →"Increase engagement" is a business goal wearing the costume of a problem statement; it names no person, no situation, and no outcome anyone would want for themselves.
- →"Reduce support tickets about billing" reframed as "customers cannot predict what they will be charged" moves the work from the help center to the pricing page and the invoice.
History
The idea that problems are constructed rather than found has a long lineage in design thinking, where ill-defined problems were distinguished from the well-defined problems of engineering. Practitioners noticed that expert designers spent disproportionate effort questioning the brief. Two strands made this operational. The Design Council in the United Kingdom introduced the Double Diamond in 2005, a simple diagram of two paired divergences and convergences: explore the problem widely, define it narrowly, explore solutions widely, deliver one. Separately, Clayton Christensen popularized framing demand in terms of the job a customer is trying to get done, which shifted attention from product attributes and customer demographics toward the situation and the progress someone is attempting to make. Both remain widely taught because both are procedural, not merely philosophical.
In Modern Design
In current product work, framing is usually a short written artifact — a problem statement, a brief, a one-pager — reviewed before design begins. Good ones name the person, the situation, the current outcome, the desired outcome, and what will be measured. They deliberately exclude the solution. Teams borrow the Double Diamond's discipline of diverging before converging, though in practice the first diamond is the one most often skipped under delivery pressure. Research feeds the frame: interviews, support logs, session recordings, analytics funnels. Jobs-to-be-done interviewing is common for surfacing the situation rather than the stated preference. The recurring modern failure is the frame that quietly encodes an existing roadmap decision, so the divergence is theater and the convergence was finished before the work started.
Real-World Example
A team is told that users are not inviting colleagues, and is asked to redesign the invite modal. Redesigning the modal is plausible work: it is dated, it has three fields, it could be clearer. Instead the team interviews fifteen people who created an account and never invited anyone. The pattern that emerges is not confusion about the modal. It is that inviting a colleague exposes an unfinished, messy workspace, and people are waiting until their setup looks respectable — which, for most of them, never arrives. The frame changes from "the invite flow is unclear" to "people will not invite others into work they are not yet proud of." That frame permits entirely different answers: templates, a private draft state, an invite that shares one artifact rather than the whole workspace. The modal was never the problem.
Key Principles
- →Write the frame down before designing, and name the person, the situation, and the outcome that would count as better.
- →Separate symptom from cause; a repeated complaint is evidence, not a diagnosis.
- →Reject problem statements that smuggle in a solution, including ones phrased as a missing feature.
- →Diverge before converging, and treat the first plausible framing as a hypothesis rather than a conclusion.
- →Be honest when a frame serves only the business, and say so rather than dressing a growth target as a user need.
- →Keep the frame revisable; evidence gathered during design is the most common reason to restate the problem.
Why it matters
Framing is where most of the leverage in a project sits, and it is nearly free compared with building. A week spent restating the problem can remove a quarter of engineering work, or redirect it toward something that changes an outcome rather than a screen. It is also the point at which a designer's ethics are most usable. A frame such as "users cancel too easily" licenses friction in a cancellation flow and will produce dark patterns downstream almost automatically. A frame such as "people cancel because they stopped getting value in month two" licenses a different investigation entirely. Both frames could be written by the same team about the same data. Choosing between them is a design decision with consequences long before anyone opens a design tool.
Then vs Now
Then
A brief arrived from a client or a department and was treated as a given. The designer's task began after the problem had been stated, and questioning the brief risked appearing evasive rather than rigorous.
Now
Restating the brief is an expected part of the work, supported by research, analytics and frameworks such as the Double Diamond. The risk has inverted: teams are now more often criticized for building the stated request without examining it.
Try it yourself
Take a complaint you have made about a product this month and write it as a feature request in one sentence. Then write three progressively wider reframings of the same complaint: one that names the task you were trying to complete, one that names the situation you were in when it failed, and one that names the outcome you actually wanted. For each frame, list two solutions it makes available that the previous frame did not. You will usually find that the widest frame admits a non-obvious answer, often involving removing something rather than adding it. Finally, mark which of your frames a company optimizing for revenue would be most comfortable with, and which one would be hardest to fund. That last question is the one practitioners face constantly.