Design DNA - A playbook for building systems that scale
Practical, example-driven design system building
Design debt is inevitable. You can delay it, ignore it, or patch over it. But sooner or later, it catches up. The only real way to keep it under control?
Think in systems. Design for scale.
And when I say “design systems,” I’m not just talking about the heavyweight, multi-layered setups you see at big companies. I mean “systems” in the truest sense - any structure that reduces debt, keeps things consistent, and lets you scale design without losing your sanity.
I want to start a new series on building design systems. I’m calling it Design DNA.
No, I’m not here to help you build the polished, enterprise-level systems you see in big companies with dedicated DS teams (I’d love to get there someday, though).
This is about practical systems you can create right in the middle of real product work. The kind that help you keep design debt in check, maintain quality, and grow without overcomplicating everything.
I want to talk about foundations that make a system work. Then I want to dig into how you can create your own Figma design system or UI kit from scratch, and maybe also how to get the most out of an existing UI kit if you don’t have the time (or budget) to build one from zero.
We’ll break down what goes into a design system, how it’s built, and why it’s worth your time even if your team is small, your deadlines are tight, and your files are already a little messy.
I want to write about all of this because they’re the kind of problems you and I are probably dealing with right now.
Why I’m writing this
Design DNA is my way of filling a gap I wish I had when I was starting out. Most design system content lives at the extremes:
At one end, there’s high-level theory that sounds nice but leaves you wondering where to start.
At the other, dense documentation for teams who already have DS engineers, governance models, and years of polish.
If you’re in the middle, building as you go, trying to ship product without drowning in inconsistencies, you’re mostly on your own.
I know, because I’ve been there.
That’s why I’m writing Design DNA. To share the wins, mistakes, and patterns I’ve learned along the way and to learn in public (especially around documentation and governance).
What to expect
Honestly, it’s still a little abstract right now. My plan is to start with the foundations (duh, obviously) tokens, color systems, typography, all the stuff that sets the stage. From there, I’ll probably move up to components, documentation, and governance (hopefully?).
I can’t promise perfect-world advice. But I can promise practical, example-driven guidance you can plug straight into your workflow. That, I’m confident about.
Cheers and see you on the other side of Design DNA 😃