Design systems. They're so hot right now. The new designer drug of the product world. Everyone's huffing 'em up like it's the second coming of Helvetica. Slick, shiny, and full of promise. And yeah, when used right, they're damn near miraculous. A holy relic passed down from the gods to bless your product with consistency and order.
But beware the zealots.
Because the more these systems are idolized, the more susceptible they become to being twisted into bureaucratic beasts by pixel-fascists who think every button and breadcrumb must bow to The System. These folks don't want to ship products; they want total control.
In this warped world, the design system isn't seen as a guide, but as gospel. It's a tyrant in a turtleneck, barking orders from a high tower of components. Step out of line? Use a 9px margin where The Law says 8? Boom. Screaming tantrum. Excommunication. No mercy. Just swift and brutal retribution in the name of consistency.
Sure, it's all a bit melodramatic, but the damage is real. This dogmatic nonsense doesn't create harmony; it breeds resentment. It turns curious designers into bitter, rule-shackled husks who'd rather torch the whole system than play design-by-numbers. And honestly? Who could blame them?
Guidance Over Gospel Top
Let's get one thing straight. A design system isn't a product. It's infrastructure. Like power lines or plumbing. Invisible when it works, and catastrophic when it doesn't. A living, breathing catalog of bits and pieces, built not to be worshipped, but to serve. And if your system starts demanding fealty like some deranged deity? Burn it down.
Because here's the real gospel. The system serves the people, not the other way around. This isn't a friggin cult. Designers and engineers are not foot soldiers goose-stepping in perfect grid alignment under the banner of Component Tyranny. The moment you forget that—the second the system starts prescribing rigid doctrine instead of offering helpful, flexible guidance—you've lost the plot.
They're called guidelines for a reason, friend. Not rules. Not commandments. Systems are fluid. Products evolve. Teams shift. Dogma dies. What a good design system should do is channel the collective voice of the people who use it; those wild-eyed product designers out on the frontlines, ideating through the chaos, pushing pixels through the fog. Let their philosophy shape the system, not the other way around.
There are plenty of designers who've been shackled to systems that forgot what they were built for. Systems so rigid, so suffocatingly prescriptive, they strangle the very creativity they were meant to empower. Innovation? Sacrificed on the altar of consistency. Designers forced to sand down brilliant ideas just to squeeze them through some pre-approved, lifeless pattern. All in the name of “alignment.” All in the name of the system.
Well, guess what. If your design team has to lower the quality of their work just to appease the System Gods, then your system has failed. Spectacularly. It's failed your team, and more importantly, it's failed your users; the actual humans your product was supposed to help in the first place.
Consistency is fine. Consistency is helpful. But consistency is not sacred.
The real north star, the only one worth following, is how well your product solves real problems for real people. That's it. That's the whole deal.
And if you believe that, then you've gotta accept the next truth too. Your design system is a product of your product. It should live by the same creed. Serve the same mission. Evolve with the same urgency. If it can't adapt to meet the product's needs—if it values internal order over external impact—then it's not a system worth keeping. It's just a glorified straitjacket with a nice Figma cover.
Who Does The Designing Top
So who, then, should design the artifacts that your system curates?
Simple. Your product designers. The ones with their boots on the ground. The ones talking to users and scraping insight out of the daily grind. They're the ones who know the stakes. They see the friction. They're closest to your users. And because of that, they're the only ones truly equipped to solve their problems.
Relying on system designers to solve product problems in a vacuum, disconnected from context, divorced from need, is how you end up with an immaculate, pristine, completely useless library. Buttons for problems no one has. Toggles built for theoretical futures. Disaster disguised as discipline.
Now sure, product designers can't always design every single element. That's not scalable, especially when you're bootstrapping a system from scratch, or your entire team is... well... you. Sometimes, yeah, things need to be defined in the system first. That's fine. As long as there's a feedback loop. Validation is the secret sauce. Without it, you're just designing on vibes and prayers.
But make no mistake. The healthiest, fastest-moving systems aren't ones where system teams churn out fresh components like they're on some kind of speed bender. They move fast because they extend what already works. They evolve. They adapt. They collaborate. The real velocity comes from building smarter, tighter, more in-tune with reality.
Let the product designers lead. Let the system respond. That's how you keep it alive. That's how you stay in fifth.
System designers, to be clear, are no slouches. We're talking about wizards of reusability; stewards of scale. They take the raw, battle-worn elements forged by product designers and turn them into durable, extensible assets that can live across teams, products, and platforms. That kind of work demands a different level of focus. One tuned to the finest details; principles, properties, states, documentation, and other invisible machinery that makes things work at scale.
While product designers are solving problems in the wild, system designers are behind the curtain, refining those solutions into patterns that others can pick up and run with. They're not there to dictate from on high. They're there to standardize, extend, and elevate. To make good ideas repeatable. To ensure that one team's success can ripple through the entire ecosystem without reinventing the wheel every damn time.
And here's the real beauty. It's a loop. A living, breathing feedback machine. Standardized assets flow back into product work, speeding things up, reinforcing what works, and giving teams a stronger foundation to push even further. That's the dream, right? A system that doesn't slow anyone down. It lifts them up, makes them faster, better, wilder. Freedom through efficiency, man. The flexibility to produce better results by using components in unexpected ways. Not a cage. A launchpad.
"Going Rogue" Can Actually Be Good Top
The terrifying and beautiful truth of product design is that, we don't always know what we don't know. Sometimes, what seems like a perfect, airtight component turns out to be a trap; completely blind to some critical use case or edge scenario no one saw coming. And you only find those cracks when someone colors outside the lines. Sometimes, the only way to uncover what's missing is to let someone break the damn rules.
Now, I'm not saying open the floodgates and let every designer go full cowboy. This isn't a call for design anarchy or some Figma free-for-all. But systems must allow for a degree of rogueness; controlled rebellion. That little bit of give in the gears is what keeps a system alive. Flexibility isn't optional; it's essential. If your system can't bend, it breaks.
Sure, guardrails are important. They're what keep things coherent, safe, sane. But those rails shouldn't be written in some detached, authoritarian tone. They should come from within. They should reflect the product design team's own standards, their own philosophies. Not some abstract, top-down doctrine imposed by a system team in a vacuum.
The system isn't there to invent new rules. It's there to help uphold and amplify the right ones. The ones forged in the fire of actual product work.
Because in the end, the best systems don't control creativity. They unleash it; safely, smartly, and with just enough space for the unexpected to sneak in.
A functional system isn't static. It's not a museum of pristine components frozen in time. It's fluid; learning, evolving, growing alongside the teams it's meant to support. The moment you lock it down, and tell your product designers they can only use what already exists, you've effectively sealed its fate. You've chosen preservation over progress. Congratulations, you're now maintaining the status quo in a world that refuses to sit still. Good luck with that.
That's fine, I guess, if your product is perfect. But let's be real. If your product were perfect, you wouldn't need a system at all. You wouldn't need design. You wouldn't need anything. You could just sit back and watch the download numbers climb while angels sing from your app store reviews. But I don't think that's the world you live in.
In the real world, iteration is the game. Discovery is the fuel. And that means making space for flexibility. Even when it costs you a little consistency up front. Because that flexibility? That's how you learn. That's how your system grows stronger. It uncovers new use cases, fresh ideas, unexpected edge cases; the raw material of progress. It gives designers the freedom to poke holes, push limits, and in doing so, make the system better.
And here's the kicker. When designers feel like they have room to move, when they know the system won't bite their hand the moment they try something new, they're more likely to use it. Adoption goes up. Collaboration increases. And guess what? So does consistency. Not from rigidity, but from usage.
A flexible system breeds loyalty. A rigid one breeds resentment. So loosen the grip. Let the system breathe. That's how you build something that actually lasts.
When To Dial It Back Top
Of course, let's not go full nihilist here. If everything's loose and free and beautifully chaotic, then congrats. You're back where you started: no system, just vibes. A jungle of mismatched components and improvised workflows, where every team reinvents the wheel and calls it innovation. Flexibility is powerful, but it needs a spine. You introduce it methodically, not recklessly.
So, here's where it makes sense to hold the line; to stay a little rigid, not for the sake of control, but for the sake of clarity:
- Naming conventions
Especially at the semantic level, names matter. They carry meaning. Subtle, shared, and incredibly useful when it works. Take design tokens, for example. These aren't just cute variables. They're signals. They tell designers and developers when, where, and why something should be used. Break that meaning, and you've introduced ambiguity. Change a name too often, and you've now got broken code, regression hell, and endless reversioning just to figure out whether "primary-700" is the same as what used to be "brand-dark." This isn't rigidity for rigidity's sake. It's discipline that protects scalability. - Foundational processes
Stuff like handoff, product inventories, design QA; these are the backbones of cross-functional design. And yes, different teams might prefer different flavors. But at the system level, choosing one consistent approach actually enhances flexibility in the long run. Why? Because now everyone's speaking the same damn language. The guardrails are clear, the expectations are set, and suddenly, you're not wasting time translating between teams. You're building faster, smarter, together.
Draw Your Own Map Top
Look, I've spent a lot of words here ranting and raving about what your system should and shouldn't do. But don't get it twisted. These are just words. Observations. One guy's field notes from the trenches.
Reject all dogmas. Burn the rulebooks.
Because the only “right” system is the one that works for your team, in your context. If that means bending every principle we just talked about into a pretzel to serve your product better? Hell yes, do it. The point of all this isn't to create some pristine, theoretical utopia of perfectly nested components. It's to make better things for real people.
And if your system isn't working? If it's slowing people down, or causing friction, or gathering dust on a Notion page nobody opens anymore? Then maybe something in these words will help you shake it loose. Maybe not. Either way, you already know what you need to do.
Just don't forget why you built a system in the first place. Don't lose sight of the real mission. Why does your product exist? Who is it helping? That's the true north. That's the thing that cuts through all the process noise and tool debates and over-documented madness.
Keep your eyes on that, and the rest will figure itself out.