The Problem with Problem Solving

If you don’t know me, I currently work in R&D for a major automotive OEM. My job most often involves creating new product concepts that convey how humans will interact with technology in the future, and I work with my team to help bring these ideas to life. The reason I bring this up is because as a result of this experience, I often work in less conventional ways, simply because conventional means don’t always work. I recently tweeted a thought that occurred to me and due to the limitations of Twitter, I felt like this subject was perhaps something worth digging a little bit deeper. So let’s begin.

What is the problem with “Problems”?

“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

— Abraham Maslow

In design, we always want to be working on things that “matter”, and drawing a distinction like “problem solving” helps elevate the design practice beyond just a fundamental exploration of aesthetics.

By talking about “problem solving”, it also helps designers align themselves more closely with business because it couches the creative process in terminology that fits within a kind of corporate lexicon.

But could it be possible that the act of trying to distill the design process into Problem–Solution pairings can actually have unintended consequences? If every project must be framed as “problems to be solved”, how close are we to being the hammer looking for a nail?

If it works, don’t fix it…

The Problem–Solution paradigm has served designers well for decades (except when it doesn’t). As mentioned already, it is a framework that helps position design as a partner in business. So why should we question something that works?

In my work as a designer in R&D, many of the things we work on begin more purely as just investigations into different technologies. I use user-centered design methodologies to identify opportunities to develop new products. In company jargon, this activity is often referred to as “pre-development”. I could, of course, define a problem statement to start an investigative project, but that would imply that a solution would be the outcome of the investigation when that isn’t necessarily the case.

This kind of work isn’t limited to just R&D. Project teams everywhere participate in research, investigations, or knowledge gathering activities all around the world. The timelines are often more condensed than what I have in R&D, but they are investigative activities nonetheless.

Furthermore, what of solutions? The implication that design exists as a solution to some pre-defined problem isn’t always accurate. Sometimes we work on things that have no purpose. For example, optimizing a sign up flow — there are always different ways of to streamline different aspects of signing up for accounts, but if customers can already sign up for products with relative ease, what purpose is there in trying to optimize that? Yet designers are always tasked with these kinds of activities, and some designers may even proactively suggest these kinds of projects!

Additionally, products undergo redesigns. Logo redesigns, new color palettes, different UI’s, adding new features, all of these things are regular occurrences in design teams. Yet if someone solved the problem before, why would we need to redesign something? Hasn’t the problem already been solved? What purpose is there in trying to solve the same problems over and over again?

Furthermore, what are we to make of companies that work within the same product category. If the design teams at Uber (for example) already solved the problem of ridesharing, what purpose is there in reinventing that UI for another product like Lyft?

What do we call it then?

So if we aren’t working towards solving problems, what do we call it then?

Something that the Problem–Solution paradigm doesn’t account for is the idea that in digital space, things aren’t ever really “done”. Maybe in traditional design projects they were, where your outcome was a poster, or a brochure, or some other thing that once it came out of the printing press, there was no real opportunity to go back to it. Digital products are different. The door is always open for change, and very often, digital products that never change are viewed as obsolete.

It’s very noticeable too. Recently, I have seen some websites that were originally built in the days of 800×600 layouts and utilize tables to control how things would display. It was an obvious difference to today’s responsive layouts, and was instantly recognizable as a relic of earlier times. I suppose in this way, someone long ago “solved the problem”, and the website owner felt no need to reinvent the wheel.

Lately I’ve tended to refer to things more as “challenges” and use my creative skills to imagine different “directions” or paths forward that have different tradeoffs that come with it. The benefit of this kind of approach is it leaves things open-ended for further investigation, somewhere down the line.

One way to understand this approach is similar to the following diagram from an article written for the Harvard Business Review by Amy Webb.

The general idea is that there is more variability the further ahead you look. Instead of defining a strategy as a linear kind of activity (with timelines), perhaps we should look to more appropriate analogies. As we venture into the unknown, the immediate path forwards may be known, but it’s difficult to understand what’s beyond the horizon and as a result, we can’t expect to plot everything in a precise way.

The timescales used in the diagram are on very long timeframes (years to decades), but why couldn’t we use a similar diagram to plot out the activities of a single year? Right now, it’s January, and how can we know today what outcomes will happen in December?

I don’t doubt that the Problem–Solution paradigm will still continue on, especially since it’s an uncomplicated (and linear!) way of understanding things. But to me, positioning designers as the heroes of solutioneering is the complete wrong approach. Designers are said to have empathy towards the customer. Having empathy is primarily an emotional activity, rather than a rational one. We talk a lot about empathy and then blow it all away by trying to frame everything we do as a rational solution to the parameters of a pre-defined problem, which seems like a rather significant disconnect.

I think it would be difficult to completely change the Problem–Solution paradigm as a framework for corporate work, but the point is, by broadening our definitions of what design (and really, a company for that matter) is meant to achieve, it might actually help improve the discourse we have as collaborators, and maybe help us make better products along the way!

Thanks for reading! If you liked this essay, please share it! If have any further thoughts about what I wrote, feel free to reach out to me on Twitter!

The Problem with Problem Solving

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s