jump to navigation

The Design of Everyday Things 08/03/2007

Posted by admin ppi-um in Bedah Buku.

Book Review: The Design of Everyday Things

Donald A. Norman
The Design of Everyday Things
Basic Books, 2002
ISBN: 0465067107 (Paperback)


Don Norman has a background in both engineering and the social sciences, with both academic and industrial experience. He is currently Professor of Computer Science at Northwestern University and Professor emeritus at the University of California, San Diego. He is active as co-founder and principal of the Nielsen Norman group, happily engaged in advising numerous companies on products and services for consumers. He was an Apple Fellow and Vice President of the Advanced Technology Group at Apple Computer, and an executive at Hewlett Packard and UNext (Cardean University), a distance education company. (From Don Norman’s Website, adapted)


Don Norman’s “all-time classic” book The Design of Everyday Things has recently become “required reading” for SAP User Experience. And – shame on me – I have to admit, I hadn’t read it up to now, even though it’s been on the bookshelves since 1988 (first under the title “The Psychology of Everyday Things” or POET) and available in paperback with the current title since 2002. Well, I finally read the book, enjoyed it, and thought that other people should profit from my reading. However, reviewing a book that has sold more than 100,000 copies seems somewhat “outdated,” and there are probably reviews galore. Therefore, I decided to write a “subjective” excerpt of and comment on this book. As there is no such category on our site, I am publishing it in the “reviews” section.

First a few words on the book’s title The Design of Everyday Things. Maybe it’s because I have been familiar with Don Norman’s writings as a cognitive psychologist for so long, or because I worked in the cognitive psychology domain for many years, but the original title seems more appropriate than the new one – which reflects Don Norman’s own shift towards design. In my opinion, the proper title should lie somewhere in the middle, such as The Psychology for the Design of Everyday Things or the The Psychology of Everyday Things for Guiding Design, but that would be far too long and never pass the marketing department… Anyway, this is book about users, that is, people (for understanding we need to consult psychology), things that are used by them, and designers – again people, who design things for people (that is, for users, customers, themselves, …).


Norman’s book consists of seven chapters. Here is a summary of their contents.

In chapter one, The Psychopathology of Everyday Things, Norman sets the stage and confronts his readers with examples of pathological design (doors, faucets, cars, thermostats, …). As everybody know, these are fairly easy to find. He introduces concepts, such as affordances and conceptual models (which are a breed of mental models), and fundamental design principles, such as visibility, mapping, and feedback. Norman’s use of the term affordances, which was originally introduced by J. J. Gibson, caused controversial discussions. In Norman’s understanding, “the term affordance refers to the perceived and actual properties of the things, primarily those fundamental properties that determine just how the things could possibly be used: A chair affords support and, therefore, affords sitting.” The term was rapidly picked up by the design community. In his article Affordance, Conventions and Design (Part 2), Norman objected to the “misuse” of the concept in the context of user interfaces for computers. Therefore, I refrain from providing an example of affordances for UIs. More on this issue in my comments further down.

The Psychology of Everyday Actions starts with “naive physics” as an example of conceptual models. People use simplified, naive models to understand the world and explain what things can happen and why. As an aid to a better understanding of how people do things, Norman presents a simple model, the “seven stages of action:”

  1. Forming the goal
  2. Forming the intention
    — Gulf of execution —
  3. Specifying an action
  4. Executing the action
  5. Perceiving the state of the world
  6. Interpreting the state of the world
    — Gulf of evaluation —
  7. Evaluating the outcome

This model suggests two obstacles to success:

  • The gulf of execution, standing for the discrepancy between what users want to do and what they are allowed to do, and
  • The gulf of evaluation, standing for the users’ efforts to interpret the physical state of the system and determine how it matches their expectations and intentions

Norman promotes his model of action as a design aid, because it leads to a basic checklist, which can help to bridge both the gulf of execution and the gulf of evaluation. The questions in the list more or less “boil down” to the principles of good design, which Norman introduced in the first chapter: visibility, good conceptual models, good mappings, and feedback.

