Appendix

List of Tips

1. You should review the Designed for Microsoft Windows logo requirements, even if you could care less about obtaining the logo.

2. Conforming to the standards makes your job easier, not harder.

3. Violate the standards to go forward, not backward.

4. Use the same term to describe the same thing. Using different terms for items that have only subtle differences will confuse users.

5. A good name now is usually better than a perfect name later.

6. The responsibility for choosing names includes the responsibility for choosing the names in a timely manner.

7. Avoid choosing joke names.

8. Effective user interface style guidelines make your job easier, not harder.

9. Having user interface style guidelines doesn't mean that you can stop thinking.

10. User interface style guidelines supplement, not replace, the standards.

11. When appropriate, include the rationale in a guideline.

12. Use resource templates to create consistent-looking resources.

13. Think like a user instead of a programmer. Trying to understand why you feel the way you do about a program will help you improve your own programs.

14. Details matter! The fact that a program's problems are minor makes them no less irritating.

15. Good programs go out of their way to help users get their work done.

16. Menu bars are an excellent teaching tool.

17. Keep menus stable. Disable, don't remove, invalid menu choices.

18. Don't use fixed user modes. Provide enough flexibility and configurability so that users can create their own modes.

19. Make your program's default configuration very simple. Let users grow into the program at their own pace.

20. Applications are usually run maximized. Design applications primarily for advanced users.

21. Utilities need to work in a small screen space. Utilities are almost never run maximized. Design utilities primarily for beginning users.

22. SDI programs that manipulate actual documents must support running multiple instances.

23. Users are not you. You need to be an advocate for the user by putting the user's goals ahead of your goals.

24. Establish the target user to help you make design decisions.

25. Always identify a target user, even if your program will be used by a wide range of users.

26. Avoid designing user interfaces based on speculation of the user's needs and goals. Work from direct knowledge whenever possible.

27. Use specific target user information to make decisions about design details.

28. Having users evaluate a design through a prototype is much harder than it appears.

29. It is hard for a user to be as critical of a prototype user interface as of a real user interface.

30. Marketers aren't users.

31. While you should always listen to your users, you should not incorporate their suggestions without question. There is a difference between what users say they want and what users actually want.

32. Establish a shared product vision to make product direction and design decisions.

33. Rapid prototyping and careful design are mutually exclusive design techniques.

34. User-centered design shouldn't result in user-designed software.

35. Be an advocate for the user. Put the user's goals ahead of your goals.

36. Looking at the user interface from the user's point of view is the first step in creating great user interfaces.

37. There is more to making a feature visible than displaying it visually on the screen. The user has to be able to understand it.

38. Intuitive = Visible + Consistent - Standards

39. Make an extra effort to ensure that essential features are visible.

40. Visibility is the ultimate goal of a graphical user interface.

41. A user interface that is too visible draws attention to itself and breaks the user's focus.

42. Use a metaphor only if it is simple and helps the user accomplish the task without constraining the user to the real-world limitations of the metaphor.

43. Unnecessary dialog boxes and message boxes break the user's flow because the user is no longer in control of the program. Rather, the program is controlling the user.

44. Your job as a user interface designer is to make the translation from tasks to program features easy.

45. The ultimate user interface design goal is to create visible tasks.

46. The most invisible form of navigation is when the user has to access several unrelated windows to perform a task. Try to make the connection between such windows visible.

47. Users understand affordance through real-world knowledge, including knowledge of human anatomy, metaphors, and experience with everyday objects.

48. The need for a label indicates that a mapping isn't natural.

49. Good constraints eliminate invalid choices while making the remaining valid choices easier to use.

50. Conceptual models happen whether or not you intentionally design them.

51. Choose the least obtrusive feedback interface that does the job.

52. The goal behind learning from the Web isn't to be trendy but to make software easier to use.

53. Consider using HTML documents even if the document looks nothing like a Web page. They are flexible, powerful, and easy to program.

54. Users need to be able to predict where links will lead and differentiate one link from another.

55. Pretend that your command buttons are hyperlinks, and try to predict where they will take you.

56. Beginning users don't understand modal windows.

57. Consider single-clicking when selection isn't necessary, but make sure that there is a clear visual distinction between single-clickable objects and double-clickable objects.

58. Consider embedding commands directly in the context where they are needed. If you do, use the menu bar for universal commands that apply in most contexts.

59. Don't use multiple windows when a single window will do. Try to have users perform a single task in a single window.

60. Try to use more white backgrounds and fewer 3-D effects to give your windows a cleaner appearance.

61. The more time and effort you spend creating a prototype, the harder it is to change—defeating the very purpose of the prototype.

62. If you don't throw it away, it isn't a prototype.

63. Programming is programming, not matter what you call it.

64. Users know that a prototype user interface isn't a real user interface, so they use it and evaluate it differently. It is harder for a user to be critical of a prototype user interface than of a real user interface.

65. You need to interpret a prototype by creating a design document.

66. Avoid dangerous vaporware. Never prototype to give someone the impression that a program is further along than it actually is. Never prototype to make marketing demos. Prototypes are for design, not for marketing.

