The Design of Everyday Things - Book Review

A book review of The Design of Everyday Things by Donald A. Norman.

Serious Principles Humorously Examined

• Authors: Donald A. Norman
• Publisher: Doubleday/Currency
• Published: 1990
• Page Count: 257
• Edition 2nd

Table Of Contents Overview:

• Preface
• 1 The Psychopathology of Everyday Things
• 2 The Psychology of Everyday Actions
• 3 Knowledge in the Head and in the World
• 4 Knowing What to Do
• 5 To Err Is Human
• 6 The Design Challenge
• 7 User-Centered Design
• Notes
• Suggested readings
• References

It took me a long time to get around to reading this particular title. It had been recommended to me well over 10 years ago when it was titled “The Psychology Of Everyday Things” and have come across references to it in other texts, all exhorting me to read it. And now, finally, I have.

Copious real-life examples, humorously illustrating fairly simple design principles that it is well to be aware of. Obviously it is aimed at designers. But one of the reasons I held back from reading it was what relevance could it possibly have for testers? Well, even if just to act as an independent expert when we are informed that “the user will never do that!”. The text confirms what we already know, “If an error is possible, someone will make it.”

As software development professionals we have to grapple with complexity every day. The complexity of: the business, the requirements, the documentation that is produced, set up of test environments, planning the test dependencies, and test data. And it is worth bearing in mind that “the principles of good design can make complexity manageable”. The principles of good design do not only apply to the final product, they apply at every stage of the product’s development.

The principles of good design are summarised in the book as visibility, conceptual model, mappings, and feedback. Visibility so that the user can tell the current state, a conceptual model which reflects the user’s model, mappings which will relate what is required to how it is done, and feedback so that the user knows what has occurred.

All of these are principles that we should keep in mind when reviewing software designs, but also for process improvement in the software development process itself. Does this system design tell me what I need to know? Do my test progress reports allow people to know what is done and still to be done? Do my defect reports allow developers to identify the problem and rate its seriousness?

In Chapter 2 there is a seven-stage model of action:

• Form the goal
• Form the intent
• Specify an action
• Execute the action
• Perceive the state of the world
• Interpret the state of the world
• Evaluate the outcome

This maps very well on to the T.O.T.E model since Miller is the stated reference. But presented in this form, it maps very well on to the process of testing: from the initial requirements, test conditions are identified which we use to construct tests. Tests are sequences of steps which we execute and determine the success of each of those steps. This will require examining the system state before evaluating whether the test passed or fail.

A common theme in the book is, unsurprisingly, that humans make mistakes. Testers are certainly aware of this, we do after all design tests which simulate the making of mistakes, asking ‘what happens if’ questions? Obviously it is more efficacious if these questions are asked during the design process so that we can build systems that respond to the users mistakes without causing irreparable damage to the system data. Testing can then validate that no damage is caused rather than discovering that damage is caused.

There are important points made, that testers will no doubt have encountered in the real world. Chapter 6 makes the point that designers are not users, neither are testers but testers do attempt to adopt a user focus during some test derivation processes but we should be aware that we still are not users. User involvement is key.

The point is also made that the Designer’s clients may not be the users. This can happen when software is being built for external users to the company but the only users that the design team has contact with are the internal support users. This is not to belittle these user’s input to the system but simply bear in mind that, when we are informed that the system works as the user’s require it, then it may not actually be the users that have required it.

There is much for the tester to take away from the book, small reminders of good testing practise that in the heat of battle might slip our mind. It is always worth remembering, when reporting defects, that the cause effect link in a defect situation is only perceived by the tester, it becomes a real cause effect link when investigated by the developer. The book cautions us against drawing erroneous conclusions from perceived cause effect links and then engaging in inflammatory communication.

Running throughout the text is the theme of models. People have models in their heads about how they expect something to work and that is how they approach the doing of a task, by consulting their model on how to achieve what they desire. This is a common theme that I have used in relation to testing, that all our testing is done through models either explicitly or in our heads. The book makes the point that we also use real world models to help guide us and provide us with stimulus but also explores the relation of models to memory. And one reason at least for documenting the models that we as testers use when testing, aside from coverage measurement and communication, is so that we remember them.

Obviously I think there is much to be taken away from this book and applied. It is well written and reading the book is a pleasantly amusing experience so it gets a recommendation from me as well as everyone that sagaciously came before me.