During our week-long course with Bert Bongers; Maria, Valentina, Dominika and I redesigned a toaster. You may also want to read part 1 and part 2 of this series of posts to learn about the concepts that we put into practice. Part 3 presents our analysis of the current toaster, and our redesign.

I’m not going to say that were doing our device parsing when we came across something interesting. I’m not going to do that because everyone knows that after you’ve toasted a first pair of slices of bread, it requires superhuman ability to get a second pair equally toasted. However, I’d like to point out that, had we though that this randomness was part of a “surprise me” feature in our toasters, we would have realized that something was wrong with the interaction anyway, when doing the device parsing.

The image on the left shows how there’s something wrong with the mapping between the input and the output, between an action on the part of the user (setting the timer) and the desired outcome (how toasted the toast is). This is a gulf of execution problem.

Depending on how hot the toaster already is and some technical characteristics, the outcome for the same knob position varies. Suposedly you can tell this because you had a look a the components, which is not really needed in the case of a toaster because I guess most people know how it works already. But, in any case, even if the output didn’t vary with variables other than the input, numbers on a knob don’t actually tell you anything about how toasted the toast will be. If you encountered this toaster for the first time, how would you know which number to choose?

So we went on to redesign the toaster for the mapping to make sense. To help the mapping, we kept the knob, but instead of having numbers we introduced the coding in the picture on the right. This is very nice as an interface, no room for ambiguity. But… how would it actually work in terms of the components of the toaster? The current toaster has a timer associated to the knob, you set it and after a while the toast is “ready” (whatever that is). Changing the numbers on the knob for pictures above will solve the mapping problem, for example for first time user of a toaster that doesn’t know what the knob is for, but will not help with the “random toastedness” factor, something inside the toaster has to change: the timer. This is the prototype for our “deterministic toaster”:

There you can see our Flash toaster (in the laptop’s screen) for which you enter how much you want to toast your bread with the knob on the bottom of the picture (to the right of the center) using the coding showed in the previous paragraph. The flashlight (blue thing on top of the plastic cup) lights the toast (green paper thing) so the webcam (white thing) can read the RGB values for the color of the toast . As bread  gets toasted, it emits different amounts of red, green blue and total light, so if you read these values you know (or the toaster knows) how toasted your bread is. We measured this in real toast, obtaining the curve on the right.

Now, replace the flashlight with well mixed RGB light, the webcam with a RGB sensor, compensate for the red glow of the resistor inside the toaster and the initial color of your bread. And when the toaster determines that the color of your toast matches your settings it can pronounce your toast “ready”.

• The book, or part I: The Design of Everyday Things
• The clock, part II: an intro to device parsing, and the parsing of a clock as example
• The toaster, part III: our redesign of the toaster, using a different combination of sensors and actuators, following Norman’s principles

(I’ll leave talking especifically about sensors/actuators for some other day, I have a rather ambicious project on them, but it’ll have to wait until I finish with the emoticons and the pagination :)

So, today: the book.

The Design of Everyday Things is a book, written by Don Norman in 1988, about how some designers are bad designers and create things that give some people trouble when they have to use them. Some models and principles are also presented in the book. I guess that you can read as many positive as negative reviews, its current relevance is also praised as well as disputed. I didn’t generally like the book and I wonder how scientific the main models presented in the book are. Even Norman admits that his 7 Stages of Action model is not validated and that the study of how people act is an “unexplored area”. The book seems to be based mainly on the cherry picking of anecdotes, some folk wisdom about how people act, a rather large bibliography list that is never cited in the book  and lots of hope that you’ll identify with some of the episodes described there in which people are frustrated and/or embarrased by their inability to make some device work and you’ll find designers guilty by association. Although just a reshuffle of common sense and other people’s papers, the book is kind of successful in bringing some concepts together, it would actually be useful if it weren’t so long and obfuscated. I don’t know, this is just my opinion. In any case, I summarized the concepts in the book, scraping off Norman’s rants, the pseudoscientific explanations and the stuff which is too old to matter, and I got the summary that follows, which is reasonably ok as very basic advice for  a designer.

