Bad Design – The Design of Everyday Things
In 2018 I got myself into a challenge of reading 52 books before the end of the year. So from time to time, you’ll find a book summary on Deesignre.
In this article, I will give a summary of the book “The design of everyday things” by Don Norman. It’s about why we should blame the designers when users make mistakes, and about how to make easy-to-use products. The first edition was written based on physical products, but very much applicable to digital interfaces as well.
Blame the designer and examples of bad design
When a user does not understand a product, he often blames himself and becomes insecure about his own capabilities. This is obviously something we want to avoid. The most famous example of bad design is the design of a door. Most people have pushed a door when they should have pulled, at least once in their lifetime. The person often feels awkward because he did such an easy thing wrong, but it’s just bad design.
How to solve bad design
Affordances: It is clear what can be done with the product. For most doors, it’s clear that you can open them. For example: giving a button depth in your design, makes it clear WHAT can be done with the button: you can click it.
Signifiers: This is about the HOW. For example: how to use a door. There is often a handle, but it’s unclear whether to push it or to pull. Note here that the signifier actually signifies HOW something works. Most people call this an affordance, but an affordance is only about what can be done with a product, not how. For example: the circular button on my radio makes it clear HOW I should use it (turning).
Mapping: Placing objects close to each other when they belong together. When a button changes a certain state in your design, place them close to each other. A famous offline example is a stove we talked about before, there are 4 pits to cook on, and 4 controls to operate them. But people rarely know which controller belongs to which pit/stove. The buttons are not placed close to the actual pit, which on one hand makes sense because that would be quite dangerous. On the other hand: I often still turn the wrong controller when trying to turn on a pit.
Constraints: People should be able to reason with common sense what can and can’t be done with the product. For example, it’s clear that a door cannot be lifted upwards and pushed downwards because of the way it’s designed. To illustrate this with another example, I have the radio in the image below at home, the buttons make it quite clear you should not pull them towards you. Perhaps because of the sleek and plain surface of the buttons I’m not tempted to pull it.
Optional content
Let’s review this radio and put the above knowledge into practice. This radio contains 6 actions. You can turn all 4 cylinder buttons, and push both. I haven’t used it in a while, and to be honest: I have no idea what button does what.
It’s obviously a radio. So it’s clear that I can listen (to music), change radio stations, and increase or decrease volume. But that’s based on our general knowledge, not the design. (affordance). It’s not clear HOW to perform these actions (signifiers). The mapping is not great as well. I know that one button is for power on/off and for volume, but based on placement there is no way in telling which one is which. Constraints are not bad. I know I cannot pull & slide the buttons, and they designed it in such a way it feels like I can turn and push them both.
The 7 steps of action to goal
The 7 steps of action to goal describe the 7 steps a user takes when taking an action on your website.
To bridge the gap of execution
- Goal: The has a certain goal, something he want’s to achieve. Example: I want to continue reading when it gets dark.
- Plan: The user plans how to achieve a goal. Example: I could sit somewhere else or I could turn on the light.
- Specify: The user specifies his plan into actions. Example: “How am going to turn on the lights by lifting my arm and clicking the button”.
- Perform: The user performs the action. Example: He actually clicks the light button.
To bridge the gap of evaluation
- Perceive: He perceives feedback, he visually sees something happen. Example: He sees the light turning on. Note here that he does not yet interpret it, he just perceives it, meaning he gives no meaning or further thought to the light being turned on.
- Interpret: He interprets this feedback. Compared to perceiving, this actually requires brain-power. What does the result mean to the user? Example: “Okay great I have light now to read”.
- Compare: He compares it to what he expected or what he has seen before. Is there enough light now?
Conclusion
The second part of the book is about how to achieve products that work. For me, this seemed like a different book entirely and was pretty basic and nothing new to be honest. The most interesting part for me the first part, about why we should blame designers and not the users. And the 7 steps of actions to goal will definitely help you to create better interfaces, just think about each of the 7 steps when creating an interaction.
Definitely a great book, and you can find it here: The Design of Everyday Thing.
Leave a Reply