style-hover,-focus,-and-active-states-differently

16th Oct 2019

I’ve been styling :hover, :focus, and :active states the same way for years. I can’t remember when I started styling this way. Here’s the code I always use:

// Not the best approach. I'll explain why in this article
.selector {
  &:hover, 
  &:focus,
  &:active {
    // Styles here
  }
}

As I paid more attention to keyboard accessibility (and therefore paying more attention to focus), I began to think we should not style hover, focus, and active states the same way.

Hover, focus, and active states should be styled different.

There’s a simple reason: They’re different states!

Today, I want to show you a magical way to style all three states effortlessly.

Let’s start with :hover.

Styling hover states

:hover triggers when a user brings their mouse over an element.

Hover states are usually represented by a change in background-color (and/or color). The difference in states doesn’t have to be obvious because users already know they hovered on something.

button {
  background-color: #dedede;
}

button:hover {
  background-color: #aaa;
}
On hover, button darkens slightly.

Styling focus states

:focus activates when an element receives focus. Elements can receive focus in two ways:

  1. When users tab into a focusable element
  2. When users click on a focusable element

Focusable elements are:

  1. Links ()
  2. Buttons (
  3. Form elements (input, textarea, etc.)
  4. Elements with tabindex

Here are a few important points to note:

  1. Users cannot tab into an element with tabindex="-1", but they can click on it. The click triggers focus.
  2. On Safari and Firefox (Mac), clicks do not focus the
  3. When you click on a link (), focus remains on the link until you lift your finger from your mouse. When you lift your finger, the focus gets redirected elsewhere if the href points to a valid id on the same page.

For focus, we’re more concerned about users tabbing into elements than clicking on elements.

When a user hits tab, they don’t know where the focus will go to. They can only guess. This is why we need a prominent change a user’s attention attention to the focused element.

The default focus style is okay most of the time. If you want to design your own focus, think about these four things:

  1. Adding an outline
  2. Creating animations with movement
  3. Changing background-color
  4. Changing color

Since background-color and color changes often accompany :hover, it makes sense that outlines or animations should accompany :focus.

You can use a combination of outline, border, and box-shadow properties to create nice focus styles. I share how to do this in “Creating a custom focus style”.

button {
  background-color: #dedede;
}

button:hover {
  background-color: #aaa;
}

button:focus {
  outline: none;
  box-shadow: 0 0 0 3px lightskyblue;
}
Focus a button with Tab. When focused, shows an outline with box-shadow.

Styling active states

When you interact with things in real life, you expect some sort of feedback. For example, if you push a button, you expect the button to get pressed.

This feedback is useful on websites too. You can style the “push button” moment with :active. :active triggers when you interact with an element. Interacting here means:

  1. Holding down your left mouse button on an element (even non-focusable ones)
  2. Holding down the Space key (on buttons)
button:active {
  background-color: #333;
  border-color: #333;
  color: #eee;
}
Changes background-color and color when user holds their left mouse button down on the button.

Two weird things to take note of:

  1. Holding down Space triggers :active on buttons, but holding down Enter doesn’t.
  2. Enter triggers links but it doesn’t create create an active state. Space doesn’t trigger links at all.

Links have a default active style. They turn red when they get clicked.

By default, links turn red when they get clicked.

The relationship between active and focus

When you hold down the left mouse button on a focusable element, you trigger the active state. You also trigger the focus state at the same time.

When you release the left mouse button, focus remains on the element

? is true for most focusable elements except links and buttons.

For links:

  1. When you hold down left mouse button: Triggers :active and :focus state on Firefox and Chrome Only triggers active on Safari (tested on Mac only)
  2. When you release left mouse button: :focus remains on link (if the link’s href does not match an id on the same page). On Safari, focus goes back to .

For buttons:

  1. When you hold down left mouse button: Triggers :active and :focus state on Chrome only. Does not trigger :focus at all in Safari and Firefox (Mac). I wrote about this strange behavior here.

If you want clicks to focus on buttons, you need to add this JavaScript as early as you can. (As for why, you can read the article I linked to above for more information).

document.addEventListener('click', event => {
  if (event.target.matches('button')) {
    event.target.focus()
  }
})

Once you have this code, click behaviour on buttons become:

  1. When you hold down left mouse button: Triggers :active in all browsers. Triggers :focus on Chrome only.
  2. When you release left mouse button: Triggers :focus on Safari and Firefox (Mac). :focus remains on button for other browsers.
Button behavior on Safari.
Button’s behavior on Safari after adding the JavaScript snippet above.

Now you know about hover, focus, and active states, I want to talk about styling all three.

The magic combination

The magic combination allows users to get feedback when they hover, focus, and interact with an element. Here’s the code you need:

.element:hover,
.element:active {
  /* Change background/text color */ 
}

.element:focus {
  /* Show outline /* 
}

For mouse users:

  1. When the user hovers over an element, background-color (and/or color) changes. They get feedback.
  2. When the user clicks on an element, focus outline shows. They get feedback.
Mouse users receive feedback on hover and on click.

For keyboard users:

  1. When the user tabs into an element, focus outline shows. They get feedback.
  2. When they interact with the element, background-color (and/or color) changes. They get feedback.
Keyboard users receive focus on Tab and on interaction.

Best of both worlds!

  1. I have not tested the magic combination thoroughly. This is a proof of concept. I’d appreciate it if you help me with some tests and let me know how it fares.
  2. If you run tests, don’t use Codepen. Focus states for links are weird on Codepen. If you hover over a link, the focus outline gets removed. Why? I don’t know. Sometimes I think it’s best to test stuff like these without any fancy tools. Just plain ol’ HTML, CSS, JS.

The non-magic (but might be better) combination

Like I mentioned above, clicks on buttons have a weird behavior in Safari and Firefox (Mac). If you added the JavaScript snippet I showed you, the magic combination still works. But it’s not perfect.

For Safari and Firefox (Mac), this is what happens:

  1. When users hold their mouse button down, nothing changes.
  2. When users lift their mouse button up, the element gets focus
Button behavior on click in Safari.

If you think this is enough affordance, then the magic combination works. You can stop here.

But if you think there’s not enough affordance, you’d want to style :hover, :focus, and :active separately.

.element:hover {
  /* Change background/text color */ 
}

.element:active {
  /* Another change in background/text color */
}

.element:focus {
  /* Show outline /* 
}
Button behavior on Safari if you styled all three states.

That’s it! Hope you learned something today!

Thanks for reading. Did this article help you out? If it did, I hope you consider sharing it. You might help someone else out. Thanks so much!

guided-by-style

How we keep our content style guide current and use-worthy at Dropbox

A brand is more than a logo. People interested in your product experience the full spectrum of your brand, from billboard ads to payment flows and everything between. Your company’s writing helps people to connect with your product, trust what you deliver, and keep using it.

Building trust

You build trust with the people who use your product by having a cohesive voice, tone, and style across the whole user journey. If your style is inconsistent or varies too much, people can get confused and might abandon your product.

If you call a feature Shopping Cart in one area but Basket o’ Things in another, some people won’t trust your ability to handle sensitive information.

You build trust by being reliable. A content style guide helps to build that foundation of trust.

Why have a content style guide?

A content style guide helps maintain a cohesive writing style across all copy. It can help you define the process for content strategy, and to make sure your copy meets certain regulations, like legal or privacy needs.

Example of a style guide home page
Example of a style guide home page

How do you maintain a content style guide?

The goal of this post isn’t to tell you how to develop your company’s voice and tone, or how to create your first style guide. There are many articles, courses, and trainings online and off that can help you in those areas.

Lessons learned

Over the years, I’ve created and managed many different content style guides for a variety of products, experiences, and audiences.

I created the first-ever content style guide for Google’s former Online Sales & Operations team. I also wrote a style guide for an upscale hair salon that wanted guidelines on how to post to social media like an influencer—and many others in between.

The question I get most often—surprisingly—isn’t, How do I create a content style guide?

Instead, people ask:

  • How do I maintain that style guide once I’ve created it?
  • What’s the process for governance, decision-making, and updates?
  • How do I get people to actually use it once I have a governance process in place?

The Dropbox content style guide

At Dropbox, I manage our internal content style guide. This means I run the monthly meetings, assign tasks, make updates, and share those updates. It doesn’t mean I make all the decisions on my own or tell people what the answer should be. We make decisions as a committee (more on that below).

I also build relationships across the company, especially with teams who can help us with answers, like Security and Legal. People on those teams learn about the style guide and maybe, eventually, come to the meetings to help us make decisions.

Our content style guide covers voice, tone, localization, accessibility, naming, mechanics, and terms and phrases. The majority of it focuses on mechanics and terms. The guide includes everything from how we use emoji and em-dashes to whether we hyphenate “dropdown.” Only internal employees can view the guide, but people across the whole company use it.

The Dropbox Brand team maintains our voice and tone guidelines, but everything else gets updated in our style guide monthly meetings.

The way we make decisions about what to add or update—our process and governance for the Dropbox style guide—is similar to process and governance for other style guides I’ve managed. Other large orgs like The Chicago Manual of Style, BuzzFeed, and the LA Times use a similar process.

Short overview of how we update the style guide at Dropbox:

  • We meet as a group every four weeks and determine which requests are easy decisions and which will require more work.
  • We take care of a few easy decisions, and start (or continue, or complete) conversations about harder decisions.
  • After we’ve made decisions, we update the style guide and socialize the updates.

For more information on how media and publishing companies manage their style guide teams, and how decisions get made at influential style guide resources like The Chicago Manual of Style, AP Stylebook, and others, I recommend attending the national conference of ACES, The Society for Editing (or following them on Twitter). The ACES conference is also a great way to meet people who work on big style guides and learn about their process directly.

Process and governance for the Dropbox internal content style guide

Feedback doc

Anyone at Dropbox can add a suggestion or request to our feedback doc. This is an internal Dropbox Paper doc that’s a list of things people think we need to add to or update in the style guide. The intro to our style guide includes a link to the feedback doc, so it’s easy to find.

Example of a feedback doc
Example of a feedback doc

#askawriter

We also have a Slack channel called #askawriter that’s open to the whole company. Anyone can ask a question that a writer will answer. If we can’t answer something in that channel, we add it to the feedback doc.

Types of questions

People from across the company ask questions about things that aren’t listed in the style guide.

They usually ask about mechanics, terms, and phrases—things that come up on their own as common issues:

  • Do we capitalize this?
  • What’s the official name of that new feature?
  • How do we abbreviate this?
  • Do we use decimals in prices?
  • What’s our standing on this particular phrase?
  • Do we have guidelines in place for X, Y, or Z?
  • My team is asking the same style or writing questions over and over again. Can I point them to an answer?

But more often, Style Council representatives are the ones who bring questions to the meetings.

Who makes the decisions?

The Style Council

Every four weeks, a group of us meet for an hour to go over the feedback doc. I call us the Style Council, as a nod to the ’80s band fronted by Paul Weller. The Style Council includes representatives from teams across the company:

  • UX Writing
  • Product Marketing
  • Brand Marketing
  • CX Customer Education
  • SEO
  • Security Operations
  • Intellectual Property
  • Design Research
  • … and a few others

Volunteers and passionate word nerds needed

It’s a volunteer group, meaning everyone who attends wants to be there. Style Council reps are typically people who love style guides and cherish language. They also—critically—get excited about researching, debating, and deciding sometimes tiny details.

One important note is it doesn’t need to be only writers or editors. Some people who don’t consider themselves writers are hugely passionate about language. These people can often spot a typo a mile away. They’re the ones you want on your style team.

No one should ever be required to be on your style guide committee. A content style guide is fueled by passion for cohesive language, consistent terminology, and the ever-changing nuances of modern spelling, grammar, and punctuation. If anyone feels forced to be there, be prepared to face a tough time making decisions.

Debates, research, and relationship-building

Sometimes our decisions take several months to reach. Sometimes we need to research tiny, picky details about spelling, grammar, punctuation, and company style.

People who love this kind of detail work are ideal for the Style Council. People who get excited by long debates with multiple stakeholders make wonderful reps.

Whoever you choose to be on your style committee, it’s important they understand:

  • the user experience goals of your product
  • the marketing goals of your company
  • and the overall business goals

Specialists make great reps because they can speak for their particular part of the company and goals. Depending on your company, that might be someone from SEO, Engineering, or Project Management.

They also need to be willing to reach out to people they don’t know across the company. Much of the work is finding the correct SME (subject matter expert) who can help us make the right decisions.

If someone would rather add things to the feedback doc and have somebody else figure out what we should do about it, that’s totally fine! In fact, we encourage it.

I’ll occasionally survey the Style Council members on the frequency of meetings and whether people are still happy to be involved. Taking a regular pulse check helps make sure the monthly syncs meet everyone’s needs.

Only one updater

While the decision-making group can be as large as you want, it’s important to have only one person update the content style guide.

This is a common practice at large style guide orgs and media and publishing companies. It helps prevent errors, overwrites, and duplication. This person is the only one who adds to, removes from, or otherwise changes the style guide. They’re usually the one who socializes the updates, too.

Our decision process at Dropbox

Review and assign

At our monthly meetings, as a group, the Style Council goes through each listing in the feedback doc, in order. Based on how complex the entry is, we decide if it needs more research.

Will we need to find an SME (subject matter expert), and if so, what team might that person be on? If it needs more research, we assign someone to follow up with an SME.

Easy decisions

If the question is fairly straightforward, we talk about it until we reach consensus.

We talk about which surface areas and audience would be affected:

  • Does this entry affect in-product writing, emails, blog posts…?
  • Does this entry affect people using the product, people reading the blog, people we’re marketing to…?

If more questions than answers come up, we assign someone to follow up with an SME or do more research.

If the entry is a question about voice or tone, we reach out to the Brand team for clarification.

If the entry is a word listed in Merriam-Webster Unabridged, we’ll usually go with what that entry says—but not always!

If it’s something listed in The Chicago Manual of Style or AP Stylebook, we’ll see what they have to say. We lean on Chicago, but we’re not a 100% Chicago guide. If we stray from Chicago or Merriam-Webster, we need a reason why, so we can defend our decisions if we need to.

Harder decisions

Often, the entries are for proprietary terms or use, so we can’t look to outside guides for answers. For those, we need to dig deeper within Dropbox.

Sometimes the decisions are hard because we have a variety of personalities in the room, with varying philosophies, and the discussion reaches a stalemate. Fostering a collaborative, calm, and inclusive atmosphere helps! Taking large decisions offline or into a smaller group can also help. The Style Guide lead will generally be the one driving this process.

If we have research or more information from an SME, we’ll incorporate that info into our decision-making. Sometimes this means we have to put entries on the back burner for a while, as teams work out their use of the term.

Updating the guide

Once we’ve decided on a term or guideline and the committee has reached consensus, I add it to the style guide and check it off the feedback list. Then I update the to-dos for the next meeting.

Socializing the updates

Finally, I gather all the new additions or updates and post them to a Slack channel called #styleguideupdates.

Example of a shared listing update
Example of a shared listing update

At the end of the quarter, I send an email of all the updates to a list of relevant teams (several hundred people). The email includes all the updates and additions to the style guide during that quarter. It also includes links to the style guide and the feedback doc, and a reminder about our #askawriter Slack channel.

The quarterly email not only updates people on what we’ve added or changed, but helps bring the style guide back on their radar. It also introduces the guide to people who’ve recently joined the company or who otherwise haven’t known about it.

Keeping the fire going

So you’ve created your content style guide, developed a steering committee, and determined a rhythm for making updates. The important next step is to keep people aware of the style guide so they actually use it.

Some ideas you might consider:

  • Quarterly email updates
  • Slack channels or similar messaging forums
  • Monthly Lunch and Learns
  • Style guide roadshows or presentations for specific teams or the entire company
  • Link to the style guide in your email signature or add it to your Slack profile

Some other ways to spread the word include citations, swag, and sharing simple tips.

Citations

UX Writer Jennie Tan offers this great suggestion: “One of the things I do is cite the style guide in my content specs so people know my wording decisions are based on guidelines and not whim.”

Swag!

I collaborated with our Brand team to print up cute bookmarks with the style guide web address and handed them out after an internal talk I gave on writing tips. It’s a sweet surprise to pass by someone’s desk today and see the bookmark on display—I know they’re remembering to use the style guide.

One-minute writing tips

One way I socialized the style guide for a long time was through “one-minute writing tips.” (One of our writers now continues the tradition.) At the beginning of weekly design crits, I’d present to the designers one tip or term pulled from the content style guide.

I followed up at the end of the quarter with a list of the terms we’d covered (including, of course, links to the style guide, feedback doc, and Slack channels).

The designers loved learning about the style guide, and I got fun feedback like:

  • I love the tips because they’re lightweight
  • Extremely helpful content!
  • Love the ongoing awareness of resources available to designers for making quick copy decisions

Stay on track

Keeping a checklist of all these ideas is a good way to help stay on track. Here’s an example of one you can use:

Example of a style guide governance checklist
Example of a style guide governance checklist

Stay worthy of trust

By putting these ideas into action, you might get similar, excited feedback on your own style guide. Helping people understand your process for making updates provides a level of transparency that internal teams crave, which also helps maintain that foundation of trust and reliability you’ve built with your style guide.

sass-style-guides

A collection of hand-picked Sass style guides.

  1. HTML / CSS Style Guides
  2. JavaScript Style Guides
  3. React Style Guides
Demo image: Sass Guidelines

Date

Author

Hugo Giraudel

About a style guide

Sass Guidelines

An opinionated styleguide for writing sane, maintainable and scalable Sass. The Sass Guidelines project has been translated into several languages by generous contributors. Open the options panel to switch.

Demo image: The Ultimate Sass Style Guide

Date

Author

Tommy Coppers

About a style guide

The Ultimate Sass Style Guide

The root of a code style is about authorship and presentation rather than function and performance. A considerable amount of time goes into developing a style. Sometimes an engineer will seek out guides, memorize patterns, and write love songs about their beloved methodology. Others might just happen upon their own way of doing things based off of years (or minutes) of developing and organizational preferences. But if styles are purely aesthetic, why do we get so upset when someone disagrees with how we’ve written our code?

Demo image: Sass Coding Guidelines

Date

Author

BigCommerce

About a style guide

Sass Coding Guidelines

Bigcommerce uses Sass for style generation. Bigcommerce’s naming conventions are heavily influenced by the SUIT CSS framework and align closely to Medium’s thoughts on CSS. Which is to say, it relies on structured class names and meaningful hyphens (i.e., not using hyphens merely to separate words). This helps to work around the current limits of applying CSS to the DOM (i.e., the lack of style encapsulation), and to better communicate the relationships between classes.

Demo image: Sass Style Guide

Date

Author

Chris Coyier

About a style guide

Sass Style Guide

With more people than ever writing in Sass, it bears some consideration how we format it. CSS style guides are common, so perhaps we can extend those to cover choices unique to Sass. Here are some ideas that I’ve been gravitating toward. Perhaps they are useful to you or help you formulate ideas of your own. If you’re looking for more examples, Sass Guidelines is another good place to look.

Demo image: Sass Style Guide: A Sass Tutorial on How to Write Better CSS Code

Date

Author

Matias Hernandez

About a style guide

Sass Style Guide: A Sass Tutorial on How to Write Better CSS Code

Writing consistent and readable CSS that will scale well is a challenging process. Especially when the style sheets are getting larger, more complex, and harder to maintain. One of the tools available to developers to write better CSS are preprocessors. A preprocessor is a program that takes one type of data and converts it to another type of data, and in our case CSS preprocessors are preprocessing languages which are compiled to CSS. There are many CSS preprocessors that front-end developers are recommending and using, but in this article we will focus on Sass. Let’s see what Sass has to offer, why it is a preferable choice over other CSS preprocessors, and how to start using it in the best way.

javascript-style-guides

A collection of hand-picked JavaScript style guides.

  1. HTML/CSS Style Guides
  2. React Style Guides
Demo image: Google JavaScript Style Guide

About a style guide

Google JavaScript Style Guide

This document serves as the complete definition of Google’s coding standards for source code in the JavaScript programming language. A JavaScript source file is described as being in Google Style if and only if it adheres to the rules herein.

Demo image: Airbnb JavaScript Style Guide

About a style guide

Airbnb JavaScript Style Guide() {

A mostly reasonable approach to JavaScript.

Demo image: Airbnb CSS-in-JavaScript Style Guide

About a style guide

Airbnb CSS-in-JavaScript Style Guide

A mostly reasonable approach to CSS-in-JavaScript.

Demo image: JavaScript Language Coding Style

Date

Author

Ilya Kantor

About a style guide

JavaScript Language Coding Style

Our code must be as clean and easy to read as possible. That is actually the art of programming – to take a complex task and code it in a way that is both correct and human-readable. A good code style greatly assists in that.

Demo image: WordPress JavaScript Coding Standards

Date

Author

WordPress

About a style guide

WordPress JavaScript Coding Standards

JavaScript has become a critical component in developing WordPress-based applications (themes and plugins) as well as WordPress core. Standards are needed for formatting and styling JavaScript code to maintain the same code consistency as the WordPress standards provide for core PHP, HTML, and CSS code.

Demo image: JavaScript Standard Style

Date

Author

Standard JS

About a style guide

JavaScript Standard Style

JavaScript Style Guide, with linter & automatic code fixer.

Demo image: function qualityGuide

Date

Author

Nicolás Bevacqua

About a style guide

function qualityGuide () {

This style guide aims to provide the ground rules for an application’s JavaScript code, such that it’s highly readable and consistent across different developers on a team. The focus is put on quality and coherence across the different pieces of your application.

Demo image: Principles of Writing Consistent, Idiomatic JavaScript

Date

Author

Rick Waldron

About a style guide

Principles of Writing Consistent, Idiomatic JavaScript

This is a living document and new ideas for improving the code around us are always welcome.

Demo image: JavaScript Style Guide

Date

Author

Khan Academy

About a style guide

JavaScript Style Guide

This guide is adapted from the jQuery style guide.

Demo image: Node.js/JavaScript Style Guide

Date

Author

Felix Geisendörfer

About a style guide

Node.js/JavaScript Style Guide

A guide for styling your node.js / JavaScript code.

Following a CSS style guide can create a beautiful code base which will make any developer love working on a project. They enable a codebase to be flexible, easily scalable and very well documented for anyone to jump in and work on with other developers.

We’ve gathered together some CSS style guides that should give you a great start on creating your very over set of rules for your CSS or one for you to follow without having to start from scratch.


CSS Guidelines

CSS Guidelines is written by Harry Roberts. High-level advice and guidelines for writing sane, manageable, scalable CSS.


Sass Guidelines


Code Guide

Mark Otto, the creator of Bootstrap has put together a code guide for developing flexible, durable, and sustainable HTML and CSS.


Airbnb CSS / Sass Styleguide

Airbnb’s “reasonable approach to CSS and Sass.” A readme to how Airbnb style their Sass, they have also provided a scss-lint.yml file to use in your own project.


CSS Bliss

A CSS style guide for small to enormous projects, without all that pomp and cruft. Many ideas borrowed from BEMSMACSSOOCSSSUITECSS.


CSS Style Guide by Mark McDonnell

This is a personal style guide by Mark McDonnell for writing CSS. As a bonus, he has also written style guides for JavaScript, HTML, PHP & Ruby


Dropbox’s (S)CSS style guide

Dropbox’s very own style guide they follow across their in-house projects.


Workable’s CSS Style Guide

This is the coding style guide Workable use for writing CSS & Sass in their projects.


Further reading about CSS Style Guides

If you’re looking to start a style guide for your CSS we’ve also compiled a list of great articles to read before jumping right into creating one.


Have a style guide that you think should be on this list? Leave us a comment!

what-are-data-visualization-style-guidelines?

Examples from the Google and London City Intelligence style guides

Organizations like Google and London City Intelligence recently extended their design systems to include standards specifically for data visualization. This speaks to the growing importance of using data and metrics in an organization’s decision making and the value of branding them appropriately.

Examples from the Sunlight Foundation and Consumer Financial Protection Bureau data viz style guides

In 2014, I created one of the first ever data visualization style guides for the Sunlight Foundation and then another one for the Consumer Financial Protection Bureau (CFPB) in 2017. I’m excited to see more organizations devote resources into standardizing their data visualization work.

The first step is defining what exactly a data visualization style guide is. As part of the Data Visualization Society, I’ve begun collecting examples of guides across multiple types of organizations. I will be taking a deep look at what is common practice, how this differs across organization types, and identifying innovative extensions that others might consider incorporating into their own guides. The more examples I have for this process, the better, so please submit guides and add to the spreadsheet!

Spreadsheet with examples of data visualization style guides

Definition: Data visualization style guides are standards for formatting and designing representations of information, like charts, graphs, tables, and diagrams. They include what (e.g. types of charts) and why (e.g. reasons for using specific colors). Templates for various tools (like Excel, R, D3.js or Tableau) often accompany a guide to show the how and to make it easy for people to apply the standards from the guide.

Data visualization style guides fit within an organization’s larger design system. They include how other guidelines, like brand standards or editorial guidelines, apply to data visualization. For example, they specify how elements like a logo, brand colors, and language tone specifically apply to charts, tables, and diagrams.

Style guides maintain uniformity across different tools and software that produce charts. An organization’s charts should be consistent across tools and look visually similar to the rest of the blog or report it’s part of. Having a style guide with principles and components that work across multiple tools, rather than just one template for one tool, helps achieve this consistency.

Designing for data is a unique challenge. It requires considerable precision and numeracy, but also careful thinking about audience, perception and accessibility constraints. Because the information needs to be conveyed accurately and understood properly, there are additional design constraints when it comes to writing chart titles and displaying connection between labels and data. Styles and colors that may work when applied to illustration do not always work when applied to the density of information data visualization often needs to convey.


As mentioned above, I’ve collected data visualization style guidelines from a variety of organizations in a spreadsheet. Often these guides are used internally as part of a larger design system, but it’s helpful to look at examples across multiple organizations when creating one of your own. Different types of organizations have different types of information, audiences and needs. I’ve organized the examples by type, and will highlight especially effective features of each. Not all organizations release their style guides publicly, although publishing them can help build brand integrity and attract talent.

Sunlight Foundation

These guidelines spec out what colors should be used for and define particular palates that signify common meanings tended to re-occur in Sunlight’s work (like when used for political parties or pro/con charts). There’s also a detailed specification for basic chart structure and how to include branding to ensure that all Sunlight charts were consistent.

Cato Institute

This guide includes examples of how to most accurately show data visualizations for their audience and a section on how to implement different categories across types of charts. The guide clearly explains some charting best practices that may not be obvious to everyone within the organization that might make a chart if they haven’t had training.

London City Intelligence

This guide dives deep into color choices and why colors work together or don’t. The guide does a great job of including examples for different types of data, as well as light and dark backgrounds.

Dallas Morning News

The Dallas Morning News guide includes details about color and style choices for maps to keep the displays consistent. It also includes a map of how the graphics process works at the organization. A style guide isn’t useful if people at the company don’t know how to use it properly and work with the system.

BBC Global Experience Language

The BBC design system has a “How to design infographics” section. Notable points include a variety of examples of labels and a section on how to design responsive graphics that work for different devices.

Google Material Design

This guide has lots of examples of dos and don’ts with explanations of why the examples work or fail. It also a section specifically about dashboards with a unique layout for dashboards to help standardize them.

IBM

IBM’s guide includes sections to help chart creators think about who the intended audience is as well as examples of common chart types and what type of data they should be used for.

If you know of a data visualization style guide that’s not on this spreadsheet, please take a moment and add it by filling out this form!


There are many different types and categories of style guidelines. It’s useful to be aware of the various types and who uses them to understand where data visualization fits into the broader design system.

family tree of style guides, all which fit into the broader design system

family tree of style guides, all which fit into the broader design system

Design systems incorporate other types of style guides, including data viz style guides

Design systems are the full set of standards and documentation. All the other examples below can live together within the complete design system. They can also include code libraries and packages for developers to build with, as well as design components. The US government has a full design system with many of these systems and UX Pin has an amazing table of design systems that categorizes their components. A data visualization style guide fits into the broader design system.

Homepage and the different sections of the United States Web Design System

Brand manuals or style guidelines are documents traditionally created by designers to document how to keep the integrity of a company’s brand across multiple implementations. They define things like brand colors with color values, typography style and usage and how to use the logo. They’re important to keep the brand consistent across materials created by different people, and to help contractors understand the core system. The design blog Brand New often pulls examples from style guides when they review new logos. One of my favorites is a spoof on brand guidelines for “Santa”. Brand manuals will influence what colors and typography is used for data visualization, as well as how the logo is used on charts.

Example from Linkedin of how to use the logo properly.

Editorial guidelines or content style guides define the voice and tone of the brand as well as specific language usage, like how and when to abbreviate or capitalize words. Mailchimp is a great example of a brand with a consistent unique tone and a thorough guide to accompany it. Editorial guidelines are usually written by content writers and are useful to anyone at the organization or outside contractors and consultants who write or edit anything about the company. Lauren Girardin wrote How to Create an Editorial Style Guide for Your Agency specifically for governments, but the content is applicable beyond the public sector. Data visualization style guides pull content from editorial style guide for title and labeling usage. It’s helpful to have consistent messaging around errors and how notes or qualifications are worded for clarity.

Example from MailChimp’s guide on how to properly use abbreviations

Pattern libraries document how design elements are used together across a website like specific page types or in navigation.The BBC GEL has a great example in their guidelines. Paul Boag wrote How to create a pattern library and why you should bother, which gives a good overview of pattern libraries and why they’re useful for UX. Data visualization is in itself a pattern that has its own set of components like titles, subtitles, charts, data, sources and legends. These all work together to create a visualization pattern.

Patterns from BBC GEL that show how components work together

Charts of charts” (which is what I’m calling them for lack of a better name) show a variety of visualization types for specific kinds of data. These can be part of a larger style guide, but on their own don’t include enough information to show the specifics of a style and why decisions were made to be categorized as a style guide. Examples include Visual Vocabulary, Chart Chooser cards, Graphic Continuum poster, and the Data to Viz website.

Example from FT Visual Vocabulary of different chart types

Standardizing data visualization in a guide can help mature this aspect of an organization and allow visualizations to fit into the broader branding and design systems that are already established. Collecting examples of these guides across multiple types of organizations and increasing this collection will show what’s standard and useful across this particular type of style guidelines.