Problem Framing
Turn a pile of research into one statement narrow enough to design against and wide enough to allow more than one answer.
Definition
Framing is the step between discovery and design. It converts observations into a stated problem, a defined audience, known constraints and a measure of success, so that later disagreements are about evidence rather than taste.
Expert heuristic. A review criterion developed by practitioners. Useful and widely taught, but evaluated by judgement rather than measurement.
On this plate
Reach for this when
- Moving from research into design.
- A project keeps changing shape between reviews.
- Two teams are solving what they each believe is the same problem.
- A brief has arrived naming the solution rather than the problem.
Common mistakes
- A solution smuggled into the problem statement.
- Constraints assumed rather than confirmed.
- No measure, so success is decided by whoever is most senior in the room.
- Reframing repeatedly to avoid committing, which looks like rigour and functions as delay.
Writing the frame
- 1
State the observed behaviour
What people actually do now, with the evidence attached. Not what they say they want, and not a feature.
- 2
Name who has the problem
A specific group with a shared situation. 'Users' is not an audience.
- 3
Say why it matters
The consequence for the person and the consequence for the business, separately. If only one exists, the work is weaker than it looks.
- 4
List the real constraints
Legal, technical, brand, timing. Constraints narrow the space productively. Fictional constraints narrow it destructively, so check which is which.
- 5
Define done
One measure that would move if this were solved, and a level at which you would stop.
Frames that fail, and their repair
| Weak frame | Why it fails | Stronger |
|---|---|---|
| Users want a dashboard | A solution disguised as a problem. | Account managers cannot tell which of their 40 clients needs attention this week. |
| Improve onboarding | No audience, no behaviour, no measure. | Half of new teams never invite a second person, and single-person teams churn within a month. |
| Make the product easier | Unfalsifiable. | Support handles 200 password reset requests a week, mostly from one sign-in path. |
Testing a frame before you commit to it
Do
- State who has the problem, how often, and what it costs them.
- Say what you would accept as evidence that the problem is solved.
- Name at least two different solutions the frame permits.
- Write down what is out of scope, so the frame can be held to.
Do not
- Smuggle the solution into the statement, as in users need a dashboard.
- Frame around an internal metric with no user behind it.
- Write a frame so broad that no result could contradict it.
- Leave the frame unsigned, so nobody can be asked about it later.
In practice
- i.
One sentence, two projects
How much the wording decidesUsers cannot find the export button and users cannot get their data into their reporting tool are the same complaint framed at two altitudes. The first buys a week of navigation work; the second might buy an integration, and only one of them ends the support tickets.
Local chart
FLOW·007 · Region IV · Grid H2
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Principles behind this
The reasoning this solution is an application of.
- Product ThinkingMOD·002 · Mental model
Often used with
These usually appear in the same screen or the same decision.
- Design BriefTPL·010 · Template
Related concept
Connected closely enough to change how you apply this.
- Competitive AnalysisRES·019 · Research method
- Jobs to Be DoneRES·018 · Research method
- Research SynthesisRES·014 · Research method
- DiscoveryFLOW·004 · Workflow
- IdeationFLOW·008 · Workflow
- Measuring UXFLOW·011 · Workflow
- Prioritising Design WorkFLOW·006 · Workflow
- User FlowsFLOW·009 · Workflow