A nearly one page summary of design rules
The first principle. When using a product to help you do a task, the product should only help and never distract you from the task.
Definition: A gesture is an action that you finish without conscious thought once you have started it. Example: For a beginning typist, typing the letter "t" is a gesture. For a more experienced typist, typing the word "the" is a gesture.
Commentary. Designing a human-machine interface demands that both the human and the machine be understood as well as possible. A understanding of the relevant portions of cognitive psychology, ergonomics, and cognetics is essential. That is not all that is needed, but it is a prerequisite.
Rule 1. An interface should be habituating.
Commentary. If the interface can be operated habitually then, after you have used it for a while, its use becomes automatic and you can release all your attention to the task you are trying to achieve. Any interface will have elements that are habituating, but the principle here is to make the entire interface habituating.
Rule 1a. To make an interface habituating, it must be modeless.
Commentary. Modes exist where the same gesture yields different results depending on system state at a time when your attention is not on system state. In the presence of modes, you will sometimes make mode errors, where you make a gesture intending to have one result but get a different and unexpected result, distracting you from your task.
Rule 1b. To make an interface habituating, it must be monotonous.
Commentary. "Monotony" here is a technical term meaning that you do not have to choose among multiple gestures to achieve a particular sub-task. Crudely, there should be only one way to achieve a single-gesture subtask.
The second principle: An interface should be reliable.
Commentary. Aside from not crashing, the system should never lose any work you have done or any information you have received or retrieved, even if you make a mistake or are forgetful. This is often not thought of as a property of an interface, but one can build a reliable interface on top of an unreliable system (of the order of unreliability of todays operating systems).
Rule 2: The system should neither lose your work nor through inaction allow your work to be lost.
The third princple: An interface should be efficient and as simple as possible.
Commentary. Time is an unreplaceable asset. An interface should not take more of your time than is necessary, either in use or in learning.
Rule 3. Good engineering practices should be applied to interface design. Quantitative measures should be used, and an interface should be close to its theoretical minimum in terms of the time it takes to do an operation.
Commentary. The GOMS model and information theoretic measures of efficiency (to name two particular techniques among many) must be mastered and used by interface designers. Another set of techniques and measures can be used to help judge learnability.
The fourth principle: The suitability of an interface can only be determined by testing.
Commentary. All of the theory in the world, and the wisest guru, cannot always predict how an interface will work in practice. One must test, objectively observe, and modify the interface if testing shows that users have difficulties. It is never the user's fault, but also remember that people find it difficult to change, so difficulties based on previous habits may not be dispositive.
The fifth principle: An interface should be pleasant in tone and visually attractive.
Commentary. How messages are phrased is important, how the interface looks is also important. But these are of secondary importance in terms of task completion. When use of the interface has become habitual, these elements go unnoticed. All of the principles, if followed, create learnable interfaces.
Summary. An interface should be effective, habituating, reliable, efficient, and tested. To the extend that doing so does not conflict with these essentials, an interface should also be attractive.
- In Memoriam: Jef Raskin User Experience Newsletter #5, March 2005