About half a year ago, there was a message that one of the conferences has a SpinOff Conference. Nice news, since SpinOff Conference is very much in my field. Plus, soon they published that at least one of the KnownPeople would give a keynote talk, which was another reason to contribute a paper. The long paper deadline came closer, but not enough data had been gathered yet to write something worthwhile. Luckily, the short paper deadline was doable, so a short paper was submitted.

Thursday the verdict was in: Accepted!!! I bounced around the whole day, certainly after seeing the awesome reviews! This means that I’ll be in the San Francisco Bay Area again in october… where I will see KnownPerson speak (for the first time, too), present my own work, probably get some new fresh insights and lots of new energy. I can hardly wait…

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.

Or how to define quality? What is quality, anyway? Well, people know it when they see it.

Written by John Guaspari

This is a short book of 96 pages and very easy to read, I finished it in half an hour.

It has one very important lesson in it as well: listen to your customers! They might not have all your technical language, but they can for sure tell you whether the product they bought from you indeed meets their expectations for that product (and needs and wants, although you might have to observe them while using your product too).
The solution is not to work harder and do better, or to have more inspectors. Neither is it to prevent mistakes from happening while producing something. The important part is to deliver what your customers need, not necessarily what they want. Always make sure that what you promise them is there.

The other important insight is that management has to give you the opportunity to implement the lessons and comments gotten from the customer. Management needs to lead the business towards QUALITY. If design doesn’t know what implementation is doing, how can there be coherence? What is the use of being able to define exactly what is which if at the end you cannot sell your product? Winning a battle, but losing the war is never what a business wants.

I read this book because I was on a quest to find out more about perceived video quality. Considering that there is no coherent definition there either, I turned to a bigger construct. And although this book didn’t give me a definition, it gave some extra directions to consider, such as marketing and consumer behaviour research. It can be hard to keep an overview of where all the knowledge is, or has gone. The best books can give you new food for thought, asking more questions, while leaving you feel wonderfully focused at the same time. Maybe the term “flow experience” would be quite right for this feeling.

Or why is usability and user experience so important for softwere developers and engineers, and how do you convince them it’s so bloody important?

The inmates are running the asylum, by Alan Cooper

This reads like a business-book, which is what it aims at. It does give a good feeling for what’s important when you develop software for people that aren’t you, especially when it comes to working through specifications (no matter who the specs are given by). Features of your software are not what is important, rather that users are able to reach their goal. So one should work goal-oriented and put in features that help users reach their goal, not put in features just because somebody thinks it’s interesting (think pointy-haired boss).

Engineering methods don’t work to solve engineering problems, because you’re blind to your own problems. A different method will probably work better. Also, it’s difficult to do both back-end and front-end design so separate both but they still have to work together. There is a conflict of interest between what the programmer wants, and what the user wants. So you don’t let a programmer referee whether a program is doing what the user wants (unless it’s something she designed for herself to use, obviously).

Bribery can work to find out what programmers are doing, but you shouldn’t have to resolve to it. On the other hand, maybe you can train some sense into them that way. Or present it together with a rational, defensible reason. In terms an engineer can understand.

Bottom line: you can listen to your users, but it’s even better to observe them. If you only listen, you’ll end up trying to sell them a 12-headed dragon.