Building a Scalable Design System
Why this mattered
As multiple teams shipped independently, design quality suffered. Every project had its own Figma file, custom components, and conflicting styles, slowing velocity and creating technical debt.
I was tasked with building the foundation for a unified design system that could scale across projects, support accessibility, and enable faster design-to-dev collaboration.
While not yet in production, this work established a system projected to reduce component build time, standardize accessibility, and create a shared design language.
My role & approach
As the sole Product Designer, I led this initiative from research through documentation, working together with engineers to build alignment around a unified approach. My responsibilities included:
Conducting the initial audit and making the case for systematic change
Driving alignment across engineering, product, and QA on token architecture and naming conventions
Defining the accessibility standards and component framework
Creating comprehensive documentation to enable future adoption
The biggest challenge was advocating for this work without dedicated engineering resources. I focused on creating thorough documentation and design specs that could serve as a blueprint when implementation became feasible.
01.
Understanding the chaos
I began by taking inventory of what we actually had documenting every color, type scale, spacing value, and interaction pattern across our products. What I found wasn't pretty.
Poor color contrast throughout. Accessibility patterns like focus order and keyboard navigation were either missing or inconsistent. Colors, spacing, and typography were hardcoded everywhere. No tokens, no systematic approach. Spacing felt arbitrary: irregular paddings and margins that broke any sense of visual rhythm.
Components were being recreated from scratch for every new project. There was no documentation explaining how anything should be used or why it behaved a certain way.
This audit became the foundation for understanding where we could consolidate and where we had critical accessibility gaps that needed immediate attention. I documented over 47 unique color values, 12 different spacing scales, and 23 component variations that could be consolidated into 6 systematic patterns.
Annotated UI mockup showing inconsistencies in a design system. The interface includes a color palette, text fields, list items, and buttons, with callouts highlighting issues such as incomplete palette, vague error text, low color contrast, unclear hierarchy, icon inconsistency, unclear button priority, and ambiguous button or link distinction.
02.
Accessibility from day one
I started with WCAG 2.1 AA guidelines, organizing findings by category: components, color, typography. While some principles naturally overlapped, this process clarified not just what our UI should look like, but why certain elements needed to behave in specific ways.
I made a decision early: accessibility wouldn't be an afterthought. It would be built into the system from the beginning. The first priorities became clear:
Proper color contrast across all elements
Clear keyboard focus indicators
Distinct visual states that communicate meaning
Logical screen reader label hierarchy
Descriptive labels
Clear copy
Working closely with engineers, I explored how to embed ARIA roles and define consistent focus states directly within our design tokens making accessibility part of the infrastructure, not something added later.
Search field showing various elements being focused.
03.
Defining a scalable foundation
To scale effectively, I designed a token-based system that abstracted visual values into semantic layers. This gave us flexibility and governance. The hierarchy worked like this:
Core tokens (e.g. color-blue-500, font-family-base);
Alias tokens (e.g. color-text-default, spacing-md);
Component tokens (e.g. button-bg-default, field-border-error).
This structure would allow us to theme products, support dark mode, and maintain parity between what designers built in Figma and what developers implemented in code.
Comparison of design tokens and their code implementation. The first panel lists core, alias, and component tokens such as color-grey-300, color-border-default, and input-border-hover. The second panel shows corresponding CSS variable definitions using alias and component token mappings.
04.
Designing for reusability
I chose to start with Fields, one of our most complex components. Instead of designing individual instances, I created a structured framework:
Variants
Input · Search · Select · Datepicker · Autocomplete · Password
Properties
Label · Placeholder · Value · Hint · Counter · Required · Icon · Background · Border
States
Default · Hover · Focus · Active · Error · Inactive (Empty & Filled)
This framework standardized the foundation across design and development, eliminating the need to rebuild something for every project.
Showcase of field variants with different types, properties, and states.
05.
Documentation & governance
I outlined documentation guidelines in Figma and GoogleDocs, including:
A Figma library for design tokens and components;
Usage guidelines (Do / Don’t, anatomy diagrams, naming conventions).
While implementation is still underway, the design and documentation provide a clear blueprint for how the system should scale and who should govern it moving forward.
What came out of it
The design system’s foundations are in place, including:
A shared Figma library with 30+ token-driven components;
An accessible base palette meeting WCAG AA;
A documented naming and structure system aligning with dev variables;
A roadmap for adoption and contribution.
Feedback from early design reviews emphasized improved clarity, reusability, and design-to-dev alignment.
Before and after comparison showing improved visual consistency and error messaging after applying design tokens on various UI components.
Looking back
This project was as much about discovery as it was about design. It clarified what the team would need to successfully adopt a design system in the future. The biggest realization was that the real work of a design system is not in Figma; it is in alignment and trust.
Start with the foundations. Tokens and naming conventions are the invisible glue. Investing time here meant everything built on top would be more flexible and maintainable.
Make adoption easy. The simpler and friendlier it feels, the more people trust it and use it.
Advocate relentlessly, but adapt to reality. Not having engineering resources was frustrating, but focusing on documentation and incremental adoption kept the work alive and positioned it for future success.
Governance matters from day one. I initially assumed the system would be self-maintaining. In reality, someone needs to own decisions about contributions, versioning, and evolution.
That’s my story. What’s yours?
Design systems can sound dry on paper, but for me this was all about making life easier for the team (and honestly, for myself too!). If you’re into talking tokens, naming conventions, or simply geek out about design, let’s connect.