WPI Worcester Polytechnic Institute

Computer Science Department

CS 3041 - Human Computer Interaction

100 Guidelines

Adapted from:	The Human Factor, Rubinstein & Hersh, Digital Press, 1984.

1.  Designers make myths; users make conceptual models.
    {using a computer should always be easier than not using a computer}
    {engineering is compromise}

2.  Separate design from implementation.
    {the perfect is the enemy of the good}

3.  Describe before you leap.

4.  Develop an explicit model of use.
    {know the user}

5.  Maintain a consistent external view of the system.

6.  Provide complete systems, not kits.

7.  Limit the scope of systems.

8.  Limit the number of states.

9.  Make states visible and visibly distinguished.

10. Minimize conceptual load.

11. Respect the rules of human conversation.
    {when people use language to interact with a computer they behave
     as if the rules for person-to-person communication applied}

12. Interrupt the person with care.

13. Respond with an appropriate amount of information.

14. Correctly represent the system's capabilities.

15. Obey the rules of human language.

16. Be consistent in the use of language.

17. Teach by example, not by formalism.
    {Use positive commands; i.e., don't use "don't"}

18. Avoid arbitrary syntax.

19. Use application terminology.

20. Use standard language.

21. Coordinate all system responses.

22. Make metaphors make sense.

23. Correct spelling.

24. Eliminate bad terminology.

25. Icons work best for concrete concepts.

26. Only let the user make simple queries.

27. Consider voice I/O for use in "hands busy" or "eyes busy" environments.

28. Avoid lengthy segments of speech output.

29. Keep voice input to one or two word commands.

30. Treat learning aids as part of the system.

31. Write the user guide first.

32. Support clear conceptual models for documentation.

33. Examples, examples, examples.

34. An index is an informational retrieval system.

35. Verify that Help helps.

36. Don't let help interfere with the task.

37. Integrate help and error processing.

38. Each mode uses a single interaction style.

39. Don't rely on punctuation to carry meaning.

40. Keep menus short.

41. Label menus.

42. ??

43. Make sure you haven't left anything out.

44. Use a pointing device.

45. Respond to direct manipulations in real time.

46. Match objects in the interface with the external myth.

47. Let the user choose the order of tasks.

48. Acknowledge user actions quickly.

49. Provide an easy way out.

50. No surprises.

51. Confirm information content, not literal input.

52. Don't distract the user with unnecessary actions.

53. Report errors simply and in context.

54. Be polite.

55. Don't blame the user.
    {the user is always right}

56. Avoid error codes.

57. Make error messages as accurate as possible, so as not to mislead the user.

58. Fix problems.

59. Don't personify the computer.

60. Distinguish between success and failure.

61. State errors in terms of the external myth.

62. Make it easy to correct mistakes.

63. Combine error and help processing. (37)
     {don't be redundant; but, repeating information aids memory}

64. Design the error behavior of the system.

65. Allow people to work in real time.

66. Announce long delays.

67. Make delays make sense.
    {response is good, adequate, or bad only in terms of the user's perception}

68. Respect the rules of good presentation on paper.

69. Present lists vertically.

70. Identify system output clearly.

71. Number from 1; measure from 0.

72. Use formatting and ordering to clarify structure.

73. Use graphs and charts.

74. Avoid clutter.

75. Visual attributes must compose correctly.

76. Don't overwhelm the user with visual attributes.

77. Make semantics of attributes clear and consistent.

78. Allow flexibility in formatting input data.

79. Provide prompting or cueing for input.

80. Allow shorthand and abbreviations in input.

81. Make frequent inputs easy to express.

82. Design keyboards as part of systems.

83. Simplify keyboard layouts.

84. Group keys according to function.

85. Separate text and control on keyboards.

86. Avoid using a key for more than one thing.

87. Decide the evaluation goals.
    {you build it, you test it}

88. Select subjects who are unfamiliar with the system.

89. Select subjects who are representative of the target user population.

90. When testing, use representative tasks.

91. Standardize the tasks.

92. Use the design guidelines to structure an evaluation.

93. Videotape real users.

94. Guidelines should be followed.

95-100. Reserved for future use.
        {always allow room for growth!}

[WPI] [CS] [CS3041]

dcb@cs.wpi.edu / Tue Mar 16 13:24:44 EST 1999