InVision presents

Design Systems Handbook


by Marco Suarez, Jina Anne, Katie Sylor-Miller, Diana Mounter, and Roy Stanfield

A design system unites product teams around a common visual language. It reduces design debt, accelerates the design process, and builds bridges between teams working in concert to bring products to life. Learn how you can create your design system and help your team improve product quality while reducing design debt.


Go to Chapter
Introducing design systems
The power of scale

Repetition and reusability make scale possible. InVision’s Marco Suarez takes you back to the foundations of component-based design and the many ways design systems enable scaling. He also addresses a few common misconceptions about design systems.
 

Go to Chapter
Go to Chapter
Designing your design system
Step by step

Starting can be the hardest step. Design systems expert Jina Anne walks through what to consider as you start out. Involve the right people, find the right model, add the right pieces—and you’ll be well on your way to establishing a successful design system.

 
 
 
 

Go to Chapter
Go to Chapter
Building your design system
A strong foundation

Building a flexible, maintainable, stable, scalable design system creates a strong base for your product design team. Etsy’s Katie Sylor-Miller shares foundational knowledge learned building design systems across cross-functional teams.

 

Go to Chapter
Go to Chapter
Putting your design system into practice
Better together

Encouraging adoption of your design system forges connections and creates champions across teams. GitHub’s Diana Mounter lays out practical strategies for sharing design systems and growing adoption, including examples from her experience.

 
 

Go to Chapter
Go to Chapter
Expanding your design system
More than the sum of its parts

Components form the core of a design system, but teams can align around much more than components. Marco Suarez outlines how teams can round out their systems with vision statements, design principles, voice and tone guides, and more.

 

Go to Chapter
Go to Chapter
The future of design systems
To infinity and beyond

Design systems play a huge role in shaping our present, but we may only be scratching the surface. Airbnb’s Roy Stanfield explores a bold future of intelligent, adaptive, context-aware systems that could further accelerate design’s possibilities.

Go to Chapter
Go to Chapter
Appendix
More resources

Design systems continue to evolve, and every company’s system can offer something to our collective knowledge and understanding. We’ve curated a list of publicly available design systems and resources to help you continue your exploration. 

Go to Chapter
03

Building your design system

A strong foundation


by Katie Sylor-Miller

Modern design systems are the result of many years of evolution in the way we write front-end code. When I started my career, most sites were built with single-use, inefficient, fragile, and inconsistent front-end codebases. Through hard-won experience and many years of collaboration and iteration, front-end developers have established more sophisticated practices for writing and organizing our code. Now, there is an explosion of front-end frameworks and tooling to help you write better, more maintainable HTML, CSS, and JavaScript.

This represents an exciting paradigm shift in front-end development, but the number of choices available can be overwhelming. A cursory glance at the table of contents for Cody Lindley’s Front End Developer Handbook 2017’s section on tools reveals a bewildering array of considerations. I couldn’t possibly cover all of the technology choices available—the factors that go into your decision-making will be largely situational, and this is only a chapter!

Instead, I’ll save you the headache of attending the school of hard knocks by walking you through what I’ve learned from building and contributing to 3 different design systems. First, I’ll cover the technology-agnostic foundational principles that should guide the development of your design system. Then, I’ll focus on some common pitfalls and how you can avoid falling prey to them. Throughout, I’ll introduce you to some of the tools that will help you along the way, but remember this: Your technical approach doesn’t matter as much as creating a living, breathing system that’s flexible, maintainable, stable, scalable, and successful in the long-term.  

Foundations

Regardless of the technologies and tools behind them, a successful design system follows these guiding principles:

  • It’s consistent. The way components are built and managed follows a predictable pattern.
  • It’s self-contained. Your design system is treated as a standalone dependency.
  • It’s reusable. You’ve built components so they can be reused in many contexts.
  • It’s accessible. Applications built with your design system are usable by as many people as possible, no matter how they access the web.
  • It’s robust. No matter the product or platform to which your design system is applied, it should perform with grace and minimal bugs.

Let’s take a look at each of these principles in more detail.

Consistency

