ROLE
TEAM
Platforms
TIMELINE
400+
Faster Delivery
Tokenized
The Process
From auditing existing components to defining token structures and documenting everything in Storybook, every step aimed to bring structure, scalability, and clarity.
Component & Color Audit
From auditing existing components to defining token structures and documenting everything in Storybook, every step aimed to bring structure, scalability, and clarity.
Audit Results (Current State)
No design system — no shared tokens, docs, or naming
Same component, different styling — badges rendered differently per module
Weak type hierarchy — headings and body blur together
Inconsistent paddings — spacing varies across screens
Input patterns not defined — labels, help text, and states differ
Redundant copy — headings repeat descriptions
Color inconsistencies — multiple near-identical blues/greys
Strategic Approach (Next Steps)
Unify components — single source of truth for badges, buttons, inputs
Type scale & roles — H1/H2/H3, body, caption with tokenized ramps
Spacing tokens — 4/8-pt scale applied across layouts and components
Input spec — label/help/error patterns + focus/disabled states
Content rules — concise headings, one-line descriptions, tone guide
Color tokens — swatches → foundations (text/bg/icon/stroke/link)
Storybook + Figma tokens — documented, versioned, theme-ready
Defining Colors & Token Architecture
After the audit, the first step was to define a scalable token architecture to serve as the foundation for all future components.
The goal was to create clarity, reusability, and adaptability across themes and projects.
We identified four key layers in the system:
Some Design Trade-offs & Technical Decisions
Key decisions that balanced design quality, performance, and development effort.
Alpha Colors vs Solid Colors
Me
Sometimes I want to achieve softer contrast without adding new colors. Adjusting the opacity gives me that subtle balance without bloating the palette.
Frontend
Alpha values don’t translate well in code. They break consistency in HSL tokens and impact rendering performance.
Resolution
We aligned on using solid, tokenized colors instead. It kept the visual balance designers wanted while improving performance and consistency in implementation.
Full Responsiveness → Desktop-First Layout
Me
We should make the product responsive so layouts adapt on smaller screens.
Frontend & Product Managers
Most users are on large monitors. Full responsiveness will delay releases and break complex tables.
Resolution
We agreed to focus on a desktop-first system, supporting breakpoints at 1024 px (tablet) and 1920 px (desktop). Screens sizes below 1024px were excluded in the scope.
Storybook Documentation
Components were documented in Storybook, enabling other teams to reuse, theme, and adapt quickly. The shared library allowed seamless alignment between design and development.
Some Components Showcase
Selected components showing how the system came to life in real use.
Learnings & Next Steps
Understanding how existing platforms handle cluster import and management to inform platform's first iteration of multi-cluster design.
Reflections
Design systems are definitely not for the faint of heart. Doing it solo sometimes feels like brewing Polyjuice Potion without all the right ingredients… You mix, test, and just hope nothing explodes.
It takes time, patience, and more trial and error than I’d like to admit. What I’ve built isn’t perfect, but it’s solid. It’s evolving, breathing, and working, which already feels like a small miracle.
I’ve realized there’s no one right way to build a design system. Every company does it differently. You experiment, talk to developers, test ideas, break a few things, fix them again, and repeat. The real goal is simple: create a shared language between design and development that actually works.
If I had more time, I’d revisit how we can simplify tokens, tighten naming conventions, and better document how each component behaves in the wild. But for now, I’m proud of how far it’s come. This isn’t just a library of buttons and colors. It’s a foundation built on persistence, curiosity, caffeine, and maybe a touch of wizardry.
What Worked
Token foundation: Establishing base tokens early gave structure and consistency across components and themes.
Design audit approach: Starting with a visual and structural audit revealed quick wins and patterns to unify first.
Collaboration with frontend: Working closely with engineers helped align design decisions with technical realities and performance needs.
What I'd Do Differently
Deeper prototyping: I’d invest more time in interaction prototypes to validate design patterns faster with developers.
Simplify token structure: I’d revisit how tokens scale, merge similar ones, and improve naming for easier maintenance.
Earlier documentation: I’d document edge cases during design rather than after handoff — it saves time and avoids confusion later.
More design-to-dev testing: Running small handoff tests mid-way could catch inconsistencies before implementation.