STC Usability SIG Newsletter: Usability Interface
Guidance on Style Guides: Lessons Learned

by Chauncey E. Wilson, Director, Design and Usability Testing Center, Bentley College
Reprinted from Usability Interface, Vol 7, No. 4, April 2001

This article highlights some of the lessons that I’ve learned about the process of creating style guides and implementing processes for ensuring that a product is consistent in a number of dimensions. I discuss the purposes and benefits of a style guide, a process for creating a style guide, the many types of consistency, reasons why style guides fail, methods for ensuring consistency, and some references that discuss these issues in more detail.

What is a Style Guide?

A user interface style guide can serve as:

• A tool for ensuring consistency across a product set
• A way to get groups to work together
• The repository for design guidelines and standards
• A training aid for new members of the product team

The creation of a style guide can serve as a focal activity for an integrated design team involving documentation, development, usability, graphic design, marketing, and other groups. The first step in style guide development is to select stakeholders who can contribute in substantive and political ways. Several members of the style guide team should have some exceptional political clout or be highly respected for their technical expertise. These powerful stakeholders can serve as evangelists for the style guide and the process for ensuring consistency.

The second purpose of a style guide is to describe the guidelines and standards for software or hardware products and (sometimes) the methods for ensuring consistency across products.

A style guide can be a training tool for new members of the design team. Since a style guide provides the basic templates, controls, and rules of design for a suite of products, a wise development manager would require every new developer to read the entire document before touching a line of user interface code.

Consistency is Not a Simple Concept!

The goal of all style guides is to enforce consistency across a set of products. Part of the early design of a style guide should be a discussion of the term "consistency." Consistency is a complex concept.

The following is a list of the different types of consistency that should be considered:

• Consistency with user expectations
• Consistency across applications that are related
• Consistency across applications that are not related but come from the same company
• Consistency with multiple style guides (note that there are often multiple style guides–the corporate logo/trademark style guide is a common one)
• Consistency with de facto standards (for example the use of blue links to denote unvisited links)
• Consistency of terminology
• Consistency of interaction (same keyboard activation methods throughout–everyone uses the same tree control and it is programmed consistently)
• Visual consistency (general GUI layout)
• Consistency between pages/dialogs/windows
• Consistency within pages/dialogs/windows
• Icon consistency
• Error message consistency

You can also define consistency as the number of if-then rules required to explain a part of a GUI or Web interface. Take the example of Microsoft Paint. The object tool bar works pretty consistently–if you click on an item, then you can draw. The toolbar in Microsoft Word has many more rules.

The following are some of the Word rules for interaction with the tool bar:

• If you click on a command button then you will get an immediate command.
• If you click on an icon with a visual area inside the icon then you get a menu.
• If you click and hold in the table icon then you display an expanding table object.

The object toolbar in Paint is more consistent because it requires one rule versus many rules in Word. Try this if-then exercise on a small part of a web site or GUI application and you will get a sense of how consistent the product will be to the user.

Benefits of a Style Guide

Gale (1996) provides a list of benefits from different perspectives. This list can be useful for justifying the time and money spent on a style guide. Gale’s main benefits are listed below:

Support for a Style Guide

The design and implementation of a user interface style guide requires bottom-up support from developers and mid-level managers who have responsibility for implementing the style recommendations. To get bottom-up support, it is important to have top-down support from senior management. A good way to ensure that you get bottom-up support is to:

• Have the senior management make the style guide a corporate (or division) priority.
• Include style guide development and consistency goals into management objectives.
• Get senior management to support the use of the corporate style guide periodically at senior management reviews.

How to Create a Style Guide

The basic steps for creating and implementing a style guide are below. The keys to success are a good requirements process, a dedicated team of stakeholders, and iterative design and testing as the style guide evolves. Human Factors International publishes a good pamphlet that covers the style guide process well. You can view an online version at www.humanfactors.com/downloads/guistandards.pdf.

The following is my version of a process for creating a style guide.

1. Find someone who has developed a style guide and is aware of the pitfalls.
2. Work with a small group to define the requirements for your style guide. Do you want it online? Will it contain method standards? Will there be a way to do updates so that everyone will be notified? Does the style guide explain how exceptions will be dealt with?
3. Put together a group of 8-12 people who will be committed to the style guide and can dedicate a major portion of their time. Make sure that a few people on the committee have the clout to make style guide adherence a corporate priority.
4. Define a structured process for the development of the style guide.
5. Start with high-level architectural guidelines and standards that will have the most impact (templates for Web pages or major features like search). Have small groups with the relevant expertise write draft sections and have the entire group review them and provide feedback.
6. After defining the high-level pages or screens, work on lower level issues and general issues like color, use of controls, and text guidelines. Base these more detailed issues on the high-level components so the design is internally consistent.
7. Continually review the sections with the committee and when they are ready, publish them to a larger audience for additional review and comment. Conduct some usability edits on key sections of the document to ensure that it is usable.
8. Decide what processes will be implemented to publicize, distribute, update, and enforce the guidelines and standards in the style guide.
9. Publish the style guide and make it clear who will maintain the document.
10. Conduct style guide training with managers, developers, QA testers, and other key groups.
11. Convince the product team to implement consistency inspections and make consistency part of everyone’s objectives, bonuses, and job descriptions!

Reasons Why Style Guides Fail Tips on How to Avoid Failure

Style guides can fail for a number of reasons. The following are some of the more common reasons for failure:

