Chapter 4. Making Room for Variation

Making a brand feel unified, cohesive, and harmonious while also leaving room for experimentation is a tough balancing act. It’s one of the most challenging aspects of a design system.

Graphic designer and Pentagram partner Paula Scher faced this challenge with the visual identity for the Public Theater in New York. As she explained in a talk at Beyond Tellerrand:

I began to realize that if you made everything the same, it was boring after the first year. If you changed it individually for each play, the theater lost recognizability. The thing to do, which I totally got for the first time after working there at this point for 17 years, is what they needed to have were seasons.
You could take the typography and the color system for the summer festival, the Shakespeare in the Park Festival, and you could begin to translate it into posters by flopping the colors, but using some of the same motifs, and you could create entire seasons out of the graphics. That would become its own standards manual where I have about six different people making these all year (http://bkaprt.com/eds/04-01/).

Scher’s strategy was to retain the Public Theater’s visual language every year, but to vary some of its elements (Fig 4.1–2). Colors would be swapped. Text would skew in different directions. New visual motifs would be introduced. The result is that each season coheres in its own way, but so does the identity of the Public Theater as a whole.

Sixteen Public Theater posters in black, white, and yellow, with slanted wood type letterforms and high-contrast images of people.

Fig 4.1: The posters for the 2014/15 season featured the wood type style the Public Theater is known for, but the typography was skewed. The color palette was restrained to yellow, black, and white, which led to a dynamic look when coupled with the skewed type (http://bkaprt.com/eds/04-02/).

Twelve Public Theater posters using black, white, and pastel colors with wood type letterforms and softer images of people.

Fig 4.2: For the 2018 season, the wood type letterforms were extended on a field of gradated color. The grayscale cut-out photos we saw in the 2014/15 season persisted, but this time in lower contrast to fit better with the softer color tones (http://bkaprt.com/eds/04-03/).

Even the most robust or thoroughly planned systems will need to account for variation at some point. As soon as you release a design system, people will ask you how to deviate from it, and you’ll want to be armed with persuasive answers. In this chapter, I’m going to talk about what variation means for a design system, how to know when you need it, and how to manage it in a scalable way.

What Is Variation?

We’ve spent most of this book talking about the importance of unity, cohesion, and harmony in a design system. So why are we talking about variation? Isn’t that at odds with all of the goals we’ve set until now?

Variation is a deviation from established patterns, and it can exist at every level of the system. At the component level, for instance, a team may discover that they need a component to behave in a slightly different way; maybe this particular component needs to appear without a photo, for example. At a design-language level, you may have a team that has a different audience, so they want to adjust their brand identity to serve that audience better. You can even have variation at the level of design principles: if a team is working on a product that is functionally different from your core product, they may need to adjust their principles to suit that context.

There are three kinds of deviations that come up in a design system:

  • Unintentional divergence typically happens when designers can’t find the information they’re looking for. They may not know that a certain solution exists within a system, so they create their own style. Clear, easy-to-find documentation and usage guidelines can help your team avoid unintentional variation.
  • Intentional but unnecessary divergence usually results from designers not wanting to feel constrained by the system, or believing they have a better solution. Making sure your team knows how to push back on and contribute to the system can help mitigate this kind of variation.
  • Intentional, meaningful divergence is the goal of an expressive design system. In this case, the divergence is meaningful because it solves a very specific user problem that no existing pattern solves.

We want to enable intentional, meaningful variation. To do this, we need to understand the needs and contexts for variation.

Contexts for Variation

Every variation we add makes our design system more complicated. Therefore, we need to take care to find the right moments for variation. Three big contextual changes are served by variation: brand, audience, and environment.

Brand

If you’re creating a system for multiple brands, each with its own brand language, then your system needs to support variations to reflect those brands.

The key here is to find the common core elements and then set some criteria for how you should deviate. When we were creating the design system for our websites at Vox Media, we constantly debated which elements should feel more expressive. Should a footer be standardized, or should we allow for tons of customization? We went back to our core goals: our users were ultimately visiting our websites to consume editorial content. So the variations should be in service of the content, writing style, and tone of voice for each brand.

The newsletter modules across Vox Media brands were an example of unnecessary variation. They were consistent in functionality and layout, but had variations in type, color, and visual treatments like borders (Fig 4.3). There was quite a bit of custom design within a very small area: Curbed’s newsletter component had a skewed background, for example, while Eater’s had a background image. Because these modules were so consistent in their user goals, we decided to unify their design and create less variation (Fig 4.4).

Three examples of newsletter modules, showing different colors, fonts, and spacing.

Fig 4.3: Older versions of Vox Media’s newsletter modules contained lots of unnecessary visual variation.

Three examples of newsletter modules, showing the same colors, fonts, and spacing.

Fig 4.4: The new, unified newsletter modules.

The unified design cleaned up some technical debt. In the previous design, each newsletter module had CSS overrides to achieve distinct styling. Some modules even had overrides on the primary button color so it would work better with the background color. Little CSS overrides like this add up over time. Whenever we released a new change, we’d have to manually update the spots containing CSS overrides.

The streamlined design also placed a more appropriate emphasis on the newsletter module. While important, this module isn’t the star of the page. It doesn’t need loud backgrounds or fancy shapes to command attention, especially since it’s placed around article content. Variation in this module wasn’t necessary for expressing the brands.

On the other hand, consider the variation in Vox Media’s global header components. When we were redesigning the Verge, its editorial teams were vocal about wanting more latitude to art-direct the page, guide attention toward big features, and showcase custom illustrations. We addressed this by creating a masthead component (Fig 4.5) that sits on top of the global header on homepages. It contains a logo, tagline, date, and customizable background image. Though at the time this was a one-off component, we felt that the variation was valuable because it would strengthen the Verge’s brand voice.

Three examples of the Verge’s masthead component: one with magenta and blue abstractions, one with a city skyline in orange tones, and one in pixelated black and white.

Fig 4.5: Examples of the Verge’s masthead component.

The Verge team commissions or makes original art that changes throughout the day. The most exciting part is that they can use the masthead and a one-up hero when they drop a big feature and use these flexible components to art-direct the page (Fig 4.6). Soon after launch, the Verge masthead even got a Twitter fan account (@VergeTaglines) that tweets every time the image changes.

Comparison of the Verge’s homepage, changing based on the masthead design and hero photography.

Fig 4.6: The Verge uses two generic components, the masthead and one-up hero, to art-direct its homepages.

Though this component was built specifically for the Verge, it soon gained broader application with other brands that share Vox’s publishing platform, Chorus. The McElroy Family website, for example, needed to convey its sense of humor and Appalachian roots; the masthead component shines with an original illustration featuring an adorable squirrel (Fig 4.7).

The Chicago Sun-Times—another Chorus platform site—is very different in content, tone, and audience from The McElroy Family, but the masthead component is just as valuable in conveying the tone of the organization’s high-quality investigative journalism and breaking news coverage (Fig 4.8).

Why did the masthead variation work well while the newsletter variation didn’t? The variations on the newsletter design were purely visual. When we created them, we didn’t have a strategy for how variation should work; instead, we were looking for any opportunity to make the brands feel distinct. The masthead variation, by contrast, tied directly into the brand strategy. Even though it began as a one-off for the Verge, it was flexible and purposeful enough to migrate to other brands.

The masthead component for the McElroy Family, showing a blue navigation bar and a pastel illustration of a forest.

Fig 4.7: The McElroy Family site uses the same masthead component as the Verge to display a custom illustration.

The masthead component for the Chicago Sun-Times, showing a white background, stark black text, and a red Subscribe button.

Fig 4.8: The same masthead component on the Chicago Sun-Times site.

Audience

The next contextual variation comes from audience. If your products serve different audiences who all need different things, then your system may need to adapt to fit those needs.

A good example of this is Airbnb’s listing pages. In addition to their standard listings, they also have Airbnb Plus—one-of-a-kind, high quality rentals at higher price points. Audiences booking a Plus listing are probably looking for exceptional quality and attention to detail.

Both Airbnb’s standard listing page and Plus listing page are immediately recognizable as belonging to the same family because they use many consistent elements (Fig 4.9). They both use Airbnb’s custom font, Cereal. They both highlight photography. They both use many of the same components, like the date picker. The iconography is the same.

Comparison of Airbnb’s standard and Plus listings, using the same brand elements but resulting in different tones.

Fig 4.9: The same brand elements in Airbnb’s standard listings (above) are used in their Plus listings (below), but with variations that make the listing styles distinct.

However, some of the design choices convey a different attitude. Airbnb Plus uses larger typography, airier vertical space, and a lighter weight of Cereal. It has a more understated color palette, with a deeper color on the call to action. These choices make Airbnb Plus feel like a more premium experience. You can see they’ve adjusted the density, weight, and scale levers to achieve a more elegant and sophisticated aesthetic.

The standard listing page, on the other hand, is more functional, with the booking module front and center. The Plus design pulls the density and weight levers in a lighter, airier direction. The standard listing page has less size contrast between elements, making it feel more functional.

Because they use the same core building blocks—the same typography, iconography, and components—both experiences feel like Airbnb. However, the variations in spacing, typographic weights, and color help distinguish the standard listing from the premium listing.

Environment

I’ve mainly been talking about adding variation to a system to allow for a range of content tones, but you may also need your system to scale based on environmental contexts. “Environment” in this context asks: Where will your products be used? Will that have an impact on the experience? Environments are the various constraints and pressures that surround and inform an experience. That can include lighting, ambient noise, passive or active engagement, expected focus level, or devices.

Shopify’s Polaris design system initially grew out of Shopify’s Store Management product. When the Shopify Retail team kicked off a project to design the next generation point-of-sale (POS) system, they realized that the patterns in Polaris didn’t exactly fit their needs. The POS system needed to work well in a retail space, often under bright lighting. The app needed to be used at arm’s length, twenty-four to thirty-six inches away from the merchant. And unlike the core admin, where the primary interaction is between the merchant and the UI, merchants using the POS system needed to prioritize their interactions with their customers instead of the UI. The Retail team wanted merchants to achieve an “eyes-closed” level of mastery over the UI so they could maintain eye contact with their customers.

The Retail team decided that the existing color palette, which only worked on a light background, would not be clear enough under the bright lights of a retail shop. The type scale was also too small to be used at arm’s length. And in order for merchants to use the POS system without breaking eye contact with customers, the buttons and other UI elements would need to be much larger.

The Retail team recognized that the current design system didn’t support a variety of environmental scenarios. But after talking with the Polaris team, they realized that other teams would benefit from the solutions they created. The Warehouse team, for example, was also developing an app that needed to be used at arm’s length under bright lights. This work inspired the Polaris team to create a dark mode for the system (Fig 4.10).

Comparison of light and dark modes for navigation menus in the Polaris design system.Fig 4.10: Polaris light mode (left) and dark mode (right).

This feedback loop between product team and design system team is a great example of how to build the right variation into your system. Build your system around helping your users navigate your product more clearly and serving content needs and you’ll unlock scalable expression.

Now that we’ve looked at a few cases where variation works, let’s look at how we can make that variation happen in a scalable way.

Approaches to Variation

Although the reasons we need variation in a system may differ, the way we achieve variation is the same. We can vary either the components or the visual language. Let’s look at both of these approaches in turn.

Varying your components

As we discussed in Chapter 3, components should be designed for flexibility. In his article “Pattern Variations,” Brad Frost writes:

At the heart of a good design system is a set of solid, flexible components that can be arranged to create cohesive, delightful user interfaces. An effective design system provides components that are robust, resilient, flexible, and adaptable (http://bkaprt.com/eds/04-04/).

There are three main ways you can modify components to express variation:

  • Content. The most obvious way is to change the content being displayed. Text, images, and media that feel tonally different will convey a different meaning, even if they’re displayed in the same component.
  • Structure. The structure of a component can also change depending on context. In Chapter 3, I mentioned how the size lever impacts not just the design language, but also the general size of your elements. A story card, for example, could be bigger or smaller to convey a change in hierarchy.
  • Style. The component could have different type, color, or spacing variations.

The Guardian uses a variety of card sizes to create hierarchy on the page and to help a reader gauge a story’s importance (Fig 4.11). Components, too, can contain visual variation to communicate a difference in tone. While the Guardian uses structure and style to indicate variation, it’s also important to note how much the content itself communicates that range. Sometimes the best strategy for supporting variation is to let the content speak.

Three examples of story cards from the Guardian, showing differences in color, text size, and image.

Fig 4.11: Compare these three cards from the Guardian. The prominent, beautifully shot food photography on the left whets the appetite. In the middle, the use of red for news content indicates that the message is serious. For the opinion piece on the right, the focus on the columnist suggests that this is a personal essay.

Varying your visual language

Think of theming as a set of interconnected variables that allow you to represent a brand’s look and feel within your design system. Theming makes it possible to flexibly change the appearance of a product without changing the underlying foundation of components.

At Vox, theming allowed us to achieve a wide range of brand expression in our design system. Each of the components in the system was designed with a default theme to let the team focus on things like hierarchy, balance, and layout first. Later, each of Vox Media’s brands got its own theme with a custom color palette, typography, and spacing scale.

Theming let us express the visual language for all of our brands in a scalable way. It consisted of a few layers:

  • Tokens: A code identifier for each role, like $text.
  • Role: The systematic usage of a token. We might give $text the role of “primary text color.”
  • Value: The actual value of that style, such as an individual hex code assigned to a token. For example, $text’s individual hex code could be #333333.

Theming works by assigning a token to every element in your UI. Tokens and roles don’t change, but values can be customized according to brand (Fig 4.12). For example, you could say that your primary text color will always use the $text color token, which will keep your system aligned as you create new variations (Fig 4.13).

Comparison of light and dark themes applied to the same component, changing the background and text colors.

Fig 4.12: An example of light and dark themes for a general promotion module. Roles, defined by token names, are consistent, but the individual values vary.
Token Role Light theme value Dark theme value
$background Page background #EEEEEE #000000
$surface Component background #FFFFFF #152935
$text Primary text #000000 #FFFFFF
$text-muted Muted text #3E5269 #DFE6EB
$interactive-action Primary action #3D70B2 #5AAAFA
$interactive-on-text Primary action text #FFFFFF #FFFFFF
Fig 4.13: Here’s how the tokens, roles, and values line up for the light and dark themes in Fig 4.12.

For theming to work, you need to give your tokens semantic rather than descriptive names. If your buttons have a background color of $color-blue, you’ll run into trouble down the line if you have to create a theme or if your brand colors change.

Building Themes

Before you can begin creating themes, you need to determine an approach to your theming. What degree of theming are you going to allow? Let’s think back to the levers and dials from Chapter 3. Are you going to let people just turn a few dials or pull the big levers? There are two approaches you can take:

  • Theme only your dials. One approach is to allow only the dials to be themed. In other words, you could allow for customization on type and color but nothing else—it would essentially be a applying a skin on top of the same interface. This approach is valuable if you’re creating a white-label product and want your customer to use their own colors, but otherwise keep the rest of the design elements the same.
  • Theme your dials and levers. Or, you could allow for both the dials and levers to be themed. In addition to allowing for color and type to be customized, you could also allow for global scale and sizing to be adjusted.

Color is the only dial you can successfully change without changing anything else. Unless you’re swapping out fonts that have exactly the same metrics, you’ll have to change spacing if fonts are altered (Fig 4.14).

Comparison of light and dark themes applied to the same component, changing the font in addition to colors.

Fig 4.14: The same component as in Fig 4.12. This time, though, we’ve changed the primary font to the very narrow Druk Condensed Super. As you can see, once you start changing type, other levers need to adjust around it.

We can use all of the foundations of creating a design language to create themes. Our trifecta of type, space, and color contains the most common elements to define for expressive themes.

Theming type

If only theming type could be as simple as swapping in a different font and calling it a day! But because typefaces vary so wildly, it’s hard to change a font without making other significant changes to the design system. Fonts vary in optical sizing; even if two fonts are set at the same pixel value, an optically small typeface appears smaller than an optically large typeface. The optical sizing depends on each typeface’s physical characteristics. A font with a small x-height, for example, looks smaller than a font with a large x-height.

The other problem with theming type is that all fonts have different vertical metrics (http://bkaprt.com/eds/04-05/). Every font file contains mathematical instructions that describe how to space each character, including the amount of room a glyph should consume relative to its specified size and the amount of space around it. That’s a long-winded way of saying that fonts have different space built into them (Fig 4.15). You will be bewildered and astounded the first time you try to vertically align two fonts within one button component, I promise.

The letters “e” and “g” in three different fonts, showing how space and vertical sizing vary widely across fonts.

Fig 4.15: Fonts vary in vertical metrics and optical sizing. That makes theming them a challenge.

Theming type is challenging, but it’s not impossible. Here’s what I’ve learned about how to make it work.

Assign your tokens and roles

The first thing you need to do is assign your type tokens and roles.

  • How many categories of fonts do you need? For our type system at Vox Media, we knew we wanted four categories of fonts. $font1 was for story titles and headings within the body of an article. $font2 was for the body copy. $font3 was for the page or section headings. $font4 was for metadata and UI copy like tags, captions, timestamps, and button text.
  • Which of these categories should be themed? You could allow for custom fonts for each of these categories, or you could restrict some choices and only allow theming for a few categories. I can imagine an instance where you would let the heading font be customized but want to leave all UI fonts the same, if you’ve found a good UI font that works well across the board.
  • Decide on your type sizes and proportions. When you allow type to be themed, you need to be deliberate about what choices will be baked into the system and what choices you’ll allow others to make. For our type system, we decided we would let teams change the baseline font size and the font ratio, but the role of type sizes would need to be consistent. We used our existing article page to determine how many type sizes we would need (Fig 4.16). The headline, for example, would use the Size 8 value while the byline would use the Size 1 value. This meant that one brand could have 44px as its Size 8 and another could have 64px, but the headline would always remain in proportion to the relative size of the other type on the page.

    An article on the Verge, with different pieces of content annotated to show which type size they use.

    Fig 4.16: Mapping your type sizes to elements on the page means your type will always be proportional, even if the individual values change.

Theming type sizes

Once you’ve assigned the type sizes to roles, you need to allow teams to customize those type sizes. You have two options here:

  1. Let teams choose each of those values individually. This gives teams more control. They can rely on optical sizing to choose the values that make the most sense for each font. The downside is that this is a dial-setting approach. And as we’ve learned, setting type by making too many granular choices can make your overall system feel disharmonious.
  2. Let teams change the base font size and font ratio. In other words, you’re letting them choose a font scale. This reduces the number of choices from ten to two. It also encourages designers to think about the big levers they want to pull, making their type feel more purposeful. The higher the font ratio, the larger the size contrast you’ll have between type headings (Fig 4.17). A font ratio of 1.125 will have less size contrast between headings than a font ratio of 1.333 (Fig 4.18). If the designers of one product decide they need a smaller size contrast between type sizes, they can choose the font ratio that will enable that.

    Comparison between a long, low-space-contrast headline and a condensed, high-space contrast headline.

    Fig 4.17: A site with long headlines and less contrast between its heading and body copy (left) might want to use a font ratio with less contrast. A more condensed typeface paired with smaller typefaces (right) would benefit from a greater font-ratio contrast.

    Comparison between two different font ratios, showing higher contrast with a larger ratio.

    Fig 4.18: Two different type scales that vary in the contrast of their headings. The left has a font ratio of 1.125 (minor third) and the right has a font ratio of 1.333 (perfect fourth).

    Earlier, I mentioned that the trickiest part of theming text is dealing with the variations in the space around the text. If you theme type, you also need to allow for the space around the type to be adjusted. At Vox, the way we solved this was by theming the space around the type.

    Theming space

    You want space to be themed as a lever, not as dials. The global spacing in your design system should feel holistic. If you have really tight spacing in some components and really loose spacing in others, your pages will feel erratic.

    A team might want to theme space for a few reasons:

    • They’re creating a task-driven experience and need compact spacing.
    • They’re creating a marketing, brochure, or editorial experience and want more open spacing.
    • They want the spacing to change based on device sizing.

Having a set of three density settings for your components could help people theme space in a way that feels consistent. Why three? You don’t want to build in too much variety. Having a compact space scale, default space scale, and loose space scale covers the most common variations.

Gmail’s density settings provide a good example (Fig 4.19). In this case, they give the end user the option to adjust the layout’s density. For your purposes, you may choose to build density settings into your components to allow internal teams to choose the density that works best for the experience they’re solving for.

Let’s look again at our general promotion module (Fig 4.20). First, we can decide the relationship of space between elements. In this case, we want a larger unit of space before and after the content. Within the content, we want to use a slightly smaller unit of space.

We can define the vertical space in a card by choosing a number from our space scale (Fig 4.21). Regardless of the actual size of the spacing unit, we know there will be more space above the headline and below the button. The card on the left uses the small space scale while the card on the right uses the large space scale. The card on the left is using the “Default” spacing scale, which means there will be 24px around the content and 16px between the content. Let’s say another team is using the design system, but they want to use the “Loose” space scale instead of “Default.” They can select that space scale globally, and the general promotion module will automatically use the pixel values from the “Loose” scale.

Comparison of Gmail’s density settings, showing how the Comfortable and Compact themes differ in their spacing.

Fig 4.19: Gmail’s density settings are a good example of how space can be themed holistically.

Comparison of two variations of a component, showing how space sizes are adjusted between them.

Fig 4.20: When theming space, first map your components to space sizes and then allow the spacing scale to be adjusted.
Size Compact Default Loose
0 0 × 0 0 × 0 0 × 0
1 2 × 2 4 × 4 8 × 8
2 4 × 4 8 × 8 12 × 12
3 8 × 8 12 × 12 16 × 16
4 12 × 12 16 × 16 24 × 24
5 16 × 16 24 × 24 32 × 32
Fig 4.21: An example of five sizes on a space scale. The “Loose” scale has larger values while the “Compact” scale has smaller values.

Theming color

Color theming means changing the color values in an interface to match an individual brand’s design language. There are two approaches for color theming:

  1. Allow foreground colors to be changed, but not the background color.
  2. Allow both foreground and background colors to be themed.

Theming only the foreground colors is much simpler, but also more limited. You would typically choose just a few areas where you’ll allow customization. In this case, you could say that $brand-01 will be customizable, but every other color will stay the same. Then, you would specify all of the areas that will use $brand-01. This is the minimum amount of theming possible, and it’s good for when you want to give teams a small amount of customization—the variations will feel pretty similar across the board (Fig 4.22).

Theming both the background and foreground gets trickier. You’ll notice I talk a lot about reducing the number of choices teams need to make when deciding on theme values. There’s a good reason for my reluctance to open up a world of options when it comes to theming.

Component theme changes showing how a button and highlight color can be blue or orange.

Fig 4.22: An example of only theming the foreground colors.

When we created our first color system at Vox Media, we allowed for many, many options. Practically every element of the page had a color variable associated with it (Fig 4.23). The navigation started with $nav-background-color, $nav-foreground-color. Okay, sensible enough—but it progressed. $nav-link-color. $nav-link-color-hover. Then, we got to our dropdowns: $nav-dropdown-bg-color, $nav-dropdown-fg-color, $nav-dropdown-link-color, $nav-dropdown-link-hover-color. Just remembering this makes me sweat. And these were only the color variables in the navigation. All in all, we ended up with almost three hundred different variables.

Our thinking was: “Let’s give designers control! They’re experts at choosing colors and will make much better choices than a machine.” In reality, though, this degree of choice was completely overwhelming. We ended up with lots of inconsistency, and a ton of visual QA tickets.

There’s a better way to theme colors: color groups.

Comparison of two variations of a component, where every design element has been marked for color changes.

Fig 4.23: These are granular color variables. Don’t do this!

Color groups

The idea of color groups is that you define foreground colors based on their background colors. Then you apply a color group to a component. For example, instead of setting individual values for every single element in our navigation, we would assign it the “dark” color group.

  • Decide how many types of background colors you need. Light and dark are the most common types of background colors, especially for complex applications when the primary goal of your theming is to switch between a “light” and “dark” mode. Editorial or content sites tend to use more colored backgrounds behind cards or containers. At Vox Media, we opted for four backgrounds: light, dark, bright, and muted.
  • Choose the background color values. Decide the color values for each of these background colors. For example, the “light” background hex value could be #ffffff.
  • Decide how many types of foreground colors you need. We used $primary-foreground for the more prominent text, $secondary-foreground for less prominent text, $accent for supplementary text (like tags), and $link for links.
  • Choose values for the foreground colors for each color group. Now comes the part where you really put your color groups together. Start with one of your background colors and define each of the foreground color values (Fig 4.24). As you create each group, remember to test the accessibility of the color combinations to make sure the foreground and background colors are accessible when used together.

    Comparison of dark and light color groups as applied to the same component.

    Fig 4.24: Examples of dark and light color groups and how they map to components.

It makes much more sense to group colors than to define every color individually. The groupings help people think about color holistically when they create a theme, which leads to more consistency: a link color will always be the same when it’s on a dark background.

The color groups also mean you have one source of truth when it comes to testing the accessibility of your color palette. If your color groups are accessible, then the color on your site will also be accessible. If you have an inaccessible color combination, you can fix that in your color group so that it will permeate the entire site.

Color is a powerful tool when it comes to theming. But please—vary responsibly and don’t create three hundred customizable values for color.

System Layers

Design systems shouldn’t be static—they should be able to flex and change over time. We are building design systems for products that need to change rapidly. To succeed, we need to account for change. Part of allowing for variation in a system is defining where change should happen most frequently.

In the book How Buildings Learn, Stewart Brand explains that different timescales can have an effect on a building:

Our basic argument is that there isn’t any such thing as a building. A building properly conceived is several layers of longevity of built components.

The layers Brand describes are site, structure, skin, services, space plan, and stuff, ordered by an increasing frequency of evolution. Site, the location of a building, never changes, while stuff—chairs, desks, phones, etc.—can change often.

Thinking of our design systems in terms of layers that change at different frequencies can help us support variation in a scalable way. For instance, changing your underlying brand principles would mean that every other part of your system would need to change, too. Changing your grid would impact layouts.

Design systems don’t need to stifle creativity or limit brand expression. You have a vast array of tools to express brand. Choose the ones that will serve your brand purpose best and focus on turning them into signature patterns.

Up to this point, we’ve focused on how to create a design system. However, we can’t see the benefits of the system until it’s integrated into real products. In the next chapter, we’ll look at how to use a design system.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset