Wednesday, October 29, 2014

The Design of Everyday Things

Don Norman's Design of Everyday Things has been in my "to read" stack for quite some time, constantly getting bumped back in favor of something more germane to my present interest, but I finally made time to give it attention - and while I've no regrets for putting it off, I don't think the time I spent was a complete waste.

The book is very popular among designers, who seem to pay close attention to everything but the title: The Design of Everyday Things is about designing everyday things.  Light switches, faucets, doorknobs, and other devices that accomplish tasks of very little importance and require very little thought.   And the author provides excellent advice in that context.

The problem is that designers take his advice out of its context - to things that have significant rather than trivial functions, and to things that are not used every day.   It's all good and well to approach the design of a light switch with the idea that it should be easy to use, and that a person should be able to switch a light on or off with little or no conscious effort.

But when it comes to significant tasks that have serious consequences, mindlessness is not an ideal and can be quite dangerous.   You certainly wouldn't want to make turning off the cooling tower at a nuclear power facility to be something that can be done simply and without conscious effort.   Nor should planning a retirement investment portfolio be designed to be done with casual disregard.   Some things are important, can have serious consequences, and merit closer attention.

Norman does acknowledge this in his book, and even suggests methods that can be used to compel a user to slow down and pay attention to what he is doing to avoid unintentional and tragic consequences.  But these parts of the book, like the title, seem to have been ignored by those who advocate that everything should be simple and effortless.

His approach to this is actually quite clever: he first spells out the rules and principles of designing for simplicity, then provides a chapter that tells how each rule can be broken to intentionally add complexity to a device or process in instances in which it is warranted.

And this makes perfect sense: simplicity, like any other principle, is not a panacea but a choice to be applied where it has positive results (and to be avoided when it may have negative ones).   Given the way his work is misinterpreted and misapplied so broadly, perhaps it could use a chapter that explains to readers when to tell the difference.

No comments:

Post a Comment