A style guide helps an organization create consistent user interfaces. A style guide consists of a set of specific user interface guidelines and a set of governance rules for the administration of the style guide.
My experience is that it is important to agree on proper governance rules for the style guide before you start writing the style guide.
The successful introduction of a style guide in an organization is not trivial as evidenced by the many following tips.
Overview of this page
Style guide: A collection of user interface guidelines used to ensure consistency in the appearance and behavior of user interfaces across interactive systems produced by the same organization.
User interface guideline: A low-level, specific rule or recommendation for user interface design that leaves little room for interpretation, allowing designers to implement it consistently.
Examples of user interface guidelines:
- The company logo must appear in the upper left corner of each page. Its position must be exactly the same as on the home page. Clicking the logo must cause the home page to be displayed.
- The height of a command button must be 23 pixels.
- For all controls, such as radio buttons, select the safest, most secure value by default to prevent loss of data or system access. If safety and security aren’t factors, select the most likely or convenient value.
- Error messages must be constructive and precise.
Source of definitions and examples: CPUX Foundation level curriculum.
- Governance rules
In close cooperation with management, create rules for governance, for example, how will compliance to the style guide be checked; and what happens if a designer or a developer despite diplomatic requests refuses to adhere to the style guide
Governance rules also describe the procedure for changing the style guide. Requests to change the style guide should be simple to submit; any paperwork should be handled by the author of the style guide.
- Sell the style guide
Sell or promote the style guide internally, for example, advertise it in the organization’s newsletter; ask top management to publicly endorse it; create a public relations plan for the style guide; include training in the public relations plan; check the usability of the style guide and advertise that you checked it.
I recommend half-day training courses based on lots of exercises of the type, “find the deviations from the style guide on this sample page.”
Make sure that busy developers can have questions about the interpretation of the style guide answered within one working day.
- The one and only
An organization should have ONE style guide to prevent the following quote by an anonymous developer, “The nice thing about style guides is that there are so many to choose from.” Style guides for specific products are OK as long as they reasonably extend and do not conflict with the organization’s style guide.
- No policing
Never “police” a style guide, that is, never enforce it strictly with reproaches or even threats. Instead, diplomatically ask co-workers who deviate from the style guide for their reasons for deviating. Be open to the fact that misunderstandings may be caused by unclarities or errors in the style guide, or user interface guidelines that need improvement. If unreasonable rejection of the style guide persists, send the offenders a list of their most important deviations from the style guide, in a non-threatening way.
- Efficient compliance checks
Create a shortlist of the 30-100 guidelines that are most important and most often violated, and check compliance with them. Otherwise the compliance check easily becomes unmanageable because most style guides contain literally hundreds of rules.
- Avoid confrontations
Avoid confrontations with designers and developers over style guides. Yield. If you feel that you have to yield too often, ask your management if the style guide is worth your and their time.
Make the style guide usable. Keep it short. Include a table of contents and an index. Test the usability of the style guide.
- Examples, examples, examples
Use lots of examples in the style guide. Examples are simpler to understand than text.
- Relevant examples
Use relevant examples in the style guide, ideally from the organization’s own user interfaces. If complex user interfaces are what the designers work on in their daily life, include complex examples in the style guide so you won’t be accused of being unrealistic and far from reality.
- Conforming examples
Make sure that the examples in the style guide conform to the rules in the text. Consider rewarding anyone who reports a deviation to the author of the style guide.
- Up to date
Maintain the style guide; ensure it’s always up to date and easy to access. Include a list of recent changes in the style guide so returning users can easily see what has changed since their last visit.
- Design patterns
Make it simpler to follow the style guide than to deviate from it by implementing frequent design constructs as standard design patterns that conform to the style guide.
- Syntax and semantics
Include both syntactic and semantic user interface guidelines. See example 1 and 2 (syntax), and 3 and 4 (semantics).
- Keep it short
Keep the style guide short; about 25 pages richly illustrated with relevant examples has worked for me.
Be prepared to handle the following challenges:
- A design construct that is clearly unreasonable but that does not violate any user interface guideline simply because no one anticipated that anyone would ever dream of doing something like that. Keep in mind that it’s impossible to design anything that is foolproof because fools are so ingenious. This certainly also applies to style guides.
- The rash innovator
The rash rule-breaker who dismisses obvious deviations from the style guide with, “Well, that may be what the style guide says, but you can’t stop progress and it’s my mission to give my users new and thrilling experiences” — even when there are ways to solve the design problem that are compatible with the style guide.
Some user interface guidelines are not exact and need to be interpreted. Such interpretations can cause a lot of political turmoil.
- Many violations
Until your design teams become accustomed to the guidelines, you may find literally hundreds of guideline violations.
A personal anecdote
When I was a style guide manager many years ago, I spent considerable time diplomatically answering calls from developers who had a really great design idea and wanted my blessing before they implemented it. Very roughly speaking
- 60% were not aware that the company had a style guide; obviously, I had not done a sufficiently good job of selling the style guide.
- 30% were not aware that the construct was already covered by the style guide; admittedly, it sometimes took a bit of careful reading of the style guide to figure this out — usability problems exist even in style guides.
- 10% were valuable suggestions for improvements.