To solve a complex problem with a complex solution is not the best approach. Deconstruct big problems into small ones for better results.

For great solutions, start by redesigning the problem.

Many UX designers, developers, and entrepreneurs take pride in how hard it was to solve hard challenges. I don’t. I hope to convince you not to either.  I’m known for enjoying the process of solving impossible problems, but the way I do it is not obvious.  I didn’t invent this method. I learned it first-hand from a master. To put it plainly; If a solution requires the application of superior intelligence, creativity or experience, it’s short-sighted and inferior. The hardest problems crumble if you know how to break them down. The best path is to deconstruct hard, complex problems into simpler ones and then solve those.

Daily design and product problems range from the trivial or easy to the hard or complex to the seemingly impossible. If you want the best result, don’t rush off to solve a big problem before putting work into redesigning the problem.

“Any fool can make things bigger, more complex, and more violent.
It takes a touch of genius–and a lot of courage–to move in the opposite direction.”
— Ernst F. Schumacher

The problem with accepting hard problems “as is”

When we are handed simple, neat and tidy problems, we should just solve them.  However, big or complex problems benefit from problem redesign for these reasons:

1. Complex design problems have a lot of dependencies and moving parts.
   For senior UX, most of the design problems we face are non-trivial. Complex problems are rarely expressed to us in the simplest way.
2. When you solve a complex problem, you get a complex solution.
   No matter how well done, complex solutions are brittle and fall apart when anything changes. We live in a very agile world where things are in constant flux.
3. When you deconstruct a complex problem into a set of simple problems, you get simple solutions.
   Problems stay solved when you address the root of the problem. This is not the same as oversimplification. To quote Einstein, “Everything should be as simple as possible, but no simpler.” Simple solutions are more flexibly applied and extended to changing conditions.

Simple solutions are sustainable.
Complex solutions are not.

Sometimes the problem is problematical

I am not suggesting that we shy away from hard problems. In fact, I wish to arm you with techniques to solve impossible problems, as well we as the merely complex. This requires more than just out of the box thinking. Problem redesign requires vision. Please watch the following video and pause it to try and solve the following easy out of the box problems. Out of the box thinking is important, but we can do better.

Impossible “Kobayashi Maru” problems

When it comes to problems, there’s a difference between hard and impossible. I call impossible problems “Kobayashi Maru problems”. It’s a reference to Star Trek II: The Wrath of Khan. Kirk was the only cadet to ever solve a strategy exercise because it’s impossible. Cadets were asked to save the Kobayashi Maru spaceship, even though the simulation was secretly rigged to make cadets fail, no matter what they do. Kirk determined that it was rigged and altered the computer so it was possible to win. When we face impossible problems, it’s not cheating to redefine the problem so that the true goal is easier to achieve.

Kirk did the two critical things we often skip:

A. Analyze to determine root causes.  Kirk tried a few times and then recognized that the exercise was a paradox. The fact that he failed didn’t matter. The fact that everybody in the history of Starfleet had failed was important. How could it be that nobody had ever even accidentally solved the problem?  That question led him to correctly surmise that the computer must be rigged. Our takeaway: Without identifying correct root causes, nothing we do will work.

B. Alter the problem to address the real root cause. In Kirk’s case, he was asked only to “save the spaceship”. He merely removed an artificial constraint that was working against him. It’s not cheating to remove a factor that students weren’t told about. If your boss asks you to solve a problem, she wants to achieve a specific high-value result. If you understand what she truly wants, she won’t mind if you can find a better, simpler way to achieve that result by changing the problem.

Overcoming the “no-win” scenario

Here’s a sampling of impossible Kobayashi Maru problems I had to solve:

1. Your prof wants you to enter a big robotics contest.
   Working solo, you start 6 months late to design, build, refine & test a robot to compete in time trials against 4-6 person teams from the best schools in North America.
2. Your employer wants you to make big changes to an undocumented archaic device that controls lethal radiation. And then not test it.
   By the way, you have to learn an old programming language and use it for the first time while tinkering with half a million lines of uncommented code; human lives are at stake.
3. Your employer wants you to design a way to prevent nuclear meltdowns.
   No pressure, but you have to design a system that ensures that a hundred different nuclear emergencies are safely handled in a crisis. It has to be quick enough to prevent a meltdown or radiation release endangering millions. For extra fun, try doing this straight out of school.
4. Your product makes fish swim across the screen. Your task is to get almost everyone in the world to use and pay for it.
   Just to make it harder, let’s ask everyone to pay about $50 and see if we can get all the major corporations, intelligence agencies and government offices to site license it.

This article is about the methodology I developed from these challenging experiences. At the end of this article, I’ll tell you what I did and how each one turned out.

Why are most design problems complex?

There are simple problems, but senior designers get bigger problems with wider implications. Let’s consider how such problems come to be in the first place.

Unmet customer needs and desires create pain points. Those pain points are communicated in a variety of ways:

• sales of a product drops while a competitor gains
• usage of a product drops
• customers complain about difficulties
• customers request new products/features
• customers rate a competing product higher

The obvious explanation is often wrong

