Solving the right problem
if you have an overcomplicated solution, it’s probably because you’re trying to solve an overcomplicated problem.
I’ve been doing design work for about 10 years now, and everywhere I’ve worked, I notice patterns. Not design patterns, but patterns in how people work, how organizations function, and how design work gets done. Once I started picking up on these patterns, I started writing things down. After a while I had collected 10 principles that seemed to be common threads everywhere I’ve worked. They’re always changing slightly and being refined over time, but in general I’ve found them to be helpful principles.
The first principle in the list is the most important, the most constant, and the most universally applicable. It doesn’t just apply to interface design or mobile apps. It applies to almost every situation:
If you have an overcomplicated solution, it’s probably because you’re solving an overcomplicated problem.
No matter what company I work for or what project I’m working on, I’ve found this principle to be incredibly helpful when thinking about design.
What’s the real problem we’re trying to solve?
Every once in a while, a designer will find themselves coming up with a completely new pattern, or combination of patterns that causes all kinds of new problems. They step back to look at it, and it seems over-engineered and complicated, but it seems like it’s the only thing they can do, as if they’re stuck between a rock and a hard place.
I’ve come to realize that 9 times out of 10, this is because they’re solving for an overcomplicated problem. They’re doing something weird because there’s something really weird happening upstream somewhere else that isn’t being solved, so the burden falls on the user experience designer to accommodate for a misdiagnosis of the real problem.
To illustrate my point, let’s walk through the common lifecycle of a design project. Let’s say a designer gets a project where the creative brief says:
Design a sign to warn wheelchair users that the crosswalk is bumpy.
So obviously, the first thing we need to do is design a wireframe:
This is a great wireframe. It’s time to add some color.
We get some feedback from the stakeholders that the line work is a little thin, and they want us to make it pop. Classic.
The stakeholders feel like the copy isn’t descriptive enough.
The legal department gets a look at the design and they want us to be more specific about when the road will be bumpy, and also more clear about who this sign is for.
Now the sign is more clear about who should exercise caution, but there are too many words on the sign. Let’s trim that message down a little.
This is much better. Pithy. To the point. Also unintelligible. But as it turns out, all the other signs on the road are yellow, so we want this one to stand out because it’s obviously the most important sign on the road.
Looks great. Only 1,347 versions later. Let’s see it in context:
The sign does the job, but now that we can see it in context, we realize there’s an issue. The road is bumpy. And not just the part where wheelchairs will be crossing it.
Let’s zoom out:
The entire road is bumpy. Let’s go back and look at the project brief:
Design a sign to warn wheelchair users that the crosswalk is bumpy.
So instead of immediately jumping in to make a wireframe and design the visual treatment, maybe the question we should have been asking is, why is the road bumpy?
Why is the road bumpy?
This is an absurd illustration, figuratively and literally, but it’s a perfect example of a project lifecycle that I’ve seen happen over and over again.
We get a highly prescriptive project brief, and we immediately jump in on the visual treatment without asking questions, and we end up designing an overcomplicated solution to a problem that shouldn’t even exist. In fact, we often spend more time debating the visual treatment than we do even asking whether or not the solution is the right one.
What I’ve learned to do in these situations is to ask “why?” A lot. Over and over. It might sound ridiculous, but when we get a project brief instructing us to design a sign about the road being bumpy, the first question is not “what color should the sign be?” The first question should be, “why is the road bumpy?”
What’s the real problem?
This is basically just another way of asking “what’s the real the problem we’re trying to solve?” The real problem isn’t the fact that there isn’t a sign. The real problem is the fact that the road is bumpy. So the real solution isn’t to design a sign, the real solution is to make the road not bumpy.
If we go back and look at the road in our illustration and ask why the road is bumpy, we’d find that the road is bumpy to accommodate for a very unique wheel that someone designed:
What’s great about this absurd illustration is that it’s a perfect example of something that happens all the time. Somewhere in the process, somebody decided to get creative, or cut corners, or there was a genuine limitation.
In this example, somebody on the engineering team got tired of making round wheels and decided to innovate. Then they realized they’d have to change the road a little bit to accommodate this new innovative technology. Hence, the bumpy road.
Maybe it all made sense at the beginning of the project, but in retrospect, maybe this wasn’t the best idea after all. It causes more problems than it solves, and now that it’s in place, it would be extremely expensive to go back and fix the infrastructure. Sound familiar?
So what’s the solution? We ask the design team to make a sign.
Usually when there’s a problem with the infrastructure that seems too expensive to fix, asking the design team to make a sign seems to be the least expensive solution.
This seems to be the least expensive solution, but usually when the UX team designs a strange interaction or a new pattern to account for an engineering deficit, what we’re really doing is putting the burden on the user to do extra work, instead of on the technology. We call this cognitive load, and generally it’s something we want to avoid.
The goal should be to have technology do the thinking for us, instead of the other way around.
Since part of my job is managing the style guide for a UX team, I’m constantly getting questions about how to use the patterns in the design system. I’ve realized that 90% of the time, if a designer is using a pattern in a strange way, or feeling like they need to come up with a new pattern to solve their problem, it’s because they’re designing around a foundational problem with the infrastructure, instead of actually solving it. As it turns out, the patterns that have already been designed account for 90% of the tasks that need to be done. When we try to create work-arounds for a faulty infrastructure, things get complicated, and common patterns start feeling inadequate.
Turn on notifications for your mind.
Over time I’ve learned to recognize situations like this, and instead of trying to fix the design, I’ve learned to ask questions. When I see something that looks like an overcomplicated solution, a red flag goes up and I try to take a step back, zoom out, and ask “why.” Usually, an overcomplicated design solution means we’re not solving the right problem.
As designers, we don’t make art, we solve problems. We just have to make sure we’re solving the right problem.
