Developing User Interfaces for Microsoft Windows
In addition to establishing goals, it's also a good idea to establish guidelines for the user interface style guidelines themselves. Here are some issues to consider:
- Try to avoid repeating what is in the standards The goal isn't to replace Designing for the User Experience but to supplement it. However, some redundancy is acceptable, especially when a guideline is easily overlooked or often violated. It's also acceptable to have some redundancy for completeness or convenience. For example, if you have five guidelines for menus but one of the guidelines is in Designing for the User Experience, you should probably include it anyway to make the guidelines easier to use. You should also cross-reference other documents as needed.
TIP
User interface style guidelines supplement, not replace, the standards.
- Try to avoid arbitrary guidelines If a guideline appears arbitrary but has a good rationale, include the rationale in the guideline. For example, rather than saying something like "Don't use yellow," say "Avoid using bright yellow as a foreground color, since it is a distracting color and is often difficult to distinguish on white backgrounds." On the other hand, if a guideline really is arbitrary, don't include it. A weak rationale is a sure sign that a guideline is bad. To be effective, user interface guidelines need support from all developers, and developers will resist guidelines that don't make any sense.
TIP
When appropriate, include the rationale in a guideline.
- Try to make the guidelines easy to follow Give plenty of screen shots and other examples to make the guidelines clear and more interesting. If you give both good and bad examples, make sure that the bad examples are clearly marked as bad. Also, clearly indicate what is considered a rule, which should be followed in most circumstances, and what is a guideline, which is a recommendation.
- Try to keep the guidelines short Long, tedious guidelines are ineffective, since they are less likely to be used.
- Make sure the guidelines match the tools used For example, dialog box guidelines for Microsoft Visual C++ programmers should use dialog units, and the same guidelines for Microsoft Visual Basic programmers should use twips.
- Try to avoid guidelines addressing Windows requirements For example, don't include a guideline that says, "Child windows must be destroyed when the parent window is destroyed." In Windows, this always happens—there is no choice.
- Try to focus on actual guidelines, not general user interface design principles If you want to establish baseline user interface design principles, use another document.