• The style guide is too big. It is best to focus on major areas that are really critical like templates for common pages than to cover every single topic as Microsoft tries to do in the 624-page magnum opus Microsoft® Windows® User Experience (Microsoft, 1999).
• There is no good publicity plan for introducing the style guide. Prepare a publicity plan and make a noticeable splash. Put up posters and have a style guide party.
• The users of the style guide have no performance objectives that will get them to use the style guide. Get upper management to include some consistency objectives in the performance plan for developers and development managers.
• Managers are not fully aware of the benefits of the style guide. Make the benefits part of your publicity plan.
• There is a perception that once a style guide is in place, no further usability or consistency work is necessary. Point out that the style guide does not address macro interaction problems that can lead to product failure.
• Key stakeholders and developers in general had no input to the style guide. Make sure that your choice of stakeholders is not based on who has time. Provide forums for wide review of the document.
• There is no good way to resolve conflicting principles. Provide an easy way to resolve conflicts. This might be a discussion forum where issues are discussed for a week and then a decision is made by the style guide team.
• The style guide has standards that cannot be followed because the development kit does not support that standard. Make sure that all the standards and guidelines can actually be followed with all the development kits. Something that worked with the Windows development kit may not work the same way with a Java kit.
• There are no formal methods (like consistency inspections) to support the style guide. A style guide in isolation will fail. Additional methods for assessing and reviewing products must be incorporated into the development process.
• There is no good way to distribute updates to the style guide. Provide a method for updating the style guide. Putting the style guide online is helpful, but you still need to alert people to changes and also not scare the development team who gets an update just before they ship. Work with management to develop reasonable rules on when new standards must be enacted.
• The style guide is not consistent and gives conflicting advice (for example, an earlier version of the Microsoft Style guide had some dialog boxes with access characters and some without access characters). Review the style guide carefully and make sure that you follow your own guidelines and that all examples are consistent with all rules. Any inconsistency in a consistency document will reduce credibility.
• The style guide is not usable. Iteratively test and inspect the document. Constantine and Lockwood (1999) suggest evaluating the style guide on the following criteria: conformity of style guide rules with accepted usability and design rules, thoroughness of the document, convenience, consistency, and compliance (do products reflect the standards and guidelines?).
• The index of the style guide is poor (not enough index terms and poor use of cross-referencing). A common complaint about style guides is that the index is not sufficient. Consider synonyms for objects (for example, text box, edit box, text field) and spend some time creating the index. Enlist the aid of a professional indexer.
• The difference between mandatory standards and recommended guidelines is not made clear. Have a clear way to indicate what MUST be followed and what SHOULD be followed.
• There are too many words. Don’t get wordy. It is useful to explain the rationale between a rule, but don’t go into too much detail.

How to Improve Consistency Beyond Style Guides

As a consultant, I wrote several style guides. One of the ways to get consistency into everyone's mind is to have product teams take a short "Style Guide" consistency course with a number of short exercises on noticing and correcting inconsistencies. Even if you don't use a particular style guide, it might be worth having a lunchtime seminar where you do some "Can you find the inconsistencies?" exercises.

Group consistency inspections are a good way to reveal consistency problems and gaps in the style guide. They are also an excellent way to stimulate cross-group consistency in areas that the style guide covers as well as areas that are not covered by the style guide. Consistency inspections generally require a catalog of screen shots that can be marked up and if possible, a working prototype that allows a review of interaction consistency.

Error messages can create many problems from simple irritation to loss of data to support calls. If you are starting a new project, consider a general-purpose error-handling tool. It is useful to have a general-purpose error-handling tool that lists all the messages. These messages could be reviewed for readability, consistency, and usability and changed by someone (a writer, editor, or usability or tech support person) other than the developer. The ability to print out all error messages easily can be a real asset for usability, consistency, and accuracy reviews.

Printing out Web pages or GUI components and laying them out in a rough workflow in a public area (not where customers will see, but where internal folks would see) and asking people to write comments on the screen is effective. You can roll these items up and carry them around to meetings (I call them "GUI Rolls"). If you have a large color plotter somewhere that can do very large rolls, that is the best way. You can layout sequences of screens with Visio for example.

You can also do a formal consistency inspection on the GUI rolls that gets into detailed interaction and flow consistency in addition to look and feel issues.

To raise awareness about style guide issues at one company, we enlarged sections of our style guide to poster size and put them up in a number of conference rooms for several months. After a few weeks, people would sometimes point to the posters when they were reviewing a specification and say—hey, this product doesn't follow that guideline on the wall.

Nielsen’s edited book, Coordinating User Interfaces for Consistency (Nielsen, 1989) is dated but still the only general reference on the issue of consistency. There are many good ideas beyond style guides for obtaining consistency across a product set.

Summary

A user interface style guide is a foundation for design but doesn’t guarantee the success of a design. A style guide is only one link in the chain of user-centered design activities that are important for product success. Requirement analysis, user profiles, task analysis, testing, and iterative design must accompany a style guide. Don’t let your development team believe that all usability problems are solved once there is a style guide!

References

• Constantine, L. L. and Lockwood, L. A. D. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. ACM Press: New York, NY, 1999.
• Gale, S. A Collaborative Approach to Developing Style Guides. Conference proceedings on Human factors in Computing Systems April 13 - 18, 1996, Vancouver Canada. ACM Press, (pp. 362-367).
• Microsoft, Microsoft® Windows® User Experience. Microsoft Press: Redmond, WA, 1999.
  Nielsen, J. (Ed.) Coordinating User Interfaces for Consistency. Academic Press: Boston, MA, 1989.

SIG Home | About the SIG | SIG Activities | Resources | Topics Newsletter |  Conference |  Bookshelf  | Toolkit  Comments or questions? Please send your email to usewww@lists.stc.org © 1998-2001, Society for Technical Communication

Last updated 07 October 2001