Living with Complexity
Donald Norman
This book is about designing systems to cope with complexity. The real focus of the book is the idea that complexity can’t be removed or decreased, but it can be “moved” around. When we complain about complexity, we are really complaining about complicated and confusing situations which make it hard for us to do what we want to do. Complication can be eliminated; complexity can’t. The question that a designer faces is this: who must deal with the complexity?
A focus on our interaction with technology masks the kinds of complexity that humans commonly master. For example, it takes years for us to master our bodies well enough to walk, climb, run, swim and speak. Learning to read takes years and math takes longer. A very complex organ (brain) must develop to do these complex tasks. Learning to ride a bike requires mastery of a complex task, but that barely prepares us to learn another complex task – driving a car. Mastering a complex task may be frustrating during the process, but it also generates a sense of pride, and then complacency (few adults feel especially proud because they can ride a bike). Professionally, learning a complex set of skills provides status in a way that learning a simple skill does not.
We rarely complain about complexity in the natural world – and often enjoy it. We typically complain about excess complexity in the made-world because it makes it hard for us to do what we want to. We are confused about what to do or about whether we are doing the right thing or how soon we will be done. We also dislike solutions that are too simple; a middle level of complexity allows us to show some mastery but does not keep us from achieving our objectives. When we discuss complicated processes or devices, we are actually discussing a psychological state – not an objective state. Eliminating complication involves changing our perception of the situation. Good design can help tame complexity, not by making things less complex – for the complexity is required – but by managing the complexity.*
Why do we experience so many complicated systems and devices? One major reason is that they are designed by technically trained people who are more concerned about the welfare of their machines that the welfare of the people who will use them. The logic of the machines is imposed on people. When Norman says “technical”, he is not limiting himself to science and engineering, and “machines” may not be mechanical devices; almost any artificial domain like accounting, law, language or social interaction could be included. Often, the people who design things have mastered that domain to the point that they have lost the sense of what a novice experiences – they do not empathize with the user as much as with the system.
Norman proposes some principles for designing in complex systems.
- Make things understandable to the user – communicate.
- Help the user connect their past to the present and the present to the future.
- Don’t use error messages. Nature does not have error messages. Computer games generally don’t either. If there is a problem, have the “system” explain the required action.
- Create “signs” to communicate what is needed. Larger buttons, brighter colors, and special symbols can provide guidance to users. Signs come in many forms; many are hints about how to proceed and thus part of communicating.
- Add structure. Break things into simpler modules or steps. Automate activities that do not involve ambiguous situations and decisions. Introduce “forcing functions” that communicate the best way to proceed; these can be subtle or intrusive depending on the context.
- Provide learning aids for the user, specific to the situation; rather than a big manual - provide just-in-time help.
While some of the problems of complex systems can be minimized, we must also accept that we will always face some complexity and complication. The real world is complex and we often benefit from the complexity. When faced with complexity, it may simply indicate that we have to develop greater skill or knowledge to eliminate the complexity. Even the most complex things are simple to those who have mastered the structure, understood its operations, and have a cohesive internal understanding – a good conceptual model. Simplicity is in the mind.
The remainder of this summary will discuss some of the examples from the book (including some elaboration of the content above). The book contains some long essays about specific complex situations and ways that these can be addressed. Some examples illustrate the extent to which we handle complexity and the amount of effort that has gone into taming that complexity (or where people have obviously not applied themselves to the problem).
For example, consider the purpose of remote controls. A typical remote control may have 40-50 buttons, and most users only use about 10. But many people have 3-7 devices, each with a different remote control. Controlling your entertainment system could involve 120 to 350 buttons. But creating one remote to control them all with just a few keys (say 20) might severely restrict what the remote can do across the collection of devices. Creating simpler individual remotes (fewer buttons) might make operation more complex (holding buttons for different time periods or pushing one button different numbers of times) to access the features of the device. Forty years ago you could turn a TV on/off, change the channel or volume. Simple! But today, you also choose inputs (game console, cable, VCR/DVR, computer, etc.), outputs (speakers, headphones, TV, etc.) multiple modes (forward/backward, 2x, 3x, etc.), and that is just the basics. When we look at all of the things that we want to do with a remote, maybe we already have the simplest option. If we wanted less functionality, we would get a simpler remote – but we want that functionality.
Many people assume that there is a trade-off between simplicity and complexity. If I want something with more features, it must be more complex (and a complex thing can’t be simple). This is false. Remember that simplicity is in the mind. The trade-off assumes a “zero-sum” game; to get more simplicity one must get rid of complexity….Complexity is often necessary. The design challenge is to manage complexity so that it is not complicated. A dirty little secret in the design world is that people like to complain about complication, but they often reject simplicity. People replaced simple cell phones with complicated “smart” phones. Cars, household appliances, TVs, and media are all more complicated than a decade before. Work processes tend to become more complicated and are just as prone to “featuritis” as any personal electronic device.
Designers have a few approaches to making a complex system less confusing. Perhaps the single most important approach is the conceptual model. An example is the computer “desktop” and “folder” system. There is no desk top or folders in the computer itself, but this concept makes it easy for us to frame what we want to do and the software hides the complexity of the actual data storage from us. We would use computers very little if we needed to track disk sectors where data were stored. There are lots of conceptual models. For example, we understand waiting in line, pyramids of increasing or decreasing desirability, recurring cycles, and toolboxes. Norman spends time describing how a phanishing hammer illustrates a conceptual model. This hammer is used by a silversmith to smooth out a surface after initial forming and has a curved and polished striking surface. The tool itself is simple. But it is one of about 60-100 hammers that a silver smith uses. The knowledge of which hammer to use for any task is complex, but the tools are simple. In addition, master craftsmen make new tools as they face new tasks. For the craftsman, these new tools simplify some task that is hard. But all of these hammers fit into a conceptual model related to shaping a firm material by striking it. When the user understands the conceptual model, it is easier to understand (or figure out) what to do. The conceptual model must be big enough to encompass the system that the user sees. We can then devise tools to make work simpler or more effective; the paradox of the quest for simplicity; to make our lives easier, we need more powerful, more complex tools. Complexity can be tamed, but it takes considerable effort to do it well.
Tessler’s “law” states that, “Every application has an inherent amount of irreducible complexity. The only question is who will have to deal with it, the user or the developer.” When you encounter a confusing process or product, it is possible that the developer left the complexity for the user to cope with. A good designer seeks to minimize the user’s confusion. Simplicity (or complexity) depends on perspective. So another way of describing the value of a conceptual model is that it provides the user with a helpful perspective on how to use the product or process to achieve their goals. The right conceptual model makes it easier for the user to use what they already know to help them act. When we recognize the model (say the concept of a folder system), we can anticipate how to use it and need only learn a few things (double click, right click, naming rules) to be fully capable. With a good conceptual model, you recognize what comes next. Complex actions are not confusing because they fit the model. A brand new model though can make a series of simple actions very confusing. Many new cars use in-dash screens to control car functions, but they are disconnected from our experience of driving (or anything else). They convert formerly simple, safe operations into potential distracting ones requiring you to read and interpret options.
A common way to build a conceptual model is to provide visual signs (think of a sign in this context as some sort of signal – not just a graphic). We are surrounded by these signs some of which are obvious and some which are not. If you have ever seen a shadow board where the outlines of tools are painted to indicate where the tools should be stored, you have seen such a sign. The conceptual model is every tool in its place and a place for every tool. A handle on the side of the door you are to pull and a plate on the side you are to push is a similar sign. Consider deciding whether an unfamiliar door is locked when you can’t see the bolt. Is the knob on the bolt supposed to be vertical or horizontal? It might be different on different doors or with different hardware. A design solution is to make a mark on the hardware so that the latch and line are aligned when the door is locked. If your lock designer did not think of this, you can apply a small colored dot at the appropriate point and achieve the same end. Signs like this work very well – until something changes. It is not unusual to find out-of-date signs that now add to confusion. The book had a photo from a hotel in which a door had a sign on if that said “not an exit” and on the wall above was found a lighted exit sign.
Signs are commonly used to increase safety. In some countries, emergency stairwells have gates on the ground floor to prevent people from descending into the basement in a fire. It is easy to open the gate if you want to go to the basement, but the hindrance is sufficient to direct people to the exit and not the basement where they could get trapped.
Another way to help a user is by creating a “forcing function”. This is a limitation that is given to the user that makes a complicated situation simpler. One of the most interesting aspects of this book (and which is hard to convey) is the wide range of examples of complexity that look simple on the surface. The author and his wife were constantly running out of toilet paper at inopportune times. To eliminate this problem, they bought a dispenser with two rolls (side-by-side). They soon found out that they still ran out of toilet paper but with a bigger interval. In seems that there are three rules that could be used in deciding which roll to take from. You could take at random, always from the bigger roll or always from the smaller roll. When asked, most people choose to take from the bigger roll; some will choose random. The best option for insuring that there is always toilet paper available is to take it from the smaller roll. In this system, there is no forcing function. Manufacturers have tried to solve this problem by creating a forcing function through stacking of the rolls so that the second roll is only available when the first roll is consumed. One nice property of a properly designed forcing function is that the correct behavior minimizes the need for problem solving or decision making: the person is gently nudged toward the appropriate behavior. This requires that the designer show empathy for the user.
Nudges are a form of forcing behavior. If you see people forming a line to get a service, you get in line too – you don’t just crowd forward. Many companies now automatically enroll new employees into a retirement savings plan while giving them a choice to opt out. Some governments automatically enroll applicants for driver’s licenses into organ donor lists with the ability to opt out. These nudges increase savings and organ donation. In the past, people had to take action to enroll, but now they must actively opt out.
Cultures are complex influences on us and can increase or decrease the complexity of getting things done. For example, some cultures use lines to determine who gets served first. Other cultures do not. If you are from a queuing culture, the crowds in a Chinese rail station are a hindrance to getting things done. Chinese people might wonder why the line moves so slowly (interesting note: studies have shown that either approach serves the same number of people in about the same time. In lines, you wait a lot with no progress on your task. In crowds, you get little bits of progress spread out over time. Lines or crowds are a cultural choice – not a functional one.) Within a line culture, it is easy for a designer to create signifiers that guide a person to the right line at the right time. This simplifies, but for a person from a crowd culture, it might be more confusing. Salt and pepper shakers can be another example. They tend to look similar and often differ only in the number of holes in the top. Ask somebody to determine which is which, some say that the one-hole shaker is obviously for salt. A person from another country will say the opposite. One Amsterdam restaurant always placed the salt shaker closer to the entrance (the salt and pepper shakers were identical). Given this ambiguity, many diners shake a bit out into their hand before seasoning their food. A simple work-around for a generally poor design.
A good designer has empathy with the future user. What will frustrate users when things are working well and what will frustrate them when they don’t? Part of the problem is that designers are cut off from users. They may think their main audience is similar experts. Database designers may not consider the users at all. Lawyers may be writing agreements and contracts (thinks terms and conditions) for judges – not the people who must agree to them. In these situations, the designer takes the “machines” point-of-view and ignores the user. This is detected by the user who can’t accomplish what they want without trouble.
As more tasks are addressed by technology, the lack of system thinking and empathy will have greater impact. People will need multiple tools to do their own complex work. People may change their objectives in the middle of the work, and thus the tools that they need to use. If designers do not understand the context and flexibility of the system of tasks, they will design their tools in ways that don’t work together. It is common to find people creating their own interfaces between different systems because the designers did not understand that the users would need to “translate” inputs and outputs from one tool to another. This is an example of imposed complication.
Empathy is critical because you can’t just ask the user what the problem is. They user will describe a series of symptoms that bother them without describing the core of what they are trying to achieve. While talking to a user is helpful, it is not sufficient. Observing the user may be much more useful in understanding the activity and its context. Apple iTunes observed that users did not want to buy sets of songs, but individual songs (they would buy an album but only record 1-2 songs). The users wanted to store these songs on a device that would allow them to be played in any order. Users did not want to have to load a song onto one device in order to load it onto the final device. And users did not want to be fined for having electronically stored music. Watching people load music onto other devices taught Apple how to design the iPod and iTunes offerings to decrease the hassle of the user. There were other devices and downloading services in the market. Apple mastered the interface between them and became dominant. Cohesive systems, total experience, and focus on the weakest link became principles guiding subsequent designs. This example shows how the line between a product and service gets blurred. An iPod is both a product (physical device) and service (easily managed portable music). Empathy allows you to see the real job being done – not just the superficial tools and processes being used.
Implicit in the preceding example is the idea that many problems arise at interfaces. Machine-to-machine or person-to-system interfaces cause problems. In some studies of doctor record keeping, it was found that a doctor might see a patient for 15 minutes and then 20 minutes entering information into the records. Medical care is a service, but a visit to a hospital reveals a world of devices interacting with the patient and other systems. All of these interfaces represent potential problems. This is true in many other situations. The interfaces are where problems arise – not the individual components themselves. Service design is about procedures – which means they have to be analyzed in action. Less money is invested in the study of services than in products, even though many companies succeed or fail on the quality of their services….disfunctionality and formlessness are not unusual in this sector; endless waits, broken appointments, unfriendliness, unreliability as well as the torture of formalities that seem absurd determine the everyday service from the customer’s point of view. And the suppliers of service moan about the customer’s lack of price willingness, about unreliable loading factors and unmotivated service employees. It is often hard to measure action at interfaces and thus the cost of poor interfaces can often be missed during analysis. By taking a more systemic view of a process and exchanges, problems can become more visible.
A classic form of interfacial problem is waiting. Whether waiting in line to check out of a store or waiting on the phone for help, it seems like pure waste for the person waiting for help. Norman offers six design principles for waiting lines.
- Provide a conceptual model – Let people know that they are in the “right line” so that they do not feel uncertain during the wait. Nobody wants to get to the front of a line only to realize that it is the wrong one.
- Make the wait seem appropriate - When the wait is due to factors beyond control (bad weather), waiting is more acceptable. Providing feedback and a sense of progress during the wait can make a big difference to those waiting.
- Meet or exceed expectations - To wait and then be poorly served is the worst. If the service is great, then the wait was not too bad.
- Keep people occupied – Some theme parks break a line up into groups and provide introductory activities. People don’t realize that they are in line; they think they have begun the experience. Some places give people a pager and send them off to do other things with an estimated time of entry.
- Be fair.
- End strong, start strong – We remember outcomes more than process. If the experience ends well, that is what we remember. A good start and finish can overcome a poor middle.
The book spends a lot of time discussing the various ways that lines can be designed. One of the surprising things about this discussion is the complexity involved in something as simple as managing a line of people waiting for help. This complexity gives rise to a large number of approaches to line management that we see in service environments. From parallel checkouts to admission windows, lines are being managed to decrease the frustration and feeling of waste. While nobody would say that the situation is optimal, it may be useful to consider the ways these lines could be worse.
Simple things do not stay simple. When a new “technology” appears, people take some time to master the technology and then they ask for more. It remains simple for them and becomes more complicated for the next person learning the technology. We must be aware that some of the complication that we experience is the consequence of our developing mastery. Complexity is conserved, we just move it around with out technology.
Comment and interpretation:
- I have been hearing a lot about simplicity lately, so I wondered what this book might have to say. I had two main take-aways. (1) We don’t complain about complexity that we create or that is part of our “normal” life. There is a degree of complexity that causes us no trouble because it is simple for us (even if not for others). (2) As I began to read, I realized that complexity is something that we manage in both product development and process development. In particular, I began to wonder how we could design work processes that felt less complicated. For me, this was the big idea. Once we understand something and are not confused, we are not bothered by complicated processes or tools. It is the feeling of confusion that we need to eliminate.
- I had a recent conversation about “tools” associated with a particular problem discovery process. My colleague expressed a concern about having too many tools. I was thinking about this concern and thought about the fact that many of the scientific advances in the last 50 years have been all about the tools. Decades ago, a major part of scientist training was in making tools. I learned some machining, electrical repairs, plastic assembly, and micro-plumbing. Others learned glass blowing, electronics and programming. The right tool makes the work easier and more accurate. A good scientist uses both general and specific tools. No doubt every professional has a similar mix of simple and elaborate tools that are perfectly obvious to them; some of which them made for themselves. I wonder if the comment about too many tools reflects the differences in the types of situations that I must deal with and the types they must deal with. The book gives the example of the many hammers used by a silversmith.
- I was recently recruited as a “user” during the development of a web portal. It was interesting because the portal had many stakeholders with many different perspectives on the purpose of the portal. Some sought to increase motivation. Some sought to provide “training”. Some wanted to increase collaboration. I just wanted to get to the toolbox. This was a complicated set of desires and the resulting portal was probably imperfect from multiple perspectives. However, from a process point of view, it was interesting that the developers collected all of these perspectives, prepared prototypes and then asked users to test them. The portal clearly evolved through this process and is probably acceptable to all. In one of the final tests, I was given a chance to drive myself through the portal to seek what I wanted to find. It was good enough to meet my needs and simpler to use than earlier versions. But they did not remove content – they organized it better as they understood how various users saw the system.
- Norman spends a few pages talking about passwords and computer security. Two really common passwords are “password” and “123456”. IT admins work hard to eliminate such passwords and often impose more complication onto the words. In response, people write them down and put them onto their computers – making them possibly even less safe. I’ve read that this problem could be effectively solved by simply increasing the length of the password and eliminating case, number and special characters. The password XXXXXXXXXXXXXXXXXXXX would be almost uncrackable (this is not my password).
- People setting up a process (like a business process) usually seek some particular outcome – often greater efficiency in execution. Business processes lose efficiency over time usually because they are adapted to do more than originally intended or to apply to situations that were not originally present. This is how evolution acts. But from the perspective of the original process – it becomes inefficient. So designers begin to revise the process. It seems commonplace that the designers do not consult with actual users. They might consult with managers or executives (powerful stakeholders), but they show little interest in the users who will be expected to use the new process. It is hard to believe that the designers understand the work or have any empathy for the users. It is more likely that they are experts in the computer processes and systems that will be used than the work that will be done with the system. It is a shame that they cannot share in the frustration, inefficiency and mistakes that arise because the designers did not think about the work that actually was done.
- Software offers good examples of both excess complication and high-quality understanding of the user’s world. Some software is created as a closed world where everything is hand entered and outputs can’t be read by any other software (so hand entering is required in the next step too). Other software is designed to offer easy data uploading and result exporting in common formats. The closed world software companies often suggest that you could do everything that you want in their system, but they don’t understand the preceding or succeeding steps of the user. In one particular case, using the software requires tracking of dozens of unique codes and operations, learning a unique series of icons (that do not resemble common icons), in a system that has no help function and restricted system visibility. The system was designed from the perspective of the software – not the users.
- We don’t usually think about service in the context of an internal corporate function, but it probably is. Research, finance, and marketing are services provided within the organization. When we talk about business process design we are talking about service design. Many internal processes seem wasteful and complicated to insiders. When internal processes are visible to customers, they often seem even more wasteful. Decreasing the complication of business processes is a good slogan, but it must cope with both the systemic, interactive nature of internal processes and the fact of conservation of complexity. Who is going to suffer so that someone else has it easier? The failure to see the systemic effects of interacting systems leads to internal announcements about simplification or efficiency that hide the fact that the problem is just be shifted from one group of people to another.
*text in italics is quoted directly from the book.
Recent Comments