The Design of Everyday Things

Zdravko Tyankov INFO 110 05/25/2008 Textbook Journal

The Design of Everyday Things (Donald Norman)

Overview: Donald Norman’s book ‘The Design of Everyday Things’ is an enlightening source of information on design challenges, practices and possible solutions. It provides the theory behind the design process. It has a long list of valuable guidelines that a designer should follow when working on a new device, technology or system. The book is very rich on practical examples which support the author’s point of view. While reading this book I realized how easy it is to fall into the vicious circle of “understanding” the user and creating a design which is supposed to suit him, but in stead it suits me, as a designer. Most of the points that are expressed by the author are very intuitive and easy to understand, yet many engineers are not following them. Being a computer-science student, I’ve made designs of my own, some of them turned out to be very good, some not as good. At one point I remember arguing with my supervisor about the usefulness of an interface that I was working on. I liked it a lot and his point was that it wouldn’t be intuitive for most users, because it was different from what we’d used before… Now I realize that he was right. Even though the author focuses exclusively on things that we deal with on daily basis, just about all of his ideas can be used in more sophisticated designs. This book provides a solid ground for any design.

Chapter #1: The Psychopathology of Everyday Things This chapter serves as an introduction to the book and the design of everyday things. It gets the reader informed about some of the most important terms and principles that will be used through the book – visibility, affordances, constraints, conceptual model, natural mapping and feedback. Visibility: “Just the right things have to be visible” [Norman] – The author describes how visibility can make a design very easy to use, if incorporated correctly. Many designers are making mistakes when dealing with visibility. The reason for that, in many cases, is aesthetics – how good the design will look if parts of it are either invisible or blend with the environment. Designers tend to create beautiful things, they usually sell vey well, and leave usability behind. The author supports his point with the major examples – a friend trapped in the doorway of a post office and the complex modern telephone systems. Affordances: “… refers to the perceived and actual properties of the thing, primarily those fundamental properties that determine just how things could possible be used…” [Norman] - In this section the author focuses on the clues that transfer knowledge to the user regarding how something can be operated. When these clues are placed properly they can allow the user to operate the device without any additional instructions, labels etc. Actually if a simple design needs any instructions to be operated, then it is considered a failure. Constraints: These basically limit users’ actions. The incorporation of proper constraints can make a design less prone to error. It will only allow the user to do the “right” things. Conceptual Model: “A good conceptual model allows us to predict the effects of our actions” [Norman] – To make a good conceptual model the designer needs to make extensive use affordances and constraints. This makes the design easy to understand and operate. 2

Natural Mapping: Taking advantage of “physical analogies and cultural standards” [Norman] can lead to “immediate understanding” [Norman]. Basically the author says that there should be a clear relationship between a control and an action. It should be as intuitive as moving a control to the left should move the object to the left. Of course there are many designs which use poor natural mappings. This leads to a lot of frustration for the user. Feedback: “sending back to the user information about what action has actually been done, what result has been accomplished” [Norman]. The user should always be notified of what’s going on in a system. If no or minimal feedback is provided it will lead to the user redoing an action several times and/or even trying to do a different action at the same time. In most cases which will lead to a disaster. The author also talks about the improvements on technology and how it usually leads to the creation of more complex devices, with less visibility and feedback. Anytime when the number of functions is more than the number of controls the design becomes complicated for the general user.

