Design is not Problem Solving

We need a more realistic definition of what designers actually do

I don’t believe in solutions.

What do I mean by that exactly?

I think people use the term ‘solution’ far too often without thinking about what it really means. Unless you work in a mathematical field with a defined set of parameters, you’re probably not solving much at all.

I’m a designer by trade, and most of us in the design industry proclaim ourselves to be ‘problem solvers.’ In fact, we use the term liberally. New mocks for a mobile app? They’re each presented as ‘solutions.’ Developed a new product? The common claim is that it ‘solves a problem.’

I’ll admit that I used to be in the ‘designers-are-problem-solvers’ camp. But over time, I’ve come to realize that this a very euphemistic term for our process and our end products. To say something is a solution means that something has addressed a problem completely. It means that the product or service is final. It’s 100% complete. There is no way to poke holes in it, let alone sink it. I don’t think any of us can claim that with our work. I believe our work is relative and never absolute.

An Important Issue

So why do I feel the need to bring this up? Is it because I’m a cynic? Is it because I want to rain on the design parade? Not at all. Rather, my goal is the opposite: I want to be more realistic about what designers actually do.

Yes, this is an issue of semantics. I think it’s an important issue for anyone working with problems, especially designers. Defining the outcome accurately sets more reasonable expectations for our work. Framing our design work as a response instead of a solution is important for all involved. It’s critical for us designers to know our own process, it’s relevant for the people that we design with, and in the end, it’s significant for those who will interact with what we create.

So if designers don’t ‘solve problems,’ then what do I believe we actually do? The short answer: we change things, responding to problems.
The longer answer: read on.

The Problems With Problems

To get to the bottom of this topic, we’ve got to get a little theoretical first. Lucky for us, a few great thinkers have already spent plenty of time dissecting this issue.

Problems Can Be Wicked

Design is about working within problems. The discipline deals with more straightforward problems (composing a page layout) and more complex ones (developing a new transportation system). But to universally define design as ‘problem solving’ is a bit hasty.

Design theorists Horst Rittel and Melvin Webber wrote about problems at length in their classic strategy piece Dilemmas in a General Theory of Planning. In this work, they introduced the idea of wicked problems, those which deal with social, economic, and environmental issues so complex and unpredictable that they can’t really be defined properly. With wicked problems, Rittel and Webber propose that a solution is almost circular to the problem itself:

“To find the problem is thus the same as finding the solution; the problem cannot be defined until the solution has been found.”

This idea has radical consequences for the term ‘solution.’ It means that we can’t predict the depth and breadth of the problem space until we’ve exhausted all of our potential responses and found the one that works. Think about it… you’d need to design all possible forms of your artifact to fully understand the problem itself. Seems pretty unrealistic.

I’ll admit that most designers don’t deal with the complexity of wicked problems on a daily basis. However, I’d argue that most of the principles that exist for wicked problems apply to common problems as well.

For instance, Rittel and Webber describe wicked problems to have issues with narrow time constraints, inaccurate test evaluation, limited financial considerations, and so on. Sound familiar? Designers face these challenges on just about every project.

Here’s the point: to fully solve a problem, we would need to know all possible outcomes of our process, conduct our work in a limited amount of time, and use a finite amount of money. These constraints seem pretty impossible in regard to any project.

There’s one more important point that Rittel and Webber make. They pose the idea that problems can often be considered a symptom of another problem. That means that problems are nested within other problems by nature. How can this be? Let’s break it down a bit further.

Problems Are Connected

Here’s something that we designers often forget: none of the things we design are isolated by themselves. We design things that exist in a larger system and that system is very complex.

Christopher Alexander explains this idea in his book titled Notes on the Synthesis of Form. He illustrates how systems have “a series of subsystems, all interlinked, yet sufficiently free of one another to adjust independently in a feasible amount of time.” In other words, the system we design within is interconnected and always changing.

The key takeaway here is that what we’re working on probably has more interdependencies than we think. Often times, our proposed ‘solutions’ can actually lead to more problems. The new product, experience, or service we introduce is connected to other things in an elaborate, relational fashion, and it can have drastic effects on those things as well.

Bigger Problems

As an example, let’s take a design innovation we’re all familiar with: the mobile phone. When they were introduced commercially in the early 1990s, cell phones attempted to address the problems associated with the landline telephone (only stationary locations, cost of cable infrastructure, issues in emergency communication, etc.). As we know, mobile devices have advanced well-beyond the simple task of making phone calls and have become a huge part of our everyday lives.

