Challenge
- 700+ components
- Extensive duplication
- Multiple naming conventions
- No design-development parity
- Multi-theme support requirements
Outcome
- Reduced component count by 60%
- Established token architecture
- Unified component model
- Enabled multi-theme scalability
- Created a shared design-engineering language
Problem Statement
System Audit Findings
Teams were shipping the same component twice — once in Figma, once in code — and neither matched. The audit surfaced the patterns behind the noise.
01. Inconsistent UI across modules
02. Slow design handoff
03.Frequent component recreation
04. Theme implementation challenges
| AREA | ISSUE |
|---|---|
| Architecture | Components created by appearance rather than behavior |
| Design | Multiple masters representing same functionality |
| Engineering | No 1:1 mapping between design and code |
| Scalability | Themes required duplicated components |
| Governance | No ownership or contribution standards |
Approach & Ownership
The problem started as:
“Design feels inconsistent”
The library wasn’t organized by logic; it was organized by appearance. Three parallel systems coexisted — color-based, style-based, and state-based — each one expanding the surface area of the library without adding any new behavior.
I took ownership to transform this vague concern into a structured solution:
Audit & Quantify
Identify and measure duplication across the component library
Identify Structure
Define structural issues and what should exist vs be deprecated
Rebuild with Logic
Create a scalable system based on logic, not appearance
Key insight
- The introduction of multi-theme support revealed that the real problem wasn’t visual inconsistency — it was architectural dependency.
- The system was still organized around appearance-based values, which made themes reliant on duplicated components and manual overrides.
- This became the turning point from UI cleanup to system-driven design, where variables evolved from visual styling into semantic, scalable architecture.
The Shift
System Architecture
Core Design Principle
If structure and behavior remain the same, it should not be a new component.
I restructured the system into:
Structure
Components
Behavior
Variants
Styling
Tokens
Content
Slots
Before vs After
Before
- Color = Component
- State = Component
- Size = Component
- Icon = Component
After
- Color = token
- State = variant
- Size = variant
- Icon = slot
Early Challenges & Learnings
During the initial restructuring phase, variable declarations were organized primarily around direct visual values and isolated component usage. While this improved short-term organization, the approach became difficult to scale as the system expanded across reusable variants and theme requirements.
To solve this, the system evolved toward semantic variable architecture, where tokens represented purpose and behavior rather than raw visual appearance.
Token structure
Multi-Theme System
Approach
I separated: Primitive tokens (base values) and Semantic tokens (usage-based)
Primitive Tokens
brand-100 grey-500Semantic tokens
bg-button-primary text-primaryDeclaring Semantic tokens with primitive tokens to support multi-theme
Why this matters
- No duplicate components for themes
- Easy updates without redesign
- Scalable theming across modules
- Aligns with engineering implementation
Component Deep Dive — Button
Quantifying what “inconsistent” actually meant.
1 Base Component with controlled properties:
Type Primary secondary Ghost
Size sm md lg
State default hover disabled
Icon none left right both
Key Decisions
Sizes
Fixed rules for spacing, typography, icon size. Removed manual resizing.
Variants
Based on purpose, not appearance. Destructive = intent, not new component.
States
Embedded inside component. Removed separate state components.
Slots
Leading icon, Label, Trailing icon.
Eliminated multiple button types into 1 unified component
Design ↔ Dev
The biggest unlock came from making the Figma model resemble the code model. Same vocabulary, same defaults, same mental model.
Before
No clear mapping between design and code
After
Code
<Button
variant="primary"
size="md"
loading
iconLeft
/>Figma Properties
- variant: primary
- size: md
- loading: true
- iconLeft: true
Impact
Before
- — Fragmented system
- — Duplicate components
- — Dev inconsistencies
After
- — Single source of truth
- — Predictable usage
- — Faster design & development
60%
Component Reduction
Reduced from 180+ to ~55 components40%
Design Time
Faster component selection2x
Dev Handoff
Faster implementation cyclesOutcome
Scaling the system
The system was designed to scale through constraints, not extensions. New modules reuse existing components; new needs are absorbed by tokens, not new masters.
Flexibility vs. Consistency
I deliberately reduced visual freedom to prevent system fragmentation. Designers pushed back early — six weeks later they were faster.
Design vs. Engineering reality
The system mirrors how engineers actually compose components — props, slots, tokens — not how designers like to draw.
What could break
RISK 01 Detached instances drifting back into custom components
RISK 02 Discipline-dependent: structure alone won’t save a culture without reviews
RISK 03 Variant explosion if intent + state are added without governance
This wasn’t reducing components. It was a shift from appearance-based design to logic-based system design.
I focused on standardizing structure, behavior, and tokens — while leaving room for flexibility in layout, content, and edge cases. That balance is what makes a system usable at scale, and it’s the lens I now bring to every product surface I design.