Research leaves you with transcripts, notes and half-formed observations. Framing is the work of turning that pile into one problem a team can act on — specific enough to argue with, open enough that more than one solution could answer it.
Skip it and the pile becomes a feature list. Someone remembers a vivid quote, a solution gets attached to it, and a quarter disappears into building the thing without anyone writing down what problem it solves. When it underperforms, nobody can explain why, because nobody agreed what success would have looked like.
The tools here — personas, empathy maps, jobs-to-be-done, problem statements, How Might We questions — are all compression. They reduce many hours of observation to something a team can hold in its head and point at.
Personas
A persona is a type of user you kept meeting, written down so the team stops arguing from anecdote. Build it from the behaviour that repeated across interviews — what people were trying to achieve, what they do now, where it goes wrong — not from age, income and a taste in coffee.
Three or four is usually the ceiling. Past that nobody can keep them straight, and a persona the team cannot name is never consulted.
The failure mode is the persona that cannot lose an argument. If every feature anyone proposes is something your persona would love, you have written a mirror rather than a user. A good persona also tells you who you are not building for, and that half does most of the work.
- What are UX personas and what are they used for? — article
- What are personas and why should I care? — video
Empathy Maps
An empathy map is four quadrants for one person in one situation: what they say, what they think, what they do, what they feel. Fill it from your notes — real quotes, observed actions — not from a workshop where six people guess in unison.
The value sits in the contradictions. Someone tells you the export works fine, and then you watch them retype the numbers into a spreadsheet by hand. Says and does have come apart, and the unmet need lives in that gap.
One map per persona per situation. A map covering "our users" averages several different people into a single person who does not exist, and an average is the enemy of a usable insight.
Jobs-to-be-Done
People do not buy products, they hire them to make progress in a situation. The job is the progress — get the team's decisions somewhere I can find them on Monday — not the feature that happens to deliver it today.
Write a job as situation, motivation and outcome: when a client call ends, I want to capture what was agreed, so I am not reconstructing it from memory a week later. No demographics. Twenty-four-year-olds and fifty-year-olds hire the same job.
This framing exposes your real competition. The job of holding on to what was agreed currently goes to a photo of the whiteboard, a message someone sends to themselves, and the assumption that it will come back to them. If your competitive analysis only lists companies with a funding round, you have not found what you are actually up against.
- Jobs-To-Be-Done Framework — article
- What is Jobs to be Done — video
Problem Statements
A problem statement names one user, the thing they are failing to get, and the reason they are not getting it. "Freelance designers lose billable hours reconstructing what they worked on, because they log time in whatever happens to be open." That is arguable — someone could bring data that disproves it — which is exactly what makes it useful.
The smuggling test: read it back and ask whether it already contains its own answer. "Users need a better onboarding checklist" is not a problem, it is a feature request in disguise. The problem underneath is that people finish setup without ever reaching the thing they came for.
Two sentences. If it runs to a paragraph you are describing a space, not a problem, and spaces cannot be solved.
- Design Problem Statements: What They Are and How to Frame Them — article
- How to craft better product problem statements with the SMART framework — video
How Might We Questions
Take the problem statement and turn it into a question that invites more than one answer. "Freelance designers lose billable hours reconstructing what they worked on" becomes "how might we capture the work while it is still happening?"
Scope is the entire skill. Too broad — "how might we delight our users" — and the room produces nothing you can build. Too narrow — "how might we add a timer to the toolbar" — and you have written a ticket and called it ideation. Aim for the altitude where five genuinely different answers are possible.
Write five or six per problem, pitched at different levels, and keep the ones that make people lean forward. If everyone in the room answers your question the same way, the question was a solution wearing a question mark.