The Design of Everyday Things
Posted comment on Drew's blog
This book covers the psychology of daily human interactions with objects and how designers can use an understanding of this create better designs. It covers some basics of human explanatory systems, human memory and common ways the human brain can create errors. The book is replete with examples of designs that are either successful or fail at interacting with particular parts of the human mental system. At the end of the book is a summary of the design process with what amounts to a checklist for making a good human interface for your device or system.
I would have to say that the most enlightening and fascinating part of this book was the analysis of everyday interactions and the mental processes associated with them. I was particularly interested in the section on internal vs external memory as I see this as very important for software. If a piece of software can use concepts and mental models that are already used in other pieces of software it makes it much easier for users to learn new software. Then for concepts that are new the software can provide explicit written or visual clues as to how new, unknown functionality can be used.
This shows why it is so important for pieces of software to use mostly standard UI elements of the windowing system they reside in. I know as a mac user this used to be problematic, as very often pieces of software would be quickly ported from windows and would use windows-like interface conventions instead of switching to more Aqua like UI layout. In these applications none of the conventions that I knew were followed and so I had to learn a new set. Now of course if I had used Windows it would have all been very natural.
Another section I found particularly interesting was the discussion of forcing functions. The idea of forcing a user into a certain set of operations so they are unable to create errors is very useful. It is (or should be) very easy to apply this in software design and, with the advent of display input systems, hardware too. With devices such as iPods we can remove controls dynamically to make sure that only relevant input is possible. However that seems to be more the exception than the rule as very often software is engineered so that extraneous input is still possible. In some cases, however, the inclusion of forcing functions is entirely dependent on who will be using a system. For a novice user, we may want to allow them to perform only safe operations, whereas a more advanced user will likely want more power over the system at the risk of possibly damaging the system (perfect example being sudo.)
This comment has been removed by the author.
ReplyDeleteI think you did a superb job of summing up the text. Your insights on the use of memory (and the pitfalls of quickly changing computer environments) are a good warning to all designers—be wary of simply expecting the user to know (or remember) how to work with an interface.
ReplyDeleteSecondly, the forcing functions section was a good part of the text as well. We must remember to eliminate most (if not all) non-viable solutions to an operation if we are to make a design that is intuitive enough for the user to manage.