Businesses act on customer feedback/inputs by formulating problems to solve. This is where defining the right problem to solve becomes problematic. The people and companies that employ me are very smart and motivated to succeed. I think that’s part of why they hired me However, customer feedback doesn’t point directly at the right problem to solve.

Here’s why it’s tricky:

• Some pain points are pretty obvious, but most are not.
  The obvious explanation could be right, but is often wrong. If customers say that a product breaks a lot, it could mean that your build quality sucks, or it could be many other things. Are customers using it correctly? If not, perhaps they need a guide or design cues to help them? Perhaps it breaks only in certain conditions or combined with other products that you did not foresee?
  
• Customers are humans that are great at communicating feelings, but lousy at diagnosing the true root causes.
  It’s easy to know when customers love, hate, or are annoyed with a product. However, customers are no better at diagnosing the root cause of their feelings than they are at diagnosing their own medical symptoms. “The product costs too much!” Does that mean that you’re not presenting enough value, or are customers unaware of all it can do, or don’t care about all it can do? Are they unable to tap it’s potential for a host of non-obvious reasons?
  
• Customers don’t always communicate at all.
  Customers don’t work for you. They are unlikely to even know what it is that makes them buy or not buy your products, much less tell you. Ask them and they will rationalize an answer, but that doesn’t make it true. Most will just quietly leave or switch when the competition is better.
• Competitor success is often misunderstood.
  A competitor’s bold new feature might have nothing to do with your customers switching. Maybe your customers had simmering angst with your product and jumped at the chance to try anything new. Maybe your competitor has a co-marketing deal with Google or just works better with other products. Copying their new hot feature might be pointless.

There’s no point in solving the wrong problem. To paraphrase H.L. Mencken:

For every customer issue, there is a problem statement
that is simple, clear, and wrong.

Redesign problems before solving them

As detailed above, it’s not easy to turn customer feedback into precisely the right problem(s) to solve. Therefore, as a senior designer, I often get asked to solve the apparent problem that:

• Oversimplifies the problem.
  The need to DO SOMETHING quickly usually results in ignoring critical details.

OR

• Overcomplicates the problem.
  Many problems are inherently complex because they touch on different systems, customer types, and user journeys over time. If you do your research well, you may discover many factors that complicate issues. Treating a complex web of factors and journeys as one big problem produces overly complex, unsustainable solutions.

Problem redesign never wastes time

If you follow a good UX design process, then you’re already doing the groundwork needed to redesign the problems.

Always start with customer pain points. For example, let’s say that your product’s usage has dropped off. Formerly loyal customers are switching to the competition. Define the right problem statement before trying to solve anything.

1. Research users to define personas.
   Who is affected? Define their needs.
2. Contextual inquiry.
   When, how and why were they using it? What were they using it for? What other products were they using that might affect it?
3. Divergent outside the box thinking.
   Hypothesize multiple scenarios. Imagine and write down every possible explanation for the customer behavior. Don’t settle for the first plausible explanation.
4. Converge and filter. Discard non-essentials.
   Look for evidence that supports or precludes each of the possible explanations for the customer pain. When you exclude the impossible, you’re left with the truth, the actual way(s) things are going wrong.
5. Write the explanations as problem statements.
   Each problem statement addresses a single issue or a tightly related set.  
   
6. Deconstruct a problem into smaller problems.
   Don’t create one solution for a multi-faceted problem. Following our example problem, we might find that customers are unhappy because your product has a bunch of friction points that a competitor doesn’t.
   1. your login takes too long and password rules are too complex
   2. your users love how your UI looks, but can’t tell what’s clickable
   3. your users can’t find features that are easier to find in a competitor
   4. your users can’t read some of your text
7. Think ahead, but not too much. Deconstruct more.
   Don’t just solve for today. Create solutions that last. If the smaller problems are still multi-faceted, break them down further. What near term features and customer needs can be anticipated? Take these into account in your problem formulation.

Now solve the smaller problems

If you’ve followed these steps, you won’t have any super-hard problems left. You’ve transformed big problems into a set of small problems that you can now solve. You’ve already done most of your UX research and analysis, so you can move fast.

At the end of the day, solving smaller problems is easier and less stressful. Your bosses will get better results, and down the road, your solutions will be easily adaptable for changing conditions. To reiterate the start of this article, I invite you to take pride in only solving simple problems because you always deconstruct complexity.

Beyond the Theory: Case Studies of Kobyashi Maru-type impossible problems

If you read the article above, you know how to do it, but perhaps you’d like to see some examples. If so, follow the link below to read the story.

• Click here to read how I redesigned the following impossible problems

A few personal examples:

1. Your prof wants you to enter a big robotics contest 6 months late.
2. Your employer wants you to make big changes to an undocumented archaic device that controls lethal radiation. And then not test it.
3. Your employer wants you to design a way to prevent nuclear meltdowns.
4. Your product makes fish swim across the screen. Your task is to get every almost ever computer user in the world to use it and pay for it.

If you enjoyed this article, share it with others.
Contact me if you need a great UX Design Director/Manager.