First there is the 7 stages of action this is the model suggested by Norman on how people act (chapter 2). If you then look back into the principles of chapter 1 and combine them into it and then add the contents of chapters 3,4 and 5, you get something like this (download as PDF here):

Some other concepts are described in the book, but frankly most of them are obvious or redundant: i.e. what people can do after physical and cultural constraints are taken into account is called by Norman an affordance, like in glass affords seeing through. Or, the notion that tasks described by wide and deep decision trees are complex vs. tasks with shallow or narrow trees, which are the simple ones…

The chapter on errors is kind of weird, the explanation about why and how people tend to overregularize the commonplace and at the same time overemphasize the discrepant is lacking, especially regarding the part about the discrepant stuff. However, I think that his categorization of the nature of slips (mishaps, or errors arising from acting incorrectly when one has the correct intention) may be useful as a checklist I may like to use to test my designs for possible causes for this kind of errors:

• Capture errors: a frequently done activity replaces a more infrequent one if the early steps for both are similar (i.e. I start to dial the dentist’s number and end up calling my friend because the first 4 digits in both phone numbers coincided).
• Description errors: the intended action is incompletely described in the user’s formulation of his/her goal, so it gets replaced by another one that also fulfills the incomplete description (i.e. put the lid of the sugar bowl onto the coffee cup, in this case the goal description would have been something like “put the lid on”).
• Data driven errors: sensory data of a similar nature replaces data that originally was involved in the action (i.e. you try to call a person but you see someone else and you call the latter’s name instead of the former’s).
• Associative activation errors: same as data driven but the “wrong data” comes from the person’s own associations instead of from the external world, the Freudian slip.
• Loss of activation errors: forgetting the goal, as a consequence the sequence of actions is truncated because the next step is unknown (i.e. I walk to the kitchen but once I get there I can’t remember why I went there or what I wanted to do there).
• Mode errors: a device has more than one mode and the user performs an action as if the device were in one mode when it is on another (i.e. trying to write text in the command mode of Vim)

And finally, after a chapter 6 that is absolutely not worth reading, in chapter 7 Norman gives his definition of User Centered Design, which consists of adhering to 7 principles (some of the ones presented in chapter 1 are there, some are missing, the others are new):

1. Use knowledge in the world (cues, labels, etc.) and in the head (user’s mental models, associations and memory).
2. Simplify the structure of the tasks (provide mental aids, improve visibility and feedback, automate parts of the task, replace the task by a simpler one)
3. Make things visible (bridge the gulfs of execution and evaluation)
4. Get the mappings right
5. Exploit the power of constraints, both physical and cultural
6. Design for error (minimize causes of error, make actions reversible, make it easy to discover that an error ocurred, take errors as an approximation through which the user gets to the goal by an alternative course of action)
7. When all else fails standardize (so arbitrary things have to be learn only once).

What can I say about these 7 principles..? For sure that reading through them was puzzling. Why didn’t he include some of the advice that he mentions on the rest of the book? Where are conceptual models and where is feedback? They looked good enough to be included as principles in chapter 1, and surely they are part of User Centered Design: providing a good conceptual model through which your user can undertand the capabilities and functionality of your design. Somehow, some things got left out and others just appeared out of the blue: when reading chapter 2 I had the impression that constraints were part of the knowledge in the world, they are in fact a subsection of that chapter, why are they being mentioned here as a separate entity? At best, chapter 7 looks sloppy. It reinforces the impression that there is no structure behind the book; which, together with the fact that in my edition (Basic Books, 2002) you can’t even tell the hyerarchy of subtitles, makes me wonder if Norman wouldn’t have forgotten to include the part about providing a good conceptual model for your users if he had paid a little bit more attention to it…

In any case, would I advice myself to read it if I ever go back in time? The answer is, unfortunately, no. Not completely useless, but I have better things to do with the time it takes to read 235 pages that can be summarized into one A4 sheet.