Chapter #2: The Psychology of Everyday Things In this chapter the author tackles the psychology behind the use of everyday things, the way that a flawed design can affect its users and how to think about those designs. Many users tend to blame themselves, when they fail to operate a device properly. The author says in a very convincing manner that in most cases the user is not to blame; the fault is in the design. Reading this chapter made me think of all the things that I do every day that cause confusion or frustration. I realized how many designs that I’m already accustomed to, have a flaw in their design. For instance the light switches in my house have a flawed design. The rooms are in the following order: you go from the living room pass the staircase to the kitchen. On the first floor there are 2 switches, one for the staircase to the second floor and one for the kitchen. They are aligned in horizontal order. For some reason the one on the left (going towards it) is for the kitchen and the one on my right is for the staircase. On the second floor the switches are reversed. Strange! That same design works well if you’re coming from the second floor downstairs, but not the other way around or if you’re on the first floor moving from the kitchen to the living room or vice versa. Well I’m used to it now, but many of my friends that come to my house tend to have problems with that. I’m no longer frustrated with this issue, because I know that it’s a fault of the design. The author describes how everything should be designed for errors. If there is an error to be made, a user will make it. Therefore a design should make sure that no error is fatal and can be reversed. Another point in this chapter is how people tend to explain functions of a given design based on other designs or their perception of how it should work. The problem is that without proper feedback a user can make up a very creative assumption about what a system does; that can be completely wrong. The author supports his view with a nice example of a room thermostat. The different psychological problems are described in this chapter - “learned helplessness” [Norman] and “taught helplessness” [Norman]. The first one illustrates that when a person fails a given task multiple times he tends to agree that either the task cannot be done or he cannot do it; therefore he believes that he’s helpless. On the extreme some of the assumptions can lead to frustration and stress. Taught helplessness refers to the occasion when a user tries to perform a task and fails, he believes that it’s his fault. Usually this is accompanied with the fact that nobody else has problems with that same task. Next time he encounters the same task, he doesn’t even try. “The result is that you can’t, just as you thought” [Norman]. This is like a vicious circle. It is also important to mention that a poor design can lead to major disaster like the one at the Three Mile Island nuclear power plant. The cause was a faulty design combined with several misinterpreted signals. The operators based their judgments on faulty feedback and their previous experience. They basically found reasonable explanations for the faulty readings of the system based 3 on what they had encountered before. This is how ours minds work. They make interpretations based on previous experience. In this chapter the author specifies the seven stages of action – forming a goal, forming the intention, specifying an action, executing the action, perceiving the state of the world, interpreting the state of the world and evaluating the outcome.

Chapter #3: Knowledge in the Head and in the World In this chapter the author focuses on the different kinds of knowledge, the structure of memory and how we can remember information. This is useful because it helps you understand how information is stored in our memory and what methods can be used to make things easier to operate, remember and recall. This is important for a designer. He should make the interface or the functionality of a device easy to remember. This allows the user to come back and operate the device without the need for manuals and more explanations. Brief reminders can prove to be useful though. There are four reasons which allow precise knowledge to lead to precise behavior – “information is in the world”, “great precision is not required”, “natural constraints are present” and “cultural constraints are present”. The use of these constraints greatly reduces the number of alternative actions, which reduces the amount of information that needs to be stored. Basically every designer should try and use a combination of all of the above methods (reasons) while working on a new device, system etc. The author goes into great detail regarding how each reason method (reason) works. There are three important categories of memory – “memory for arbitrary things”, “memory for meaningful relationships”, “memory through explanation”. The first one is a rote learning technique. Basically this is how we learn the alphabet, the multiplication tables and all sorts of commands that need to be executed on a given system. The second one is used to store the structure of meaningful information. The last one keeps the explanations and interpretations of events. These are “fundamental to human performance, both in understanding the world and in learning and remembering” [Norman]. A helpful guideline in the aspect of recalling is to use reminders. “A good reminder method is to put the burden on the thing itself” [Norman]. Obviously these reminders should not be flooding the design; they should be intuitive and properly placed. For example if you need to return a DVD, you can put your car keys on it. Since you always leave with your car, you can’t possibly miss it on your way out. Natural mapping is also described in more detail in this chapter. Through natural mapping a design can become very easy to grasp and recall. When it’s done well it can make all operations very intuitive. The user doesn’t have to think a lot before performing an action, because it feels intuitive and natural to him. The author backs up his point here with an interesting example about the burner controls on a stove.

