You think building a design system is about components. It’s not. It’s about thinking clearly at scale.
When I joined Myxellia, the design files were chaotic.
Not broken, just… reactive. A button here, a modal there, reused when convenient, remade when not.
It wasn’t anyone’s fault.
This is what happens in fast-moving teams.
You prioritize shipping, and design becomes a series of one-off decisions, a kind of UI improv. But over time, it gets heavy. You feel it when design reviews take too long. When devs ask, “Is this the right version?” and you hesitate.
So I started asking a different kind of question:
“How might I design clarity into the system itself?”
Not just a library. Not a UI kit. A thinking tool for the whole team.
Phase 1: Order from Chaos
The first thing I did wasn’t glamorous.
I gathered every piece of UI we had from buttons to error states and looked for patterns.
What was consistent? What was duplicated? Where were we making the same decision… again and again?
Then I built a system based on variables: color, spacing, typography; all abstracted, all reusable.

That small move changed everything.
Now, I could switch between 4 modes from dark, dark green, dark blue to light theme in seconds. Adjust spacing across hundreds of components with a single tweak. I wasn’t designing faster, I was thinking faster.
Phase 2: Designing a System That Thinks
So I partnered with engineering early, rebuilt our system using ShadCN and Radix, and mapped every Figma variable to real code tokens, one source of truth, no guesswork.
But I also did something I hadn’t done before:
I treated the system like a living product.
I added documentation that updated as components changed.
A shared Storybook that showed usage patterns in real time.
A change log. A feedback loop. Even onboarding guides.
And suddenly, things started to click.
Designers weren’t asking “Can I use this?”
They were confidently shipping without asking.
Here’s what changed:
UI bugs dropped by 60%
Design-dev handoff became a breeze
New features shipped faster because we weren’t reinventing anything
We created products that felt cohesive even as the team scaled
But here’s the twist:
What I really built wasn’t a set of components. It was a decision-making engine.
A system where defaults were strong, choices were clear, and everything had a purpose.
I left behind documentation, patterns, and tools. But more importantly, I left behind a team that could move.
Because the truth is:

