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.

EDIT: Manuela wrote another, easier to read summary.

Escaping flatland

The methods in this book work to increase the number of dimensions that can be represented on plane surfaces and the data density. Nearly every escape from flatland demands an extensive compromise, trading off one virtue against another. Even our language often lacks capacity to communicate a sense of dimensional complexity. Some design strategies are found again and again (examples of over 380 years of sunspot data analysis). These design strategies are surprisingly widespread, albeit little appreciated, and occur independently of the content of the data.

Massive Java railroad line example on p. 24-25. The train diagonals cleverly multiple-function, recording six variables at once (p. 26). Example of criminal activity for a trial on p. 30-31. The chart invites reading both horizontally and vertically. The eyes detect curious patterns, which make these displays persuasive and memorable. Visual displays of information encourage a diversity of individual viewer styles and rates of editing, personalising, reasoning and understanding. Unlike speech, visual displays are simultaneously a wideband and a perceiver-controllable channel.

We envision information to reason about, communicate, document and preserve that knowledge. Chartjunk on p.34: data-thin, uncontextual graphs. Its promoters imagine numbers to be dull and tedious, requiring ornament. If numbers are boring, you got the wrong numbers. The audience might be busy or eager to get on with it, but not stupid. Chartjunk looks more like a poster, meant to be looked at from a distance (thin data density).

Micro/macro readings

Detail cumulates in coherent structures. Simplicity of reading derives from the context of detailed and complex information, properly arranged. To clarify, add detail. Stem-and-leaf plots of statistical analysis also rely on micro/macro design (examples on p. 46-47).

We thrive in information-thick worlds because of our marvellous and everyday capacities to select, edit, single out, structure, highlight, group, … Visual displays rich with data are not only an appropriate and proper complement to human capabilities, but also such designs are frequently optimal. If the visual task is contrast, comparison and choice, then the more relevant information within eyespan, the better. Low-density requires visual memory, a weak skill. High density also allows viewers to select, narrate, recast and personalise data for their own uses.

What about information overload? The question misses the point. Clutter and confusion are failures of design, not attributes of information. Interesting quote on typography on p. 51. The deepest reason for displays that portray complexity and intricacy is that the worlds we seek to understand are complex and intricate.

Layering and separation

This technique is one the most powerful devices for reducing noise and enriching the content of displays. The various elements interact, creating non-information patterns and texture simply through their combined presence (1 + 1 = 3 or more). Colour effortlessly differentiates between annotation and annotated (example on p. 54). What matters is the proper relationship among information layers (example of old + improved design on p. 54-55). For tables, try to do without rules altogether, only use when absolutely necessary. Example of map (good and bad) on p. 58. Example of (non-)dull background on p. 59. Notes on how 1 + 1 = 3 can also be applied to noise on p. 61-62. Example of use of colours (another bad + good design) on p. 63.

Information consists of differences that make a difference. A fruitful method for the enforcement of such differences is using layering and separation.

Small multiples

Quantitative reasoning is based on “compared to what?”. Small multiples answer by visually enforcing comparisons of changes, of the differences among objects, and the scope of alternatives. Information slices are positioned within the eyespan, so that viewers make comparisons at a glance. Example of drawing a Kana character on p. 69. Simultaneous two-dimensional indexing of the multiplied image, flatland within flatland, significantly deepens displays with little added complication in reading.

Colour and information

Example of Swiss mountain map on p. 80. Fundamental uses of colour in information design: label (colour as noun), measure (as quantity), represent or imitate reality (representation), enliven or decorate (beauty). Principles to minimise colour damage: (1) pure, bright colours have loud, unbearable effects when they stand unrelieved over large areas adjacent to each other, but can work very well when used sparingly on or between dull background tones; (2) placing of light, bright colours mixed with white next to each other usually produces unpleasant results, esp. if the colours are used for large areas; (3) large area background or base-colours should do their work most quietly, allowing the smaller, bright areas to stand out most vividly (strongly muted colours, mixed with grey, provide the best background for the coloured theme).

What palette of colours should we choose to represent and illuminate information? Use colours in nature (familiar and coherent, possessing a widely accepted harmony to the human eye), esp. those on the lighter side such as blues, yellows, and greys of sky and shadow. Great examples on p. 90.

In the ocean map, quantities are shown by a value scale, progressing from light to dark blue. Colour rainbows confuse viewers to mumbling colour names and the numbers they represent (“To see is to forget the name of the thing one sees”). Colours are sensitive to context. In the ocean map, contours (which are very helpful) are labelled with depth measurements. Edge lines allow very fine value distinctions, increasing scale precision. Example of bad map/good colour on maps on p. 94-95.

Narratives of space and time

Example of bad/good train schedule on p. 104-105. Space-time grids have a natural universality, with nearly boundless subtleties and extensions. Great, assorted examples on p. 110-111. Example of “tale of two cities” on p. 112-113.

Final notes

I’m aware that this summary is not very useful if you can’t see the different diagrams being examined, but it’s partly for myself :-) Anyway, if you like the ideas in the book, go buy it, it’s a great book in a big format, with really nice paper and full of very interesting examples of both good and bad information design.

First, the good old editor is not there anymore: the Typo editor used to be really good, because on the left hand side you had a very reliable and easy to use textarea with Wiki syntax (you can choose which exact syntax you want), and on the right hand side you had a “live preview” of your post, automatically updated with Ajax, that showed you how the post was going to look like. Well, that’s gone. Now there are two options: some retarded WYSIWYG box, that I tried to use and failed, and some good old textarea… without the damn live preview. That sucks big time, because there is no other preview (that I have seen: please enlighten me if there is indeed one), so I just blindly write things in a Wiki format, and hope that it’s going to look OK when I press “Publish”.

Second, I was playing with the Wiki format for the articles, and I changed it to “Markdown” (I always mix “Textile” with “Markdown”, and never remember which is which; the one I prefer is Textile). After I hit “Save”, not only the next article was parsed in Markdown format by default, but every single blog post. It’s like, you select the parser the system is going to use to interpret your whole blog. How retarded is that? Once you have written posts, it doesn’t make sense to change their syntax (unless you do it manually editing the post itself). Clearly the format is a property of each blog post, not of the whole blog installation.

Not everything is bad though: it seems that now you finally have a “Draft” concept, so I can start writing a blog post and just save as a draft, instead of unticking the “Online” property and saving as a normal post. Also, the drafts are saved automatically, so I don’t have to remember to hit “Save” from time to time just in case the browser crashes or I hit something stupid and erase the contents of the post. Yay for that.