Simplifying token management for the OmniDS design system
Tokens are hard to manage, especially on a large scale. Read how I led the process of creating and managing the OmniDS token system at Omnipresent.
Background
Read how I helped create Omnipresent's design system from scratch.

A design system is a collection of reusable components, principles, and patterns guided by clear standards that can be assembled to build a variety of applications. Design systems can vary in complexity, but one constant factor is the importance of effectively managing and streamlining the process of changing and updating them. Without a proper method to easily manage and update a design system, one of the most significant reasons for having a design system, which is scalability, is compromised, that where token management system comes in.
Problem
Figma, unfortunately, lacked the necessary system to accommodate token references, a crucial component in constructing a scalable design system. We required a more nuanced solution, particularly a system that would enable us to seamlessly transfer any changes made in Figma directly to our codebase. As we began laying the groundwork for our design system in Omnipresent, we soon realized that if we desired a streamlined approach to managing and updating our design system, Figma would not suffice.
Our needs
While conducting our research and planning for the design system, we had a clear understanding of the necessary complexity required to establish a foundation for scalability. Token referencing played a significant role in our design system implementation.

For instance, within our design system, we had global colours such as [grey_100], which could be referenced by colour categories like [background], which in turn could be referenced by specific types like [page_background], [modal_background], and so on. This approach allowed us to easily modify the colours of all backgrounds across our platforms and design files by simply adjusting the value of [grey_100]. Additionally, we could modify all references to the [background] token by directing it to [grey_400], for example.

The image below illustrates the level of complexity required for our design system.
token referencing
Design system complexity diagram. Image gotten from Lukas Opperman
Before delving into the tools we use for managing the tokens, it was crucial for us to establish a naming convention for our design system.
Naming convention
I took the lead in this endeavour, which involved extensively researching existing design systems and conducting thorough desk research to determine the most suitable approach for our project. I conducted numerous explorations, tested various ideas, and, most importantly, collaborated closely with the engineers who would be responsible for building the backend of the design system.
naming convention exploration
Some of my early exploration for the naming convention of button colour tokens
After numerous explorations and collaborative testing with engineers, we ultimately arrived at a token naming system structure that provided us with sufficient flexibility to make changes and updates over time. This structure allowed us to modify and reference tokens at different levels, precisely aligning with our initial goals.
naming convention
The final naming convention structure.
Token management
Deciding on a suitable naming convention was one aspect of the task, but finding an efficient way to manage the token system proved to be more challenging. Right from the beginning, we aimed to provide designers with the capability to easily change and update tokens directly from Figma and push them to GitHub without requiring assistance from engineers.

Over a span of three months, while concurrently working on other aspects of the design system, both the engineers and I explored various options for token management. These ranged from attempting to develop a custom solution to considering third-party alternatives. Eventually, we discovered a Figma plugin called "Figma Tokens," now known as "Tokens Studio" that proved to be a suitable choice for managing the design system. With this setup, we could create and modify tokens directly within Figma, and the plugin seamlessly transformed them into a JSON file that could be effortlessly pushed to GitHub, all directly from the Figma interface. This streamlined our workflow and greatly simplified the process of updating the design system.
token studio
Managing our tokens with Token Studio
Token JSON
JSON file generated by Token Studio that can be pushed to GitHub directly form Figma
Component tokens
With the token naming convention and token system management now finalized, I began the task of creating tokens for all the components that had been designed by the entire product design team. My responsibility was to take these components, assign the appropriate tokens to them, or create new tokens if necessary, and then pass them on to the engineers for development. Essentially, I had to review each and every component to ensure that the correct tokens were applied to them.

This was an ongoing process that I carried out every time we wanted to add a new component to the design system.
tokens
The tokens I created for Buttons and Icons with their description, names and references
Conclusion
The process of creating and managing tokens in a design system is an ongoing effort. As the brand evolves and new components are added, there will always be updates to be made. Although setting up these systems can be challenging and complex, they are essential for seamless scalability. In my experience, dedicating sufficient time to establish these systems eventually saved us a considerable amount of time when we needed to make updates to the brand colours or other design elements.