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
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

Designing your design system

Step by step

by Jina Anne

Starting a design system can feel daunting. There are so many things to consider: the design style, how to design for modularity and scalability, how it will be used by other teams, how to sell the idea to the decision makers in the company. Where is a designer to start?

Big problems are always more manageable when broken into smaller pieces. Before diving into the design process, start by considering who needs to be involved in the creation of your design system and how the team will work together. Once you’ve got the right people assembled, you’re ready to start thinking about the design language of the system, which will include color, typography, spacing, and more. Your visual design language will be the foundation of your UI library—a series of components that can be quickly assembled to create an interface.

Let’s take a step-by-step look at how you can start designing your design system.

Who should be involved

Rachel Cohen, Jessica Clark, and David Carmona from LinkedIn's Art Deco Design System team discuss how the system was formed, rolled out, and governed.

Before beginning work on your design system, take a moment to think about the team you’ll need to bring it to life. Who needs to be involved? Spoiler alert! You’re going to need more than just designers.

Here’s a quick list of the disciplines that can be represented in your team to create an effective design system:

  • Designers to define the visual elements of the system
  • Front-end developers to create modular, efficient code
  • Accessibility experts to ensure your system conforms to standards like WCAG
  • Content strategists who can help the team nail the voice and tone of the system
  • Researchers who can help you understand customer needs
  • Performance experts who can ensure your system loads quickly on all devices
  • Product managers to ensure the system is aligned with customer needs
  • Leaders (VPs and directors) to champion and align the vision throughout the company, including up to executive leadership

Once you’ve got the right skillsets represented in the design systems team, identify leaders to represent each area. These people should be able to drive decisions forward. Know who on the team can advocate for each of the areas of the design system.

With a team of experts guided by strong leadership, your next task is to establish the right team model to help you achieve your goals.

Choosing the right team model

The team model that brings people together is as important as the team creating the design system. In “Team Models for Scaling a Design System,” design systems veteran Nathan Curtis outlines 3 popular team models used by many companies.

The solitary model: an “overlord” rules the design system.

The centralized team model: a single team maintains the design system as their full-time job.

The federated model: team members from across the company come together to work on the system.

There are strengths and weaknesses in each of the above models. A solitary model is fast and scrappy, but with 1 person in charge of so much, the “overlord” can become a bottleneck to the completion of many tasks. A centralized team, on the other hand, keeps the system well maintained, but the group may not be as connected to the customers’ needs as they may be less involved in user research. Finally, a federated team has great insight into what’s needed for all the product features and user needs, but this group can be quite busy working on those areas outside of building the system.

Many teams are moving away from the solitary model to the centralized or federated model. As Curtis mentions in his article, overlords don’t scale. The centralized or federated models are usually much better for scaling a design system.

I wrote about the Salesforce team model in response to Curtis’s piece. When I was at Salesforce on the Lightning Design System team, we used a combination of the centralized and federated models. In an enterprise organization as big as Salesforce, a centralized design systems team was not enough on its own. With so many key players involved and the amount of ground we had to cover across products and platforms, we needed a more sustainable approach.

Though the Lightning Design System has a core team, there are also core contributors from many of the product and feature areas in the Salesforce ecosystem who act as a federation of practitioners, surfacing new ideas and making requests for the design system to evolve. Researchers, accessibility specialists, lead product designers, prototypers, and UX engineers work with the central design system team to both consume and help establish the patterns, components, and the overall design system. Engineers refine all code to make sure the system is performant and production ready.

Though the solitary model is less popular in most teams because the primary contributor can become a bottleneck, there are situations where it can work quite well. In the midst of a political campaign moving at breakneck speeds, Mina Markham had little time to bring in reinforcements as she developed new online assets for Hillary Clinton. She created a design system called Pantsuit to help many teams in many locations expedite design and production while maintaining consistency in the campaign brand. The solitary model let Markham focus on speed first and longevity second, which is a different tract than a typical enterprise might take.

As you determine what team model works for you, consider your goals. If you want to move fast, the solitary method is ideal initially, though some work may need to be done later to fully adopt it across other teams. If you want to move fast, but want to encourage buy-in from the start, consider the centralized team model. And to get the most buy-in and shared ownership, the federated model is a good option. In any case, remember that a design system is a product, so staff it like a product instead of a project; you want people committed to maintaining and evolving it.