Chapter #4: Knowing what to do In this chapter the author focuses on the various types of constrains and affordances and the way to apply them to everyday things. In addition to that, the text expands on the topic for visibility and feedback. There are four types of constraints that can be applied to a design – physical constraints, semantic constraints, cultural constraints and logical constraints. Physical Constraints: Basically this type of constraint physically limits the possible operations. The value is in the fact that it relies upon “properties of the physical world for their operation; no special training is necessary” [Norman]. Physical constrains can be useful only if they’re visible to the user and easy to interpret. For example a well designed car key should work 4 regardless of its orientation. You can benefit from that when you’re in a storm with arms full of packages. Semantic Constraints: They “rely upon the meaning of the situation to control the set of possible actions” [Norman]. This means that the general knowledge of the situation and the world should limit the possible actions. For example the rider of a motorcycle should face forward and the windshield is supposed to protect his face. Therefore he won’t sit backwards. This is a general understanding of the situation and can be considered in a design. Cultural Constraints: These constrains rely upon “cultural conventions” [Norman]. Each culture has a set of actions which are allowed at different situations. This set of actions is interpreted as a cultural constraint. Using these constraints can be a powerful tool in a designer’s hands. For example the color of the stop light is culturally defined as red. Therefore it can be used in any design and will mean, to the user, the same thing. Logical Constraints: These constraints provide a logical relationship between function and action. Natural mappings work based on logical constraints. Logic connects “the special or functional layout of components and the things that they affect or are affected by”. The problem is that not many designers use natural mappings. In many designs look is more important than usefulness. Throughout the chapter the author describes various examples and provides feedback on how they can be improved. His focus is on the visibility and affordances issues with the simple things like - various types of doors and switches. In the end he mentions that many faults can be bypassed if a good display is added to the system. Unfortunately this addition usually costs a lot and is considered unpractical with cheap designs. In the last section of the chapter the author talks about sound and how it can be useful as a mean of feedback. But it needs to be added with caution because sometimes from useful it can become annoying.

Chapter #5: To err is Human This chapter is focused on the categories of errors that a user can make, the lessons that should be derived from those errors, some models of human thought, conscious and unconscious behavior and the ways to explain some of the errors that users make. A major point in this chapter is that to make error is human. Therefore designs should be made so they can minimize the causes for errors, make it possible to reverse an action, make it easier to discover the error when it occurs and provide ways to correct it. Our ability to generalize and draw conclusions from small amounts of information can be very helpful in new situations but it can also lead to errors. Some situations can look similar but they might not have the slightest relationship. There are two types of errors. Slips – small things which result from a mess up in the performance of a given task. They are easy to discover. Mistakes on the other hand can be major events which are very hard to detect because the action performed is appropriate for the given goal, but it’s wrong. There are six types of slips – capture errors, description errors, data-driven errors, associative activation errors, loss-of-activation errors and mode errors. The author has provided a very nice example for each one of them. Usually when people perform multiple tasks at the same time they can make the wrong associations for the given task at hand. For example when you call on the phone sometimes you can hear yourself saying “Come in”, in stead of “Hello”. You welcomed the person on the other side, but in the wrong manner. The author spends a reasonable amount of time describing how to detect slips and the lessons that need to be learned. Basically the designed system should be able to prevent some errors from happening, detect and correct others when they occur. 5

The new approach for dealing with human memory and cognition is called “connectionism”. It’s trying to explain how the brain works. Much of the knowledge that we have is hidden and can be triggered through various actions and situations. Usually we think of an example, come up with another example, then put them together in a story and believe that this story is true. The problem is that the story will be different depending on the examples that we chose. It’s important to use relevant examples in order to come up with relevant stories and relations. An interesting section of this chapter is the explanation of human error trough misinterpreting of situations, human logical explanations and social pressure. All information listed in the form of examples is reasonable. Many users are under pressure when they perform different tasks. People tend to come up with logical explanations for various system errors. Problem is that you never know when to pay attention to what the system says and when to logically reason it. This section got me thinking a lot about errors/disasters that have happened recently and what might have caused them. The section explaining how to deal with errors was also very useful to me. The author conveys his idea that warning signs and signals usually don’t do the trick when dealing with errors. In a power plant there are so many signals that can go off at the same that they will more likely confuse and stress the operators than help them. Therefore the author proposes the extensive use of forcing functions. They are a form of physical constraint, which prevent an action from happening if the previous stage of that action has failed. All of this is backed up with examples for car interlocks, lockouts in staircases and a gaming platform.

