Please read the previous article for methodology: How to redesign UX problems. If you thought it was just theory, read the case studies below for inspiration to redesign super hard problems into simpler ones. 

“I don’t look to jump over 7-foot bars:
I look around for 1-foot bars that I can step over.”

-Warren Buffet

The thing I like about hard challenges is that it’s an opportunity to improve my method of problem-solving.

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 standard out of the box problems. Out of the box thinking is important, but we can do better.

Examples of 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 problem because it’s impossible. The students were told to save the ‘Kobayashi Maru’ in a real-time strategy simulation. They weren’t told that the computer was rigged to make them fail, no matter what they did. Kirk had the genius insight that the computer must be rigged because nobody had ever even accidentally won. This insight led him to redefine the problem so it was solvable, and then, magically, he solved it. In the cases below, you’ll see how I learned how to solve UX design problems while breaking down and solving seemingly-impossible issues. If I could do it, you can do it too.

1. Your prof wants you to enter a big robotics contest 6 months late.

Task & Conditions
I had no team and was already 6 months behind several 4 to 6 person teams from the biggest universities in North America. The contest was to design, build and program a robot to get the fastest time playing a game: The Towers of Hanoi. The game has 7 rings that must be moved one at a time from one post to another without ever putting a larger one on top of a smaller one. This required at least 127 high precision moves..

The apparent problem
The obvious way to solve the problem was to program a human-like robot arm to arc through space and carefully do the 127 minimum moves; each move consisting of picking up a ring from one post before arcing up and over to place it on another post.

How I redesigned the problem
I didn’t have access to precision human-like robot arms, so I decided to build my own from surplus dot matrix printers. I deconstructed the problem of moving a piece from complex arcs that a human arm would perform, to only 3 degrees of linear movement. I further transformed the problem by mounting the game itself on one printer motor. I controlled the motors with microcontrollers driven by a program in BASIC. Each degree of motion (horizontal, vertical, grasping) became a separate optimization problem.

Results
I iterated endlessly to optimize and defeated all other entries by a huge margin: 5.8 times faster than the best competitor and with accuracy as close to 100% as could be measured. The control program was so efficient that it could show a visual animation of each move as it controlled the motors. When it won, I had to run it another 5 times because people couldn’t believe what they were seeing. The next-fastest competitor used two human-like robot arms, was 5.8 times slower and failed 30% of the time. It was a team of 6 guys from a top US university led by a prof who wrote the textbook for robotic control systems. They programmed two industrial robots costing $22,000 while mine cost maybe $10 in spare parts. I was accused of cheating by redefining the problem, but I followed all the rules and won fair and square.

2. Your employer wants you to make big changes to an undocumented archaic device that controls lethal radiation. And then not test it.

Task & Conditions
I was fresh out of college. My employer had a particle accelerator (high dose radiation) that they were repurposing as a food irradiator. I was asked to produce live animated charts to monitor the irradiator. If you irradiate food perfectly, you eliminate bacteria. Food can then be safely shipped unrefrigerated to feed people in remote locations. However, the wrong dose produces radioactive food or could kill people in the room.

The apparent problem
Creating the animated charts was easy. To get the data, I had to program the control computer, an ancient PLC. I had to learn a bizarre programming language where code looked like wiring diagrams. There wasn’t enough memory in the PLCs for any new code. I was ordered to rewrite the radiation control software, a half million lines of uncommented PLC code, to make room to add my new code.

How I redesigned the problem
The problem itself felt wrong. There was no code documentation to look at and the original programmer was mysteriously unavailable.  I was told his code was perfect. That set off alarm bells. I asked to retest the control software to make sure my alterations wouldn’t screw anything up. They refused. When I asked why, they said “If you weren’t a genius, we wouldn’t have hired you.” So, I got creative. I asked if I could just upgrade the PLC memory. They refused, saying it would cost $37k. Being frustrated and concerned, I got more creative. The PLC supplier loved my animated charts, so I proposed a deal. They eagerly agreed to trade $50k of free PLC upgrades for the right to resell my integrated charting.

Results
I felt deep in my bones that the radiation control software was NOT safe to change. I thought I would be praised for finding a free way to a safer solution. Instead, my bosses were pissed and threatened my job and career if I didn’t follow orders to rewrite the code, even though they would not retest the system. I refused and moved to another working group. Unfortunately, I was later vindicated.

Years later, I learned that the irradiator was used as a medical imager and was the cause of the worst software error in history. Someone followed orders and mucked with the code after I refused. Google “Therac 25”. People died from radiation exposure, and there were million dollar lawsuits. If I had ignored my intuition and followed orders, more people might have died and it would have been my fault. My takeaway: Doing the right thing for your employer sometimes means questioning what you’re doing. I was right to question my orders and propose alternatives. Once you are tasked with a problem, it becomes your responsibility.

3. Your employer wants you to design a way to prevent nuclear meltdowns.

