The Anatomy of a Design System

Sparkbox has been fortunate to work with many exciting and innovative clients on projects related to their design systems: how to build them, grow them, and ensure they’re generating results. If there’s one thing we’ve learned in years of design system research and work, it’s that a necessary starting point is a shared understanding of the system. Even within a single organization, design systems can mean many things to many people. Without a clear and common definition of what a design system is, we can never achieve the potential for that system.

What Is the Context for a Design System?

Brand is where communication between an organization and its key audiences begins. Most organizations have established brand elements, such as a logo, a positioning statement, colors, typefaces, etc. To reach key audiences, brand elements are filtered through different media: advertising, print, digital experiences, and retail, to name a few.

The design system oversees and empowers that brand expression for digital experiences. Digital experiences can range from websites to native applications to kiosks. A single user will often interact with the organization using more than one of these touchpoints. When the experiences don’t align, it creates an erosion of trust in the brand. Consistency of brand expression isn’t the only reason to work with a design system, but it’s one of the most important.

So, What Is a Design System?

A design system is an internal tool and methodology used by product teams to create digital interfaces. A design system includes:

• Assets, documentation, and processes that determine how an organization creates their digital interfaces

• Foundations, tokens, core systems, and components that enable brand-aligned digital design at scale

A design system also provides a common language for your product teams that enables healthy collaboration and efficient delivery.

Because of the complexity in the anatomy of a design system, I’ve found it best to break systems down into a series of layers. These layers start more theoretically and—each layer building upon the next—become very practical. Let’s dig in.

The Four Design System Layers

Based on our experiences and observations, a design system can be broken down into these four layers:

Design systems can be broken down into four concentric layers starting with Foundations at the center, then Tokens, then Core Systems, then Components.

Foundations Layer

The goal of the Foundations Layer is to define a subset of the organization’s brand to be used in the design and development of digital interfaces. The best design systems clarify and focus brand guidelines in ways specific to digital interface work. For example, an organization might determine that only a subset of the colors permitted for the brand as a whole should be used in digital products. Or maybe there are special typefaces to be used in digital interface design. The Foundations Layer of the design system, its innermost core, captures those distinctions and the reasoning and principles behind the brand. This may include basics like logo, color, and photography styles, or even more details, like a point of view on animation.

Tokens Layer

The goal of the Tokens Layer is to take the design concepts expressed in the Foundations Layer and codify them for use in constructing digital interfaces. Those design concepts are given a name and a value and sometimes other attributes such as a role or state. Once tokens have been defined, they can be translated into formats for use with multiple platforms. This is the power of tokens—you have one place to manage design decisions and the ability to use those defined values wherever people using the design system need them. Once a brand element has been tokenized, it’s much easier to perpetuate change throughout the system and resulting interfaces.

Core Systems Layer

The goal of the Core Systems Layer is to offer a solution to common interface challenges such as layout, type scale, theming, etc. Core systems are the reusable “building-block” systems used to solve these challenges. One way to think of this is that codifying a single design decision results in a token, but codifying how those design decisions work together is a core system. Most of the time, core systems are built with tokens, which enables that “ease of change” described earlier. Core systems also make it easy to build components in a consistent way and give design system subscribers a tried and true approach for solving common interface challenges.

Components Layer

The goal of the Components Layer is to define and make available the reusable parts of a digital interface. Components can range from simple (a button or text input) to complex (a header or navigation). When built properly, they are constructed from foundations, tokens, and core systems. Many people think of a design system as primarily a set of components, and there may be some users who only interact with the Components Layer. Components are where much of the value of a system lives—they promote efficiency and reuse—but having the inner layers behind them gives them greater depth, reasoning, and flexibility.

The Three Parts of the Design System Layers

Each of these four layers is made up of three parts that work together to make a design system functional, educational, and sustainable. Those parts are Assets, Documentation, and Processes.

Let’s look at each of the three parts:

Assets

Assets are the things that make each layer of the design system usable: design kits, code libraries, software tools, or even install scripts and repositories. As the layers build upon one another, there are an increasing number of associated assets. For example, the Foundations Layer is mostly educational. It contains lots of documentation but few assets. On the other hand, the Components Layer has many assets that can be actively utilized to build digital interfaces.

Documentation