67. Use prototyping by example to design new user interfaces by modeling them after appropriate user interface elements of existing programs.

68. Paper and pencil are the most powerful, efficient design tools available. Use paper prototypes to create new designs.

69. Use scenarios to prototype specific tasks.

70. Use resource prototypes to create nonfunctional prototype programs without writing any code.

71. Prefer nonfunctional prototypes. Avoid writing prototype code.

72. If you must create a functional prototype, try to implement as little functionality as you can. Create either a horizontal or vertical prototype and establish a strict time limit.

73. Simplicity is the most important quality of good user interface design. Much of the user interface development process involves simplifying the interface in some way.

74. Windows typically allows you to implement a user interface feature in several different ways. Often the difference between a simple user interface and a complex one lies in making the right choices among these options.

75. A convertible dialog box is a good choice when either the modal or modeless state makes sense. It lets the user decide.

76. Context menus aren't visible, making them a poor choice for programs that are targeted at beginning users.

77. Static lines and text are a good alternative to group boxes because they don't take up as much space and don't add to the clutter.

78. Test the program using a trackball. All interactions seem more complex when using a trackball.

79. Make simple things easy, complex things possible.

80. Standard controls have a significant advantage over custom controls simply because they are standard. Users already know how they work.

81. Don't use custom controls just because you can. Always have a reason.

82. Choose custom controls that look and behave like standard controls. Ideally, users should have no clue that they are using a custom control.

83. Direct manipulation makes using software fun. It is the ultimate form of interactivity.

84. Direct manipulation usually involves using a mouse, but sometimes using a mouse feels indirect. The user's subjective feel of the manipulation is more important than the specific input device used.

85. Before you create a new dialog box, ask yourself whether you can create a way to perform the action directly.

86. A dialog box whose appearance mimics the window it supports can often be eliminated by direct manipulation.

87. You should indicate that an object can be manipulated by changing the cursor.

88. Prevent accidental manipulation. Avoid ambiguous manipulations, and limit the number of objects that can be manipulated.

89. A good default doesn't have to be right all the time.

90. Give the default value that is most likely to be right, given how the setting is used.

91. Defaults should change only as a result of user input.

92. Use placeholders to make it clear that a value hasn't been set.

93. Provide defaults based on the user's actual behavior.

94. Make carefully selected features visible by turning them on by default when the program is first installed.

95. Consider automatically saving file changes by default. Provide an Abandon All Changes command to allow users to revert to the original document.

96. Consider safety when selecting default values. Never use a default value that would surprise the user.

97. Dismissing an unchanged dialog box with the OK button should have the same effect as dismissing it with the Cancel button.

98. Make sure that an activity that has significant consequences requires explicit selection from the user. Disastrous actions should never result from the default.

99. Property sheets should always reflect the actual state of an object.

100. While having more options makes a program more configurable, it also makes it harder to configure. Avoid providing options that aren't useful.

101. Provide configurability to make your program accessible to all users.

102. Prefer implicit settings (that is, direct manipulation with persistence) to explicit settings (that is, property sheets or dialog boxes) whenever possible.

103. Simple configurations are better than powerful ones.

104. Always implement the Apply button in property sheets.

105. Consider providing a Restore Original Settings command to return the program to a configuration that is known to work.

106. Make multilevel configurations visible. Put related configurations in a single property sheet.

107. If you set rules for using an interface, you need to explain them.

108. Previews help users make choices and verify results by giving immediate visual feedback before the user makes a selection.

109. The type of preview to use depends upon how much accuracy you need to effectively indicate the results of a selection. Use the simplest preview type that does the job.

110. Preview animations with animation.

111. Don't explain a feature—show it with a preview.

112. Tooltips lose their value if there are too many of them.

113. Make your tooltip text informative yet brief. Avoid stating the obvious.

114. Aim tooltip text at intermediate to advanced users.

115. Dialog boxes break the user's flow.

116. The psychological effort to use a dialog box is probably more significant than the physical effort.

117. Having to constantly access a dialog box to perform a routine command is a sign of an unnecessary dialog box.

118. Consider combining several related dialog boxes into a single dialog box.

119. Create objects using appropriate defaults to free the user from having to set properties.

120. Use the toolbar to cancel toolbar commands.

121. Consider using the status bar to eliminate notification message boxes.

122. Consider using control enabling and animation to eliminate notification message boxes.

123. Consider using flash boxes to provide feedback that isn't essential for the user to know.

124. Consider providing an undo command to eliminate confirmations.

125. Don't confirm saving changes unless the user actually made changes.

126. Prevent invalid input to eliminate error messages.

127. If you fix problems automatically, make it obvious.

128. Use automatic features to help the user, but leave the user in control.

129. A program should restore itself to the state it was in when last quit.

130. Allow the user to fully customize automatic features and include the ability to turn them off.

131. Use automatic features to help the user, but leave the user in control.

132. The best programs go out of their way to help users get their work done.

133. Assign the initial input focus to the control that the user is most likely to interact with first.

134. Use the Rebase and Bind utilities to reduce your program's load time.

135. Let Windows automatically optimize drawing by not calling the UpdateWindow function unless really necessary.

