Ten years ago, we weren’t really building design systems. We were just sharing files and hoping people copied the right button.
Five years ago, we got variants and thought, “Finally! Some structure.”
Three years ago, we started replacing those variants with tokens and variables. Cleaner. Smarter. Less duplication.
And now, post-Config 2025, we’ve got smarter grids, quietly powerful if you’re juggling multiple brands, breakpoints, or component libraries.
In short: design systems have grown up. They’re more manageable, more robust, and easier to scale than they’ve ever been.
But all that flexibility comes at a cost.
If you’re running a system with serious surface area, you’re not just maintaining a sticker sheet. You’re managing a living product. One that gets disrupted every time Figma updates their sidebar.
The upside? Your system is getting stronger. The downside? So is the complexity of keeping it aligned.
Here are some of my thoughts around what it takes to keep a design system stable when the tools beneath it never stop evolving.
Isn’t a design system just following best practice?
A designer asked me that once. Totally earnestly. They weren’t being difficult; they just didn’t see why a whole team was needed to maintain one.
And a few years ago? Fair question.
Back then, design systems were mostly about consistency. Buttons, spacing, type. Making sure everyone used the same dropdown and didn’t butcher the grid.
But now?
Now systems are powered by tokens, variables, modes and responsive logic. The designers building them are working more like developers. They’re not just keeping things tidy. They’re thinking ahead: how this will scale, how it’ll flex, what Figma’s next update might break.
My priorities are:
- Designers still need to follow the system. No hacks, no overrides.
- You need team maturity. Knowing when to build from scratch, when to reuse, when to ask.
- But designers also need room to explore. If someone’s spending more time worrying about system rules than solving the actual problem, something’s not working.
And that’s exactly why specialist system teams matter. To turn good, one-off ideas into reusable patterns. To clean things up after the exploration, so the whole team moves faster next time.
Figma isn’t static, and neither is the system I’m building
Even when things feel pretty solid, I’ve learned not to get too comfortable. Not because someone’s broken the system, but because the tools keep moving underneath it.
What felt like a clever solution six months ago can suddenly feel outdated overnight. Keeping up without constantly tearing things down takes a bit of foresight and a lot of flexibility.
For me, that’s meant building the system knowing full well I’ll have to change parts of it later.
A few principles that have helped:
- I use semantic tokens wherever possible (spacing-md, surface-elevated), as they simplify global changes down the line.
- I keep components modular. If changing a dropdown breaks four cards, that’s on me, not the designer.
- I avoid “hero” variants that try to solve every possible state or layout in one. They look impressive but they’re fragile. And they rarely hold up for long.
- I don’t assume the current structure is final. Design for change. It’s always easier when you’ve planned for it.
When the system evolves, I bring the team with it
You’ve just refactored a bunch of components, cleaned up the spacing tokens, rebuilt the grid with the latest Figma updates… It feels like progress.
And then someone clones an old file and drops in the 2022 footer like nothing changed.
It’s not sabotage. It’s not even laziness. Most of the time, they just didn’t know. Or maybe they heard something vague in Slack but didn’t catch the detail, and definitely didn’t open the Confluence link.
I’ve learned not to rely on announcements. What works better is making the learning part of the system itself:
- I leave short notes in component descriptions, especially if something’s changed or simplified.
- I embed Loom links directly in Figma. Just quick explainers, what’s new, when to use it, why it’s better.
- I encourage the use of playgrounds. Draft files where people can drag, play, and see the component in context, not in isolation.
- I use sticky notes in the canvas like quiet nudges:“Updated version – one less variant, simpler layout logic.”
If the only way someone hears about an update is by accident, it’s not really part of the system.
And if people have to rely on second-hand info, it’s not adoption, it’s guesswork.
Documentation helps, but it’s never been enough
Even with all the in-system guidance, sometimes people need more than a note or a Loom. Especially when they’re under pressure or deep in a complex flow. That’s when they fall back on what they’ve used before.
So I’ve stopped relying on documentation as the main source of truth. I still keep it updated, but I’ve found that being visible matters more. What’s worked better for me is staying present and keeping the system visible in the day-to-day:
- I join early design reviews so system thinking is part of the work from the start.
- I offer to pair when something’s unclear or new, not to police but to unblock.
- Regular showcases have proven to inform teams and capture feedback, leading to stronger adoption.
- Figma training isn’t optional. I keep teams up to speed with quick videos, lightweight docs, and group sessions. Better tools don’t help if no one knows how to use them.
At one point, we ran monthly design showcases across a 30+ person team. Every month, designers would walk through the work they were shipping. What changed. What they tried. What they learned.
It was more than just a nice moment of connection, it was the perfect slot to demo design system updates in context. You’re not just announcing “we’ve updated the button group,” you’re showing it live, in use, in a real feature someone’s shipping.
That kind of visibility sticks.
It turns passive listeners into active adopters because they’ve seen it, they’ve heard the rationale, and they know exactly where to find it.
So yes, I’ll keep the documentation up to date. But for me, adoption happens through relationships, not release notes.
When I update, I try to clean up after myself
It’s easy to get caught up in the next shiny thing. Refactor the button, rebuild the grid, rework the layout logic. And I’ve definitely gone down that rabbit hole.
But over time, I’ve realised: if I don’t clean up what’s left behind, I’m just creating confusion for everyone else. Old components stick around. Outdated patterns linger in files. And suddenly, no one’s sure what’s safe to use anymore.
Now, when I replace something in the system, I try to:
- Mark the old stuff clearly –
deprecated/,old/, etc.- and include a scheduled date of removal. - Unpublish it from the library once it’s safe to do so.
- Leave a trail (usually a quick note or update board) so people can trace the change if they need to.
It’s not exciting work, but it makes a difference. Because if the library starts feeling cluttered or unreliable, people stop trusting it.
Manage Change Like a Product
At scale, system updates need more than just cleanup, they need structured process. Here’s what I’ve found helps:
- Staging libraries: I test big changes in a separate playground before pushing them live. It gives space to stress-test and collect early feedback. This is where Figma Branching is a powerful feature and often underused.
- Versioning: When changes are significant, I publish updated components (
Card v2,Grid v2) alongside existing ones, with clear naming and a deprecation plan. - Figma Changelogs: Add changelogs, update notes, and usage guidance directly in Figma, on the canvas, in descriptions, or pinned comments. If it’s not where people work, it won’t get seen.
- Make rollback easy: I don’t delete components immediately. I unpublish them with plenty of warning, keep a labelled reference in the system for a transition period, then remove them once I’m confident nothing depends on them (Figma’s “Used in files”) panel.
Do we need to adopt updates on day 1?
Figma releases a new feature and the instinct is: “We should use this.”
Just because Figma ships something new doesn’t mean your system needs it right now. In large-scale systems, early adoption can cause more churn than value. Especially when it triggers mass refactors without clear upside.
So I’ve learned to be deliberate.
How I evaluate new Figma features
Before adopting anything, I run it through a quick framework:
| Criteria | Questions to Ask |
|---|---|
| Value | Does it solve an actual pain point? Will it reduce maintenance or duplication? |
| Impact | How far does this reach? Three components or three hundred? |
| Risk | Could it break layouts or visual consistency? What’s the risk to legacy files? |
| Scalability | Will this help us scale better across themes, brands, or breakpoints? |
| Adoption | How much learning is required? Will it slow the team down before it helps them? |
Based on this, I’ll usually tag updates as:
- ✅ Adopt now: High value, low risk. Easy win.
- ⏳ Wait and watch: Promising, but still unclear or not yet mature.
- ❌ Ignore (for now): High disruption, low reward—or simply not needed.
Stable systems > shiny features
In design systems, stability builds trust. If everything’s changing all the time, no one knows what’s safe to use. That’s when people start cloning old files or rebuilding their own buttons “just in case.”
So I adopt with intent.
Because being early is great, but being reliable is better.
Adoption takes time. That’s normal.
System designers are often early adopters.
We’re testing new features the week they drop, thinking three steps ahead, designing for scale.
But the rest of the team? They’re solving real problems right now. Their priority isn’t tokens, it’s getting the work out.
So don’t expect instant adoption. Don’t get frustrated when people keep using the old components. Design maturity takes time.
The job isn’t just to build better components.
It’s to support people as they learn to use them.
To make the system feel useful, not overwhelming.
To be consistent, but not rigid. Evolving, but not chaotic.
Because design systems aren’t just about consistency anymore.
They’re about velocity. Autonomy. Thinking at scale.
And to get there, we need to stop thinking in atoms and molecules and start thinking in behaviours, outcomes, and orchestrated systems.
If you get that balance right, your system won’t just survive the next Figma update.
It’ll make your team faster, calmer, and more confident.
Which, let’s be honest, is the point.