Design Tokens
Design Tokens are a great starting point for Design Codification and help us embrace cross-functionality and collective ownership.
Last updated
Design Tokens are a great starting point for Design Codification and help us embrace cross-functionality and collective ownership.
Last updated
Design Codification represents one of the fundamental principles of Lean Design System, as it enables cross-functional teams to work collaboratively and adopt collective ownership of a design system. However, planning and implementing a comprehensive component library can prove a substantial challenge, even for experienced teams. Taking incremental steps towards this goal will help us get started, especially if we're new to concepts such as design-as-code and radical cross-functionality (as proposed in Win Friends, not Battles). Maintaining design aspects in the form of Design Tokens makes for one such approach. According to design system advocate Jina Anne (who is also co-chairing the W3C's Design Tokens Community Group):
With Design Tokens, a design system can be built from the bottom up and in a technology-agnostic manner, as the information encoded within them can be pulled into any kind of framework.
Design Tokens can be described as an abstraction of all aspects shaping the design of digital products. In contrast to hard-coded values maintained all over the place, tokens are the central roots of a scalable and consistent design system. With Design Tokens, a design system can be built from the bottom up and in a technology-agnostic manner, as the information encoded within them can be pulled into any kind of framework.
A well-thought-out Design Tokens structure constitutes the bedrock of a lean code repository. It provides the DNA for our components and a shared language between domains. A design system based on Design Tokens forces designers and developers to continually form consensus, promoting a healthy interweaving of skills and responsibilities. Designers are encouraged to gain at least a basic understanding of the code in order to define and approve tokens. Front-end developers learn about the purpose behind design-related decisions and the relationship between properties, as Design Tokens manage to bridge the semantic gap between the designers' intentions and the technical implementation. They provide additional richness to design definitions and make technical and stylistic nuances more tangible to both audiences.
Design Tokens also provide designers and developers with powerful levers to make changes quickly and effectively throughout all layers of the design system and our front-end implementations. These layers include the brand design properties at the core of the design system, higher-level themes, custom adaptations, and the specific UI component mappings on the surface of a digital product. The following examples will illustrate how we can structure a Design Tokens repository to make full use of the concept.
The currently preferred approach to maintaining Design Tokens is storing them in JSON files, as it's the most widely supported format. From there, all information can be pulled directly via JavaScript or compiled to CSS. The examples below are written in SCSS to make them easier to read for designers who may be unfamiliar with JSON.
Design Tokens are organized in a tree hierarchy, where we define increasingly specific design decisions as we move towards the leaves of the tree. There's no limit to the number of hierarchical levels we establish, we're free to explore different structures and find the perfect fit for our needs.
To exemplify such a structure, we first take a look at colors. More specifically, we will learn how a color definition is passed through the semantic layers of a Design Tokens architecture—from the most abstract level of the color palette all the way up to the tangible level of a UI mapping. We start with plain values and after that, use aliases (mappings) to draw on lower-level definitions. Subsequently, we apply the same idea to border radii. Similarly, we start with an abstract, subatomic definition and specify increasingly semantic mappings. Now let's see what the corresponding SCSS would look like—switch between the two tabs to inspect both examples:
The following animation (fig. 1) illustrates how we can now make changes on various levels of our design system with ease. The three columns represent three individual design tokens and show how each of them affects the rendering of a simplified profile card component. (The animation is based on Example 2 but skips the first layer for clarity.) By changing the value for our default border-radius (red), we substantially change the look of our UI, as several higher-level tokens all reference the same root token. The lever gets shorter with each level, as we can see in the second column: Changing the button border-radius (blue) only affects the rendering of the two buttons in our example. And lastly, changing the call-to-action button border-radius—unsurprisingly—manipulates nothing but the one call-to-action button element in the example.
A structure as outlined above will not only prove more human-readable—it also provides us with levers to make changes through all layers of our design system without doing unintentional harm. And the way we map abstract values to tangible attributes creates semantic guardrails, making a design system based on Design Tokens self-governing to a certain degree. I.e., as a developer, I wouldn't just assign a color called "button color" to a text paragraph and instead, highlight a potential gap in the Design Tokens repository if the proper token appears to be missing.
The way we map abstract values to tangible attributes creates semantic guardrails, making a design system based on Design Tokens self-governing to a certain degree.
With the help of Design Tokens, we can genuinely embrace cross-functionality and collective ownership. Furthermore, they enable many other powerful concepts, such as A Steady Flow Truth and a flexible front-end architecture as outlined in Radical Modularity.
Gradually and naturally evolving the structures of an emergent design system may lead to clutter. Tidy up! guides the way to continuous improvement and an optimal design.
D. Kurfess