Your first, most important task when starting out is to define the rules of your system, document them, and ensure that everyone follows them. When you have clearly documented code standards and best practices in place, designers and developers from across your organization can easily use and, more importantly, contribute to your design system.

Code style guides

Code style guides provide the grammar rules of syntax and semantics for your code. Code syntax is the set of rules for structuring and formatting your code (e.g. curly braces always go on a new line). Code semantics provide the rules for making your code understandable (e.g. alphabetize CSS property declarations). But don’t get bogged down fighting pointless wars over tabs versus spaces. The most important thing is to end up with consistently written code, not to achieve theoretical perfection!

Automating code style

To enforce your code standards and achieve consistency in your system, help your contributors write code that follows the rules through linting and tooling.

Linting is an automated process of analyzing code and raising errors when code either doesn’t adhere to your syntax rules or is broken, buggy, or malformed. Linting tools such as CSSLint or StyleLint for CSS, and JSHint or ESLint for JavaScript, can be run manually as part of your local development process, as an automated pre-commit hook before code is checked into source control (the best option), or run as part of your build process.

Code editor configuration

An often-overlooked but important corollary to linting is providing an Editor Config to enforce code style in your editor(s) of choice. EditorConfig.org (figure 1) provides a cross-platform format to define stylistic rules for most code editors and IDEs, so you can automatically convert your tabs into spaces—thus ending the tabs versus spaces war!

Self-contained

Your design system should live in a source control repository independent from your main codebase. Although it will require more work to get up and running, a separate repository brings many long-term benefits:

  • It enables versioned releases of your code (more on this later)
  • It allows you to share code across multiple teams, products, and codebases
  • It forces you to develop components in isolation so they’re not tied to a single use case
  • It provides infrastructure for a robust front-end testing architecture
  • It forms a foundation for a living style guide website

A standalone design system repository functions as a single source of truth. There is only one place where components are defined, which then gets shared into other codebases as a discrete dependency. Because all usages point back to a canonical implementation, changes in a single place propagate through the entire system.

Ideally, all of the code for each component within your system is co-located: CSS, JavaScript, HTML templates, and documentation all live in the same place, possibly the same directory. If you’re using React with CSS-in-JS, each component may even be encapsulated in a single file. The closer the pieces are to each other, the easier it is to trace and manage dependencies between bits of code, and the easier it will be to update and maintain.

Reusable

Successful design systems are highly reusable. Bootstrap, the most-used front-end library of all time, powers hundreds (if not thousands) of websites because it was architected with reusability in mind. Writing components to be reused in multiple contexts is vitally important, yet hard to do well—make components too focused for a single use case or too inflexible, and users will end up creating their own patterns.

To be reusable and scalable, patterns need to be modular, composable, generic, and flexible.

  • Modular components are self-contained with no dependencies
  • Composable components can be combined to create new patterns
  • Generic components can handle multiple use cases
  • Flexible components can be tweaked and extended to work in a variety of contexts

Modular CSS architecture

Reusability and scalability in design systems begin with taking a modular approach to your code architecture. CSS, however, is not inherently modular. So over time, systems like SMACSS, OOCSS, and BEM have added structure and modularity to CSS. More recently, CSS-in-JS approaches such as Styled Components have solved the problem by defining CSS properties in JavaScript code structures.

Whether you use one of these systems or roll with your own, the fundamentals of any good CSS architecture are the same:

  • It has clear naming conventions for components, variations, and utilities
  • It’s tightly-scoped and has low-specificity CSS that limits unintentional side effects
  • It has utility classes that allow you to modify styles in a managed way
  • It has rules for building modular, composable, generic, and flexible components

To learn more about architecting CSS so that it meets these criteria, I highly recommend Harry Roberts’ https://CSSguidelin.es/ (figure 2), then adding this type of documentation to your system.

Accessible

For too long, accessibility, or a11y, has been misunderstood as building sites for a small group of users of assistive technology—a blind person using a screen reader—and far too often dismissed as too complex, too time-consuming, or “not our customers.” Accessibility, however, is not just for a single, small group, but for an estimated 15% of people worldwide (56.7 million people in America alone) with a wide spectrum of permanent or temporary visual, auditory, motor, and cognitive impairments.

