Why do styles guides have what not to do?

Question

I'm tasked with writing a style guide for a .NET application. Currently there's about six developers that just do whatever they want in terms of style. Similar buttons are in different spots, different controls are use, etc., etc. It's a mess.

I've researched some other style guides, and they often (always?) show what not to do. The lead developer mentioned that the style guide will be better received if I omit any "don't do's" and only include the "do's".

Why do style guides have what not to do listed as well?

Answer 1

When you provide only one side of the story you allow the listener to fill in the other half on their own. This can be a powerful story telling tool...

... but when you don't want to leave a situation open to interpretation you need to provide both sides of the story.

When learning how to do something new you find guides explaining the "Do's and Don'ts of [my new skill]". By providing both sides of the story you reinforce the proper behavior, you illustrate to the reader that what you are saying as "correct" is true, and "here are a few examples of what not to do, and why".

Without a "don't" a reader can easily formulate a rationale in favor of violating the suggestion. Remember, this is a "style guide" - not a "style mandate". A reader can easily say: "They suggested that but I think this will work, and they didn't tell me not to do it!".

Providing an example (or multiple examples) of the don'ts does a few things to provide big impact:

1. They plug gaps that could otherwise be interpreted differently by different people.
2. They give visual feedback of how "good" looks, versus "bad".
3. They explain why you should do it correctly, and how doing it incorrectly can affect the experience.
4. They show the reader that you know what you're talking about! This isn't just a style guide full of your subjective preferences, it takes the reader through the whole story and makes them understand why "this is correct" and "that is bad".

Look at any of the Human Interface Guidelines (aka: Style Guides) of major brands. They all include DOS and DO NOTS, and explain why and/or provide proper alternatives:

iOS:

Android:

OSX:

Windows:

Answer 2

Dont's can be as important as Do's in UX

While design frameworks should focus on describing positive practices and principles (do's), it's important to provide guidance on avoiding common pitfalls, antipatterns, and errors.

---

Some best practices are simply easier to articulate in the negative than in the positive. For example, which of these is easier to understand?

1. Do ensure that content doesn't move when the user may be reading it. Also, do ensure that content that is supposed to be equal in important is shown simultaneously onscreen (i.e. so that there is no inadvertent bias towards visible vs hidden elements).
2. Don't using carousels.

Following the positive guidance (#1) should avoid the use of carousels. But that requires a lot of thinking and a very clear understanding of abstract guidelines on the part of the designer, who has to figure out how to apply the guidelines to a particular widget.

Since carousels are a popular, concrete element, it's very helpful to cover the antipattern specifically as a "don't". The two aren't mutually exclusive: for example, you can articulate a positive principle and also point out common antipatterns to avoid.

---

This principle is not unique to UX. Since you are discussing this with a developer, it may be helpful to point out that most development guidelines also use a combination of do's and don'ts. For example, the zen of python contains the following don'ts:

Errors should never pass silently.
In the face of ambiguity, refuse the temptation to guess.

...and the Android design principles contain these negatives:

Never lose my stuff
Don't interrupt me unless it's important

Answer 3

The key message to communicate to the reader is not the do and it is not the don't either. It is the difference between the two.

Showing the two next to each other communicate this difference about as clearly as it can possibly be done. If you show them only one of the two, they will be left guessing what difference you actually had in mind.

It is also useful when somebody has made a mistake, and you refer them to the guide. If the guide has a don't do example, which matches exactly what they did, then the correction comes across more clearly.

Answer 4

I've found that there are some DON'T DO examples that can actually impact a product more negatively than a DO example would affect it positively. Poor color contrast or font choice can turn people off a product quickly even if it has a well thought-out navigation system and the flow from one screen to another makes perfect sense.

In software development we call the DON'T DO examples "anti-patterns". Showing what not to do has an added benefit in that it allows you to identify examples you may have seen in the past and prevent you from making those critical mistakes.

Answer 5

Having illustrative examples of proper and improper usage is great for a couple reasons that come to mind.

• Reinforcement of good behavior juxtaposed against poor behavior. Without the don't, you allow a developer to potentially stray too far when implementing.
• Some people are visual learners. Example: Just because you say 'line height should be 1.5' doesn't mean someone will understand why without an illustrated example of the poor readability provided by other line-heights. The style guide is an opportunity to enforce guidelines but also teach others the value of your decision decisions.
• Don't's create some collateral that prove you've thought out the interactions and want to enforce consistency. If a developer willfully or otherwise implements a don't, you have something concrete to reference as backup to your point.

I am using a style guide myself on our application - and I find one of it's strongest advantages being that you have documented not only UI but also the rationale behind your decision - which should serve as the foundation of discussion and ultimately a better design. Hope this helps.

Answer 6

If the style guides have proper "do's" like " only on black " or only "4px rounded corners" you don't really need don'ts. From a designer perspective this approach can limit the creativity but will definitely boost the interface consistency of your application.

Answer 7

Many people naturally have a lot of great ideas and also a lot of not-so-great ideas. If a developer is given a list of how various ways to do things, but the list doesn't describe how to do everything that needs to be done, the developer will have to invent ways of doing things not on the list. A developer's whose first idea for how to do something happens to be a bad one may waste time developing that bad idea if its problems aren't immediately apparent. A developer who knows of many ideas that may appear attractive but really aren't may be able to more quickly recognize bad ideas and thus avoid spending too much time on them.

More generally, to really understand what is good about something, one must understand what is bad about the alternatives. Oftentimes, the most interesting lessons of history don't come from knowing about what things were tried successfully, but instead from knowing about what false paths exist that one should avoid.