This is my summary of the book “Living with Complexity”, by Donald A. Norman (of “The Design of Everyday Things” fame, among others). It’s a book about how it’s wrong to consider complexity (in design) a bad thing. I have skipped a fair deal of the text in the summary, mostly because it wasn’t applicable to my job. I have also reorganised the content a lot.

Main message

Complexity in itself is neither good nor bad, it’s confusion that is bad. Good design can help taming complexity, not by making things less complex, but by managing the complexity. There are two keys to cope with complexity: design that show its underlying logic to make it understandable, and our own skills and understanding of that logic. People need to take the time to learn, understand, and practice, because systems that deal with complex activities will not be immediately understandable, no matter how well they’re designed.

The misguided cry for simplicity

The argument between simplicity and features is misguided: people want more capabilities and more ease of use, but not necessarily more features or more simplicity. What people want is understandable devices. It’s not even a trade-off between simplicity and complexity because (a) simplicity is not the goal, and (b) you don’t have to give up something in order to have more simplicity.

We seek rich and satisfying lives, which goes along with complexity. Too simple and it’s dull; too complex and it’s confusing. This happens in every subject (also music, movies, etc). The problem is when complexity is arbitrary and unnecessary.

What makes something simple or complex is the conceptual model of the person using it: many activities we think of “intuitive” now, like swim or ride a bike, have taken us years to learn and master. We can often use something by following instructions, without having a good conceptual model. But then we run into problems, and we complain that it’s too complicated. Comparisons with tools like hammers are wrong, because (1) even if the tool is simple, mastering its usage actually takes a long time; and (2) users of those tools typically need many of them, and each one has to be mastered separately.

On anti-social machines

Machines are often anti-social when things go wrong: they become unresponsive and unhelpful, like bureaucracies. The problem is that the designer typically focuses on correct behaviour (ie. not a lot of work on error conditions). This is worse when systems are designed by engineers who view things from their logical point of view, feel people “get in the way” (the “foolproof” systems syndrome).

We try to add intelligence to machines, but what they need (and this is seldom considered) is communication skills, etiquette and communication. We often need to change our goals in the middle of an operation, or want to substitute or skip some steps, or do them in a different order, or are interrupted and have to finish a task at a later point. Most systems don’t allow this. Isolated, context-free intelligent tools can’t be sociable.

System thinking

System thinking (considering the entire process as a human-centred design) is the secret to success in services. This is part of what has made Apple so successful: (1) design cohesive systems, not isolated products; (2) recognising that a system is only as good as the weakest link, and (3) design for the total experience.

Desire lines (like messy trails besides the designed paths in the real world) can often teach us something about what people want and how the design might have gone wrong. Neglect of usage patterns can turn simple, attractive items into complicated, ugly ones, and also turn simple components into a complicated combination when they are put together. Everyday life is often complex not because of a single complex activity, but because of many simple activities with different requirements or idiosyncrasies.

Waiting lines

Waiting lines have been studied from the efficiency point of view. But what about the experience? Principles to improve the latter:

  1. Provide a conceptual model (perhaps the most important principle): uncertainty is an important cause of emotional irritation; people need assurance when they have problems.
  2. Make the wait seem appropriate: people should know why they wait, and agree that it’s reasonable.
  3. Meet of exceed expectations: always overestimate waiting time.
  4. Keep people occupied: it’s psychological time, not physical, that is important. Give people things to do, keep lines moving and make them appear short.
  5. Be fair: emotion is heavily influenced by perceived causal agents.
  6. End strong, start strong: in order of importance, the end, start, and middle are the most important to take care of.

The memory of the whole event is more important than the details of what happened. When there are positive and negative components, it’s best to: finish strong, segment the pleasure but combine the pain, and getting bad experiences out of the way early.

Principles to manage complexity

Note that this list is heavily edited compared to the book.

  1. Make things understandable. Good conceptual models have to be communicated effectively. Jurg Nievergelt and J. Weydert argued for the importance of three knowledge states: sites, modes and trails, which can be translated into three needs, namely knowledge of the past (knowing how we got into the present state; many systems erase the past so we may not know how we got there), present (knowing the current state, how are we regarding starting point and goals, and what actions are possible now) and future (knowing what to expect).
  2. Avoid error messages. They indicate the system is confused, not the user. Don’t scold her. Good design means never have to tell the user “that was wrong”.
  3. Structure. Divide the task into manageable modules that are easy to learn, or find a different way to frame the problem so it’s less complicated.
  4. Automation. Many tasks can be simplified by automating them, but this only helps if it’s reliable: when there are errors, it can be more complex to switch back and forth between automated and manual than to not have any automation at all.
  5. Nudges and defaults. Sometimes forcing functions (constraints that prevent unwanted behaviour) are too strong, all is needed is a gentle nudge. Defaults are an effective way to simplify the interaction with the world, and a strong tool to drive people’s behaviour.
  6. Learning aids. Instruction manuals are rarely read. When people use a new service or system, they have a goal, they’re not going to read the instructions first. Most people want “just in time” learning and learn better when they need to. The best explanations are in context and show how the task is done (short video demonstrations work well).

And that’s it. Hope you enjoyed  it.