With the team and the model that organizes them established, it’s time to start your design system just as you would any new product—by talking to your customers.

Interviewing customers

As with any product design process, it’s important to do your research. Who will be using your design system and how will they use it? Your design system will get used much more often if you create it to fit into the workflow of other teams. By interviewing users, you can pinpoint problems ahead of time, define principles that will help others use the system properly, and focus your energies on the most important things.

A less common group of people to interview are members of your open source community. This exists more likely in organizations that provide developer tools for customer and partner communities. If you plan to open source your design system—a potentially bigger project—then you’ll need to speak with potential contributors and consumers to discover what use cases your design system will need to satisfy.

And then there are the executives, leaders, and management. It is important to get their thoughts as well. You will need their buy-in to support and fund the system. Listen to their concerns and use them as actionable goals and metrics to achieve. Examples of requests might be shipping features faster, better performance, and improved UI quality.

With insights in hand from customer interviews, it’s time to take an inventory. There are 2 types of interface inventories to be created:

  • An inventory of the visual attributes (such as spacing, color, and typography), which will help create a codified visual language
  • An inventory of each UI element (such as buttons, cards, and modals), which will help create a UI library of components

Let’s first focus on a global visual inventory.

Creating a visual inventory

Of course, if you’re starting a design system for a product that doesn’t yet exist, you can skip this step and jump straight to creating a visual language for your new product. Lucky you!

Conducting a visual audit

As we start to take inventory, it’s good practice to take a look at the CSS used to create all of those elements you just captured in your visual inventory. Use a tool like CSS Stats to see how many rules, selectors, declarations, and properties you have in your style sheets. More relevant, it will show you how many unique colors, font sizes, and font families you have. It also shows a bar chart for the number of spacing and sizing values. This is a great way to see where you can merge or remove values.

If you’re creating an inventory in Sketch, use the Sketch-Style-Inventory plugin to aggregate all colors, text styles, and symbols. It also gives you the ability to merge similar styles.

Creating a visual design language

I must admit, as an art school graduate the visual design language in a design system is my favorite part to work on. I love thinking about color theory, typography, and layout, which are at the core of any design system.

If we break apart each component of a design system we find that these fundamental elements make up its visual design language:

  • Colors
  • Typography (size, leading, typefaces, and so on)
  • Spacing (margins, paddings, positioning coordinates, border spacing)
  • Images (icons, illustrations)

Depending on your needs, you may also include the following to further standardize the user experience:

  • Visual form (depth, elevation, shadows, rounded corners, texture)
  • Motion
  • Sound

Consider the role each of these design elements plays in a simple component like a button. A button typically has a background color, typography for the label, and spacing inside it. There may be an icon next to the label to create a visual cue. A border on the edge serves as simple ornamentation and may even round the corners. Finally, hovering over or clicking the button could trigger animation or sound as feedback to the user. Though a button may seem simple, there are many design decisions required to bring it to life.

Design tokens

Before we dive into visual design standards, I want to discuss design tokens. Design tokens are the “subatomic” foundation of a design system implementation. At its simplest, they’re name and value pairs stored as data to abstract the design properties you want to manage. With the values for all design tokens stored in a single place, it’s easier to achieve consistency while reducing the burden of managing your design system.



In design tokens you can store colors, spacing, sizing, animation durations, etc., and distribute them to various platforms.

We’ll look more closely at design tokens in Chapter 3.


The colors you choose for your design system are more than just an extension of your brand. A UI uses color to convey:

  • Feedback: Error and success states
  • Information: Charts, graphs, and wayfinding elements
  • Hierarchy: Showing structured order through color and typography

Common colors in a design system include 1–3 primaries that represent your brand. If none of these work well as a link and button color, then you may have an extra color for that as well. It’s a good idea to use the same color for links and button backgrounds as it makes it easier for users to recognize interactive elements.

You’ll likely have neutrals for general UI backgrounds and borders—usually grays. And finally, you’ll have colors for states such as error, warning, and success. Group these colors to see how well they work together and refine as needed.

