Design Token Screenshots

From Inconsistency to Scalability: Building a Comprehensive Design Token System at Lotic.ai

Lotic Design System Case Study | đź“ŤProduct design at Lotic.ai

This case study explores how I built a comprehensive design token system by leveraging the newly introduced Figma Variable features to enhance its functionality and integration.

To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. All information in this case study is my own and does not necessarily reflect the views of Lotic.ai.

Context & my role

Lotic.ai is creating an ecosystem with various products, including Talk2Me App, Lotic Delta, Lotic Labs, and Lotic CMS, each featuring its own design library. The design team consists of six designers, none of whom are dedicated solely to managing the design system. Instead, each designer plays a role in collaboratively developing and refining the design system.

As more products continued to join the Lotic ecosystem, we increasingly noticed inconsistencies within the existing design system across different products. Such issues are common, particularly in a rapidly growing startup environment, but they pose a significant challenge to the scalability of the design system and its ability to accommodate new requests, such as multi-theme support. Recognizing these inconsistencies, I proposed to the leadership team that I take the lead on a project to address and resolve these design system issues. In this project, I served as the design lead, working closely with the Chief Architecture Officer, the engineering and the product team to find and implement solutions.

The problem

To understand the challenges faced by the design system, I conducted several rounds of interviews with the design, product, and engineering teams. Through these discussions, we identified the following problems:

- Inconsistency: The design system exhibits inconsistencies across various products, including:
    - Mixed use of hard-coded values (e.g., color hex codes) and Figma styles.
    - UI elements that do not align with the Lotic brand.

- Scalability: The design system struggles to scale effectively:
    - It cannot accommodate new requests, such as supporting multi-theme brands or light mode (the main app started with dark mode).
    - It struggles to integrate with new products.
    - It lacks support for testing purposes.

Pain point

These issues lead to several pain points:

- Design team: The current design system hampers the growth of the design team and their ability to collaborate effectively.
    - Onboarding new designers is time-consuming, and they often face confusion when creating new components.
    - The design team struggles to collaborate effectively due to the lack of a standard visual language, leading to inconsistent design outputs and inefficient workflows.

- Engineer team: The engineering team finds it difficult to implement components due to inconsistent styles.

- Product team: The product team faces challenges when creating tickets that specify requirements, due to the lack of a standardized design system.

Project goals

The primary goal of this project was to address the inconsistencies and scalability issues within the existing design system at Lotic.ai. Specifically, the objectives were to establish a unified design language across all products, streamline the integration of design tokens to support multi-theme and light mode functionalities (we started off by dark mode), and improve overall scalability to accommodate new products and future design requests.

Figma variables

In the summer of 2023, Figma introduced a new feature called Figma Variables in Config 2023. With the release of Config 2023, Figma Variables were officially launched, allowing users to store reusable values for various design properties and prototyping actions. Initially, it supports four types of values: color, number, string, and boolean. Additionally, it offers modes to facilitate multi-theme systems. Given these capabilities, I saw an opportune moment to leverage Figma Variables to address the design system's challenges.

Figma Variable Image
Figma Variable Type Image
Research

My research revealed that a well-implemented token system could address the issues we faced. To deepen my understanding, I studied established design systems from leading companies such as Salesforce, Amazon, Spotify, Intuit, Atlassian, and Bloomberg. My focus areas included:

🤔

· What design tokens are and their origins.
· The benefits of using design tokens.
· How other companies manage their design tokens.

Research Image
Research
The solution

When developing the token taxonomy, I adhered to the following principles:

🤔

- Clarity: Ensure that each token is clearly defined.
- Consistency: Maintain uniformity across platforms.
- Scalability: Design the system to be easily expandable.
- Semantic and Use Case-Oriented: Use naming conventions that reflect each token’s purpose in design.

By applying these principles, I created a token system that is intuitive and user-friendly.

Create an intuitive token taxonomy

The token system is structured into two levels: Primitive tokens and Component tokens.

Token Tructure Image

Given the current limitations of Figma Variables, we support the following types of tokens: color, spacing, and shape (such as corner radius).

Primitive tokens

Primitive Tokens are the foundational elements of the token system, each assigned specific values for various properties, such as colors, spacing, or shape. For instance, tokens might be labeled as "Primary 50," "Secondary 200," or "Tertiary 500." These labels provide a clear and consistent naming convention for these values without specifying their contextual use in design. This ensures that the tokens are easily referenced and applied across different design elements.

Primitive Tokens
Primitive tokens
Component tokens

Component Tokens bridge the gap between primitive tokens and their practical application in design. They link the fundamental values, such as "Primary 100," to specific design functions or elements, like "color-text-primary." This approach assigns context to the primitive values, making it clear how they should be used in different design scenarios. By defining tokens in this way, the system ensures consistency and clarity in how design properties are applied across various components.

Color tokens

In the primitive token collection, I assigned hard-coded values to names such as Primary.100: #C2CEFE. For the component tokens, I established a naming convention that clearly defines each token using the following structure: Category - Property - Item - Variant - State - Scale. This approach, ordered from the most generic to the most specific, aligns with industry standards revealed through my research.

Color Tokens
Shape tokens