In Knowledge in the Head and in the World, Norman points out that we apply knowledge, which partly resides in our heads and partly in the environment. Knowledge in the world relieves our memory in several ways: Information is in the world and need not be stored in memory. Memory can therefore be less precise. And as the subsequent chapter will show, physical as well as cultural constraints further limit the number of allowable actions. All this leads to the paradox that precise behavior can result from imprecise knowledge. Both types of knowledge have their tradeoffs, though. Designers should keep in mind at least one simple rule: “Out of sight, out of mind.”

With all our memory limitations, how can we really know what to do? In Knowing What to Do Norman gives away this secret and explains how different types of constraints narrow down the range of possible actions: We can rely on physical, semantic, cultural, and logical constraints. Turning to practice, he then applies the notions of affordances, constraints, and mappings to real-world examples: doors and switches. He also discusses how the principles of visibility and feedback (which are, of course, related) help achieve better designs.

To Err is Human is devoted to errors. Norman distinguishes between slips and mistakes: “Slips result from automatic behavior, when subconscious actions that are intended to satisfy our goals get waylaid en route. Mistakes result from conscious deliberations.” He classifies slips according to: capture errors, description errors, data-driven errors, associative activation errors, loss-of-activation errors (which normal people know as forgetting…), and mode errors (for descriptions, see below). As Norman views mistakes as errors of thought, he discusses various models of human thought, among them connectionist models (which I was interested in for a while).

In The Design Challenge, Norman introduces evolutionary design but dismisses it because it is too slow for today’s industrial processes. In a case example, the typewriter, he demonstrates that “once a satisfactory product has been achieved and is widely adopted, further change may be even counterproductive.” Then Norman focuses on designers and asks why they sometimes go astray. He believes putting aesthetics first is one of the reasons. He then talks of the many pitfalls that lure designers, using the faucet as another case history. Finally, on page 177 of 217, Norman turns to computers and discusses some of the design challenges that computers present. He never promised that this would be a book about computers but all of the design principles presented are valid for computers as well – it is just that computers can be frighteningly more complex than any other “thing.”

The last chapter, User-Centered Design, aims to point the way to a new, user-oriented design philosophy. As far as I know, the term was coined for the first time here. Norman more or less reiterates the concepts and principles presented in the book, introduces three conceptual models – the user model, the design model, and the system image – and provides useful advice on how to simplify the structure of tasks. For readers with little time to spare, my advice would be: Read at least this chapter. Here, you will find the “essentials” of the book, but, of course, you will miss the many useful real-world examples and explanations. Last but not least, Norman provides a somewhat pessimistic outlook on the “home of the future” – I wonder whether he ever saw Monsieur Hulot in Tati’s legendary movie “Mon Oncle” …


I would like to add a few comments on some of the not so common concepts presented in the book. I will not comment on visibility and feedback, because these principles are so well known and obvious – but nonetheless often violated.

Conceptual Models

Conceptual models are mental models of the working of devices. They allow us to predict the devices’ behavior, the effect of our actions on them, and to come up with explanations. Norman distinguishes between three conceptual models: the user model, the design model, and the system image. Conceptual models need neither be complex, complete, nor even correct. It is therefore important that designers provide a suitable model of the system. Their internal model of the design, the design model, is conveyed to the user through the system image. This, in turn, is the basis for the user’s model, which ideally should coincide with the design model so that the user understands the designers intention. This is why Norman calls the system image critical.

Using a different “language” in her book The Semiotic Engineering of Human-Computer Interaction, Clarisse Sieckenius de Souza focuses on the dialog between designer and user and talks of the system image as “the designer’s deputy” who is telling the user:

  • “Here is my understanding of who you are, what I’ve learned you want or need to do, in which preferred ways and why. This is the system that I have designed for you, and this is the way you can or should use it in order to fulfill a range of purposes that fall within this vision.” She continues: “This message is encoded in one or more signification systems … specially designed to enable user-system communication and is conveyed through the system (channel or medium) itself.”

In his article Affordance, Conventions and Design (Part 2), Norman argues that the underlying conceptual model is the most important part of a successful design. He calls it “the hard part of design: formulating an appropriate conceptual model and then assuring that everything else be consistent with it.”