Larger design systems sometimes include colors for objects and products. For example, at Salesforce we had a color for contacts, for sales deals, or groups, and so on. We also had them for products: Sales Cloud, Marketing Cloud, Analytics Cloud, etc. Color can be a helpful wayfinding tool for your users.

Using color for wayfinding can be tricky to do while maintaining accessibility, as people who are color blind may not be able to discern some differences.

Depending on how strict you want to be with your palette, you may want to include a range of tints—a color mixed with white—and shades—a color mixed with black. Sometimes you may use other colors instead of white or black to avoid muddiness, such as an orange to darken a yellow so it doesn’t appear brown.

These color variations allow designers to have choices. But be warned, having too many choices can lead to major design inconsistencies. Keep your inclusion of tints, shades, and neutral palettes slim to prevent misuse of the system while still giving designers the flexibility they need. You can always add more colors as you find the need.


Fonts and weights

The fonts you choose have a high impact on both your brand and your user experience. Keep legibility in mind as you select the right fonts for your system. Keeping to common system fonts like Helvetica, Times New Roman, or Verdana can be a great shortcut, as they are familiar to the user’s eye. Some companies prefer custom web fonts to better reflect their brand, but pay special attention to how you use them as performance can be affected.

Most design systems I’ve worked on include just 2 typefaces: 1 font for both headings and body copy, and a monospace font for code. Sometimes there’s an additional font for headings that compliments the body font. Most design systems do not have a need for more, unless you have a system that supports multiple brands. It’s best to keep the number low as it’s not only a best practice of typographic design, it also prevents performance issues caused by excessive use of web fonts.

These days it’s trendy to use a font at a very thin weight, but be aware that legibility can become an issue. If you want to use light or thin weights, only use them at larger text sizes.

Type scale

When selecting the size to set your type, consider the legibility of the font you’ve chosen. In most cases, a 16px font size works well. It’s the default font size in most browsers, and it’s quite easy to read for most people. I like using 16px as it works with the 4-based metrics used by Apple and Google (and is gaining traction as the standard approach). I recommend this as your baseline, though I would use it in a relative format like 1rem for CSS-based systems.

You can use a modular scale for larger or smaller font sizes for other elements such as headings. A modular scale is a set of numbers in which you have 1 base number, and a ratio to generate the next number. You keep applying the ratio to the new number to get yet another number.

As you design your type treatments, be sure to give thought to how it will respond to various screen sizes to maintain legibility. You won’t want your headings to be too large for mobile devices. And for much larger displays, you have the room to bump up sizes.

A common method is to enlarge headings on larger viewports. You can also use viewport units to scale your type based on a percentage of your screen size.


Leading, or line-height in CSS, can improve readability and aesthetics of your typography. While the best line-height can vary depending on the font face and the line length, a general rule of thumb is to have leading at around 1.4–1.5x the font-size. 1.5 is recommended by the W3C Web Accessibility Initiative.

It also makes your math more predictable, but you don’t have to calculate it. You can define your line-height without a unit of measurement and the browser will do all the hard math for you.

For headings, tighten it up depending on your typeface. In most cases, I find a 1.25 or 1.125 ratio works quite well.

Spacing and sizing

The system you use for spacing and sizing looks best when you have rhythm and balance. This means using numbers based on patterns and proportions. Using a consistent spacing scale also promotes maintainability through ratios by making layouts more predictable and more likely to “fit” and align well.

When I designed an Android app, I studied Google’s design guidelines. I noticed a pattern of using 8dp between elements and 16dp for outer gutters. It broke me out of using a 10-based scale I was accustomed to, as I found that 4-based worked so much better.

A 4-based scale is growing in popularity as the recommended scale for many reasons. Both iOS and Android use and recommend metrics that are divisible by or multiples of 4. Standard ICO size formats (which are used by most operating systems) for icons tended be 4-based (16, 24, 32, etc.) so that they scaled more easily. The browser’s default font size is usually 16. When everything is using this system, things are more likely to fit in place and line up. And finally, responsive math works out well.

For horizontal spacing, an 8-based scale works quite well. You can make margins and padding equal or in proportion to the font size. But for vertical spacing, I tend to use a 12-based system. This is due to the line-height I get of 1.5 (with the default font size of 16px) getting us to 24.

