Enterprise Design Systems Management

The Anatomy of a Design System

Ben Callahan

Ben Callahan

Enterprise Design Systems Management

Check out a free preview of the full Enterprise Design Systems Management course

The "The Anatomy of a Design System" Lesson is part of the full, Enterprise Design Systems Management course featured in this preview video. Here's what you'd learn in this lesson:

Ben discusses the layers that comprise a design system, including foundations, tokens, core systems, and components. An organization's brand, codified design decisions, building block systems, and reusable parts of a digital interface are all parts of a design system.


Transcript from the "The Anatomy of a Design System" Lesson

>> Now, once you've decided that a system is what you need, it's really helpful to understand what the heck you're in for. [LAUGH] So what I'm gonna cover is a fairly comprehensive breakdown of design systems. I think as an industry, we've been doing this stuff for a while now.

It's been seven, eight years since the words, design system have really kinda come on the scene. And before that, five or six years, folks were working very systematically, right? So this, as I said earlier, is an attempt for me to kinda put a stake in the ground and define what I mean when I use all of these kinds of words.

We're gonna start with the layers that are labeled along the bottom here, foundations, tokens, core systems, and components. And then we will talk about how each of those layers is broken down into three parts. So that's assets, processes, and documentation. The layers are very conceptual, and the parts make those layers a lot more tangible.

So let's dive in, and we'll start with foundations. So the foundation's layer of a design system is the subset of the organization's brand that's intended to be used for the design and development of digital interfaces. So we can think about something like color. I heard somebody online was saying color is a struggle for them.

So in the context of a brand, there's all kinds of color you can use. Many times, if you look at your brand guidelines, there's gonna be a whole palette of colors for use in expressing that brand. But in digital interface work, oftentimes we don't wanna use tons and tons of color.

It's mostly a gray scale, right, to sort of build an interface that kinda disappears. And then we use one or two primary brand colors to kinda highlight or accent things. And then we may have a small subset of colors to use for more specific meanings, like a cautionary color or a successful color, things like this.

So that is definitely a subset of the types of colors that might be needed in the brand expression. So what we're doing here is we're looking at everything that's available in that brand layer, and we're scaling it down to just the things that are needed to create a digital interface.

So other than color, what else can live at the foundational layer? Well, there's lots and lots of stuff that can live here, okay? The lists that I'll share with you here are definitely not exhaustive, but these are just the kinds of things that are representative of what most systems are offering.

So things like design principles, how do we make decisions around design? Things like logos and typefaces, how do we use those, and what's the appropriate way to do so in a digital world? What about how we use audio or sound? How about voice and tone for our content?

Layout guidelines, motion guidelines, elevation, all of that stuff can be included at the foundations layer. The best design systems are able to clarify and focus those brand guidelines in ways that are very specific to the digital work we've got to do. So that's kinda the foundation's layer. The next layer, we just call the tokens layer.

And this is a set of codified design decisions that are based on the stuff we've identified in the foundation's layer. So the goal of the tokens layer is to take those design concepts that we just covered in foundations and express them in a way. We say that we use the word codify.

But really, if you're a developer, you can think about this as very similar to a variable. All I really mean is that we give them a name and we give them a value, so a token name and a token value. And if we use color as an example, you might define a color, token with a name of color primary brand and assign that token, the value of your brand's primary blue color.

It's not just colors, of course, this applies to, and it's much more complex than this because there are layers of tokens that you can define if needed But I want to give you the concept here. And you could codify lots of different things beyond color. You can do type stacks, you can do radius for your buttons, all that kinda stuff.

And we do this for many reasons. But there are kind of three primary reasons that we've kind of moved in the direction of tokens. The first is consistent design or cohesive experiences. That's because if you've got that single source of truth for, in this example, the hex value of a primary brand color, then you can trust that it's gonna be used the same everywhere, right?

You were mentioning earlier, you did some research and you found there's lots of different buttons, or lots of different colors and all this stuff. And there's arguments about whether that's a concern or not. But this is a way to kind of say, let's bring that all under control.

