Design of Everyday Things: Reactions of book and Chapters

I think it's very easy to see why The Design of Everyday Things is extremely famous and influential. Despite being written in 1998, it manages to capture and articulate many abstract processes as to what makes good and bad design to the point where it really pioneered this kind of open talk about it. Considering the fact that poorly-designed products are still rampant in today's market, ranging from obscure devices to extremely well known hardware and software, it's easy to see how the book has managed to stay relevant and will continue to be so for quite some time.


Although at a glance one could attribute the book's age to be a bad thing, it can be intriguing to see Norman's view on multiple different technology-related predictions and observations that either were flat out wrong or simply irrelevant today. One of the most obvious ones is his daydream about the portable device that he ended up describing as essentially the modern smartphone, which I think is very good foresight on his part, thought right at the end he states that the device should be easy to "plug into a telephone". It almost makes me build a time machine to go back so I could go "salesman" on him and tell him "HAVE I GOT THE PRODUCT FOR YOU!". On the other hand, his obsession over what he believed are poorly designed faucets, especially the automatic kind, did not ring true in the long run considering hands-free faucets are by far the most popular ones in modern public restrooms.

One thing that I did find intriguing on his part is his half-insult of a bad product "probably winning a prize". He later explains why exactly he makes that snarky remark, and by all accounts I agree with him, mostly because I tended to be guilty of this as well. Several years ago I was making games as a hobby and in one particular instance, I released a short demo of a game that was received pretty well much to my pleasure. One vital complaint kept coming up, though. I had neglected to put in any instruction that there was a button that made the player character run faster when pressed and held. Because nobody knew it was there, nobody used it, and as it happened I had inadvertently made the very first jump of the very first level in the game almost impossible to make without using this dashing function.

The game won no prizes, of course, but I was the only person overlooking the entirety of the game's production and I had "insulated" myself in terms of the user controls. I tested the game so much to the point where I was using the "dash" button so much I didn't even think twice about not including it in any kind of documentation. Worse yet, I didn't think twice about making that first jump hard without the dashing. In hindsight, it was very poor design on both counts. I only wish I had had more tact in designing these things. I'd have a hard time showing any of my games from back then comfortably, even if I'm still proud of it myself.

I can only imagine what so many other designers of so many other fields must think when they read this book, thinking how poorly they designed things just as I did myself when reading about these blatantly terrible decisions. It's why I think anyone designing anything for an end user should take a look at the principles presented in this book.

Chapter 1
There was one particular answering machine (back in the day when we still had a landline) that we owned that was helpful enough to let us know in its Asian, robotic noise that the battery was about to run out. It was even recited with a slightly anxious tone, as it if the machine were genuinely worried. This was very nice and helpful, except for the fact that we had no battery hooked up to it; the machine's only source of power was a cable that plugged to the wall. In fact, there was no battery compartment at all. It was actually a "leftover feature" from the more advanced answering machines of the same product line that did have a battery compartment. This meant that even though I had no battery hooked up to the machine and had no way of adding one even if I wanted to, the machine still worriedly informed me that there was "LO BATEREE!" For many years it was the mystery of the house, until we figured out it was just a sub-par answering machine and we threw it out for a better one.

Chapter 2
The second chapter talked a little bit about "blaming the wrong cause" that in my opinion has only gotten worse as technology progresses. We all have a relative who continuously asks us why such-and-such has happened on their computer, and while the reason and solution are both very simple to regular users, in reality it's actually a pretty obscure method of solution. In fact, there are many instances in which the cause of the problem is not communicated at all.

One good example of this is in connecting to wi-fi networks, particularly at the A&M campus. As amazingly progressive a campus-wide wi-fi network is, it isn't so amazing when a laptop attempting to connect to it has the user input his or her NetID and password, sometimes two, three times in a row. Or four. Or ten. I did once have to input it actually ten times. I knew what the problem was and how to solve it, or rather how to actually connect. But to a person who isn't too savvy in terms of wi-fi connectivity, much less dealing with a campus-wide network that has "character", it would be very easy to have a person think that the problem is on their end for a variety of reasons. I did, at least, considering for the longest time I thought one had to have a different username and password since my regular NetID account name and password did not seem to work.

Chapter 3
The third chapter deals with the differences between the information of the world vs. the information of the head, and how people can relate different memories to different particular tasks or information to be remembered. This particular chapter rings true to me as I tend to be a pretty forgetful person from time to time, although there are occasions in which I remind myself of things in a way that I can only describe as an "epiphany". I'm sitting in a car late at night and out of nowhere I'm reminded of a small detail I need to do, with no stimulus form the world or any thought process that led me there. For a long time I considered why this was so, and why sometimes I forgot even the most basic of things while others I managed to have almost supernatural memory. I think the third chapter in the book presents the reason very well. In reality, each time I happened to remember out of something, I began to analyze why exactly I managed to remember it. Sure enough, it was the things around what I was supposed to remember that gave some kind of context to it, and I remembered them in such a way that made retrieval of the memory in my brain much easier and intuitive. Often, things that I observed as I was remembering "out of the blue" were actually related, albeit in some subconscious way, considering how I never considered my outside surroundings to influence my "epiphanies" until I really started thinking about it. The third chapter did two things for me: it articulated in more concrete details why I (and I assume many others) can remember things seemingly out of nowhere, and two, it proved I'm not crazy (at least in regards to this).

