I took on the challenge of turning our growing unstructured Pattern Library into a solid, scalable Design System. My approach focused on:
Building a strong foundation: I used Figma variables to tokenize key UI elements, making them consistent and easier to manage.
Keeping design and dev in sync: Right from the start, I worked closely with frontend engineers to make sure our designs matched the live product.
As a result, we built a clean and consistent design system that reduced UI debt and supported our long-term growth. Collaborating closely with engineers also made the process smoother and more efficient.
UI Elements Tokenized
New Components
Reduction in Design Time
We started with local styles for color and typography, but as the product grew, they became a bottleneck. Scaling revealed the need for a more structured system to ensure consistency and efficiency.
Without tokens, every update had to be done manually across components. This slowed the process, increased inconsistencies, and made it harder to scale as new features were added.
To future-proof our product and ensure design consistency as we continued to expand, we needed to transition from local styles to Figma variables and tokens.
I knew building a design system was a big lift, so I started with the basics — tokenizing core UI elements like colours, typography and spacing to reduce redundancy and inconsistency.
With the release of Figma Variables, I ran a live demo to show how tokenization could streamline updates and boost efficiency. The team saw the value, and we kicked things off by implementing colour tokens first.
I started by auditing the product’s existing colour usage across both design files and code, uncovering inconsistencies and redundant values. To bring alignment, I developed a colour token system grounded in semantic naming.
Working with the frontend team, we first assigned Hex values to primitive tokens (e.g., #4D4BE7 → brand.500), then mapped them to semantic tokens (e.g., brand.500 → background.brand). We ensured the new naming conventions fit smoothly into existing frontend workflows without causing disruption.
The relationship between Hex value, primitive and semantic colours
The relationship between primitive and semantic colours
We decided on a naming structure that is simple but powerful. It's easy to learn and flexible enough to grow as the design system gets larger and more complex.
Naming structure for semantic colours
Examples of semantic colours used on a card
I approached spacing by using t-shirt sizing—tokens like XS, M, and 4XL mapped to pixel values. This made it easy to keep spacing consistent across padding, margins and layout gaps, making the interface more cohesive and easier to maintain.
Spacing options based on T-shirt sizing, with dropdown and card examples
Tackling a large design system can feel overwhelming, so I approached it one component at a time. I began by thoroughly refining the first component—ensuring all properties were correctly set, including variants, booleans, and instance swaps.
Dropdown component sheet with all interaction and list variants
I created detailed documentation covering its purpose and use cases, best practices, a component anatomy, and accessibility guidelines like colour contrast and compliance. Before moving forward, I synced with the team to confirm alignment, then repeated the process—scaling the system piece by piece.
Documentation sheet including component anatomy, variants and use cases
I implemented theme-aware tokens to support both light and dark modes, enabling smooth transitions between them.
Mode-specific variants: Each semantic colour has a corresponding version for light and dark themes, ensuring visual consistency across different backgrounds.
Contrast & accessibility testing: All colors were tested to meet WCAG contrast requirements in both modes.
Future-Ready: The system allows for future expansion, enabling adjustments for branding updates or additional themes.
I made sure every component was usable for everyone—not just some. That meant checking color contrast early, designing for keyboard navigation, and using tools like Stark and Able in Figma to audit as I built.
Example of WCAG 2.1 level AA colour contrast requirement
Avoiding the debt trap with regular check-ins
Leaving components untouched only compounds the mess. A design system isn’t a one-off—it’s a living thing that needs regular care. Things that helped us are:
Regular check-ins on the design system
Weekly syncs or open office hours with frontend devs
Keeping an eye on how components are being used and updated
Utilize Figma's full power and new tools
Figma Variables, AI-powered plugins, and advanced features have changed the game. Instead of sticking with old habits, tapping into these tools has helped me work faster, scale smarter, and create more clarity across teams.