Task & Conditions
When I worked in a design group for Atomic Energy, I was tasked with hard problems. One was to design a system to help operators handle a hundred different nuclear emergencies that could cause a meltdown or a radiation release that would endanger millions of people.

The apparent problem
Previous design efforts had focused on giving more information to reactor operators. As shown above, a reactor is complex, with hundreds of gauges, dials and indicators to monitor every part of it. It was assumed that showing a visual representation of the whole reactor would help operators figure out what to do. My group even programmed a simulated reactor which allowed operators to try actions before doing it for real. Lots of impressive, gorgeous graphics, but all it did was make the problem worse.

How I redesigned the problem
The stated problem was wrong. Look at that control room again. The new fancy displays did not replace any of those indicators. It just added a lot more visual noise. The clock is ticking. There’s a hundred possible emergencies. The right action must be taken quickly or people die. From usability tests, I determined that giving operators even more information to look at in an emergency was worse than useless. It was paralyzing.

So, time to redesign the problem. My research indicated that the operators were smart, but still humans who rushed to act, missed details, froze and made errors in a crisis. Normal operations were complex. Nuclear emergencies are so complicated and rare that nobody can get good at handling them. They had a 340 page book detailing how to handle a hundred different possible emergencies. There were nuclear physicists they could call to talk them through a crisis, but the physicists were far away, not always available, and couldn’t see the indicators showing the reactor state.

My approach was to design a diagnostic expert system available 24/7 to talk the operators through diagnosing and solving emergencies. I created a hypertext-based system that guided an operator one step at a time through diagnosing and resolving any emergency.

Results
It didn’t work right away. I had to deconstruct into smaller problems and iterate. The final version had very concise text at each step with focused images and some live reactor data that helped operators choose the next step. It helped operators resolve hundreds of emergencies calmly and confidently with plenty of time to spare. It went so well that it was approved for deployment to real reactors and presented before the International Atomic Energy Commision as a landmark design for the future.

UX is more than a few books, an online course, or an HCI degree. Iterating on many high stakes projects like this one deepened my skills in a way nothing else can do.

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.

Task & Conditions
In my own consulting company, we stumbled into creating a product. We made a screensaver that makes things animate on screen. I offered it for free on the internet, but people insisted on paying for it.  I was curious why.

The apparent problem
It appeared that people wanted to pay for visual eye candy on their screen. When people hear the word screensaver, they think “Oh, that useless toy that people used to pay for.” The problem seemed to be how to get more people to buy pretty, but essentially useless, animation. So we dreamed up lots of fun animations with morphing shapes, colors, lines, flying logos and fish swimming across the screen.

How I redesigned the problem
By analyzing the fan mail and complaints (often in the same correspondence), I determined that we were dead wrong. The problem wasn’t “how to sell eye candy” at all. I broke the feedback into 3 persona groups and found a common theme: control.

At the time, work on computers was unpleasant. Computers crashed. Software was poorly designed. Sitting all day, staring at a screen, and working in an open office are all bad for you. When you took a break, having a little bit of animated joy automatically appear on your screen allowed people to feel better at work. Being able to customize it made people feel in control.

Computer screens were susceptible to burn-in. Buying a screensaver made employees happy and prevented employers from having to frequently replace $350-$1,000 screens, thus controlling costs.

The problem became “How to deliver control and joy that satisfies both workers and bosses”. I refactored the product to include the first way to lock a PC to protect its data when you walk away. I simplified to create the most elegant and forgiving interface of its time. Workers wanted it. Bosses needed it to protect and control their offices. Within a few months, every company, government, intelligence agency and home user couldn’t wait to buy it.

Results
You might have heard of the result. It started out as Magic, but became After Dark, the flying toaster screensaver that was the world’s #1 biggest selling software. For it’s time, it was bigger than Facebook. It retailed for $50, but had a very high ROI by saving assets and protecting data while also being tons of fun.

If I had just accepted the obvious, it would have just been a useless eye candy toy. It wouldn’t be an important part of design history still featured in museums and discussed in the media. By listening to customers and refactoring what it really was, it became a different and much more valuable thing.

Summary

The cases above are extreme examples. Problem redesign has saved time for me on more than 50 design projects. It doesn’t have to be an impossible problem to benefit from simplifying it before you go about solving it.

“The definition of genius is taking the complex and making it simple.”

-Albert Einstein

It doesn’t take a genius. The world needs people simplifying problems instead of creating complex solutions that end up making things worse. Here’s a secret: You know that you have simplified a problem enough when there’s a big gap between how difficult the problem is perceived initially compared to after simplification.

If a problem starts off seemingly hard or impossible, but then seems simple and obvious after the fact, then you’re done. A superior solution stays solved even if some conditions change. The funny thing is that it creates cognitive dissonance when an incredibly hard problem has an incredibly simple solution. To resolve the dissonance, some will think that the problem couldn’t have been that hard in the first place. Not so. It means you did your job. It’s unfortunate that we live in a world where people brag about solving hard problems instead of simplifying them first.

“Simplicity is the ultimate sophistication.”

-Leonardo da Vinci

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