Thankfully these attitudes are changing and our industry is embracing a more inclusive definition of accessibility. Making your site accessible to users with disabilities improves the experience for everyone who visits your site. If that isn’t enough motivation, improving your site’s accessibility can help improve SEO, and it’s becoming increasingly more important from a legal standpoint to avoid costly lawsuits.

In a landmark case against the grocery chain Winn-Dixie, a federal judge ruled that websites are subject to the provisions of the Americans with Disabilities Act (ADA). If you’re just learning about accessibility, there are a lot of resources to help you get started. I recommend reading the introductory articles from the W3C’s Web Accessibility Initiative (WAI) WebAIM, and the A11y Project. You can inspect the current state of your site using Tota11y, an a11y visualizer bookmarklet by Khan Academy. Starting an accessibility practice where none has existed before can be challenging, but when you leverage your design system, it’s easier than you might think.

Enforce a11y with your design system

To ensure everyone at your organization builds accessible sites, features, and apps, enforce accessibility best practices in your design system code.

  • Test your color usage against established color contrast guidelines (figure 3).
  • Build components to be keyboard and screen reader accessible by default. The Ebay Accessibility MIND pattern library is an amazing, thorough resource to help guide development of accessible components and best practices. Encourage contributors to build according to these guidelines and test their code using keyboard-only navigation and assistive technology devices like screen readers.
  • Include in your documentation code standards and guidelines for common a11y best practices such as using larger, legible text sizes, always associating a form field with a label, and properly adding alt text attributes to images, to name a few. Salesforce’s Lightning design system and Shopify’s Polaris are great examples of accessibility guidelines in practice.

These accessible practices improve usability for everyone by making it easier to view, interact with, and navigate a site, improving form completion rates and reducing user mistakes.

Use the power of your single source of truth to create a foundation for accessibility, thus relieving some of the burdens from product teams. It’s much easier to build in accessibility from the start than to bolt it on after a feature has been designed and built.

Robust

A robust design system has a strong foundation of tests behind it. Testing provides confidence in your code, which facilitates adoption. Users will know that they can upgrade or change their UI without it breaking in unexpected ways. Additionally, your design system is uniquely positioned to form a foundation for robustly testing your front-end code.

Test your design system instead of your complicated UI

Keeping tests up to date for pages, applications, and features—especially on a rapidly changing site or one with heavy experimentation—requires a lot of work. Tests get out of date quickly! You can narrow the scope of your tests and gain higher levels of confidence in your site-wide front-end code by heavily testing your design system components. You already need to generate example code for the different states of each component for your documentation—use those as your test fixtures.

Types of tests

There are 4 types of tests used for ensuring stability in your design system:

  • Unit testing: These tests verify that small units of code (usually individual JavaScript functions) behave as expected. Unit tests execute functions with a set of predefined inputs, then verify that they return the expected output. Some popular frameworks to use are Mocha, Jasmine, and Jest.
  • Functional testing: In functional tests, examples of your code, or “fixtures” are run in a virtual “headless” browser, then tested by performing simulated user actions, and checking the new state of the browser for the expected result of those actions. Functional testing frameworks include Nightwatch, Protractor, and Casper.
  • Visual regression testing: These tests help catch unintended visual changes to component styles. The test framework takes screenshots of your fixtures both before and after the changes, then compares them using an algorithm to detect visual differences. There are open source frameworks like Wraith, Gemini, and BackstopJS, as well as paid services like Applitools and Percy.io. Go to Kevin Lamping’s excellent resource Visual Regression Testing for more information and options.
  • Automated accessibility testing: Leverage tooling to ensure that your components are accessible. Some options for running automated a11y audits are Paypal’s AATT and a11y by Addy Osmani, and aXe by Deque Systems.

Common challenges

No system is ever perfect. You will make decisions that you later regret, no matter how much time you put into designing your design system. You can, however, anticipate issues that arise as your system grows, and work to avoid or mitigate their effect on your project. There are 3 common challenges I’ve seen arise in multiple design systems:

  • Keeping documentation up-to-date with your system code
  • Handling breaking changes
  • Avoiding performance degradations

Let’s look at each of these concerns in detail.

Maintaining documentation