Occasionally, you may have to break this rule. If you’ve added a 1px border to something, this border can throw off alignment by a hair. So you might find yourself using a padding or margin that subtracts that amount. This is something that you do on a case-by-case basis.

You probably want elements to grow and shrink with the content. For general sizing, avoid setting widths and heights unless totally necessary. You can achieve responsive design much easier if you let elements flow to fill the space they’re given in the layout.


File formats

For icons and illustrations, I find using a vector format (SVG) works best for scalability and responsive design. However, if you find yourself needing to use photography, you may need to use a rasterized image format like JPG or PNG.

For most photos, illustrations, and diagrams, you can allow the image to go 100% to the container or viewport and let the height automatically set itself by not defining it. This works best for responsive layouts. You may also want to define some preset widths for images if you don’t want it to go full width (for example, half-width, a third, or a fourth). I recommend setting these as max-widths so that the image can rescale for smaller screens.


Before drawing your icons, come up with your guidelines around them first. Will they be filled or outline? What is the line weight? Will they use more than 1 color? What sizes will they be? Is there an icon art boundary set inside an outer boundary?

You may have different styles for different icon types. For example, utility and action icons (like a notifications bell or a settings cog icon) may be solid and 1 color, while navigation icons may be multicolored and more creative. Clear guidelines will keep your icons unified.


Illustrations are a great way to add some character to your product. You can use these for empty states, loading screens, modals, and other components that invite visual interest. Shopify went to great lengths to produce unique illustrations for all of the empty states of their platform, which conveyed a strong sense of brand personality (figure 19).

Similar to icons, it’s helpful to have guidelines for the style of your illustrations (figure 20).

Visual form

Visual form, or the material quality of your UI, is about the background images, gradients, and textures, shadows and elevation (z-indexes), rounded corners, and borders. These are visual qualities that help emphasize and decorate elements to add visual hierarchy and aesthetics. In any case, all are examples of ornamentation that need to be standardized.

Google does a great job indicating how depth and elevation work with layering of components (figure 21).

Motion and sound

When you define your visual language, motion and sound might not immediately come to mind. You experience these in a different way. But motion and sound can have a high impact on the experience of your app. You’ll want to have that systemized as well for consistency. I personally haven’t explored these areas as much as I’d like to admit, but there are some great examples in the wild.

Creating a user interface library

Before we conducted a visual inventory, which looked at the visual qualities of elements, such as color, spacing, and typography. Now, we will conduct a UI inventory, in which we look at the actual pieces of UI—like buttons, cards, lists, forms, and more. Where visual language is all about the visual approach and how things look on a global visual level, a user interface library (otherwise known as a pattern library) looks at actual components of a UI.

Let’s take a look at each of these design elements and the role they’ll play in your design system. Take stock of all interface elements in production to see just how much design debt you need to address and what elements are most commonly used. Warning! This can get a bit depressing, as most companies have an intense amount of inconsistency in their UIs.

To create an interface inventory simply open all products in production at your organization, screenshot all buttons, forms, various type styles, images, and collect them in a slide deck or on big posters where the whole team can see.

You can do this with cut out print-outs or through screenshots. Gather the folks you’re involving (as mentioned earlier in this chapter). Have them conduct this inventory with you, either through a shared presentation or via a hands-on activity. The idea is to gather the different components you’re using and categorize and merge them.

Some like dividing the pieces into elements, components, regions, utilities, and so on. Atomic Design is a great example of this line of thinking, which is a great conceptual model. But when it comes down to it, everything is pretty much a component, so at the end of the day, you could label all as such. But in general, what I see most design systems break things down into are:

  • elements (or basics, or atoms)—these are small, stand-alone components like buttons and icons
  • components (or molecules, or modules)—these are usually an assembly of small components into a larger component like a search form (which includes a form input, a button, and potentially even a search icon)
  • regions (or zones, or organisms)—these are an area of the UI like a left-hand navigation
  • layouts—how the pieces are laid out on the page (like a header region, followed by a sidebar and main content area, followed by a footer)