Chapter 4
This fourth chapter that has a slight focus on readability of user interfaces regarding switches and knobs reminds me of a brief and just as painful stint at creating synthesized music. This is something that my brain apparently believes is a good idea about once every year or so, despite me having zero music production or writing knowledge of any kind, and despite knowing this full well, I continue to try doing it. The adventure of music creation almost always goes in the same pattern. First is the installation of my favorite freeware music creation program, and then goes the lengthy process of VSTi hunting. VSTi are essentially virtual instruments that create samples of other instruments, from fully synthesized electronic sounds to imitations of acoustics, strings, percussion, etc. As with most of my brief stints, I'm unwilling to pay for the "fancy" commercial VSTis and stick with the ones written by enthusiasts that they themselves distribute for free. I applaud their ambition and generosity, but to be perfectly frank the phrase "you get what you pay for" applies pretty well here. Much like with the book's picture titled "Typical Audio Mixing Control" in Chapter 4, all VSTis have a GUI that attempts to emulate an actual mixing control board. The problem is that very rarely are these control boards laid out in any sort of logical way, nor do they attempt to follow any convention among each other. Some have knob-like buttons that the user can click on and move up and down to move the knob clockwise or counterclockwise. Except some of them go haywire when one attempts to move the mouse up and down. These must be manipulated by a circular motion of the mouse. The knobs are all vaguely labeled with incredibly unhelpful two-letter abbreviations, and many VSTis never even label any of their knobs. Some don't even have any documentation at all. Assuming that I manage to even find a VSTi that I can manipulate without having to take a seminar, some VSTis are even incompatible with the program that I was using. If Donald Norman ever woke up in a cold sweat over a nightmarish interface, I'm pretty sure it'd be this kind.

It's at this point that my attempt at music-making dies a horrific and un-triumphant mess. I look forward to doing it all over again in the near future.

Chapter 5
Chapter five's topic of human error and how things happen makes an astute observation of hindsight always being perfect. When looking back on major catastrophes, it is very easy to say who was at fault, why the error was made, and, most importantly, why the people were incompetent for making the error. There seems to be some kind of human propensity for declaring what experts should have done at the time of the crisis. In a way I think it's some kind of indulgence on the part of those analyzing the situation. After all, if I can say for sure what the technicians at Three Mile Island did wrong, I can surely believe that I'm more competent than a person with a college degree in that field working at a nuclear power plant. A very recent example of this is the crash of the Costa Concordia in Italy that resulted in a sunk ship, dozens dead, and a potential environmental disaster. Ironically, the captain of the ship responsible had been interviewed a couple of years prior for some publication, and in this interview he responded to a question regarding cruise ship crashes that involved him deriding the captains for their incompetence. In the interview, he went on to make multiple statements about his particular skills as a captain and implied that the crashes he was asked about would never happen on his watch. Even more interestingly, after the captain himself crashed his own ship into a reef, he became the target of extreme hatred nationwide in Italy and was heavily criticized for his incompetence.

In some ways I think this "chain" of derision from one group to another that was responsible for a disaster can sometimes prevent the public from acknowledging design problems in systems that can prevent them. Even if the Costa Concordia disaster was brought about entirely due to incompetence, it's probably prudent to at least put some consideration into the captain's claim that the reef was not in the map available to the captain.

Chapter 6
This lengthy chapter dealt with a pretty wide topic, in the challenge of actually designing objects. A few of the topics interested me, particularly in the derision of Norman toward the "hi-tech, motion-sensing faucets" and the concept of "feature creep". First, the use of the term "creeping featurism" sound positively archaic, though I found it interesting to note that Norman talks exactly about the concept of Feature Creep. I find it very intriguing that this concept could arise as early as 1988, when user-oriented computer software was relatively in its infancy. I didn't imagine that software could get bloated to a point where Norman and other analysts would be able to pinpoint this phenomenon so early on. It's also very interesting (and rather sad) that the phenomenon is still in full swing today, probably even worse so.

The second is the words directed at "hi-tech", motion-sensing faucets. I think it's important to note that today these faucets are in nearly every modern public building in the US, I found it rather interesting that Norman only devoted a couple of lines in the book to this implementation and essentially dismissed it. His words about the lack of water flow and temperature control seem to contradict the state of public faucets today. In hindsight it doesn't seem like water flow and temperature control are that important in public restrooms. Indeed, they seem to be used only for a few seconds at a time. I never really considered this lack of control in restrooms to actually be a bad thing, though in 1988 when flow and temperature controls are a given, taking them away would seem heinous.

Chapter 7
Chapter seven ultimately let me see exactly why the book is as famous and well-regarded as it ended up being. This chapter mostly deals with principles that Norman considers important to follow (or, in some cases, break) to guarantee good design. The usual requirements were there: make the user hold the object in a way that intuitively leads to using it the right way, make the object simple enough to encourage picking it up and using it at once, make sure that the feedback maps correctly to the user's vision of how the device will work, etc. However, what I realized just as I was finishing the chapter is that these suggestions were not the "usual requirements". In fact, many of these hadn't even been established as "requirements" at all. In this sense, it might seem like the book was dated in that it tends to focus a lot of on design aspects that even regular laymen know about, but I believe the reason why this book was as influential as it was is because it helped establish these protocols as universal. It helped me see just how many seemingly simple objects today are actually designed very carefully. Of course, there do seem to be objects that clearly have still not gotten with the program, even after around 24 years. I think the ubiquity of good design these days makes poorly-designed devices far more blatant because of it.