Chapter #6: The Design Challenge In this chapter the author debates on the reasons for engineers to create poor designs. He starts with the natural evolution of design. This is a process which requires a lot of time. Each stage of the software is studied well, the bad features are changed and the good ones are kept. If a change reduces the quality of the software then it gets reversed in the next version. Problem is that in today’s fast paced environment new models are already underway even before the old ones have been released. The current market demands speed and novelty. Therefore not many companies have enough time to contribute to natural evolution of design. With the typewriter example, the author conveys the idea that once a satisfactory product has been produced, no further changes should be made. Designers should know where to stop. Unfortunately companies need to make more money, therefore they go into extremes. On many occasions this leads to a new design which is worse than the one before… There are three main reasons for designers to go astray. First is that people like what they see and buy things for their aesthetics. Companies make things that can be sold; therefore they also focus on this aspect of the design. Second reason is that designers become experts in the use of the systems that they work on. Therefore they cannot see why their system would be hard to read for one group of people and confusing for another. The expertise levels for a designer and a user are different. Users are experts in the task that they need to perform with a given device. The third reason is that designers have to please their clients. The clients usually are not the actual users. All of these combined leads to designs which are beautiful and somewhat hard to use. For a good design engineers need to find the equilibrium between usability and aesthetics. Bad designs are produced when the main focus is on the cost, durability or the aesthetics. Norman calls this “the problem of focus” [Norman]. Next the author talks about flexibility in a design. There is no simple solution for everyone. Compromises have to be made. With a flexible solution you’re offering a chance for everyone to use your system. With a fixed design you’re just excluding that group of people that have special needs. “Selective attention” is another interesting topic that the author talks about. Designers usually attend the immediate problem and forget about the rest. This allows users to performs actions, 6 unthinkable by the designers, and get exposed to dangers. For example when a slice of bread gets stuck in a toaster, the user tends to use a knife or a fork to get it out. The problem lies in the fact that there are exposed wires very close to the top. A major point in this chapter states that “If you can’t put the knowledge on the device” [Norman], then you should “develop a cultural constraint: standardize what has to be kept in the head” [Norman]. This is backed up with an extensive example about sink faucets - the way they operate and the confusions that are caused by poor designs. A big thing in electronics and software development is to add more and more features with each new release. Even though it sounds great, adding new features adds another level of complexity to the system. The author calls this “disease” - “creeping featurism”. Norman offers two ways out of this. First one is to avoid the addition of new features, except for those that are absolutely necessary. Second one is the organization or “modularization” of the system - a “divide and conquer” approach. This makes each module simple on its own, because it contains only a limited set of features and properties. Another interesting section in this long chapter is the one about “How to do things wrong”. Here Norman has a list of things that need to be done in order to get a design all wrong. Of course this should be a list of things that designers have to avoid: Make things invisible – provide no feedback or visual result from an action Be arbitrary – make arbitrary mapping between intended action and executed action Be inconsistent – makes new rules everywhere Make operations unintelligible – use abbreviations and uninformative messages Be impolite – insult, snarl and mumble Make operations dangerous – allow one erroneous action to destroy invaluable work. The chapter ends with a section about explorable systems. These systems invite the user to explore their functionality without any danger for content or the user. Basically the user tries all the buttons to see what happens. There are certain requirements that need to be met in order to make a system of this kind.

Chapter #7: User-Centered Design This is the concluding chapter of the book. It works as a summarization which provides all principles, methods and guidelines in order to make a good design. In addition the author compiles a list of seven principles which allow for a hard task to be transformed into an easy one. Then he elaborates on each of those seven principles and the sub-principles behind them. Overall it’s a great ending for the book. But I can argue on several of the examples that are used in this chapter. For example I believe that spell-checking is actually making your own spelling worse. It is true that at first you remember some of the words that you’ve got wrong, but after a while you don’t even pay attention to those. Why? Because you know that the system will correct them anyways. So all you do is try to get most of it right and way for the correction. There is no learning in that, it’s sheer laziness. In this chapter the author spends some time on bigger problems like “Over automation” and how it can affect a person’s skills or job and the society. People should always have control and influence over what’s happening. Norman also talks about designs which are exclusively made to be difficult to operate. These are usually designed with caution in mind. The author provides an example with a school door for the handicapped. Since no student is allowed to go out without supervision, a design has been implemented which allows only teachers (not handicapped) to open the doors. Other types of systems which are made deliberately hard to operate are – security systems, dangerous equipment and operations, secret doors and safes, computer and video games etc. The final set of examples in this book is about future designs for a “smart house” and a “house of knowledge”. While these offer great sets of features and properties, usability is questionable. Will a designer be able to 7 make a system of this magnitude easy to use and operate? We don’t know yet. A lot of appliances have been automated with the use of computers, but so far there has been no successful full design of a smart house. We just have to wait and see.