Natural Mappings

The term “mapping” refers to the relationship between two things. In the context of design it is the relationship between the movements of controls and the results in the world. Natural mappings take advantage of physical analogies and cultural standards, leading to immediate understanding. For example, if you move the mouse on the mouse pad left or right, you move the mouse pointer left or right. Often, however, there are no such correspondences, and difficulties result. For example, would you turn a faucet lever clockwise or anti-clockwise in order to change the temperature of the water? Sometimes, cultural constraints (conventions, standards) can be established to overcome these issues. Turning the faucet clockwise seems to have become a standard for increasing water temperature.

In user interface design mapping problems abound. I had my worst experiences with 3D graphic programs, but even the functioning of ordinary scrollbars may not be evident to the uninitiated user because the window content scrolls in the opposite direction to the cursor movement.

Constraints and Affordances

Constraints are physical or other properties that limit the universe of possible actions to often only a few, particularly, when acting in combination. Physical constraints, for example, may “constrain” the possible movements of objects or their parts. As a simple example, a train can only travel on its rails, otherwise it will run into severe problems. Semantic constraints refer to the meaning of objects or situations and thus may limit the number of interpretations of situations, for example, the observation of UFO appearances or less obscure events. They rely on our knowledge of the world. Cultural constraints are based on cultural conventions and these may no longer be valid when applied to foreign cultures. Finally, logical constraints are based on the rules of logic, provided these can be applied… By the way, Norman counts natural mappings as logical constraints.

In UI design, there are many constraints. I would consider the numerous UI standards as cultural constraints. Conventions that differ between cultures, such as the meaning of colors or the use of graphics showing faces or body parts, are often a source of misunderstandings. Many designers are unaware of them because they lack experience in these matters.

In his article Affordance, Conventions and Design (Part 2), Norman distinguishes between real and perceived affordances. He writes that if he were to ever publish a revised edition of POET, he would replace each occurrence of “affordance” with “perceived affordance” (see note), because that is what the book is really about: “The designer cares more about what actions the user perceives to be possible than what is true.” Norman adds: “Moreover, affordances, both real and perceived, play very different roles in physical products than they do in the world of screen-based products. In the latter case, affordances play a relatively minor role: cultural conventions are much more important. … In graphical, screen-based interfaces, the designer primarily can only control perceived affordances. The computer system already comes with built-in physical affordances. The computer, with its keyboard, display screen, pointing device and selection buttons (e.g., mouse buttons) affords pointing, touching, looking, and clicking on every pixel of the screen. Most of this affordance is of little interest for the purpose of the application under design.”


Figure: Many designers would say that a button affords to be clicked (left) – Norman objects to this use of the term; even if the cursor changes its shape to indicate a click option (center), he would call this a cultural convention that has to be learned. The only “acceptable” use of affordance in this context would be the physical constraint that the cursor cannot leave the screen (right)

Norman continues: “Far too often I hear graphical designers claim that they have added an affordance to the screen design when they have done nothing of the sort. Usually they mean that some graphical depiction suggests to the user that a certain action is possible. This is not affordance, neither real nor perceived. … It is a symbolic communication, one that works only if it follows a convention understood by the user.”

With respect to constraints, Norman explains: “Physical constraints are closely related to real affordances. … Logical constraints use reasoning to determine the alternatives. … Cultural constraints are conventions shared by a cultural group. … Symbols and constraints are not affordances. They are examples of the use of a shared and visible conceptual model, appropriate feedback, and shared, cultural conventions.”

Normal concludes his article with the plea neither to confuse affordances with perceived affordances nor affordances in general with conventions and goes on: “Affordances reflect the possible relationships among actors and objects: they are properties of the world. Conventions, on the other hand, are arbitrary, artificial and learned. Once learned, they help us master the intricacies of daily life, whether they be conventions for courtesy, for writing style, or for operating a word processor.”

Please, excuse the inclusion of lot of citations …

When All Else Fails, Standardize