The first time I built a front-end component library, my team decided it would be easier to create a documentation website with a codebase separate from our application. In hindsight, this decision broke the cardinal rule of Don’t Repeat Yourself. Whenever a component changed in our main codebase, we had to remember to actually update the documentation, then do the tedious work of duplicating the changed code in 2 different codebases. Unsurprisingly, our documentation got out of date almost immediately!

Learn from our mistakes by reducing the distance between your documentation and code and using automation.

Minimize separation between library code and documentation code

Earlier in the chapter, we discussed storing your design system code in a separate repository that functions as your single source of truth. When documentation and code are co-located, it’s more likely that you’ll remember to update the documentation when a component changes. Consider adding a pre-commit hook to your design system repository to warn contributors when their code adjustments don’t also contain updated documentation files.

Automate documentation

Start by documenting your system using simple, human-readable files written in markdown, co-located with each component. Github is already configured to render and display any file named README.md when you’re viewing a folder’s contents—you might not need a flashy website at all!

If and when you do decide to create a full-featured documentation website, use automation to simplify the process. Instead of creating a new codebase for a separate website, use a tool that will auto-generate documentation for you—there are lots to choose from—reducing the amount of structural HTML you need to write and maintain.

Handling change

As adoption grows and your design system becomes more widely used, you will invariably realize that you didn’t get it all right the first time, and you will need a plan to handle breaking changes. A breaking change is a situation where necessary changes to a component’s code will break existing usages of that component or class. The Morningstar design system provides guidance to contributors on what is considered a breaking change. If mishandled, breaking changes can be a major pain point for your users.

The wrong way: duplication

Initially, all of the CSS and JavaScript for Etsy’s Web Toolkit lived in the same monorepo with the rest of the team’s site code. This meant that whenever someone made a breaking change to a component, their commit making the change had to also contain fixes and updates for every single usage of that component. At first, when just a small team built and used the system on a subset of pages, finding and making these changes was relatively easy. But as adoption spread throughout the company, this quickly became unmanageable.

It became such a headache to make major structural changes to existing components that our team at Etsy started to duplicate and deprecate—when we refactored our Tab component to make it fully accessible, we created a new component named “Tabs2,” and deprecated “Tabs” in the hopes that teams would take on the work to upgrade their code. But without clear guidance on how, why, and a timeline stating when to upgrade, most uses haven’t been updated to use the new component. This kind of duplication is a code maintenance nightmare.

The right way: versioning

Breaking changes are easier to manage if you store your design system code in its own source control repository. This gives you the ability to do versioned releases of your code, which can be shared with other projects. Git allows you to tag a commit with a release version number, and package managers like npm and Yarn allow you to package up and publish multiple versions of your design system code.

With versioned releases, the adopters that integrate your design system code can target a specific version as a dependency and control when and how upgrades to new versions are handled. Make sure to publish release notes detailing changes so other teams can learn how upgrades will impact their codebase and better plan for upgrade work in their project timelines.

Avoiding performance issues

As a design system grows over time, generally so does the file size of assets sent over the wire on each page. This can negatively affect your site’s page load performance, which in turn negatively affects your company’s bottom line. Help the products built on your design system avoid performance issues by taking a mobile-first approach and build your system with modularity in mind.

Mobile first

Poor page load performance will have the largest negative effect on mobile visits. According to statistics from Google and Akamai, more than half of mobile visitors will abandon pages that take longer than 3 seconds to load, yet the majority of mobile sites take longer than 10 seconds to load. As mobile traffic overtakes desktop, speeding up your page’s performance is more important than ever to give you a competitive edge.

Build your design system mobile-first—test early and often on real devices with real hardware and a real network connection so you can understand the experiences of real users.

Leverage modularity

Initially, it made sense to bundle all of the Etsy Web Toolkit components and utilities into single files for CSS and JavaScript. While this is useful for prototyping, it adds unnecessary weight to production pages that don’t use all the components. Now, we’re working to avoid performance problems by better using the modularity inherent in the system. To do this, we are:

  • Deciding on a set of core components and utilities that are most frequently used. This base file will be included on all pages that use the design system and can be cached by the browser across page requests to improve load times.
  • Ensuring that all components are fully modular with no cross-component dependencies (unless they are explicit and managed by the system).

