26/04/2026
12 months ago, Radix had what many SaaS products quietly live with - a Frankenstein.
Different patterns, mixed components, and several design approaches stitched together over the years.
Nothing was broken, but nothing was scalable either.
Radix is an MDM platform managing large fleets of remote devices.
The product surface continues to expand, and eventually, the UI foundation must catch up.
So we decided to introduce a robust design system.
Not a Figma library, but a system that designers and engineers could actually use together.
◆ Choosing the system
We didn’t spend months debating.
The tech team and I spent a day reviewing several options.
I audited the Figma side, and developers looked at the code.
The criteria were simple:
→ Rich component library
→ Real code implementation
→ Tokenized structure
→ Active maintenance and support
→ Good documentation quality
→ Compatibility with our tech stack
We landed on PrimeNG because it fit Radix’s stack and came with a mature component ecosystem.
◆ How we rolled it out
We didn’t try to “fix” the entire product.
Instead, we made one rule: every new screen must use the new design system, both in design and in development, with no exceptions and no quick fixes.
And the product gradually evolves forward instead of trying to rebuild everything at once.
◆ My role
My main job wasn’t designing components.
It was making the system real for the team and ensuring it was actually used.
I took ownership of the transition:
▸ Running workshops with developers
▸ Walking through tokens and components in Figma
▸ Explaining how components map to PrimeNG
▸ Answering questions and guiding implementation
▸ Supporting real use cases during development
▸ Making sure adoption actually happens
About five developers started working with the system directly.
Once everyone understood how the pieces fit together, collaboration became dramatically smoother.
◆ What changed
Two things happened quickly.
Speed increased, because designing new screens became mostly composition and much less reinvention.
Consistency started appearing, and the UI stopped drifting in random directions.
◆ Important detail
The product is still a Frankenstein.
But now we have something much better:
↳ A clear path forward
↳ A shared system across teams
↳ A scalable UI foundation
↳ Real components in production
↳ Tokens driving consistency
↳ A structure that supports growth
A path to turn Frankenstein into Robocop.
Every new feature moves the product closer to a coherent system.
◆ One thing designers misunderstand about design systems
A design system is not a design asset.
It’s infrastructure.
When the system is shared between design and engineering, tokenized, and backed by real components, both designers and developers move faster, handoff becomes smoother, and the product scales without UI chaos.
That’s when a design system stops being a Figma file…
…and starts becoming part of the product architecture.
