What does it mean to define the right problem?
Defining the right problem means writing a short, specific statement of what is going wrong, who it affects, and what it costs, and agreeing on it before anyone proposes a design. The statement becomes the test every later idea has to pass.
A useful statement has four parts: a person or group, a situation, a difficulty, and a consequence. “Buyers abandon the form” is a start. “Buyers on phones who reach the address step give up because the keyboard hides the field they are typing in, and the order is lost” is a problem someone can work on. The second version can be checked, and it rules out many ideas that would have felt reasonable.
The Design Council’s Double Diamond describes the same idea in its first diamond, which it says helps people understand, rather than simply assume, what the problem is, before any answers are developed. It is a public frame for this stage of work.
Why is the first statement of a problem often wrong?
The first statement is often wrong because it describes a symptom, a solution someone already has in mind, or one person’s view. All three arrive quickly and sound confident, which is why they get accepted.
A symptom reads like “the dashboard is confusing.” It tells you something hurts without saying where. A hidden solution reads like “we need a chatbot,” which skips the question of what the chatbot is for. A single viewpoint reads like “customers want more features,” when the sentence comes from one meeting, one email, or one loud account.
None of these are bad faith. People describe problems in the terms they can already see, and they usually see them from where they work. The job of the early conversation is to move from the description to the situation behind it.
How do you find the real challenge?
Ask what is going wrong, for whom, and what it costs, then follow the answers back to a cause. Watch what people do as well as what they say, because the two often differ.
Four moves help:
- Ask the three questions. What is going wrong? Who runs into it? What does it cost them, in time, money, errors, or trust? If an answer is vague, ask for a recent, specific example.
- Ask why, repeatedly. Each answer is a claim. Ask why it happens until the answer is something a person could change. Several rounds often reach a cause.
- Look at behavior. Sit with someone doing the task, or watch a recording. A person who says a screen is fine and then hesitates on it has told you something.
- Collect what already exists. Support tickets, search terms, drop-off points, and returned orders each describe a problem in different words. Compare them.
Write what you find in plain sentences. If you cannot say it in two or three sentences, you do not have it yet.
Who should be in the room?
Include the people who live with the problem, the people who will build the fix, and the people who pay for it. Each holds a piece the others lack, and leaving any group out produces a framing with a hole in it.
People who live with the problem know the detail: the workaround, the moment of failure, the thing that looks small and wastes a day. Builders know what is possible, what is fragile, and what will cost more than it appears. People who pay know the constraint and the outcome that counts.
You do not need a large meeting. Three to six people, each in a different role, are enough for a first framing. A single interview can stand in for a group, as long as someone speaks for each viewpoint.
How do you work on it together?
Share the framing in writing, invite disagreement, and agree what a good outcome looks like before anyone draws a solution. Writing makes the framing visible, and visible framings can be corrected.
A short document does the job. State the problem in the four-part form, list what you know and what you are assuming, and describe the outcome in terms someone could observe. “Fewer abandoned orders at the address step” is observable. “A better checkout” is not.
Then ask people to find what is wrong with it. Disagreement at this stage costs an hour. At the prototype stage it costs a sprint, and after launch it costs a rebuild. Treat every objection as information about the problem, and record the answer in the document so the reasoning survives.
If two people disagree on the problem, the work is to find out why, often by returning to a specific example. Do not average the two statements.
Where does the problem become workable?
A problem becomes workable at the point where a large, tangled situation narrows to something a small group can act on this week. Before that point there are too many causes to touch. After it, there is one place to start.
You can recognize that point by how the work feels. The conversation stops circling. People can name the first thing to try and the person to try it with. The statement fits on a page, and nobody needs a diagram to follow it. Reaching it is rarely a single insight. It usually comes from setting aside the parts of the problem that are real but belong to later, and keeping the part that lets you cross from discussion to action.
Be willing to narrow further than feels comfortable. A smaller problem solved well leaves room to take on the next one. A broad problem approached whole tends to produce a plan that nobody starts.
Does it work outside design?
Yes. The questions about what is going wrong, for whom, and at what cost apply to any domain, because they ask about people and situations and not about a subject. The domain is the way in. The method is the same behind it.
I have worked on retail, business platforms, learning products, automotive interfaces, and banking, and the same framing questions applied in each. The vocabulary changed, as did the stakeholders and the constraints. The sequence did not: find the real difficulty, say it plainly, and check it with the people who live with it.
This is why the studio does not limit itself to a sector. A team that knows its field well still benefits from someone who asks the three questions fresh. The people inside the field supply the detail, and the outside view supplies the structure. The studio describes how it works with clients on the studio page.
How do you know the framing was right?
A good framing is specific, shared, and testable. You know it was right when a prototype built from it addresses the difficulty people described, and when the people who live with the problem recognize it in the result.
Test it early and cheaply. Show a rough prototype, a sketch, or a written scenario to two or three people and watch what they do. If they use it as the framing predicted, keep going. If they struggle with something the framing did not mention, the framing was incomplete, and revising it is the right outcome.
Keep the written statement alive. Update it when you learn something, date the change, and note why. Teams that revise their statement openly make better decisions than teams that defend the first one.
If you want help with this stage, an audit or short sprint is one shape this work takes, described under ways to engage. The same discipline of strategy before design applies to websites, and the studio’s product and UX design practice starts here. To talk through a problem you are carrying, email the studio. For related reading, see what AEO is and the practical WCAG 2.2 note.