Packaging and sharing the system’s code so that it can be consumed as individual CSS and JavaScript modules added as dependencies only when a component is actually used on the page. We use an in-house system to define dependencies in our front-end code. Build your design system modules so they work with the dependency manager that your team uses. Webpack is a popular option.

Forward-thinking

Design tokens

For most of this chapter, I’ve focused on building design systems for web applications and sites. However, that’s not the full picture. Modern organizations face unique challenges with their design systems at scale. Today, we build for multiple web and native platforms that need design consistency. Larger organizations may have multiple sub-brands that want the shared support, functionality, and organization that a design system brings, but each needs a different, brand-aligned look and feel. The Salesforce UX team introduced a solution to both of these problems: design tokens (figure 8).

Cross-platform sharing

Design tokens are a way to abstract design details like colors, fonts, rounded corner radius, etc., into a format that can be shared across platforms using Salesforce’s Theo tool. Instead of defining your main brand color as a SASS $variable in your web app, a UIColor in your iOS app, and a textColor in your Android app, you define a single design token in a shared JSON file that gets compiled into platform-specific code (figure 9). Decide to change all of your rounded corners from a 3px to 5px border-radius? Change the value once in your tokens file, and it propagates to all of your apps automagically.

Multi-product theming

You can also use tokens to “theme” the same structural styling for multiple brands. One brand wants orange buttons and the other wants blue? No problem! You can define different token values for each brand, then combine each to the same, base CSS to output themed versions of your design system. That way, all of the classes are the same, and all of the accessible JavaScript functionality you worked so hard to build can be used as-is with no modification for each brand.

Conclusion

Systematizing your front-end code benefits everyone in your organization: developers move faster, designers don’t have to reinvent the wheel, and ultimately, your users have a better experience. But starting out can feel overwhelming!

Thankfully, there is a wealth of resources and a growing community of folks sharing their own best practices to help you build your system. Anna Debenham’s Styleguide Resources lists nearly 500 public design systems/style guides/pattern libraries to use as inspiration. While they look and feel very different, each shares a common goal and is built upon foundational principles that our industry has developed through many years of trial-and-error.

A flexible, maintainable, stable, scalable, and successful design system begins with a strong foundation that goes beyond frameworks or tooling. If I’ve learned anything in my career, it’s that the only constant in front-end development is change. Chances are, within a few years, the technology driving your front-end will look very different than it does right now. If you build for the long-term and plan to handle change, then you can implement new, better practices as your system grows.

That’s not to say you should aim to create another Bootstrap right out of the gate. Even if your team can only implement a few of the best practices we’ve discussed in this chapter, it’s still worthwhile—some of the techniques I recommend haven’t yet been implemented in the design system that I work on every day! Design systems are not a one-and-done thing, but a continual process of iteration and change as we make mistakes, learn from each other, and create new and better approaches to front-end code.

05

Expanding your design system

More than the sum of its parts


by Marco Suarez and Sophie Tahran

As mentioned in Chapter 1, early software programming was limited by the speed and capability of hardware. But over time, hardware became increasingly faster and cheaper, and the inefficiency of software became even more noticeable.

As product teams are expected to move faster and faster, speed and efficiency is an ever-growing concern. However, design systems enable teams to find speed, efficiency, and consistency through reusability. As you experience these benefits, other areas of inefficiency that were once unnoticeable become glaring.

Alignment is often one of those areas. Aligning team members, teams, and a company around things like direction, expectations, and quality is critical to moving and scaling quickly. Without alignment, friction increases and velocity slows—something product teams cannot afford.

A design system is a fantastic way to create alignment around interface design and implementation. But beyond components, teams can build alignment with vision, design principles, process, and voice and tone.

Vision

A vision statement moves everyone toward a common destination. Vision is your North Star. It’s a reusable statement that gives context to your work to help your team stay on track and in sync. A vision statement declares what your team, product, or company is attempting to achieve and why it’s worth achieving. It’s comprehensive yet memorable, elevating yet attainable.

