Hey, I Think We Need a Button – Part 1: Design Tokens

Design system is a kit of tools and documentation—components, guidelines, principles—that is used by designers and developers to create user interfaces (UIs). It’s a common framework that enables different groups of designers and development teams to create UIs that are consistent with each other. This consistency leads to an improved user experience but there’s also a benefit for design and development efficiency that comes from reusable components and design patterns.

A central part of a design system is the library of reusable UI components—things like text fields, dropdown menus, and message boxes. The star of this blog series is one of those components: a button, a component so mundane and simple that you might not think that much of it... yet. We’ll examine a button component from different angles and see what kind of considerations go into integrating one into a design system. Today’s angle: design tokens.

Fig. 1. It’s a button, probably quite similar to the million other buttons you’ve encountered before.

To arrive at the simple button in Fig. 1, countless of design decisions have already been made behind the scenes. Let’s break the button into smaller components (Fig. 2) and see how we can utilize design tokens to help us systemically define these aspects.

Fig. 2. Our button broken into three components: dimensions, color, and typography.

Dimensions

What size should a button be? Well, it depends on all kinds of factors but here’s a start:

• Buttons should be sized consistently.
• Buttons should be sized in harmony with all the other elements and patterns in the design system.

The first point is easily achieved by just having a button component in the first place: we just use the same component everywhere. The second point? To clarify, it means the different kinds of elements fit together even if they are of different sizes, kind of like pieces in a modular shelving system. We can start by utilizing an eight-point scale system where element dimensions only use multiples of eight (8, 16, 24, 32, etc.), as demonstrated with our button in Fig. 3.

Fig. 3. Eight-point scaling system. (The total width of a button varies based on the text.)

When all the elements use the same scale, components will quite often just naturally fit into each other. But, as buttons are a very central part of any design system, it can make sense to extend this quest for consistency even further. For example, matching the height of the button to the height of common input fields such as a text field creates additional synergy within the design system (Fig. 4).

Fig. 4. The heights of the components are harmonized.

Design tokens are the usual solution to manage these kinds of shared characteristics in a design system. They are a collection of shared values (sizes, spacings, colors, etc.) with descriptive names that are then applied to individual components. These tokens are then used in both the design files and actual code implementation, ensuring parity between the two. In Fig. 5, we’ve revised the button to use two design tokens: a unit (eight points, making the side padding 3 × unit = 24) and an input-height (5 × unit = 40).

Fig. 5. Token names in blue. While the sizes are unchanged, the design intent is now explicitly apparent.

Now, whenever we need a new kind of input field, like a select list, we can refer to our tokens and use the input-height token. And if the size doesn’t work in that case, we are better equipped to either 1. decide to use a non-matching size (consequences of which are immediately apparent) or 2. change the value of the input-height token to something else (a single value controls both the design files and the code implementation).

Or maybe, later, in a hurry, we forget that such a token exists and we define the height of a new input field as something other. Having the earlier design decision explicitly stated (if only in two words: “input-height”) probably decreases the chance of that happening in the first place, but it also vastly increases the chances of someone else, like a developer familiar with the tokens, catching your mistake for you. The use of design tokens increases the understanding of the design for everyone involved.

Color

As with dimensions, we need to make sure that color is used consistently across the design system. Our button currently uses two colors: one for background and one for foreground (text).

Colors are another great use case for design tokens. In Fig. 6 we have two design tokens:

• accent (a color that really pops in a layout)
• accent-foreground (a color used for foreground elements on an accent background color)
  

Fig. 6. The two color tokens.

Tokens can refer to other tokens as demonstrated in the previous section with input-height being defined as 5 × unit. The idea can be extended to a whole hierarchy of token chains where the meaningful and specific semantic tokens are defined using other tokens, which might refer to other tokens and so on, all the way down to the primitive tokens (e.g. blue-60 from a brand style guide).

Fig. 7. With color tokens, the reference hierarchy can become several layers deep.

Fig. 7 has examples of two and three layers-deep token reference chains. The first one is pretty simple: accent color is defined as blue-60. But what’s that token between gray-0 and accent-foreground?

Foreground elements are usually either dark on a light background (considered the “default” in our example) or light on a dark background (“inverse” in our example). The token in the middle, foreground-inverse, is an intermediate semantic token with the meaning of “foreground color (light) on inverse background color (dark)”.

Typography

The look and feel of a text in any context, including buttons, depends on the overall typographic direction of the design system. A single text style consists of several components, such as typeface, weight, and size. Skipping all the technical considerations, text styles are composite tokens that collect all of these aspects into a single token. And to ensure consistency across different text styles, many of these aspects are defined as separate tokens (Fig. 8).

Fig. 8. The text style token our button uses is called a label.

Let’s take fontSize-3 from Fig. 8. A token named fontSize-3 implies the existence of font sizes 1 and 2, and realistically there’s a whole scale of font sizes all the way up to the largest headings. Add to that that some of these typography tokens are probably referencing other tokens: e.g. common line heights would probably be multiplies of the scale unit token (eight points, remember?). We haven’t gotten very far with our button, yet we start to get some sense of the interconnectedness and breadth that a well-thought-out design system has.

As the number of tokens increases, it’s beneficial to have a robust and well-documented token naming structure. Having one makes it easier to name the tokens and more importantly, it organizes tokens into a discoverable hierarchical structure. So instead of having a token called accent as we had previously, we add a prefix to group it with related tokens: color-accent. A solid naming structure simplifies the communication of more complex ideas, such as when interaction states are added to the mix in the next part of this series.

In conclusion

Fig. 9. “It’s just a simple button...”

Why do we make a seemingly simple thing so complicated? Here are some key takeaways:

• Design tokens systemically define details, reducing the design space and making future design decisions easier.
• Use of design tokens steers the designer building the design system to think in terms of these interconnected systems, which in turn increases the quality of the overall design system.
• Design tokens act as an additional layer of documentation. The intent of hundreds and hundreds of small design decisions becomes more apparent when they have an explicit label attached to them.
• In addition, all kinds of benefits relate to the development side of things that are outside the scope of this series.

In the next part of this series, we’ll see how interactions and accessibility concerns affect our button as we add new states and address its behavior in different contexts.