Maeda’s book is in keeping with one of his own tenets: don’t make things too long or overly complex. He actually manages to say all he needs within a 100 pages. Nevertheless, it took me a while to get through “Laws of simplicity”, because it’s a lot of information, densely packed.

He summarizes his laws of simplicity as follows:

  1. REDUCE: the simplest way to achieve simplicity is through thoughtful reduction.
  2. ORGANIZE: organization makes a system of many appear fewer.
  3. TIME: savings in time feel like simplicity
  4. LEARN: knowledge makes everything simpler
  5. DIFFERENCES: simplicity and complexity need each other
  6. CONTEXT: what lies in the periphery of simplicity isn’t peripheral
  7. EMOTION: more emotions are better than less
  8. TRUST: in simplicity we trust
  9. FAILURE: some things can never be made simple
  10. THE ONE: simplicity is about subtracting the obvious and adding the meaningful
  • AWAY: more appears like less by simply moving it far, far away
  • OPEN: openness simplifies complexity
  • POWER: use less, gain more

In a way, what to take away from reading was fairly easy to start with. Think about the things you design, and think about them in a meaningful way:
Why is that function there? Why does it function the way it does? Could it be made easier, simpler? Or will it be worth it for users when they learn what the function does and learn it well? In other words, is the learning curve worth the effort needed to get to know your design, and if so, how will you convince users to go through the learning curve?

Executing this kind of thinking at all times isn’t easy though. It means that you have to reflect on your design, keeping in mind your users all the time. Not only that, if you work in a team, you have to convince everybody else of this too.
Keeping everybody focused on simplicity (or at least relative simplicity if you can’t make things simple) is a hard task to execute. So, just because you are trying to keep things simple, doesn’t mean it’s easy to achieve.

Considering that I don’t really design products, how to apply these principles for me? Well, they can also be applied to writing papers, and blog posts. Externalize reasonings, ask ‘why why why’ all the time and make it explicit. You know why, but you cannot assume that readers do. And sometimes, when you explain why things cannot be that simple, people take the time to follow through your complex reasonings.

Advertisements