136. Optimize drawing by passing the InvalidateRect function an invalid rectangle whenever possible. Try to invalidate the smallest area possible.

137. Avoid erasing the background unless really necessary.

138. Use the CS_HREDRAW and CS_VREDRAW styles only when necessary.

139. Consider rendering to a bitmap instead of rendering directly to the screen.

140. Improve drawing and scrolling performance by redrawing only the invalid area.

141. The programmer is primarily responsible for software quality.

142. The key to successful programmer testing is to change your perspective and use your program like a user.

143. As a programmer, you can find user interface problems that are impossible for other testers to find.

144. Evaluate the usability of your program with your team members by using a short list of high-level design principles.

145. Give a lot of demos to obtain valuable feedback, especially early in the development process.

146. Users aren't designers, but they can tell you if a design has usability problems.

147. User testing is the most realistic indicator of how users will react to your program. You have to watch real users struggle to use your program.

148. Some user testing is better than none. Don't feel guilty for using user techniques that are less than ideal.

149. Focus user testing on learnability. If users find the program easy to learn, chances are they will find it efficient, not error-prone, and enjoyable as well.

150. Testing with beginning users is more likely to reveal problems.

151. Ask the test user to think out loud, that is, to verbalize all thoughts while performing a task.

152. Avoid giving the test user assistance during the test. Encourage the test user to ask any questions—you just won't be able to answer them.

153. During the test, keep your eyes and ears open and your mouth shut.

154. Users want to be nice, so you can't always take what they say literally.

155. It can be a humiliating experience to watch someone trash your work. Consider having someone else conduct the user testing for your user interfaces.

156. Lighten up! Test users are doing you a big favor when they find problems in your user interfaces.

157. Your other team members want to be involved early in the development process.

158. Make sure that the other team members understand that their input is wanted.

159. Use graphic designers to improve your program's functional visibility and its visual appeal.

160. Technical writers are in a unique position to find user interface problems.

161. Don't document problems; fix them.

162. For dialog boxes with nondestructive actions, assign the default button to the command the user is most likely to choose.

163. For dialog boxes with destructive actions, assign the default button so that the user can make any single mistake without serious consequences.

164. For dialog boxes with catastrophic actions, assign the default button so that the user has to make two explicit mistakes in a row before there are serious consequences.

165. Assign the initial input focus to the control that the user is most likely to interact with first.

166. Never use assertions or TRACE statements as a substitute for error messages.

167. Don't use error messages as a substitute for assertions or TRACE statements.

168. Make the error message as specific as possible. There is no harm in eliminating unimportant options, but never eliminate important ones.

169. If an error can occur as the result of several conditions, provide a specific error message for each condition.

170. Use the Windows Troubleshooters for solutions to system problems.

171. Use progressive disclosure for complex error messages.

172. Make sure that the string parameters to error message text constructed at run time aren't empty.

173. For internationalization, always put the error message strings in string resources, and construct strings at run time using FormatMessage.

174. Keep the recommended solutions practical. Never propose a solution that isn't likely to be right.

175. If your program has a toolbar, provide direct printing.

176. Make your print previews interactive when possible.

177. You can find many types of printing problems by checking for incorrect assumptions in your printing source code.

178. Use print previews to find many types of printing errors.

179. Help should be helpful.

180. Prefer task-oriented Help.

181. Having exactly the same help online and in the printed documentation isn't helpful.

182. The readme file is your last defense against technical support calls.

183. Avoid restarting Windows during an installation.

184. Reduce Start menu clutter by not adding installation, documentation, and technical support_related files to the Start menu.

185. Reduce desktop clutter by not adding icons to the desktop, Quick Launch bar, or taskbar System Tray without asking permission.

186. The best setup programs go out of their way to help the user control his system.

187. Don't overexpose the readme file during the setup process.

188. Avoid presenting unnecessary setup options.

189. Never ask the user a question unless you really want to know the answer.

190. All user choices should result in valid installations. Never offer the user a choice that could lead to a bad installation.

191. Consider eliminating the need for installation of CD-ROM-based programs.

192. If a setting requires the distribution media or is required for the program to run, make it part of the setup. Otherwise, make it part of the program itself.

193. Test your setup program by using the VeriTest Install Analyzer.

194. Do not assume that standard screen elements are drawn using shades of gray. Always use the GetSysColor and GetSysColorBrush functions to draw such screen elements.

195. Select the system colors based on their description, not their appearance. Do not mix and match system colors that are part of a set.

196. Handle the WM_SYSCOLORCHANGE message so that color changes happen immediately and completely.

197. To help you find system color problems easily, always set your computer's Windows appearance scheme to one that doesn't use any of the default GDI colors.

198. Choose a minimum recommended video mode for your program.

199. Regardless of your minimum recommended video mode, make sure all dialog boxes fit within a 640 × 480 screen resolution.

200. Always give your static text controls room to grow to avoid resolution-dependent problems.

201. Always develop dialog boxes while using small fonts to eliminate static text control size problems.

202. Handle the WM_DISPLAYCHANGE message.

203. When you receive feedback in the form of a solution that doesn't seem to make sense, always ask: "What problem in the program would this solution solve?"