After you complete the inventory, you can merge and remove what you don’t need (either in a spreadsheet or even directly in a code refactor if you want more immediate change). Also, document what the component is and when to use it. This will become your UI library (or pattern library, or component library, depending on what your organization chooses to call it.).

Most design system documentation includes the component’s name, description, example, and code. Others may show meta data, release histories, examples, and more. What matters most is that you show what’s necessary for your team to get your work done.


Creating a design system not only helps your team produce more consistent user experiences, it also builds bridges between design and development. By creating a common visual language codified through design tokens, and a set of components and patterns cataloged in a UI library, you’ll vastly improve designer/developer communication. You’ll also have fine-tuned control of the UI in a way that is manageable, scalable, and robust.


The future of design systems

To infinity and beyond

by Roy Stanfield

I find it exciting to see design systems empower design teams to scale and consistently produce solid products, but I know we’re only scratching the surface of our potential. There’s so much more we can accomplish.

At Airbnb, we’ve been pondering how we might push our design system in new directions, and we’re inspired by design-forward companies that share our desire to craft the future of design systems.

In this chapter, I want to introduce you to a new way of thinking about design systems. Design systems can transcend the walls of a single company to exist as shared standards and customizable tooling with help from the open source community, which can accelerate development and eliminate the need to start systems from scratch. If we’re really bold, we could be creating adaptive, intelligent systems that are context-aware and compose themselves—reducing our workload and ultimately unlocking AI-powered design.

But, I’m getting ahead of myself. Let’s start with nuts and bolts.

Building a common foundation

In his 1998 essay Interchangeable Parts, Tim Sheiner examined the historical standardization of parts for physical products, and predicted how this will play out for digital products.

A designer’s familiarity with the concept of a design system is based on the systems they’ve encountered, what platforms they’ve been tasked to support, and where they’ve worked. Books like this one help us converge on a high-level definition for design systems, but a more rigorous definition will ensure the utility and flexibility of our work.

Finding a standard that supports shared goals will involve decoupling a design system from its implementation, cataloging common UI and associated states, and more strictly defining design primitives and components. This could then be expressed in a file format that’s able to define a component or design system more completely.

An example of differing goals

Currently, existing systems reflect the specific needs of the companies that created them. Since each company is building an entirely independent system, design system development starts from scratch—possibly with help from a web toolkit like Bootstrap, relying on the internal knowledge of the team, and only focusing on top-level needs. As a result, even the best systems contain flaws and lack the necessary tooling to speed development and track results. And if a company’s priorities shift, its design system must shift, causing another section of the design system to be built in the same limited way.

For example, one of the reasons Airbnb created DLS was to minimize and sync differences in UI between our supported Android, iOS, and web platforms. In The Way We Build, VP of Design Alex Schleifer writes, “Universal and Unified define the system’s approach we apply when defining patterns. Is it part of a greater whole? Does it work across devices?”

In our idealized vision, a mockup easily ports between platforms—creating a better design and development experience. This cross-platform UI would give Airbnb guests and hosts alike the same end-product experience as if they jumped between mobile app and desktop web.

In contrast, supporting multiple device platforms was initially less of a concern at Etsy, where the main priority was to scale its web platform. During my time there, the team built the web toolkit with the core website as its primary focus. Later, Etsy expanded upon its toolkit to support different branding elements for other internal web initiatives. Karyn Campbell describes what it was like modifying the Etsy design system while making Etsy Studio. “While we made a conscious decision to depart in some instances with the UI in order to birth this new brand, we also retained many underlying components that our design systems team had created.”

A priority at Airbnb was having the same functional and visual voice across platforms. A priority at Etsy was to support multiple web products with varying brand initiatives. Both were valid needs. A shared standard for design systems would need to ensure a solid foundation so that both these and other real-world priorities could more easily be achieved.

Gathering examples of different design system priorities will help create a checklist to make sure your design system standards address real concerns. Any company adopting these suggested standards could be assured their design system development focuses on immediate company needs, as well as adhering to standards they plug in to a growing body of open source code and tools that support most operational transformations that could be encountered.

But what should be in the design system standard?

