The Problem-First Design Process

"The greatest challenge to any thinker is stating the problem in a way that will allow a solution.” Bertrand Russell

I want to be rich. I want to be more mindful. I want to start my own company. These all seem like reasonable goals but when stated in this way they are almost impossible to achieve. Why? Because they are not stated in a way that allows for a solution. They are, in fact, a statement of desire and not a set of requirements that would allow anyone to achieve the stated goal.

In this article, I propose a design process that focuses on understanding the problem and, in so doing, it's requirements--a process I call "problem first." If you understand the problem, making the solution will be simple. 

The following exchange between founder of Patagonia Yvon Chouinard and his head of design, as retold in his book “Let my People go Surfing”, shows a useful example. As they discuss how to make the best product, one person states a goal as a desire that is impossible to achieve, while another begins to state requirements that will allow for the development of solution to meet their goal. 

“Early in our history our chief designer for many years, Kate Larramendy, issued me a challenge. She said that we didn’t make the best clothing in the world, and moreover if we did, we’d go out of business."

“Why?” I asked her.

“Because the best shirt in the world is Italian,” she said. “It’s made from hand-woven fabric, with hand-sewn buttons and buttonholes, and impeccably finished. And it costs three hundred dollars. Our customers wouldn’t pay for that. “

I asked “What would happen if you threw that three-hundred-dollar shirt into your washer and dryer?”

“Oh, you’d never do that. It would shrink. It has be dry-cleaned.”

To me a shirt that has to be treated so delicately has diminished value.  Because I think ease of care is an important attribute, I would never own a shirt like that, much less make and sell one.”
—Yvon Chouinard (2006), Let My People Go Surfing

This example shows that instead of stating a goal for his perfect shirt Chouinard states the problem as different requirements which allow for the best outcome for his particular set of consumers.

Today the approach to problem solving in design is both linear and iterative. Yet, these methods allow very little room for clearly stating the problem and reframing the requirements / strategies required to create something great.

This diagram shows a popular method of production called “waterfall”, a small amount of time spent up front stating the problem while the rest of the process is spent trying to create a solution to this problem statement. Unfortunately if the problem isn’t stated correctly at the beginning, many issues occur during the production process, leading to pretty mediocre results. This style also manages the process with hard deadlines and sets of milestones that have to be met.

In reaction to this, the “agile” process was created,
which works this way: 

This process is the opposite of waterfall; it looks to iterate quickly through all parts of the project in quick 2-3 week sprints. This is meant to allow for more feedback in the design process and creates a more reactive process as new information is learned. But, as with the waterfall model, agile is also a managerial process; in each structured 2-3 week sprint, a number of targets must be met. Even though things can change due to new information, the mentality is still focused on production. We are making something, just quicker.

All processes have their strengths and weaknesses. The biggest weakness of either “waterfall” or “agile” is their focus on creating a solution immediately. By its nature, this causes a narrowing of thinking and exploration which can lead to unforeseen issues in the production process. 

Even more problematic, in both processes the work of framing the problem is only a small part of the overall process and is attached to the idea of production which means that the thinking will be narrow and be influenced by subsequent stages. This leads to a process which is only 20% stating the problem and 80% creating a solution.

What’s an alternative? 
The “problem first” method I suggest follows a different path, spending the majority of the time on stating the problem, rather than on creating a solution. I have found from long experience that, even with the best of intentions, predetermined milestones and assumptions, and a focus on solution, can only create a climate of narrow thinking where milestones are all-important and the problem at hand is too often neglected.

This is what the problem-first process looks like:

I assume that to many people this will not look like a process at all; to some degree that is the point. Without all the artificial milestones and deliverables, this process allows for free exploration of the problem space. Many of the usual activities will be done--brainstorming, sketching, research, interviews etc.--but all with the goal of each week stating the problem, requirements and assumptions in a clearer way.

What do I mean by stating the problem? Well, this will also look familiar to anyone who has designed anything before: making artifacts of possible solutions, doing and recording research with consumers and businesspeople, stating assumptions about the market, creating metrics for success. Yet, these are all done with the aim of stating the problem and not making a solution.

Once the team is happy with the problem statement, making the solution is a natural process because they understand the problem. They have not had the burden of artificial deadlines; the problem statement itself is a clear guide to show them whether the design solution they are creating meets the needs at hand. While this sounds like magic I can assure you it’s not. It's hard work, but it is work with a focus and a clear idea of :

What are we building?
Why are we building it?
Who are we building it for?

When you can answer these questions with confidence you will be on the right track to making something valuable and innovative.