Vision creates clarity, making non-essentials easier to identify. Momentum is far easier to build once everyone knows where they’re going and why.

A few years ago, the Starbucks product team was reorganizing and needed to clarify—for themselves and the entire company—their reason for existing. In a corporation as large as Starbucks, it’s vital to clearly and succinctly express the purpose and value of your team.

“We create digital products that make our customers happy and our partners proud.” This statement became their rallying cry. The vision grounded decision-making to improve the experience for customers and partners (baristas, managers, office employees) as well as achieve business goals.

Informal vision statements for discrete projects also became useful. “Clarity first, then elegance if possible,” was the guiding principle of a recent redesign.

Nick Grossman of Union Square Ventures gives several examples of how a North Star impacts company alignment in his talk, “Purpose, Mission & Strategy.” One example he gives is about Foursquare’s product focus moving from the consumer app to the direction of being a location data platform that could power other applications. This was a massive shift in direction. It was the vision “making cities more delightful” that provided a much-needed North Star for employees to accept and embrace this new model. Grossman says, “It was a watershed moment for aligning the company around a new direction.”

It’s helpful to assess your progress as a team. At Etsy, we held retrospectives after every major launch. A retro is a meeting to celebrate the things that went well and identify the things that didn’t for a particular launch. It’s also an opportune time to check your alignment with your vision.

Design principles

Designers often operate with their own implicit set of standards to evaluate the quality of their work. But when teams grow, explicit standards become necessary to unify all with a shared language and a guide to evaluating the work. How do you define good design? How do you know what’s essential and what’s arbitrary? How do you know when something is ready to ship? How do you know if you’re on the path to achieving your vision?

A system of principles can provide the answers. Design principles act as a reusable standard for designers to measure their work. They replace subjective ideals with a shared understanding of what design must do for users. Just as guardrails keep you safe and on the road, design principles keep teams on the path to achieving their vision.

Posting your principles on the office walls, creating a computer desktop wallpaper, adding them to your design systems site, or printing them on notebooks are all great ways to keep them top of mind. Task your most senior designers with using them in every design critique to ensure the new language is adopted. This new system of language will become a vital part of your design system because it creates alignment, enabling your design team to scale.

While designing InVision Studio, the design team realized far too much time was spent debating solutions. So a set of principles was drafted to help navigate the complexity of designing software. These principles were used to guide individual decision-making, help reach agreements faster as a team, and acted as a transcendent standard to create harmony and cohesion throughout the product. The principles were modified over time as Studio evolved and needs changed, but these principles aligned the team and helped them keep the velocity they needed.

Process

Providing a clearly defined process for how user experience problems are approached and solved builds alignment within product teams. This consistency helps to remove friction and build velocity.

Process guide designers through a series of clearly defined milestones, each with different objectives and deliverables. These milestones act as interdependent components that, when used together, improve the probability of arriving at optimal solutions.

A repeatable process offers several key benefits:

  1. It provides clear expectations within each step, allowing you to focus solely on the tasks at hand without worrying about what to do next
  2. It builds data within each step that can be referenced and used to inform future iterations or course-correct low performing launches
  3. It creates an understanding of the roles and responsibilities of each team member involved—bringing the right people in at the right times, making everyone’s involvement beneficial to the quality of the output

A repeatable process will ensure progress is smooth, efficient, and predictable while also improving the quality and consistency of your work.

At InVision, our process has 6 steps:

  1. Understand: First, we use customer research and insights to gain a deep understanding of the problem space and identify how it aligns with our business goals. Product management leads this phase and works with the research team to conduct interviews, gather data, and perform competitive research.
  2. Explore: The design team then ideates and explores possible solutions. They work with product and research teams to produce wireframes, core flows, and user journeys.
  3. Define: Once a potential solution has been identified, the product team works to align everyone on what success looks like. The output of this work is a problem statement and defining measurements of success.
  4. Design: Refining the solution is design team’s responsibility. They work with the research, product, and engineering teams to develop core flows, prototypes, and identify tech requirements.
  5. Build: Engineering translates the design and prototypes into reality. The product team orchestrates quality assurance, support documentation, and the sales and marketing teams.
  6. Learn: At this point, we observe the effectiveness of our launched solution. The product team collaborates with the research, design, and engineering teams to gather insights to measure against our success metrics. We use these insights to inform our next steps and start the process over again.

