Session 4

Eight Golden Rules of Design for Users


820:240

Environment, Technology, and Society


Opening Comment

As I re-read Chapter 1 in The Design of Everyday Things, the following ideas struck me:


Exercise: Eight Golden Rules of Design for Users

Context

You have begun to explore how users can be frustrated by the design of everyday things and how they form a conceptual model of the things they use. You have read through Page 17 of The Design of Everyday Things. You have consider different types of users and different ways that users interact with a product.

Goals

  1. To explore interface design principles based on your collective experiences as users.
  2. To make connections between these design principles and the diversity of users.

Tasks

Work in teams of three or four people based on the number in the upper right-hand corner of this page.

A well-known book on design for users defines eight "golden rules" of design for users:

Use this list of golden rules to do the following:

  1. Pick something people use, like a car or microwave or cell. For each golden rule give either an example of how the product satisfies the rule or an example of how the product violates the rule.

  2. As a group, identify your own "golden rule" for interaction design, one that is not on the list above. Be sure to explain what your new rule means. Now, make room for your item on the list of eight by eliminating the rule from the list above that you think is least needed or least important. Why did you choose to delete that particular rule? In what way does your rule improve on the deleted rule?

At the End

  1. Your group submits a written report of your results from the two tasks. Your report should summarize any discussion that ensued and should answer any questions directly asked.
  2. Each group will present some of its conclusions.


Summary from Exercise

I took the list of eight golden rules from Designing the User Interface, by Ben Shneiderman... again.

The rules that you were most likely to eliminate from the list were "Make sure that users know when they are done with a task." and "Reduce load on the user's short-term memory." One group said that we didn't need this rule as much as others because it is already covered by "Offer informative feedback." (I agree, but I suspect that Shneiderman knows this and thinks that 'a sense of closure' is so important that it is worth mentioning separately.) One group eliminated "Make users think they are in charge," saying "I just want done what I want done. I don't need to feel in charge!" Do you feel that way about all the tools you use?

Your new rules included... [coming soon]

In my past courses, the rules from Shneiderman most commonly retained involved consistency, feedback, error handling, and reversal of actions. Rarely does any group retain 'design dialogs to yield closure' or 'support internal locus of control'. Why do you think that is?

What are the advantages of stating explicitly these principles when they seem implicit in some of the others? In what do these guidelines differ from their "relatives" on Shneiderman's list. (Think about intellect versus psychology...)

New rules proposed by past students included "make the interface easy to adapt", "match the user's task", "provide on-line help", and "give the user a way to terminate the system in a fail-safe mode".

Some group generalize 'provide shortcuts' to a rule about 'adapting to the type of user', which also included the providing of help. How much is this science fiction, and how much can we achieve today?

Other ideas that have surfaced as possible rules: "match the environment", "provide help -- outside of the software", "provide appropriate response times", "(use graphics that) send the right signals to the user", and "provide multiple input devices".

How do you go about creating new rules? (Sometimes it's hard to create anything once you have seen an answer...) Three strategies I'd suggest you try sometime:

Keep in mind that more general rules will be less directly helpful in some contexts, and that more specific rules will be less broadly useful in some contexts.

Students Summaries


Eugene Wallingford ==== wallingf@cs.uni.edu ==== September 5, 2003