Documentation is just what you would expect: a detailed explanation of why something is the way it is and a breakdown of when and how to use it. Like assets, the style and scope of documentation vary from layer to layer. With the Foundations and Tokens Layers, documentation might include more information about the reasoning behind choices that the organization has made, while for the Core Systems and Components Layers, documentation is more instructional and practical.

Processes

Processes define human behaviors as we work on and with the design system. They answer the question, “who does what.” While assets are functional and documentation is educational, processes are what help us to create a sustainable design system. As a system matures, it becomes more complex and involves more people. Processes are intended to ensure that the system is trustworthy and stable while being used by cross-disciplinary teams. In many ways, a design system is as much about a community of people as it is the tools and technologies used. Processes tie the two together.

Altogether, this model offers a way to consider the pieces and parts of a design system. Every intersection of a layer and part should eventually be filled in, so it also gives you a roadmap of work to consider. But most importantly, the anatomy of a design system gives us all some common language to use as we’re striving to build truly valuable systems.

The Anatomy in Practice

From a purely theoretical standpoint, it can be hard to picture how all the layers and parts work together without more context. To help paint a clearer picture, let’s look at how two common elements make their way through the layers of a design system: color and buttons.

Foundations Layer: Color

Color at the Foundations Layer is where you articulate a subset of the brand colors for use in digital interface design. This layer is primarily comprised of Documentation and Processes. Let’s look at the three parts of the Foundations Layer.

Documentation

• Guidelines for the kinds of considerations needed (accessibility, consistency, etc.)

• High-level explanations for things like multi-brand experiences, dark or light mode, or high contrast mode

• Numerous color levels such as neutrals, primary brand colors, and secondary and tertiary colors

• Explanations for the reasoning behind the color usage, such as communicating an emotion, ensuring brand consistency, using colors to communicate hover or focus states, etc.

Processes

• Communication between the organizational brand team and the design system team

• Ensuring information about color changes is shared appropriately

• Adding new brand colors to the Foundations Layer

• Removing or changing brand colors in the Foundations Layer

Assets

• Due to the conceptual nature of the Foundations Layer, there are no assets for color

Tokens Layer: Color

With foundations in place, you can tokenize those colors. A token is a codified design decision, meaning we’re establishing a set of color names (along with other properties) and giving them values. Using color tokens gives you three distinct advantages: consistent color usage, ease of color changes, and multi-platform support. Let’s look at the three parts of the Tokens Layer.

Documentation

• How to name tokens

• The values of each token and their attributes (like color role, color state, color variant, color theme, color family)

• Levels and hierarchy of tokens

• Best practices for using tokens and the intended use for each token

• Ownership and status for each token

Processes

• Adding new color tokens

• Modifying existing color tokens

• Deprecating color tokens

• Testing color tokens

• How subscribers log issues or request features

• How to transform tokens for use in new platforms

Assets

• A token management system

• The tools and scripts used to translate the tokens

• Token files for each platform

Core Systems Layer: Color

The Color Core Systems Layer is where you offer systematic solutions to the challenge of using color in interface design. These core systems should be built with the tokens defined in the previous layer. Let’s look at the three parts of the Core Systems Layer.

Documentation

• How each core system works

• Best practices for using those systems

• Information on migrating to and extending those systems

• Identifying the current status of each system and who owns it

Processes

• Keeping color systems in sync across platforms and tools

• Adding, modifying, or deprecating color core systems

• Testing color core systems

• Reporting issues with current systems

• Requesting new color core system features

Assets

• Color use or theming systems built with SaaS, CSS, or other frameworks

• Color contrast checkers

• Color palette files for use in design tools

Components Layer: Color

Although color plays a critical role in every digital interface, you shouldn’t have to spend much time thinking about color beyond the first three layers. Once you reach the Components Layer, you’re taking advantage of all the work you’ve done in the previous three layers. So, color itself is not a component. Instead, it is built into the components that you’ve created.

Buttons

We’ve observed that by the time you reach the outer layer of your system—the Components Layer—color doesn’t have an independent role. It is contained in the work that has already been completed.

You can think about buttons as the opposite. Buttons, though they will be a factor in almost every design system, don’t start at the Foundation Layer. An organization doesn’t make an executive-level decision about what a button looks like on an app. Instead, a button is the product of many decisions that come before it: organizational standards (Foundations Layer), tokens (Tokens Layer), and core systems (Core Systems Layer) that lead to components.

Components Layer: Buttons

Documentation