Conclusion: In my opinion there are three main goals to this book. First one is to give us the fundamentals that can work as a solid ground for any design. The second one is to get us thinking about the flaws in poorly designed simple devices and systems, in other words to get us to look with a critical eye on the usability of a design. The third one is to get us more involved in the psychology of a design - to show us the user perspective and how various designs affect people. The author uses a hands-on approach which works wonders. The book is full of interesting designs. While most of them are flawed, because the author is using them to emphasize his point of view, there are some which are pretty unique and very well thought out. The casual style of the book makes it easy to read and comprehend. It offers tremendous help in understanding what our course is about. While working on our group conceptual design and prototype we tried to refer to and use the author’s guidelines as much as possible. Considering that we were making only a screenshot-prototype, some of them were not easy to incorporate. In the process of reading this book I started thinking more critically about the things that I do everyday. I started recognizing different design flaws in the simple things that I use on daily basis. On several occasions I would catch myself thinking “Hey, this is not right, it should have been done this way to make it easier for me – the user…”, and then I’d think “Oh yeah, I read about that in the ‘Design of Everyday Things’ textbook. Awesome!”. I’ve been interested in web design and development for quite a while now. This book gave me some great insights on things that I was doing, which were wrong from user and usability point of view, and things that I should start doing when designing a new interface or a whole system. Overall this was a great read. The final example of the invisible computer embedded in a personal calendar sounds really fascinating. It might take a few years to create such a system.

Task-Centered User Interface Design (Clayton Lewis and John Rieman)

Overview: The book by Clayton Lewis and John Rieman, “Task-Centered User Interface Design”, focuses on the physical process behind the creation of a design. It goes from the design planning process and the finding the requirements, through the creation of the initial prototype and finishes with the testing of the design with and without users. These two books combined, cover all the fundamental material that a designer should consider when working on a design. One cannot go without the other.

Chapter #1: Task-Centered Design This chapter acts as an overview of what the book is about. It goes briefly into the various procedures that need to be completed during the development of a new interface design. This chapter can easily work as a check list for designers who’ve just started working on a new project. The authors are mainly referring to teams of designers and programmers; therefore it shows that the focus 8 is on designs created by big companies. Even if that is the case, many if not all guidelines provided in the book should work with smaller projects as well. The chapter covers topics like the understanding of the end-user’s needs and the main tasks that need to be performed in the new system, the creation of the design and the different ways to grab conceptual ideas from other designs. People have already put a lot of effort in the creation of useful designs. It seems plausible to use some of their ideas in our own designs. In our group design project we also borrowed ideas from various websites and online search engines. The combination of ideas, those from various websites and ours, made for a very nice design. And important section in this chapter is called “Iterate”. It brings the interesting question “When should the iteration stop?” I find this to be interesting because with designing and testing you should always know when to stop. If you don’t then you’ll just keep on modifying and updating for ever.

Chapter #2: Getting to Know Users and Their Tasks This chapter emphasizes on the users – what is important for them, their needs and the tasks that they need to perform. All the information here is very important for any design. The chapter kicks off with an example about a group of people that start a design without knowing who’ll be using it and for what. It led to a disaster – no customers, no users, no money. Before starting any design people should think about the potential users. They should discuss with the users what they do and how the system can fit in. A typical problem in many designs is that the people that are sponsoring the project, the clients, are not the potential users; therefore you cannot go to them for information. You need to find the real users and gather requirements for your system. Sometimes it can be hard to do, but it’s important for any design. Unfortunately users don’t usually know exactly what they want. Therefore their requirements are not always easy follow. Users can usually say what needs to be done, but not how you can do it. Therefore further discussion on the requirements is needed. Another thing that designers should be cautious about is that users are not always right. The chapter goes over these problems and their possible solutions. A major topic in this chapter is the way tasks should be dealt with. The authors propose the idea that each task should be described in great detail. This way you can produce a scenario for each task. Often “a decision requires you to look beyond the specific examples you have and make a judgment about what will be common and what will be uncommon” [Lewis and Rieman], this statement is important because it shows that designers should think out of the box. Requirements are important but you should always try and show some creativity and question the requirement. Things change over time, requirements change as well. These changes must be taken into account, one way or another. The chapter ends with the “Specification” phase of the software development.

