Design Tokens- Future of Design Systems

Have you ever heard of this term before? Well if not, don’t worry. It is still a comparatively new term. I learned about it only a few months back and thought to document the learnings precisely and upto the point here. I hope you guys will enjoy the read.

Context

Through this case study, I hope to improve the overall understanding of design tokens for the readers. There are other articles, youtube videos on this topic out there too, but I always have found most of them confusing. So here’s my try to explain it in a more intelligible way.

Before diving into what exactly design tokens are, let us first look at some pain points we are facing currently.

Pain Points

• It's very challenging to maintain styles consistently and easy to understand across every device.
• For efficient communication between designers, developers, PMs, etc., all stakeholders should share a common understanding of design system foundations, its rules, guidelines, etc.
• The design system should be able to communicate to every team member how to use its several elements in different contexts effectively.
• Development effort is way too much when it comes to updating any hard-coded value and this takes time from other important projects.

These pain points can be solved efficiently. How?

Introducing Design tokens-

Design tokens are variables that are responsible for storing foundational design values (color, typography, spacing, shadows, animations, etc) that are needed to maintain a design system. And then the tokens are used in applications and libraries instead of hard-coded values to ensure flexibility and unity across all product experiences.

Example of design token in the real world-

Suppose your friend has a long name that is difficult to remember, then you try to give him a nickname. And you and your friend circle will refer to him with that easy nickname only.

Also, there can be more than one nickname according to his position, right? E.g.- Venkat Gopal Krishnan who we know as GK is the class topper as well as class monitor. So these two terms are also a nickname for Venkat Gopal Krishnan.

So whenever anyone calls GK, Class topper, or Class monitor, you know who they are referring to.

Got it? Now imagine that long name as a hard-coded color value and your friend circle as your team including designers, developers, and PMs.

Let’s consider the same thing with the design foundation file.
Let’s suppose there is a color (#DD4848). Hard to memorize? Give it a nickname- Red 300.

Now, where will this color be used? Suppose the designer decides it will be used as a Primary background and on the Secondary button. Then, he will name it as PRIMARY SURFACE and SECONDARY BUTTON respectively, and the team will share a common understanding this way and hence less confusion.

In this way, every style/decision can be given a nickname to be understood easily.

Now that you have a good understanding of how tokens can be helpful. Let me introduce what different kinds of tokens exist.
After studying several design systems, I can say that there are only 3 types of tokens. Although different design systems name them differently. But they have the same meaning. Personally, I love how google describes design tokens. So according to google, there are-

Reference tokens-

They usually point to a static value of any design decision such as a hex code for color or font and weight for type. Reference tokens can also point to other reference tokens; they do not change based on user or device contexts.

System tokens-

These are the decisions that systematize the design language for a specific theme or context.

System tokens define the purpose that a reference token serves in the UI.

When applying to the theme, a system token can point to different reference tokens depending on the context, such as a light or dark theme. System tokens should point to reference tokens rather than static values whenever possible.

Component tokens-

Component tokens represent the elements and values that comprise a component, such as containers, label text, icons, and states.

Whenever possible, component tokens should point to a system or reference token, rather than hard values such as hex codes.

While some component style choices won’t be expressed as a token, a token should be used whenever a design choice applies to multiple components with similar uses.

So why don't we just make one reference token for each style? It will be effortless and less complex. Why do we need to make system and component tokens? Let's understand by an example-

Consider you have made just a reference token for a style and applied it directly to use cases. And now you have to change it for one particular component. You cannot change it through a reference token otherwise every component style linked with that reference token will change. You will have to change it manually, wherever you have used that component. Then there is no point in making the token.

Now imagine you created a reference, system, and component tokens for a style and linked them like the image below.

Now if you want to change the style for any component, you just have to change the component token linked with it once and it will change at every place the component is used.

Nomenclature-

Now, how to apply the tokens to design foundational files so that the styles are easy to maintain, and how exactly should we name them? Well, looks like an easy job but let's think about it.

We have to name different tokens based on their usage for a better understanding of the whole team. There should be one system in which we name them and the team can refer to the system to understand or find their token.

So basically it depends on the design team what system they choose to name the tokens. Mostly, they are all same. And there is no perfect way to do this. Let’s see-

Google’s way of naming a token

As you can see, we can break down the complete token name into 3 parts-

1. All token names in a design system start with the system name, such as md for Material Design.
2. An abbreviation for the token type: ref is for reference tokens; sys is for system tokens; comp is for component tokens.
3. The token name ends with a descriptive name to communicate the token’s role.

For example how google and adobe name their design tokens

Above is a structure of how the tokens are linked according to the use cases. It gets more complicated as a design system upgrades. It's difficult to maintain but eases the other things like consistency in design decisions and less effort to the development team.

How does it help the development team? Let's see!!!

Till now, we know the design system can be well organized and easy to understand for teams by using design tokens.

Now, what if I want to change a particular hard-coded value? Let's see what happens currently-

Current Process-

Suppose the design team wants to update a typeface in the design system. Let’s see the current workflow-

This workflow suffers from several pitfalls:

1. The design team gets sad- The design team depends on the development team to see the core style updates. This slows down the design process.
2. The development team gets sad- Updating a typeface or color value in the codebase is not very time-consuming when you only have to update a single style variable. But doing this again and again for several components and also compromising to work on something valuable to the company really slows down the development process too.
3. Since companies often track project tasks with a task manager, this change would imply another ticket/task to deal with.
4. The time lost by the company also delays the go-to-market of its products.

This workflow can be optimized!

How Design tokens can help optimize?

Well, once we have made every style a token from a token generator. Our foundational file is easy to understand and use. The next thing would be to apply design tokens over components and finally transpile to platform-specific formats (custom variables, sass, XML…).

We bring our design logic closer to the development logic to be able to change code components from design in the future while reducing communication challenges that cause friction between both, the design and dev teams.

Tokens can be the link between the handoff from design to development and will lead to a less confused, more consistent, and efficient work team.

Process after Design tokens-

This would save a lot of time for the team and will ensure consistency and efficiency in design making both designers and developers happy.

Tools

Currently, there is no inbuilt functionality in Figma for generating design tokens. Although we can use some Figma plugins to do the work. There are not many tools that can generate design tokens to be directly linked with developers in their code. Some of them are-

1. Figma tokens
2. Zero height
3. Arcade

Conclusion

There is a lot more to tokens. They can be very complex when it comes to practically applying this knowledge to your design system. With every additional token, the complexity of the design system increases and thus increases the effort to maintain it.

This is a still a growing topic and we might see integrated functionality within Figma in the future to ease the maintenance of the design file and handovers to the developer.

And that’s a wrappppppp🥳! Thanks for reading guysss❤️!! I hope it was a helpful read✏️️.

💬 I am open to discussion on design tokens. If you have any questions on implementing, naming or documenting your design tokens, let me know in the comments. I would be happy to discuss.

⚡Hold on to the clap button a little longer if you liked this read⚡

Reach me out at rahulbhojwani154@gmail.com or connect via LinkedIn.