However, this amazing invention has also brought about a number of undesired consequences. The mobile phone has unfortunately caused the following problems:

• Introduced dramatic changes to social interaction patterns (source)
• Increased traffic mortality rates from texting while driving (source)
• Created a potential cancer risk from exposure to electromagnetic radiation (source)
• Instigated human rights violations from its material supply chain (source)

I’m willing to bet that those who brought the mobile phone to fruition probably didn’t foresee these issues playing out on a global scale. It may have addressed a few big problems, but it created a whole mess of others.

The lesson here is that what we design and introduce to the world has systematic repercussions. The initial design and successive iterations did not — and could not—take into account all possible outcomes. The same could be said for other large technological innovations in the past (automobile, airplanes, etc.) as well as whatever we’ll design and introduce into our culture in the future.

Smaller Problems

This lesson isn’t limited to only large technological leaps. The same systematic issues exist in smaller, everyday design problems we face. Here are a few common design scenarios and some potential consequences:

• Scenario: Changing a website navigation
  Potential Consequences: The placement affects page hierarchy, which could affect click-through rates, which could affect revenue.
• Scenario: Redesigning a brand identity
  Potential Consequences: Updating styles or colors affect marketing efforts, which could affect perception among new and existing consumers, which could affect quarterly sales projections.
• Scenario: Designing a UI style guide for a new app
  Potential Consequences: The button size affects the written content, which could affect user understanding, which could affect initial adoption rates.

In each of these scenarios, there are multiple ways of approaching the problem. There are also many unique ways to respond during the process, each with different outcomes. But there is not one perfect way of ‘solving’ the problem in the end.

What Designers Actually Do

The realization that there may not be one fail-safe solution doesn’t mean we should stop responding to problems. It means we need to think about what we’re really doing when we design. Sure, we’re addressing problems, but there’s more to it than that.

Design as Change

In his classic book titled Design Methods, John Christopher Jones proposes that all design is concerned with change:

“To design is no longer to increase the stability of the man-made world: it is to alter, for good or ill, things that determine the course of its development.”

That’s a lot of pressure. But would we designers have it any other way? The changes we deem necessary to make are often a result of problems that exist within our world’s larger system. In essence, the ‘design as change’ definition is just a more realistic version of the ‘design as problem-solving’ argument.

If you think that ‘design as change’ is too lofty of a definition to apply to what you do, I challenge you to think again. Here’s why: we’re all analytical beings who desire to change something in our world in order to understand it better. These changes — be it for a website or a communication device — can have a lasting effect for better or worse.

And if we’re going to put something in the world (on screen or in the physical environment), we should try our best to predict the effects of our design.

Appropriate Responses

As designers, I believe that it’s our responsibility to choose the option that best addresses the issue at hand, but has the least negative impact upon the rest of the system as a whole. As I stated above, we change things when we design, and we have to be aware of the intricate relationships involved in that change.

We should understand that problems — no matter how big or how small — are really complex. Instead of trying to find ‘solutions’ to problems, we should think about creating responses to problems.

How do we do that? We need to start by accepting the limitations that problems afford us. If we position our work as a response, we’re already setting clearer expectations and acknowledging constraints. As famous designer Charles Eames once said,

“Design depends largely on constraints… Here is one of the few effective keys to the Design problem: the ability of the Designer to recognize as many of the constraints as possible; [their] willingness and enthusiasm for working within these constraints.”

Once we specify constraints, we have a rough outline of the problem space to work within. And just as Rittel and Webber explained, understanding the problem gives us a much better idea of how to respond.

Empowering the Design Process

The idea of framing our work as a response instead of a ‘solution’ should be empowering for our design process. By acknowledging our limitations, we actually create the space to iterate and test our design work — because we know it can’t be perfect. We can evaluate the performance of the most approporiate responses with research, and then rework our initial ideas to better address the problem. The sponsors of our work will be more confident in what we deliver and so will we.

As I mentioned at the beginning, this is a matter of semantics. I believe that our definitions influence our experience. Small tweaks to our approach can yield big results. If we look to respond to problems instead of trying to ‘solve’ them, I believe our design process will be improved and our end product will be improved as well.