This heading encapsulates Norman’s advice and solution to the many mapping problems that cannot be solved by correspondences or where the optimal solution may not be obvious. The problem with this approach is that everybody has to agree on the standard and adhere to it. UI design is an example of standards which are not generally agreed on and adhered to – that’s why we need user experience and usability people (see, for example, the position of the default button in Windows and on the Apple Macintosh).

Error Types and Other Classifications

When reading the book, you will easily recognize Norman’s background in science: a classification here, a model there, and so on. What’s the point of all these classifications? Isn’t it enough, for example, to watch users committing errors, find the reasons, and fix the issues? Yes, but you fix only singular problems. And no, because you can achieve much more. Classifications allow you to assign observations to categories, classes, or types – whatever you care to call them –, such as the error types provided by Norman. With respect to error types, the next step would be to count the errors in the different categories. This would allow you, for example, to prioritize error fixes. If you are lucky, you can even perform some statistics with the numbers. Categories also have advantages for design: Instead of fixing individual and, maybe anecdotal, issues you can set about fixing classes of problems, as described by a category, and come up with more general solutions to the underlying issues. Your fixes will simply cover more situations (singular fixes may do that as well, but you do not know how well they will work in general).

As an example, let me shortly describe Norman’s error types, as their names may appear somewhat cryptic:

  • Capture errors: A frequently performed action “captures” or takes charge of a rarely performed action – you end up doing something quite different from what you initially intended. These errors happen when two action sequences have their initial stages in common, with one sequence being unfamiliar and the other well practiced.
  • Description errors: The intended action has much in common with other possible actions; therefore, the intended action, if not clearly specified, may fit several possibilities. For example, long rows of identical buttons may cause description errors.
  • Data-driven errors: These errors are caused by automatic behavior, which is driven by data and “bypassing” consciousness. Highly learned behaviors are automatic.
  • Associative activation errors: Not only external events but also internal thoughts or associations may trigger the wrong action or association.
  • Loss-of-activation errors: This error type captures what normal people would know as forgetting… (its name refers to the activation of memory, which can get lost)
  • Mode errors: Mode errors occur whenever devices have different modes of operation and the action appropriate for one mode has different meanings in other modes. To direct attention to these errors, UI designers invented the motto: “Don’t mode me in!”

I wouldn’t say that this list is complete, but it is a good example of the approach to putting observations into categories.

Design for Errors

Error robustness is a requirement of the ISO usability norms. You can conform to this requirement in different ways: One way would be to design an application in which users cannot commit any errors. Typically, this means restricting the users’ actions and options to a minimum, making this approach only suitable for simple applications. Another way would be to overwhelm the users with error messages. This would put the burden on the users who get blamed for all the errors they make. Still another approach would be to list and describe the errors in the manual and let them go unnoticed in the application – there will be a time when the users finally recognize that they are on the wrong track… This approach would enforce the use of manuals, which typically remain unread. All these approaches do not look very promising.

As a psychologist, Norman, of course, advises designers to take error-prone human behavior into account: Design so that errors can do no harm, help users easily recover from them or undo them, support users and even guide them where appropriate. I would like to add, that designers should make more use of the “quirks” and “weaknesses” of human behavior revealed by psychology. This knowledge can help them deal with errors more smoothly and from a human perspective. Regrettably error handling is still mostly dealt with from a purely technical perspective, such as the need to cope with “improper” characters that the user has entered.

Final Word

I hope my excerpt and comments will not discourage anyone from reading the book. Instead, I would like this article to a useful guide for keeping track of the many fruitful ideas in the book. I must admit that I got lost from time to time. When I ha dfinished the book, I had to recover the ideas by going back in the book scanning the headings, and reading the table of contents (and by writing this article). Maybe it’s just my bad short-term memory, maybe some orientation guides would have been useful – even though they might have given the book a more “scientific” appeal. You will also realize that I left out a lot in my excerpt…



This reminds me of Prof. Bur-Malottke in Heinrich Böll’s novel “Doktor Murkes gesammeltes Schweigen” who required a radio station to replace all occurrences of the word “Gott/God” by the phrase “Jenes höhere Wesen, das wir verehren/That Higher Being whom we worship” in the tapes of his radio performance.


No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: