Design System Rebuild
Led a 2-year design system rebuild for a scaling SaaS team — cut design-dev communication cycles by 60% and built a shared component library in Figma.
Timeline
2021 to 2023 - 2 years
Team
Product Team: Suki, Jack, Winky, Me, Front-end Team: 3+
MY RoLE
Led the rebuild of the Design System from audit to rollout
Defined component structure, naming rules, and usage patterns
Managed documentation in ZeroHeight and coordinated with Storybook implementation
Hosted bi-weekly syncs and onboarded new designers into the system
Overview
As the product and team scaled, we ran into UI inconsistencies and repeated miscommunication between design and engineering. Components were often duplicated, usage rules were unclear, and designs across the product lacked consistency.
To address this, I initiated a Design System rebuild with my supervisor, securing strong support from the CEO and Front-end Lead. We later expanded the design team to 4 members, and together created a modular, scalable system that improved consistency, accelerated delivery, and strengthened the design–dev workflow.
Challenge
Keeping the team aligned
As new designers joined, different habits and design logic made consistency hard to maintain.Making design decisions under disagreement
Opinions often differed on visual details, and I needed to turn subjective debates into clear, shared decisions.Balancing UX, development effort, and business needs
Custom feature requests from leadership had to be balanced against engineering cost and delivery timelines.
Discovery
When I joined the project, the design workflow was fragmented.
The Figma file contained redundant components with unclear usage, making it hard to tell which version was correct.
Developers frequently needed clarification on spacing, button types, and component behavior, slowing down implementation.
New designers struggled to identify the right source to follow, leading to delays and visual inconsistency.
Over time, it became clear that the core problem was not visual inconsistency, but the absence of a shared source of truth. Instead of treating this as a cleanup task, I reframed it as a system problem and led the team to build a design foundation that aligned designers, developers, and stakeholders around the same playbook.
Solution
Before scaling the system, I first rebuilt the foundation. I reviewed existing UI components, grouped them by function, and cleaned up duplicates so the team could work from a clear baseline instead of accumulating more design debt.
Next, I aligned early with the CEO and front-end team to focus on the most critical components first. We agreed on structure, naming, and behavior upfront, which helped designs move into implementation smoothly and reduced rework later.
To keep everything consistent, I created a single source of truth for finalized components and usage guidelines. This made design decisions easy to reference, helped new team members onboard faster, and reduced back-and-forth across teams.
As the team grew, I focused on scaling ownership instead of control. Responsibilities were shared, changes were reviewed regularly, and quality stayed high without turning the system into a bottleneck.
Impact
Reduced design–dev back-and-forth by 60%, measured through Slack history and fewer live meetings.
Developers shifted focus from spacing details to functionality discussions.
Internal teams (CS, Accounting) noted the UI was more polished and intuitive.
Established a reusable, consistent, and scalable design foundation for the company.
What I’d Do Next
To scale the system further, I’d introduce design tokens for colors, spacing, and typography. This would streamline handoffs, reduce repetitive updates, and allow the team to adapt UI themes or branding changes more efficiently across platforms.