Imagine a tool that can specify which design primitives, (e.g., fonts, spacing, color—more on that below), components (and their states), platforms, and what documentation and testing are needed to have a fully formed design system. The tool would also allow the designer to specify which components were not yet needed and which platforms could be added later. With this tool, a designer would have a framework stating what aspects of the design system were completed or outstanding. A product manager could export documentation, and a developer could easily export UI and UI tests—no longer needing to translate UI from Sketch to code, or from web code to native implementation.

If created today, not only would this tool provide industry-wide savings, but it would start to standardize the low-level definition of a design system. Working backward, let’s now imagine what kind of definitions such a tool would need in order to exist.

First, decouple the design system from any specific implementation. We’re not creating React components (nor other web implementations), nor Android UI, iOS UI, or even Sketch files. Instead, our system is an abstraction that can be deployed to any target implementation. We’re going to need a file format to describe this abstracted design system. The exported format could be rendered into views by open source modules specific to each target implementation.

Next, codify the definitions of design primitives and components so they are fully expressed in the design system format. Dang, .dsf extension is already in use! Guess we’ll have to settle for the .dang file extension!

Design primitives are the building blocks of a UI. These include specific predefined colors, fonts, spacings, and more. They are foundational visual elements that can be combined into components. Changing primitives is echoed throughout a given design system’s components, and doing so changes the overall feeling of a brand. Additionally, what are components? We’ll also need to codify those. Components are mostly views composed of design primitives and smaller components whose minimal internal logic is mapped exclusively to state and state change. Benjamin Wilkins, Design Lead on the Design Tools team at Airbnb, describes the difference between primitives and components in minute 7:00 of his talk, Thinking in Symbols for Universal Design.

Next, we’ll need to catalog all of the common UI components in use today. Just as a typeface may have its unique take on the letter “A” (the letter’s visual appearance may vary between typefaces while its meaning is maintained), a .dang file would have a text input component that varies in visual representation but not functionality. The catalog will need to group components with their accompanying states (selected, focus, on-tap, error, etc.) and detail interactions to distinguish between mobile, desktop, and TV UI.

What are the benefits of this catalog? To start, functional tests for common components could be easily automated through contributions from the open source community. In many cases, UI engineers would no longer need to write their own tests. The cataloged components would also enable a marketplace of boilerplate design systems that can be installed interchangeably, and against which custom UI can be built and substituted. This means bootstrapping the creation of every design system is no longer necessary.

Lastly, we need to allow for the evolution, growth, and extensibility of design systems built upon the shared standard. Just because we’re aware of which components are needed today doesn’t mean that we’re able to predict all the elements needed for future innovation. A process for modifying existing components or creating wholly new ones is in order. Thoughtfully standardizing our collective knowledge will produce a more consistent user experience, accelerate development, decrease investment needed from individual companies, and enable open source and collective development of next-generation design tools that conform to shared conventions.

Creating a single source of truth

The elements that make up a design system—principles, UI components, patterns, and documentation—create the human-computer interaction layer for our apps. Product designers and system designers are directly responsible for this layer, and therefore should own the design system and its representation in the codebase.

There are 2 hurdles to achieving a single source of truth. First, our current design tools are inadequate. Most only allow us to produce images of UI and prevent designers from achieving product level fidelity. Second, if the implementation of a design system is spread across multiple repositories (Android, iOS, React Native, React, etc.), collected in a Sketch file, and documented on a website, then there really is no single codebase to represent a truthful account of the system. Lacking a single source of truth, the design system—spread out over multiple codebases—becomes an amalgam of sources that easily fall out of sync.

Our tools

Designers use tools like Sketch, Illustrator, or Photoshop to draw pictures of UIs, yet these are actually just representations of interactive components that look different, behave differently, and contain different data depending upon the state of the app at a given time. As Colm Tuite notes in the article Design tools are running out of track. Here’s how we can fix them, “Think of the number of simple interactions which are commonplace in almost all of our products yet cannot be communicated through our design tools.”

Tuite then mentions interactions and states such as hovering over a button, focusing an input, checking a checkbox, and identifying scroll areas. He points out that our design tools aren’t prompting designers to think with product level fidelity, and so a designer’s work is usually missing some of its most important details.