Voice and tone

Sophie Tahran, InVision’s UX Writer, weighs in on the value of writing guidelines—and how to create them.

Great writing is an essential part of great design, but even in-house UX writers aren’t able to edit every single word in a product. That’s where writing guidelines come into play. A source of truth promotes good communication, credibility, and consistency—no matter who’s writing content.

Every writing guide should cover both voice and tone. While your voice generally stays the same (like a personality), your tone shifts according to the situation (like an attitude). Both are an essential part of communication—and you can’t ship a product without effectively communicating it.

Because voice identifies who we are and defines our relationships, building writing guidelines early on is one of the best ways to gain credibility with your users. They’ll begin to recognize you, and know that they can trust you.

Writing guidelines also help evolve your voice. Just as your personality matures over time, your voice will evolve as your company grows. Guidelines define what you should sound like right now, so when you do steer away from them, you’ll know that you’re doing so intentionally. (“I’ll just throw an emoji in this subject line,” turns into, “Hey, let’s test how emoji perform and see if they’re worth adding to our writing guidelines.”)

Without thoughtful writing guidelines, teams risk allowing their voice to be determined by patterns instead of users’ needs, and end up making decisions solely based on what they’ve done in the past.

Building writing guidelines

Start with an audit. Talk to people across (and outside) the company: designers, writers, support agents, co-founders, users, etc. Your goal is to get their impression of the company’s personality. Consider not only conducting interviews, but also creating mood boards—visual collections of colors, people, places, and more—to represent more emotional, intangible qualities.

Define the findings. Have a core group of people, normally writers, narrow down the best words to describe what you found. Is your voice human, real, and bold? Or is it kind, experienced, and empowering? Take into consideration not only how you sound now, but also what you aspire to be and avoid (“InVision is never clickbait-y or pandering”).

Tone can be more difficult to hammer down. It shifts according to the situation, so it’s sometimes more helpful to provide direction than it is to identify characteristics. State your key priorities, like, “Always provide clarity,” and, “Consider the user’s emotional and mental state.” This is also a good place to determine whether humor has a place in your writing, and where you fall on the formality spectrum.

Once you’ve identified the more nebulous aspects of your voice and tone, carry that same thinking into the tangible. What should your different channels look like? Do you use sentence case or title case?

You may find that you have a need for multiple guidelines—voice and tone within your design system, a company-wide style guide focusing on words only, and brand guidelines that also encompass visual design.

Get buy-in. Potentially more important than building voice and tone guidelines is encouraging everyone to follow them. Anyone who works with content should have a chance to sign off.

Find a home. Your guidelines need to be easily found and integrated. If you’re building voice and tone into your design system, follow Mailchimp and Shopify’s lead in giving writing its own section, separate from components, principles, and layers. You can also go one step further by creating a separate list of copy patterns (like Mailchimp did) for grab-and-go words.

Develop. Writing guidelines are living, breathing documents that require maintenance as your company grows. From the start, use an editable Paper or Google Doc—and better yet, schedule monthly check-ins.

Invest time in writing guidelines from the start. Most companies have more people representing their voice than you’d expect, from product designers to support agents. By having a source of truth—and creating it together—you can offer users a better experience.

Conclusion

Just as design is far more than the sum of its parts, your design system can serve as far more than a components-only guide. Vision, principles, process, and voice and tone expand your design system into additional areas where reusability can also increase speed and efficiency.

Design systems have changed the way we design and build applications—so much so that we must look at the future of design through the lens of systems. In a future where design systems gain wide adoption, design could take on many new, exciting forms.

About the Authors

Marco Suarez
Product Designer, InVision
Katie Sylor-Miller
Staff Software Engineer, Etsy
Roy Stanfield
Design Lead, Airbnb
Diana Mounter
Design Systems Manager, GitHub
Jina Anne
Design Systems Pioneer, Independent
Design Systems Handbook
Design Systems Handbook

Design better. Faster. Together.

Transform your products with the world's leading digital product design platform

GET STARTED NOW