For each component, you’ll need detailed documentation about what it is, when and how to use it, and all its variants. For a button, this might mean:

• Breaking the button down and giving names to all of its pieces (the border, the background, the text, the icons, etc.)

• Explaining when and when not to use a button

• Explaining all of the button’s variations and their purposes

• Explaining how to size the button

• Explaining how to position the button (perhaps using core systems like layout or grid)

• A breakdown of the interactions that are possible with the button

• How content should be considered for the text of the button

You’ll also need documentation written specifically for the users of the design tools and development frameworks you are supporting (how to install, use, extend, within the specific tool or framework, etc.). Finally, it’s important to offer a way to indicate the current status and any future planned work for the component. This will build trust with your subscribers and create some accountability for you and your team.

Component-level documentation is where most of your subscribers will spend the bulk of their time. That means this content is absolutely critical to their success. As the components are adopted, keep track of the challenges your subscribers have using them and continue to add this information into the documentation. This work is never done, so go into it with that perspective in mind.

Processes

Processes in the Components Layer are also critical. Since you have created button component assets for all the tools and frameworks your team uses, you have to put a great process in place to keep all of those assets in sync. One of the most common areas where trust is broken between design system teams and their subscribers is when the design-focused assets are not in sync with the dev-focused ones. This issue represents a broken promise the design system was meant to keep. As components are being built or modified, there will be times when these assets are out of step, so a solid process for how to iterate them, release them, and communicate about their status is absolutely necessary.

You will also need processes to manage the situations where the component doesn’t meet all the needs of a particular subscriber. How do they communicate this to the design system team? How do they report issues and add new components or variants? How will you test when those changes occur? How do you capture the metrics you’ll use to verify that a new variant or modified component can be integrated back into the design system?

Assets

A button component should have assets available for use in all of the toolings your design system supports. This often includes things like a Figma or Sketch (etc.) file with the button and all its variants, coded versions of the button component and its variants in the frameworks your organization uses (React, Angular, iOS, etc.), even versions of the Button in prototyping tools like Axure or InVision.

Considering the Design System as a Whole

There are also assets, documentation, and processes that fall outside of any single layer and apply collectively to the system.

Design System Documentation

Documentation for the design system is focused on making various subscribers from different disciplines feel like they belong here—using the design system. It can feel welcoming to a user to see content that’s focused on their needs or challenges. Think: “How to get started as a Designer.”

Over time, there will also be a great deal of documentation needed to explain how components work together to create excellent digital experiences for your audience. What are the best practices for using your system? How should buttons live on a page together? How do you handle empty states? These guidelines (also called best practices or patterns) are really documentation for the system.

Finally, you should also take the time to document how folks can contribute to the system. Setting the expectation that part of using the system is contributing to the system will pay dividends over time.

Design System Processes

Of course, those ideas of contribution and communication result in processes that will need to be defined and shared. Many design systems teams have put in place a council or regular open doors to invite communication from subscribers. You may have concrete ideas about how you want people to contribute. All of these processes need to be explained.

Design System Assets

The primary asset of the design system itself is the documentation site. This is the repository for everything we’ve just discussed. Remember that if your documentation site is confusing, it reflects poorly on the system itself. Findability and an intuitive information architecture are necessary. Your subscribers will use the system in ways they aren’t supposed to: if they can’t find the components they need, they’ll make their own. These kinds of problems erode trust in the system. Investing in the documentation site is critical to the healthy maturity of any design system.

In Conclusion

Design systems have enormous potential to help elevate the creation of digital experiences for your company. But experience has proven to us that without a shared understanding of what a system is, the benefits will be very difficult to realize. Our hope is that this model—the anatomy of a design system—will help you define the necessary clarity for your team.

It’s also important to remember that a design system is more than just a set of components. The components are the product of layers of intentional work that begin with the most fundamental elements of brand and identity. Without solid foundations, the system will be unsteady, and you won’t realize the true value for your team.

And perhaps the most valuable aspect of design system work is the unifying aspect it can have on a team. Design systems bring together the needs of every discipline, all for the benefit of the organization. This lofty vision of a fully unified, cross-functional, multi-domain team is achievable. Your design system won’t make it absolute, but it can help move you in the right direction by giving everyone a shared understanding of the way your organization approaches interface work. And when your people are in agreement the work is better and your customers are happier. This is the promise of a design system.