Problem Framing in Service Design: How to Define the Problem Before You Solve It
Most service projects begin with a problem that someone has already defined. Calls are too high. The form is too long. The process takes too many days. The statement arrives with a budget and a deadline attached, and the team is expected to start solving it.
In my experience the stated problem is usually real, and it is usually not the best one to work on. Problem framing is the habit of looking at how a problem has been described before deciding what to do about it. This article sets out why that matters, what the best-known example shows, and a five-step way of doing it that fits inside a normal project.
The slow lift
The example most people know comes from Thomas Wedell-Wedellsborg, in a 2017 Harvard Business Review article called Are You Solving the Right Problems? The tenants of an office building complain that the lift is too slow. Asked for solutions, most people suggest the same things: replace the lift, fit a stronger motor, improve the algorithm that runs it. The building managers do something else. They put mirrors next to the lift, and the complaints fall, because people who have something to look at stop noticing the wait.
The part of the story that gets lost is the author's own caution. The first framing was not wrong. A faster lift would probably have worked. His point is that "the lift is too slow" and "the wait is annoying" are two descriptions of the same situation, and each one makes a different set of answers visible. A frame is not true or false, but it decides which solutions you are able to see.
He also reports a survey of 106 senior executives from 91 companies in 17 countries. In it, 85 percent agreed that their organisations were bad at diagnosing problems, and 87 percent agreed that this carried significant costs. It is one survey, and I would not lean on the numbers. The direction is hard to argue with.
Why services are especially prone to this
In a service, problems tend to surface a long way from where they start. The contact centre reports the calls, but the cause may be a letter written by another team, a status message nobody owns or a rule that changed last year. Whoever notices the symptom writes the problem statement, and they write it from where they are standing.
Donald Schön described this in The Reflective Practitioner in 1983. In problem setting, he wrote, "we name the things to which we will attend and frame the context in which we will attend to them". Naming is a choice. Rittel and Webber made a related point ten years earlier about the hardest public problems: "There is no definitive formulation of a wicked problem".
How you explain the problem already contains a view of what the answer should be.
So the framing of a service problem is a design decision. It is just one that is normally made before the designers arrive, by whoever wrote the brief.
Five steps for framing a problem
This is the sequence I use. It is my own working method, not an established model, and it borrows from Wedell-Wedellsborg's practices and from the UK government's guidance on discovery.
→ Write the problem down exactly as it was given to you
→ Ask whose problem it is, and who is missing from that answer
→ Separate what is known from what is assumed
→ Write at least three other versions of the problem
→ Choose one, and say what would prove it wrong
The first step sounds trivial and is not. One of Wedell-Wedellsborg's seven practices is to get people's definitions in writing, because a room can agree on a problem for an hour while holding four different versions of it. The UK guidance on the discovery phase makes a similar move. If you have been handed a solution, it says, "reframe it as a problem to be solved".
The second and third steps are where the evidence comes in. A problem reported by operations is a cost problem until you find out what it is for the person on the other end of the phone. A statement such as "people prefer to call" is an assumption until someone has checked. Two more of the seven practices help here: ask what is missing, and question the objective.
The fourth step is the reframing itself, and the fifth keeps it honest. The Nielsen Norman Group describes a problem statement as "a concise description of the problem that needs to be solved", and advises leaving solutions out of it. I would add one line to that: what you would expect to see if your framing turned out to be wrong.
A worked example
Take an illustrative brief: calls to the contact centre are too high. As given, the problem belongs to operations and the obvious answers are more staff or a chatbot.
What is known is that call volumes rose after a new online application was launched. What is assumed is that people would rather phone than use it. Three other versions might be these. People phone because the confirmation message does not say what happens next. People phone because the status page shows the same words for three weeks. People phone because the service has no way of telling them about a delay.
Each version points to a different piece of work, owned by a different team. Suppose the call notes support the second one. The chosen problem becomes: people cannot tell whether their application is moving. It would be proved wrong if callers turned out to be asking about something else entirely.
Two tools to use with care
The Five Whys, which comes from Taiichi Ohno and the Toyota Production System, is the best-known way of getting beneath a symptom. It is worth knowing its limits. Alan Card, writing in BMJ Quality and Safety in 2017, argued that it forces a single causal path and assumes there is one root cause. Services usually have several.
How might we questions are useful once a frame has been chosen. Used earlier, they give a badly chosen problem a more attractive sentence.
Knowing when to stop
Framing is not an invitation to question the brief for ever. A day spent on these five steps at the start of a project is usually enough to change its direction or to confirm it.
Sometimes the result is that the problem is not worth solving. The UK guidance is clear that this is acceptable: "It's not a failure to stop at the end of the discovery phase".
The problem you are handed is a first draft, and it deserves the same editing as anything else you would put your name to.
Template: the companion resource for this article is a duplicable problem framing worksheet, with the five steps, a table for separating what is known from what is assumed and space for three reframes.
Join The Curious Society Learning Path
Explore practical learning resources designed to help you build deeper knowledge, stronger judgement and real-world capability.