The Shape token, especially the radius token, ensures consistency in defining the corner radius of components. In the primitive token collection, I used the T-shirt sizing method to categorize these tokens. For component tokens, the naming follows this structure: Category - Property - Item - Variant - State - Scale.

Shape Tokens
Spacing tokens

The spacing token ensures uniformity in defining the spacing both within and between components. In the primitive token collection, I adopted a scale from 1 to 24, with corresponding values ranging from 4 to 96 pixels. This approach provides a clear and consistent way to manage spacing sizes. For component tokens, the naming convention follows a structured format: Category - Property - Item - Variant - State - Scale.

Spacing Tokens
Thinking

When I was structuring the tokens, an engineer asked,

"Why do we need different levels of tokens? Can we just hard-code the values in component tokens?"

This question prompted me to reflect on the rationale behind the entire token system. There are several reasons for using multiple levels of tokens. First, primitive tokens provide a consistent foundation by defining basic values like colors and spacing in a centralized manner. This consistency ensures that design elements are uniformly applied across the system; Second, component tokens build on these primitive tokens by linking them to specific design functions and contexts, such as defining how a color is used for text or backgrounds. This layered approach enhances scalability, as changes to primitive tokens automatically propagate through component tokens, simplifying updates and maintaining coherence; Lastly, separating tokens into different levels allows for greater flexibility and adaptability in design, supporting various themes and design requirements without the need for hard-coding values directly into components.

Workshop to audit the all designs

After establishing the naming conventions for the primitive and component tokens, I organized a workshop with another designer to audit all the components in the design system. This workshop allowed us to review each component and map the tokens to their real-time application in the design. It also provided an opportunity to address and correct inconsistencies as we conducted the audit and mapping.

Workshop
Workshop
How it supports the multi-theme system

The token system also supports a multi-theme design system. With the introduction of Modes in Figma Variables, we can easily switch between different modes and themes by just dragging and dropping frames across various parent layers. When I was presenting this project to the entire company, I created a playful Barbie theme for our product, which brought a lot of laughs, especially since the Barbie movie was a summer hit.

Workshop
Different themes
Tested by design and engineer team

To ensure the token system's effectiveness, both the design and engineering teams conducted thorough testing. The design team used the tokens in various design scenarios to evaluate their applicability and consistency across different components. They tested how well the tokens integrated with existing design elements and verified that the system maintained visual coherence. Simultaneously, the engineering team implemented the tokens in the codebase to assess their functionality and ease of use. They ran tests to confirm that the tokens were correctly applied and that any updates or changes were reflected accurately in the user interface. Feedback from both teams was collected to identify and address any issues, leading to refinements that enhanced the overall robustness of the token system.

Handoff and implementation

I worked closely with the engineering team to implement the token system on the backend. To support their efforts, I created a detailed design specification that serves as a definitive reference for both engineers and designers using the design tokens. This document evolves alongside the token system. I also organized a presentation for the entire engineering team, including Lotic’s overseas team in Europe, where we reviewed and discussed the system and addressed their questions.

Throughout the implementation process, I frequently assisted with technical issues and responded to engineers' inquiries. Based on their feedback, we iterated on the token system to refine and improve it.

Presentation and team training

Once the token system was implemented, I introduced it to the entire company during our company-wide event known as Wed Show & Tells. The presentation was a success and generated significant interest in the design system. Additionally, I organized a series of training sessions for the design team to ensure they were well-acquainted with the new system and could effectively integrate it into their workflows.

Slack notes
Measuring the success

The design token system enabled the design team to maintain consistency and scalability across different platforms. It also facilitated the implementation of new requests, such as light mode and partnership branding themes, effectively supporting evolving design needs.

Learning

Building the design token system at Lotic.ai was a challenging yet rewarding experience. I learned that creating a comprehensive token system requires not just technical knowledge but also a deep understanding of the design needs and challenges faced by various teams. The iterative process of refining tokens based on feedback from both design and engineering teams highlighted the necessity of ongoing communication and collaboration.

Another significant learning was the value of thorough documentation and training. Providing a detailed design specification and conducting training sessions helped bridge the gap between design and implementation, ensuring that the token system was used consistently and effectively across the board.

Summary

Creating a comprehensive design token system is no easy task that requires careful consideration and a balance of strategic thinking, expertise, and collaboration. The challenge intensifies when the system must cater to diverse design needs and evolving requirements. Success in this endeavor involves integrating thoughtful planning with user-centered methodologies, including interviews, research, user testing, and workshops to ensure that the system is both effective and adaptable.

Parting words
I had the pleasure of working with Chuchu at Lotic.ai, where she consistently demonstrated her exceptional talent as a product designer and systems thinker. Chuchu was instrumental in managing and organizing our design system, ensuring every detail was captured and documented. Her initiative in taking on tasks and responsibilities was impressive.

Chuchu is not only detail-oriented but also highly collaborative. She worked well with both product and engineering teams, ensuring that everyone was aligned and that her design vision was effectively translated into engineering handoff artifacts. Her craft and curiosity made her a critical asset to the team.

From Deanna Glaze, Senior Director, UX and Design

Thank you for taking the time to read this case study. I’m happy to answer any questions or discuss further. Feel free to contact me via email or LinkedIn.

Back to Top