Definition
Problem understanding is the work of investigating a need before attempting to meet it. It means identifying who is affected, what they are actually trying to accomplish rather than what they asked for, what has already been tried and why it did not hold, and which constraints will shape any possible answer. It is distinct from problem-solving, which comes afterward and is usually the part people enjoy. The output of this stage is not a sketch. It is a statement of the problem precise enough that someone could disagree with it. A problem you cannot state in a sentence that could be wrong is not yet understood; it is still a feeling.
Why It Exists
Design effort aimed at a misunderstood problem is wasted no matter how skillfully it is executed, and the waste is invisible until very late. The classic failure modes are consistent across every discipline. A team builds a faster way to do something nobody needed to do. A team treats a symptom — people miss the deadline — without touching the cause — nobody knows the deadline exists. A team accepts a stakeholder's requested solution as if it were a statement of need, and delivers exactly what was asked for to universal disappointment. Understanding the problem first is the cheapest possible insurance, because changing your mind about a problem costs a conversation and changing your mind about a built product costs a quarter.
Examples
- →A hospital redesigning a form should first ask why staff work around it, not simply make the existing fields prettier.
- →A city adding parking may be answering a demand problem that better transit or pricing would resolve more cheaply.
- →A team asked for more features should first check whether the existing features are even discoverable.
- →A furniture maker facing high returns should study how the chair is used at home before redrawing its shape.
History
Formal problem framing grew up alongside twentieth-century engineering and operations research. Herbert Simon's 1969 book 'The Sciences of the Artificial' defined design as devising courses of action aimed at changing existing situations into preferred ones — a definition that quietly makes describing the existing situation accurately into the first obligation. Simon also introduced the idea that real problems are ill-structured: they do not arrive with a clear goal state or a complete list of options. Later design research, notably Horst Rittel's account of 'wicked problems', pressed further, arguing that for many social and organizational problems the formulation of the problem and its solution are inseparable — you only learn what the problem was by attempting an answer.
In Modern Design
Contemporary product and UX practice usually opens with a discovery phase before any solution is drawn: interviews, observation of real use, support-ticket analysis, and quantitative data about where people drop out. Techniques such as repeatedly asking why a problem occurs are used to walk from symptom toward cause. The framing is often written down deliberately — as a problem statement, a job to be done, or an explicit hypothesis — so that it can be argued with later and so that the team can tell whether they were right. The discipline is less about any single method than about resisting the pull toward the satisfying part of the work too early.
Real-World Example
Perceived waiting time is a well-documented case of reframing. Systems that feel slow are often not slow in any measurable sense; the user simply has no evidence that anything is happening. The engineering framing — make it faster — is expensive and has a floor. The design framing — make the wait legible and tolerable — produced progress bars, skeleton screens, optimistic interfaces that show a result before the server confirms it, and the practice of using idle time for something the user values. Related work in service design showed that occupied time feels shorter than unoccupied time. Same underlying delay, different problem statement, radically cheaper and more effective answer.
Key Principles
- →Understanding the problem precedes designing the solution, and the two use different skills.
- →Ask who is affected and why, not only what symptom is visible.
- →Treat a requested solution as evidence about a need, never as the statement of the need itself.
- →Repeated 'why' questioning walks a team from symptom toward root cause.
- →Write the problem down in a form specific enough that someone could argue it is wrong.
- →A well-executed answer to the wrong problem is still a design failure.
Why it matters
This stage is where the largest and cheapest gains in any project live. Every hour spent getting the problem right saves many hours of building, and unlike most design skills it requires no craft — only discipline and the willingness to be temporarily uncomfortable without a solution in hand. It is also the part of the work that earns designers a seat in strategic conversations. Anyone can be handed a specification and execute it. The practitioner who can show that the specification answers the wrong question, with evidence, changes what the organization does rather than how it looks. That is the difference between being a supplier of artifacts and a participant in decisions.
Then vs Now
Then
Design briefs arrived as specifications: build this object, with these dimensions, for this price. The problem had already been defined by someone else, and the designer's contribution began at the point of execution.
Now
Discovery is treated as part of design itself. Teams interview users, observe real behavior and write explicit problem statements before drawing anything, because in software the cost of building the wrong thing well is enormous.
Try it yourself
Recall a recent frustration with an object, service or app. Write it down as a single sentence. Then ask why it happened, and write the answer. Ask why of that answer, and repeat until you have gone five levels deep or reached something you genuinely cannot explain. Notice where the chain shifts from a property of the thing to a property of an organization or an incentive — that shift is usually where the real problem lives, and it is usually not where the first sentence pointed. Finally, write one new problem statement based on the deepest cause you reached, and compare it with your original.