The second reason that we might think about this kind of approach is ease of change. So when you do decide to rebrand, I think you mentioned, Kayla, you guys were about to rebrand, [LAUGH] and you wanna change that primary color in some way. Well, this gives you a single place to make that change and kind of see that ripple through all the interfaces.

So it's really powerful, right? Now, with that power, comes risk. And we'll talk a little bit more about what that looks like when we get to the processes or process section of this. So ease of change is another opportunity that we get when we think about things at the token layer.

And the third is multi-platform support. So once you've defined the tokens for your system, you do that in a place that's separate from all the tooling that your designers use, that all of your developers use. It sort of lives in its own place, and you get the opportunity then to kinda transform or translate those values out to different tech stacks, or designed tooling, or whatever it is that you need to use.

So in this way, you can support your web interfaces, maybe built with Sass or native applications in iOS. The same tokens can be translated for use across any of the tools that you might need. I'll share in the resources section, at the end, there's some really cool work being done on token specification as well.

So if you're not falling along with some of the stuff that's happening there. This stuff is real, it's happening, it's been supported, there's really smart folks working on it. So really cool to see this coming to life. So I mentioned color, I think I even mentioned border radius, there's lots and lots of stuff that you can codify.

So again, not an exhaust of lists here, but just a handful of things you could also consider. Things like spacing, right, how much space do we need in and around the objects? What about elevation? How much depth do we want our interface to convey? Opacity, volume, borders, timing, all of these kinds of things, any single design decision you can kinda codify with a token.

It's a pretty long list, and the ones that you choose to implement are really gonna be determined by what's important to you and your interface. So I won't tell you here's the ones you should definitely do. Color tends to be an easy one, because every interface has some kinda color in it.

[LAUGH] So that's tokens at a conceptual level. Let's kinda move on to our next layer, which is what I just call core systems. I think of the core systems layer as a set of building blocks systems, and these are used to solve common interface challenges. So one way to think of this is that, if you codify a single design decision, you're gonna get a token.

But if you codify how those design decisions work together, you come up with a core system. So you could codify a single decision like spacing in a token, and then using that spacing token you could more broadly codify how you handle layout and use that token in a grid.

So there's a lot of common interface challenges you can come up with, create solutions for, things like your iconography. I mentioned grids, but also just layout in general. Theming, color systems, type scale systems, all of these core systems that enable you to build interfaces with ease. Most of the time, these core systems are built with the tokens that we defined at the previous layer and that enables that sort of ease of change, which we talked about earlier as a benefit for token work.

So these three innermost layers I just call the fundamental layers, these are what everything else is kinda based on. And if you're someone who's building or maintaining a design system, then creating stability in these fundamental layers is a big part of your job. The fourth layer, though, is kinda where your subscribers will probably wanna focus, right?

This is what we call the components layer, and this really just contains the reusable parts of a digital interface. This is what most people think of when they talk about design systems. This is your buttons, and your alerts, and all this stuff, right, form inputs, labels, all of it.

Now, components can be really simple, like a button or a text input. But they can also be complex, like a header or a navigation. So you can nest simple components to create more complex ones. And when they're built properly, they are constructed from the foundations, the tokens, and the core systems.

And while your subscribers will likely focus mostly on this components layer, having those fundamental layers beneath is what gives them the greater depth reasoning and flexibility that you kinda need to evolve as things around you are changing. I mentioned a few, but the list of possible components is obviously very long.

[LAUGH] If you go to any design system documentation site, there's usually a link somewhere that gets you to the list of components, and these can range anywhere from just a few to, 20, 40, 60, 80 components. So there's lots of these, but common ones are things like buttons and search bars, text inputs, tabs, tooltips, radio buttons, all the stuff that makes up digital interfaces.

Of course, it's impossible to list them all here. But hopefully, you can kinda see how this building approach, starting with the brand and adding layers until we reach these components will give you a really solid and extendable design system. Now, in order to really kinda cover this topic, we have to break these layers down just a little bit to kinda make them a little bit more practical, a little bit more tangible.

So let's do that real quick.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now