Understanding the Parts of a Design System

Tokens, assets, components, and patterns.

By Carlos Yllobre Aleman, Senior Product Designer, Workday

This is the third in a series of articles about design systems thinking. Read Part 1 and Part 2 here.

Essentially what makes up a design — or any — system is the sum of its parts and the connection between these parts, working towards a defined purpose. This concept is clear but not complete. When it comes to understanding the system as an entity, we need to dig deeper and get to know those pieces and their interactions.

In previous articles, I have talked about applying systems thinking and following a useful methodology to build a system. This time, I would like to talk about the design system itself, as well as its parts.

Tokens

Everything starts here. Tokens are the beginning of everything — as fundamental as it sounds — since everything in a design system is made of tokens. That’s why any small change you apply to one of these could trigger a ripple effect in every area of the system and the product.

The concept of “design tokens” was created by the design system advocate Jina Anne to refer to those entities that store visual design attributes. Since then, the name tokens has spread across the industry to become the most common way to identify these pieces. But what exactly are tokens?

As defined by the Workday’s Design System team:

Tokens are the smallest pieces of our Design System. Their primary function is to store UI information that allows for building assets, components, and patterns at a sustainable scale while securing consistency across our platforms.

Based on this definition, 2 key metrics help us understand and define tokens:

1. A token is an immutable element that requires a well-defined and justified adoption and/or modification process.
2. A token is a raw material or tool we use to build more complex elements like assets, components and patterns.

Some examples of Tokens are a color palette, typography, spacing rules, or non-visual elements like motion guidelines.

Assets

Some designers and developers like to treat assets as more complex tokens, and they are not necessarily wrong since these could be managed in the same way based on their characteristics. However, I prefer to separate assets into their own category for two reasons:

1. To avoid confusion between the two since they might be used similarly but come with different building and intake processes.
2. To keep the concept of tokens as clean and close to its true nature as possible.

Assets are more complex UI units used in the same way as components but built with a fixed function or purpose. They depend on tokens in the same way as components, but they are built differently. Some examples of assets could be your icon library, brand assets, or illustration packages.

Components

The components are groups or blocks of tokens or other components built together with specific functional behavior that serves a variety of applications.

These are the building blocks and the most recognizable parts of a Design System, used by many product teams and therefore subject to more updates and modifications than other elements.

I highly recommend to organize the components of your Design System by doing 2 things:

1. Consider Information Architecture:

In my previous article about design system maps, I talked about the importance of counting with a taxonomy map to organize and better understand our systems. The components, like any other part of the design system, are not exempt from this. By creating “umbrella” categories, we make sure we cover different sets of components with similar main functionalities, separating them from other sets and identifying at the same time, types of components and their variations.

E.g. Use Simple architecture to organize components:

Category: The descriptive high-level bucket.

__ Type of Component: Needed for additional categorization.

____Variation: Prescribed alteration of the component.

2. Define Levels of Complexity

It is important to notice that not all components are the same. They present different characteristics and different levels of complexity. Because of this, we need to be able to define our components and organize them based on their nature and structure.

The levels of complexity we need to define will depend on the size and the type of Design System, but for most of the systems out there I would recommend counting with three levels of complexity to define their components.

Level 1: Standalone components made with tokens only.

Level 2: Components built by grouping Level 1 components together with tokens and simple interactions.

Level 3: Components built using other components in addition to logic and interaction metrics. Due to their complexity, some of these are covered under Patterns.

Patterns

Patterns are tricky to define, and this is due to their complexity and how they are created. Patterns are more related to solutions than to isolated elements in a system, so even though they could be created and curated by the Design System team, the norm should be that Patterns are created and fed back into the system by those solving the problems in your organization: the product teams.

Patterns consist of a reusable collection of components that can be defined by their respective interactions when solving a design problem. These need to be adopted and documented as business cases and together build a consistent and robust ecosystem.

Based on this definition we can provide with 3 key metrics that help us identify and validate what a pattern is:

1. A pattern is a solution to a common design problem, always linked to a business case.
2. A pattern needs to be reusable and linked to components. This is not always the case, but it is where the main value is for product teams.
3. A pattern must document and provide guidelines about how the problem was solved by the product team.

Pattern vs Complex Component

It is common to have some confusion when talking about complex components and patterns; that’s why I want to shed some light here. Patterns and components are intrinsically related but they are required to be documented in different ways, simply because they are created and used differently.

A pattern provides us with a specific context about a solution, how that solution was tailored and what set of components and tokens were used to get to that result.

A complex component responds only to its primary function or purpose as a component. It provides documentation about its logic and interaction metrics without any other context than self-definition. Because of this, It can be used in multiple cases and scenarios by giving the product teams the flexibility they need to solve new problems.

Summing Up

Every design system is different because it is built based on the needs of its primary users, the development and design team, and the type of product it is serving, but there are always things in common worth understanding and defining. This article is not meant to be a reference for classifying the different pieces covered here; my intention is to help shed some light for a better understanding of systems and its parts.

Thank you for reading!