Building a universal design system
How I turned multiple overlapping projects into one reusable system and cut future design time without sacrificing brand nuance.
Client
Multiple
Year
2024-2025
Scope
Challenge
In late 2024, our agency hit a good problem: too many new projects at once.
As the solo designer, I had to make a strategic decision about how to manage my time. Creating and maintaining separate UI libraries on top of designing features, attending meetings, and implementing revisions would force a trade-off: either rush and risk quality, or slow down and miss timelines.
My previous workflow included building a custom UI kit for each client. It worked for one-offs, but the team has already started experiencing friction with this approach:
Redundant effort: design and dev kept rebuilding the same patterns.
Hard to reuse across projects: even when a functionally identical component existed elsewhere, pulling it in wasn’t feasible, so we rebuilt it from scratch under time pressure.
Painful changes: a small tweak (like a color or spacing) required updating every instance of a component by hand.
Inaccurate handoff: without clear specs and guidelines, developers had to interpret designs, so Figma and production drifted.
No single source of truth: decisions lived in files and messages, and teams made different choices over time.
It was clear that repeating our old habits would only magnify these issues with the new workload. I realized I needed to stop thinking about individual projects and start building a single, universal system.
The challenge was to create a system that was flexible enough to adapt to different client brands, strict enough to enforce quality, and served as a single source of truth that was easy for developers to implement accurately.
Approach
Before I could get to my favorite part (making everything pretty), I needed a plan of action. This was my first time building a proper, reusable design system, so I started by mapping what “good” should look like for our context:
I started by studying giants like Carbon by IBM, Material Design System by Google, Attlasian Design System and many more, but their massive scale and only the final, polished version available to the public made them more inspiration than a practical guide.
The real breakthrough came when I shifted from studying what they built to how they built it, which lead me to discovery of Atomic Design and design tokens.
This gave me the perfect blueprint: Atomic Design provided the logic for building components, while tokens ensured the whole system could be flexible and scalable for future projects.
Here is how I organized everything using this principle, starting with the smallest pieces and building up:
How do I build a solid foundation that won't break later?
This system needed to work for multiple clients, where brand colors and fonts would always be different.
Here is where design tokens shine. I set up two layers: foundational “Primitives” (the raw values) and adaptable “Semantics” (the roles those values play). For color, that meant separating “what the color is” from “what it’s used for”, making it easy to re-brand without breaking designs.
During this step, I made sure to align the plans with the team to reduce any potential slowdowns. I sat down with our lead developer and we shaped spacing and naming to match their workflow. We adopted a simple 4‑point rhythm that can grow in small, predictable steps, so layouts stay consistent now and remain easy to extend later, with no rewrites, just additions.
Not every decision needed endless options. For things like borders, corner radii, and shadows, we chose a small, clear set ("T-shirt sizing", think XXS to XXL). Fewer choices meant faster builds and a more consistent look.
Typography followed the same principle: swap, don’t rebuild. The font family is a single variable, and sizes follow a steady scale tied to our grid, with sensible line heights so text reads well across brands.
The throughline: build with the team, keep the system lean on day one and add as you go by structuring the system in a way that future growth is painless (or as close to it as possible).
Building the component library: core principles
With the foundations set, it was time to build the components, the reusable building blocks of our system. I focused on a few core principles to guide the process.
Configurable base → faster builds
In order to reduce the system complexity, I built components to be configurable. By adjusting a few properties (likesize,state, orwithIcon), we could adapt a single base component for multiple needs. This saved significant design and development time.This approach also simplifies building new components. Here I show how fast a search bar component can be created: instead of making a brand‑new thing, I started from our input and adjusted the instance. Devs didn’t rebuild; they extended. We stayed visually consistent without slowing down.
(This is an ongoing learning process. Our team is still refining how we identify which elements should be globally reusable versus which are true one-offs, but this approach has been a huge win for simpler, foundational components.)
Nested components
Following Atomic Design, smaller "atoms" (like an icon or text label) were nested inside larger "organisms" (like a full button). This meant a change to a base component would instantly and safely update everywhere it was used across the entire system. It also made adding new variants simple: I could add an option to the base component without having to rebuild the larger, more complex ones.
Auto-layout for responsive behavior
Each component was built with Figma's Auto Layout to be inherently responsive. This ensured they would adapt well across different screen sizes.Tokens & variables
To bridge the design-to-code gap, I defined each component's internal structure using our foundational spatial tokens (e.g.,radius-sm,spacing-4). This created a clear contract for developers, and ensured the final build matched the design precisely.
Prototyping as a communication tool
I connected component variants to create interactive states (like hover and pressed) directly in Figma. This turned static designs into live demos, making design reviews with stakeholders faster, more intuitive, and left less room for ambiguity.
The rules that defined my thinking process and would allow us to scale was this: change a value, not the design; enforce consistency through structure; build from a single source of truth.
Theory meets practice: what I've learned along the way
While Atomic Design and other large systems provided the map, building it with my team taught me the practical lessons that made all the difference.
The “base” ships, the “mapped” explains
Initially, I designed complex components with specific, realistic data already applied. My lead developer quickly pointed out they first build the generic, "dumb" component, then connect it to data. We adopted this workflow: the library now provides the clean base component for developers, alongside a mapped example with realistic content for context and for usage in designs.
Keep families together to keep context
Splitting atoms and organisms into separate pages looked tidy but broke context. Tables and table cells live together now. Seeing the base next to the thing that uses it made inheritance obvious and updates easier.Show the backstage, reduce the guesswork
Many systems I studied hid documentation in separate docs. Looks clean, but in reality devs have to search for all the possible variants and tokens applied to a component, which takes a lot of time and opens a possibility of error. After communicating with the dev team and learning what information they need, I created specs and tokens sheets pinned beside each component. It drastically cut down on searching, reduced guesswork, and led to faster, more accurate implementation.Properties are tiny acts of architecture
This was one of my biggest lessons. Naming properties isn't just about labeling; it's about planning for the future. A generic property liketypecan quickly become ambiguous. I learned to think about future use cases and choose more precise, architectural names likeintent(e.g., destructive, confirm) orcontext(e.g., input, dropdown). This foresight meant new variants became simple additions, not painful rebuilds.
Impact & next steps
The design system is definitely still a work in progress, as we continue to fine-tune the process and further build it out. Even in its early stages, it has already transformed our workflow, delivering clear results based on direct feedback from the development team & clients.
🥳 Some wins:
Faster development - less time spent on coding new components
Efficient Handoff: The system acts as a single source of truth, requiring less explanation.
Reduced QA Cycles
True Consistency: the coded product is now a near-perfect match to the Figma designs
✅ Next steps:
Expand the Library: strategically build out more components, templates, and pages
Formalize Guidelines: Document "do's and don'ts", as well as page templates to ensure the system can be used independently as the team grows
Gather feedback from the end-users of our products to validate and iterate on the system's effectiveness
Tackling this as a solo designer was a daunting task, and I certainly made mistakes along the way. However, those challenges were my greatest teachers. This project taught me invaluable lessons in system architecture, the art of syncing design with development, and the importance of clear communication.
And after countless hours spent structuring variants and tokens, I can confidently say I became a Figma wizard in the process.
