Simplicity as an Outcome of Thinking

The concept of simple is all around us – the rise of Apple means that our exposure to a beautiful design ethic is ever-increasing. A lot of companies want to take a shortcut to compelling design by imitating Apple, but there’s a great quote from Steve Jobs on the reason that’s hard to do:

‘When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can oftentimes arrive at some very elegant and simple solutions. Most people just don’t put in the time or energy to get there.’

When I’m working on the interaction design of corporate systems for clients, I’m almost always briefed that the design ‘must be simple’, and I’ve been thinking about what that means.

In the wonderful Simple and Usable, Giles Colborne describes four methods of simplifying, using a TV remote control redesign as an example project:

  • Remove – get rid of all unnecessary buttons until the device is stripped back to its essentials
  • Organize – arrange the buttons into groups that make more sense
  • Hide – hide all but the most important buttons…so that they don’t distract the user
  • Displace – create a very simple remote control…and control the rest via a menu on the TV screen

These are steps in the journey towards simplicity, but if they’re used on their own, then they’re only impacting the surface of a design without addressing the fundamental purpose of the interface, or the needs of the user. In his book Simplicity, Edward de Bono makes the distinction between Simple (focusing on the core of a problem) and Simplistic (removing complexity), and to me this beautifully summarises a point that I made much more clumsily a while ago.

A lot of people seem to have a hard time thinking through a problem – it’s easier just to cut and paste solutions we’re familiar with, or take stuff away until we have a solution that looks simple. With the first approach we might be solving a different problem or ‘fighting the last war’, with the second approach; despite its simplicity, we might be obscuring the job to be done. If a user cannot see how to perform their task, they are more likely to abandon or circumvent the process we’ve designed.

The world is complex, as are so are many of the problems that we need to solve, and the key to solving them is applied thought. The Feynman Problem-Solving Algorithm, supposedly coined in jest by another Nobel Prize-winning physicist, Murray Gell-Mann, described legendary physicist Richard Feynman‘s innate problem-solving ability:

1. Write down the problem.
2. Think very hard.
3. Write down the answer.

Gell-Mann was apparently being facetious, but with the addition of a couple more loops, the Feynman Algorithm describes the key steps:

A riff on the Feynman Problem Solving AlgorithmSimplicity is subjective, contextual, and difficult to test – this makes it a poor input variable.
Rigorous thought, and focus on the problem we’re trying to solve will give us a fighting chance of arriving at the most useful solution within the context of the problem.
From the user’s perspective, the most useful solution is often the simplest, and we’ll find that the people who use our designs will say ‘oh, that’s really simple’ – bringing to mind Mark Twain’s quip on the effort it takes to give the appearance of simplicity to the reader:

‘I didn’t have time to write a short letter, so I wrote a long one instead.’

Simplicity isn’t an input of the design process – it’s an outcome of a applied thinking.