Sketches of apps are then handed off to developers who have to translate them into working UI. Between the designer and the 4 developers that it takes to convert the design into Android, iOS, React Native, and React, it takes 5 different members of the team begin to bring the design up to product-level fidelity. Since the original sketch was missing details about state and interactions, a back-and-forth conversation between designer and multiple developers is needed to make the designs production-ready. And because the implementation is coded by 4 different humans, it’s likely that unwanted variation creeps into each implementation.

For similar reasons, many designers have focused on sharpening their coding skills for at least 1 platform. There are many advantages to this, but if you’re a systems designer creating components for cross-platform use, coding those components for a single implementation is not yet enough.

Multiple implementations

The attempt to reach a single source of truth is further complicated when working on cross-platform design systems. Jon Gold identifies places where Airbnb’s DLS workflow could be improved in Painting with Code.

At Airbnb, Gold has taken some exciting first steps toward solving this problem with his project React With this tool, layered Sketch files can be generated from the React codebase. This means components in the Airbnb React repo, which already have product-level fidelity, can be populated with real data and rendered to a Sketch file. It’s another reward for those adventurous designers willing to learn React!

It’s also a touchstone technology, pointing us toward understanding mockups not as the source of truth, but instead as another target for automated output. With these generated files, we get a clear picture of which components are sitting in the repo. Best of all, a product designer relying on Sketch does not have to change their workflow and can use more accurate files (generated by the codebase, not by hand) to compose their work. At last, we can have confidence in how the components look at product-level fidelity and in how these components behave with real data.

React is great because it syncs the React and React Native repos and Airbnb’s design system Sketch files. But what about the Android and iOS implementations? How can designers make sure these are in sync? React points the way, but we’ll have to go further.

Here, we can learn from tools and WYSIWYGs of the recent past like Dreamweaver and Interface Builder. Tools in this category allow users to combine elements of UI, hook the UI up to data and interaction, and then export deployable code. Unfortunately, these software produce code that’s not maintainable by humans, and so few companies use them as an official part of their process. Did these tools promise too much and deliver too little?

Luckily, design system components are simple views with minimal logic. (Learn more about views and MVC architecture here and here.) Unlike the promise of tools like Dreamweaver and Interface Builder, components are easily exported view files that developer partners can incorporate into existing workflows.

Solving 2 problems with 1 tool

To create a designer-controlled source of truth, we’ll need next-generation design system tools to enable the composition of components and to automate the output of the design system to any number of target clients (codebases, vector files, and documentation sites).

As outlined in the section above, if we standardize an export format that contains production-level fidelity for components, then other interpreter modules can be freely built to compile a single component file into all the various flavors of production code. Then, varied implementations of any given component would flow from a single source of truth and would plug right into existing workflows—saving resource-intensive and error-prone human interpretation of mocked UI. Product designers and design system designers would finally control the UI they have always been responsible for.

At Airbnb, we’re tackling this challenge in a variety of ways, including with Lona, our tool for defining design systems and using them to generate cross-platform UI code, Sketch files, images, and other artifacts. A highly experimental prototype, Lona represents our exploratory approach to discovering what’s next for design at scale. Taking a research-based approach to the future of design systems encourages experimentation and collaboration.

Intelligent systems compose themselves

If you’ve not heard of Alan Kay, make sure to look him up. He’s credited with inventing the graphical user interface, Object Oriented Programming, and—with his concept of the Dynabook—even the tablet. Given that design systems fit firmly inside of the world that Kay and his peers built, it’s worth listening to him.

Once the magic of design system standards enables both private and open source development for cross-platform use, design systems will most likely reach new heights of functionality and popularity. Whereas siloed development requires talented people to reinvent the design system anew for each employer, standards-based design systems might easily plug into a passionate community that will add capabilities to our nascent tools.

Taking inspiration from Kay and the PARC maxim—“The best way to predict the future is to invent it”—I’ll sketch out a stretch goal for the future of design systems and tools in the paragraphs that follow.

Virtuous cycle—plugging into the feedback loop

Often, our design systems contain components that aren’t tracked in any special way. Without special consideration and considerable development effort, the design systems team is blind to the usage statistics and performance metrics directly associated with the system. To gain insight into design systems, teams must manually track which components each product team uses, and then try to glean usability information from product team UX research and performance metrics.

