Building a Scalable Design System
The team moved fast, but new features looked and behaved inconsistently, slowing development and duplicating design work.
I began exploring a scalable design system to build a clear, consistent, and accessible foundation.
Why this mattered
Design quality and consistency had become difficult to maintain as multiple teams shipped independently. Each project had its own Figma file, custom components, and conflicting styles, which slowed design velocity and increased implementation debt.
I was tasked with researching and defining the groundwork for a unified design system that could scale across projects, supports accessibility, and enables faster collaboration between design and development.
This work remained in the exploration and alignment stage, discussed with developers and PMs, but has not been yet implemented in production.
01.
Understanding the chaos
I began with an inventory across our current design system, documenting color, type, spacing, and interaction inconsistencies. Some of the discovery included:
Poor color contrast, missing or inconsistent accessibility patterns such focus order or keyboard navigation;
Hardcoded values in colors, spacing, or typography applied directly instead of using tokens or styles;
Spacing misalignment such as irregular paddings, margins, or grid gaps breaking visual rhythm;
Components recreated from scratch across projects;
Lack of documentation for usage or behavior.
This helped surface opportunities to consolidate redundant styles and identify accessibility gaps.
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 at the core
I started by reviewing the WCAG 2.1 AA guidelines and organizing the findings by category such as field components, color, and typography.
While some principles naturally overlap, this process helped clarify why and how UI elements should look and behave in specific ways.
Accessibility wasn’t treated as an afterthought. It was built into the system from the start. Among the first to be spotted and included in the design were:
Proper color contrast
Clear keyboard focus indicators
Distinct visual states
Logical screen reader label hierarchy
Descriptive labels
Clear copy
Working closely with engineers, I also explored how to embed ARIA roles and define consistent focus states within our design tokens.
Search field variations showing input states and icon alignment in a research repository form.
03.
Defining a scalable foundation
To scale effectively, I designed a token-based system abstracting visual values into semantic tokens for flexibility and governance.
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 hierarchy allowed us to theme products, support dark mode, and maintain parity between Figma and 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 modularity
Starting with Fields, one of our most complex components, I created a structured framework for reusability, such as:
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)
Standardizing their foundation aligned design and development while reducing redundancy.
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 scaling and governance.
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.
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.
Being the only designer meant wearing many hats: researcher, architect, builder, and advocate. The biggest realization was that the real work of a design system is not in Figma; it is in alignment, trust, and adoption.
A few lessons that shaped the outcome:
Start with the foundations. Tokens and naming conventions are the invisible glue.
Design for people, not just patterns. Collaboration across dev, QA, and PMs was what made it meaningful.
Make adoption easy. The simpler and friendlier it feels, the more people use it.
Keep it alive. A design system is never finished; it grows with the product.
If continued, my next focus areas would have been introducing automation between Figma tokens and code, and defining governance for long-term maintenance.
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.