Problem Framing

A frame is a way of seeing a situation that makes some solutions obvious and others invisible. The same situation can be framed as a design problem, a training problem or a policy problem, and each frame leads to different action. Framing is therefore a design decision with consequences, not a preliminary formality.

Take a crowded train station. Framed as a problem of too many people, the answer is more space or fewer passengers. Framed as a problem of uneven movement, the answer might be signage, scheduling or doors. Framed as a problem of anxiety, it might be information. The situation is the same.

Frames are usually implicit. They arrive in briefs, in the words people use and in the solutions they already prefer. Making the frame explicit is the first step to testing it, comparing it with others and choosing deliberately.

Researchers such as Kees Dorst have argued that experienced designers work by actively reframing, treating the frame as something to create rather than to receive. We build the skill in the modules that follow.

The problem stated in a brief is often a symptom, or a solution in disguise. A client who asks for a new app may really have a problem with customers who cannot find information. A request for a poster may hide a problem of low attendance with several possible causes.

A simple method is to ask why repeatedly. Why do you want an app. Because customers keep calling. Why do they call. Because they cannot find opening times. Why can they not find them. Each answer moves closer to an underlying cause. Five rounds is a rule of thumb, not a requirement.

Look also for the difference between the stated need and the goal behind it. The stated need might be a feature, while the goal is that people trust the service. Designing for the goal may lead to a different feature or no feature at all.

Be tactful. A client has already invested in their framing. Present your reframing as a way to deliver the outcome they want more reliably, backed by evidence from research.

Reframing techniques are deliberate moves to break out of a stuck frame. Change the point of view: how would each user group describe the problem. Change the scale: zoom out to the system or zoom in to a single moment. Change the constraint: drop an assumed limit and see what appears.

Other moves include inversion, asking how to make the problem worse and then reversing, and analogy, asking what other domain has a similar problem. You can also ask what the problem is not, which can expose boundaries you assumed.

Produce several reframes rather than one. Write each as a short statement. Compare them, and notice which ones change the kind of solutions you can imagine. A reframe that suggests the same ideas as the original is not a real reframe.

Test reframes against evidence. A creative frame that does not fit the research is a distraction. The best reframes explain more of what you observed than the original, and open better options.

How Might We questions turn a problem into an invitation. The three words are chosen deliberately. How suggests that a solution exists. Might says that we are exploring, and not yet committing. We says that the work is shared. The format is associated with Min Basadur's work at Procter and Gamble and was widely popularised by IDEO and the Stanford d.school.

A good question has the right width. How might we make sure everyone eats is too broad to guide a session. How might we get the lunch queue under ten minutes using the existing tills is perhaps too narrow. A useful question sits between, such as how might we help students get a hot lunch within their break.

Write many questions from one insight and test them by asking for quick ideas against each. If ideas come easily and vary, the question is productive. If they all look the same, the question is too narrow. If people do not know where to start, it is too broad.

Keep the person and their need in the question. Questions that drop the human centre drift into technical or organisational concerns and lose their guiding power.

Scope is a design decision with consequences. A scope that is too broad gives the team too much to explore and no clear finish. A scope that is too narrow prescribes the answer and leaves no room for insight.

Signs of too broad include vague success measures, endless research and difficulty saying what is excluded. Signs of too narrow include a solution already implied in the statement and no meaningful alternatives. A well scoped problem has a clear person, a clear context and a clear boundary on what is in and out.

Use boundaries in several dimensions: who, where, when and which parts of the experience. Writing an explicit list of what the project will not address is as important as what it will. This protects the team from scope drift.

Scope can and should change as you learn, but changes should be deliberate and recorded. When scope changes, update the problem statement and tell stakeholders, so that nobody works to an outdated frame.

Stakeholders often disagree about solutions because they are quietly working from different problem frames. Surfacing and comparing frames can resolve conflicts that arguing about solutions never will.

A practical method is to ask each stakeholder to write what they believe the problem is, in one or two sentences, without discussing it first. Put the statements side by side. Differences are usually revealing and often surprising to the people involved.

Then work toward a shared frame. Use evidence from research to discuss which statement best explains what is observed, and look for a statement that everyone can accept as a starting point, even if it is not their own words.

Keep the agreed frame visible. Put it on a wall or at the top of a document and refer to it when decisions are made. When someone proposes something that does not fit the frame, you have a clear way to discuss whether the frame or the proposal should change.