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
This article highlights some of the lessons that Ive 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
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
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
- 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
guidesthe corporate logo/trademark style guide is a common one)
- Consistency with de facto standards (for example the use of blue links to denote
- Consistency of terminology
- Consistency of interaction (same keyboard activation methods throughouteveryone
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 consistentlyif 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. Gales main benefits
are listed below:
||Maintain control over look and feel
||Produce usable systems that reduce support costs and increase
||Increase market awareness
||Capitalize on learning
||Increase product awareness
||Enable production of reusable software
||Reduce training costs
||Reduce development time
||Improve staff retention
|Reduced resistance to new technology
||Reduce arbitrary design decisions
||Increase user acceptance of new systems
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.
- Find someone who has developed a style guide and is aware of the pitfalls.
- 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?
- 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.
- Define a structured process for the development of the style guide.
- 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
- 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.
- 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.
- Decide what processes will be implemented to publicize, distribute, update, and enforce
the guidelines and standards in the style guide.
- Publish the style guide and make it clear who will maintain the document.
- Conduct style guide training with managers, developers, QA testers, and other key
- Convince the product team to implement consistency inspections and make consistency part
of everyones 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
- 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. Dont get wordy. It is useful to explain the rationale
between a rule, but dont 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
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 sayhey, this product doesn't follow that guideline on
Nielsens 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.
A user interface style guide is a foundation for design but doesnt 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. Dont let
your development team believe that all usability problems are solved once there is a style
- 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,
Last updated 27 January 2004