Chapter #3: Creating the Initial Design This chapter talks about the initial design and how to deal with it. The authors go into a discussion about the various interface frameworks and the advantages of their use. The chapter proceeds with information on how to implement ideas that have already been thought of. As a designer you should always try to incorporate as many previous ideas as possible and focus on the parts of the system which are new or unique. This is the only way for designers to actually improve on a system or create something innovative. Any design or a piece of it (ex: an interaction technique) that you find in another project, which is not copyrighted and suits your system, should be used. Experimenting with novelties can be risky; therefore you should try and get a solid ground, one that has already been proven to work, and develop on it. This minimizes the risk. The authors support their ideas with examples about Mac Paint and the toolbox that is used in it. An important part of an interface is the visual. Having this in mind the authors have dedicated a whole section on graphic design principles. Here they talk about various techniques for visually 9 organizing the screen in separate blocks, making frequently used controls obvious and easy to access, using similar screens for similar functions, not putting color as a medium for information and not cluttering the screen. All of these have proven their importance in the design of interfaces. We thought about some of these while working on the prototype for our group project.

Chapter #4: Evaluating the Design without Users The focus in this chapter is the evaluation of a design without users. Three ways are presented to the reader – “Cognitive Walkthroughs”, “Action Analysis” and “Heuristic Analysis”. All of the above are described in great detail. The chapter is full of diagrams and screens from actual designs. This makes it easier for the reader to understand in a more profound way how the evaluations work. Cognitive Walkthroughs: This is a “formalized way of imagining people’s thoughts and actions when they use an interface” [Lewis and Rieman]. Basically the designer, or group of designers, should pick a task from a given prototype and make a believable story about each action that the user needs to perform when dealing with that task. If at any point an action cannot be matched in the story it means that there is a flaw in the design. Action Analysis: This is an “evaluation procedure that forces you to take a close look at the sequence of actions a user has to perform to complete a task with an interface” [Lewis and Rieman]. There are two phases to this evaluation process. First one is to determine the physical and mental steps that a user needs to perform when dealing with a given task. Second one is to analyze each step and look for potential problems. There are two types of Action Analysis – “formal” and “back-of-the- envelope” analysis. Heuristic Analysis: Represents “general principles or rules of thumb that can guide design decisions” [Lewis and Rieman]. While the above evaluations methods are task-oriented, this one isn’t. Yet it can prove to be very important in the task-centered design, which is the main focus of the two authors. Heuristic Analysis is a task-free approach which catches problems that can be missed out from the task-oriented analysis.

Chapter #5: Testing the Design with Users This chapter emphasizes on one of the most important and most disregarded aspects of the design process – testing. Many big and small companies tend to either skip or go briefly through this process. Some do it due to lack of time, others don’t want to spend money on it, but in all cases the users suffer from it. It is important to find the right subjects for your testing. If the real users are supposed to be lawyers, you should get lawyers to test it. When you have the right testers you should give them a list of tasks that need to be tested. You should try and make your task list so that each line of code can be run through at least once. All major functions should be tested under various conditions. While testing is very important recording the results and using them afterwards can prove to be at least as important.

Conclusion: This book was also an interesting read but from a different point of view. The style used in it was more refined. The targeted audience was different. Even though there were many interesting examples that made the material easy to understand, there were still a couple of sections which were a little unclear. While Norman’s book was focusing on the theory and psychology behind a design, this was focusing on the physical process of going from a bright idea to a full fledged design. It emphasized on the various phases that need to be completed prior to the start of the designing process, during the development of the design and in the evaluation and testing of the prototype. A lot of thought needs to be put in the structure, graphical design and functionality of the new interface. The prototype needs to be iterated through a couple of times in order to achieve a functional/useful 10 mock-up design. A lot of the information presented in this book helped us improve on our group design project. We spent hours refining our screens. Overall this book was fun, but a little harder to read. It can be considered the essential continuation of Norman’s ideas.

Bibliography: #1 – Donald A. Norman – “The Design of Everyday Things” #2 - Clayton Lewis and John Rieman - Task-Centered User Interface Design