My role:
UI/UX designer (core team of 2)
Timeline:
5+ months (ongoing)
Scope:
System-wide update
The Product Design System update was a logical and necessary step in implementing the latest color system changes at the company. My colleague and I considered this process a greater option than just updating colors — to modernize and strengthen the entire design system.
At first, we took this on as a side initiative, but later — after company leadership recognized the impact of our work — it became a formal priority. Over 5 months, we have been working intensively to enhance the design system. The core updates are complete, but our efforts are still underway.
The design system provides a solid foundation. At the same time, it has to be adaptive enough to meet the requirements of the fast-growing products. To find out the gaps, the research process was divided into 2 major stages — assessing the current system state and exploring the best industry practices:
Evaluating existing design system
System &
component
audit
Usage
analysis
Team
feedback
Accessibility
check
Industry & competitor research
Tokenization
best
practices
Component
architecture
review
Color
system
application
Documentation
strategies
These research insights helped to shape the plan focused on key objectives and accessibility as a guiding principle:
Establish a clear token hierarchy for typography, measurements, and color.
Integrate the recently developed organization-wide color system to all UI elements.
Update existing components and map them to design tokens.
Introduce new components according to product requirements and input from the team.
After defining these objectives, the next step was to deal with the implementation challenges.
*Design tokens are small reusable values stored as Figma variables.
Hierarchical token structure is the basis for the consistent and scalable design system. For this reason, a 4-level framework was applied within 3 key groups — color, typography, and measurements.
A good way to visualize this is as a tree, where each level builds upon the one beneath it:
Primitives (level 1 - roots). The foundation of the system — these are raw values such as specific color hex codes, font sizes, and spacing units.
Alias (level 2 - trunk). The intermediate level that assigns meaningful, semantic names to primitive values for easier reference.
Mapped (level 3 - branches). Defines specific mappings based on UI needs.
Component (level 4 - leaves). The final stage, where tokens are applied directly to UI components.
Level 1
Level 2
At level 3 (mapped) the real difficulty began as I aimed to build a universal system that would be clear, scalable, and universally applicable to all UI components. Considering the complexity and multiple approaches, I came up with a structure that categorized colors into state-based groups, each with 3 core parts:
Text
Container
Border
This categorization mirrors the fundamental structure of UI components and eliminates guesswork for designers.
The video below demonstrates this structure:
Level 3
The hierarchical structure, applied to the colors, expanded to typography and measurements. The tokens started at level 1 as raw values and were grouped into well-defined groups at level 3. Since the typography and measurements were simpler than the colors, levels 2 and 3 had the same structure to preserve a unified system.
Additionally, at level 3, I introduced effect tokens, which combine numerical values (such as blur, spread, and opacity) and color. This made the process of building, modifying, and keeping all styles consistent much easier.
Initially, we considered introducing level 4 for even greater refinement. However, implementing it upfront would have significantly extended timelines. We decided to keep the process efficient and establish level 3 as the solid base. Level 4 is still in the pipeline and will be executed once the new design system is fully in place.
This third-level-based token framework helps intuitively find and apply the right properties to components.
Beyond clarity and consistency, accessibility was a key consideration throughout the token implementation. This included WCAG-compliant color contrast and typography settings optimized for clarity across all sizes.
The following step involved converting tokens into styles to be easily and consistently used by the team. In this way, I created text styles, effect styles, and color styles.
Styles act as an easy-to-use layer on top of the variable system. The layer lets the designers apply predefined values and not deal with each variable manually. These variables serve as the detailed building blocks underneath.
For example, text styles reference specific variables for font family, weight, size, line height, and letter spacing. In the same way, effect styles pull in individual variables for blur, spread, color, and position.
Since styles are linked to variables, updates made at any level cascade automatically through the system, instantly reflecting across all levels, styles, and into components.
Text styles
Effect styles
We revised every component, mapping each detail to tokens and refining their structure. This created a more flexible and scalable system.
In addition to the token integration, we focused on missing states, sizes, and functional enhancements with accessibility compliance in mind. Some components required small adjustments, while others were completely rebuilt to accommodate evolving needs. The previous design system referenced Material 2 and included many company-specific components. Material 3 transition was therefore a balance between adopting its principles and preserving the unique flows and visual identity of our product.
What initially seemed like a simple update quickly turned into a larger effort, with every component revealing more areas for improvement. As the scope expanded, 2 team members joined this initiative.
The Chips component is one example of such processes. The following image shows the transformation from the original form into a fully tokenized, structured design. Similar updates were made to the entire component library.
Before
After
We added several company-specific components to strengthen the design system. In particular, data tables are one of the most highly requested.
Data tables were widely used across the team but lacked consistency. Each designer had their version. So I took the initiative to provide a standardization and create a unified data table component.
Since most of our data tables share a similar structure, I designed a master component with 3 key parts: header, columns, and pagination. To make it suitable for all scenarios, I first analyzed the existing tables in various designs, identified common patterns, and established a single, cohesive structure and style.
The final data table component is presented in the video below:
From the beginning, I was capturing the foundation of our design system, including its structure, logic, and how tokens transitioned between defined levels.
My documentation covered several types of records, such as:
Token tables specifying accessibility standards and naming conventions.
Component and style descriptions explaining purpose and key styling details.
Canvas annotations with additional notes and short usage guidelines.
Layout, spacing, and anatomy details, handled through the EightShapes Specs plugin.
Rebuilding the design system requires continuous work, but our team has already built a solid foundation — the token hierarchy, dozens of refined components, introduced variables, and well-structured styles. While long-term results are still unfolding, these numbers reflect the foundational work completed so far:
4
level token hierarchy established
59
components refined/built
119
unique variables implemented
182
styles created
The design system includes 25 published user-facing components (with 367 variants), supported by 34 hidden building block components (with 371 variants) — for a total of 59 components and 738 variants.
Besides the numbers, early assessments show the system has produced immediate improvements in the following areas:
Consistency: every team member now works within the same framework, which leaves no room for individual interpretations and keeps designs aligned.
Efficiency: design workflows have become faster, as unnecessary revisions and repetitive work are reduced. Designers can dedicate more time to creative tasks.
Scalability: the system remains flexible as tokens adapt effortlessly to new requirements.
Accessibility: inclusive design principles shape every aspect of the system (from foundational elements to interactions) to meet WCAG standards.
The key idea is to provide detailed instructions to the designers. While some sessions have already been conducted, additional training opportunities remain. Successful implementation requires practice.
For this, I will lead workshops and hands-on training sessions, on which I will focus on component usage in Figma. The initiative will ensure designers apply system components correctly and efficiently, while also helping me strengthen my public speaking skills.
Although testing is ongoing, it is vital to ensure components perform effectively across all possible use cases. Earlier, I created the documentation describing the technical side (system implementation, structure, and logic).
The next step is creating Best Practices Documentation to prioritize real-world applications, workflows, and usability guidelines. It would be a practical guide for designers to use the system efficiently.
To gain real-time insights into the design system impact, we are planning to implement Componly. The tool will measure how often components are used, where inconsistencies arise, and how effectively the system supports design workflows. This data will guide future refinements and help improve overall efficiency.
At first, Level 4 tokens were planned, but due to time constraints, we proceeded by referencing values from Level 3.
In the future, fully implemented Level 4 will offer full control over the system:
System-wide changes could be handled at Level 1 or 2.
Global design updates affecting multiple components could be performed at Level 3.
Component-specific adjustments could be managed at Level 4 (it will allow targeted refinements without affecting unrelated elements).
The final result will probably look like this:
Level 4
The company plans to bring it all to life not only in Figma and transition the system from design to production. For this, developers, engineers, and other contributors will be united into a dedicated implementation team responsible for building the design system in code.
Designers, including me, will act as stakeholders and remain closely involved throughout the process — reviewing implementation progress, validating accuracy, and ensuring alignment with the design system’s structure and intent.
Leading this initiative was a transformative experience, significantly strengthening my systems thinking, problem-solving, and skills in cross-team collaboration.
Deep research and planning were essential stages to tailor the appropriate approach. Although none of the token frameworks I analyzed fully addressed our unique challenges, extensive research helped me to uncover best practices for our design system.
A design system is not only about the people building it — it is shaped by everyone who interacts with it. We built the new design system almost from scratch. And collaboration was key to success here, as everyone brought different perspectives. This way, the new design system became well-structured and aligned with the team's needs.
Through training sessions with designers, I realized that building the system is only half the work — the real challenge (and reward) lies in helping others use it effectively. These sessions have also become a source of continuous feedback, highlighting areas for refinement and reinforcing the value of iteration. And the fact that the developers have already started to bring everything to life in code is another acknowledgment of my work.