At Airbnb, we see data from the large proportion of our native apps, which now use design system components. Connecting these stats to user metrics lets us know which components might be underperforming and deserve special attention.

Similar metrics also have an internal benefit. Dashboards containing usage data aid the internal perception of the system among product designers and engineers alike. It’s easy to imagine that tracking the use of a design system can go beyond recording end-user impressions (views) and interactions. Even analyzing the usage of documentation, design files, and other internal tools can lead to insights that better enable product teams.

But why should such insights be limited to just a few companies with the resources to create similar tooling? A module could be built for just this purpose. It would track where canon components are used in product and then apply a flag to that component. These flagged components could be polled, and usage stats could come straight back to the design systems team. The insights would then be used to improve internal tools and the system itself.

Layout aware

Another promising direction would be for our components to become somewhat layout aware, and then declare their intended use to both the system at large as well as sibling components. Given this new super power, design system components could now communicate where they should generally be used and then share information about what types of data they generally contain. Even a simplified implementation of this functionality would help designers instantly swap abstracted data sets to, for instance, see how translation might affect the layout of a particular component given a longer language like German or a right-to-left language like Arabic.

This awareness might even go a step further with a given component stating the kinds of screens or interactions preceded by its own display, and again which kinds of interactions or screens should follow upon user interaction. This awareness would enable predictive assembly.

Predictive assembly—a pattern tool

Because each component now sends messages about where it’s typically used and what type of data it usually contains, we should also be able to see existing components predictively assembled into screens. A future tool might allow the product designer to view a particular component, click a randomize button, and see the component in situ with other components arranged in an order that more or less semantically makes sense.

By allowing designers to up-vote particularly useful component groupings (or patterns), a layout aware tool featuring predictive assembly—perhaps better described as a design system pattern tool—could become an instrumental way in which product designers quickly discover repeatable patterns in the system. With just a single click, a designer would be able to compose an effective solution made of many components and export the basic design for any project. Moreover, with the advent of standardization, design systems could become plug-and-play with compositions composed by predictive assembly, allowing for a quick way to assess the integrity of a given design system.

Predictive assembly would enable the product manager, developer, or product designer to provide a set of data and ask for a menu of pre-assembled screens that display the data. We could then choose the best option, only correcting the layout if needed.

It’s worth noting that if we get particularly good at predictive assembly and consult the right minds to take it further, we will soon find ourselves in a world where machine learning provides artificial intelligence for plug-and-play design systems. Among many other things, we might witness the birth of a world where phone users could eliminate branded apps, preferring a locally installed design system that could spin up UI without needing to load templates over the network.

As designers, we continue to rely on intuition, performance metrics, and user research to create products. If a large percentage of our users can complete a task and proceed to the next stage in the flow, then we generally call the design successful. We use templating languages to add options to a design so even more users reach their goals. But by connecting design systems to artificial intelligence, we could achieve a step change in customizable UI. Instead of designing products that work for most users, systems design and AI will apply specific solutions for specific individuals.

Designers should prepare now by discovering a bit about machine learning, reading about the breakthroughs enabling AI today, and finally, thinking about how ML could impact design tools.


As digital product designers, we’re asked to ride the waves of change in our industry. People just like us helped small development teams create apps for desktop computing in the 1980s. In the late 1990s, other designers formed a coalition that pressured large software companies to unite front-end web development through the web standards project. In the mid-2000s, we focused on communication and user-generated content while developing patterns for creating web apps, and just a little later, all our work was available in mobile form factors like the iPhone. Now, after nearly 4 decades of designed computing, design systems and AI are shaking hands—presenting us with new opportunities for innovation at scale.

Every designer will now be asked how they might change custom, one-off design solutions into reusable components that grow the system. We’ll have to think more holistically, and work collectively to develop and learn a new set of tools.

How can we work together to improve our workflows and better scale design? What should be in a design system standard, and what kinds of tools could be built if such a standard existed? How will design systems and AI combine to create extremely customized interactions for end users? There are many questions, and each answer points to a possible future. What I love about design is that it enables each of us to explore the ideas we feel may have the biggest impact, and project our ideas outward and into the future. Innovation is certain.

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