Role
Team
Timeline
Solo Designer
Product
6 months
WCAG 2.1 AA
compliance achieved across components
30+ components
built by a token-driven system
Why this mattered
As teams shipped features independently, the product quality was suffering. Every project launched with its own custom-built components, conflicting styles, and component behavior.
We needed a unified design system that could scale across projects, standardize accessibility, and enable faster design-to-dev collaboration.
My role & approach
As the sole Designer, I led this project from start to finish, working closely with engineers to get everyone on the same page. Here's what I did:
Audited what we had and explained why a system update will benefit
Agreed with the team on the design token structure and naming rules
Set accessibility standards and created the component framework
Drafted clear documentation so people can refer to it
Design process
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 did I find? Poor color contrast throughout. Accessibility patterns like focus order and keyboard navigation were either missing or inconsistent. Colors, spacing, and typography were hardcoded in some places. No systematic approach. Spacing felt arbitrary: irregular paddings and margins that broke any sense of visual rhythm.
Some components were being recreated from scratch. There was no documentation explaining how anything should be used or why it behaved a certain way.
Annotated UI mockup showing inconsistencies in a design system. Includes color palette, text fields, list items, and buttons, with callouts highlighting issues such as incomplete color palette, vague error text, low color contrast, unclear hierarchy, icon inconsistency, unclear button priority, and other.
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. The first priorities became clear:
Proper color contrast across all elements
Clear keyboard focus indicators
Distinct visual states that communicate meaning
Logical headings 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. 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 is built in Figma and what developers implemented in code.
Brainstorm sketch of design token hierarchy with flowcharts, color swatches, wireframes, and handwritten notes figuring out the structure.
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, which include:
A Figma library for design tokens and components;
Usage guidelines (Do / Don’t, anatomy diagrams, naming conventions).
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 (hint: they need to trust the system).
Start with the foundation. What do we currently have? What do we need? 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 (actually) use it.
Governance matters from day one. It's easy to assume the system would be self-maintaining. In reality, someone needs to own decisions about contributions, versioning, and evolution. That someone can be anyone, if the system is simple enough.
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.