Your Design System Is Not a Project. That's the Problem.
EP01 — Most design systems don't fail because of bad components. They fail because of one thinking error. Here's what it is.
Every design system has a launch moment. A Figma file goes live. A launch email goes out with three exclamation points. And then — slowly, quietly — nothing happens.
Not a dramatic failure. Not a rejected proposal. Just a gradual accumulation of workarounds. Designers detaching instances. Engineers writing custom CSS. A component library that exists and a production codebase that tells a completely different story.
As expected — nobody filed a ticket for it.
This is not a tooling problem. It is a thinking problem. And the thinking problem has a name: the Project Mindset.
The Project Mindset Is Why Your System Rots
I once worked under a Director of Design who came from physical media. Print. Advertising. Decades of brand work where consistency meant a style guide, a color palette, and a set of rules printed in a PDF that lived on a shared drive.
When the idea of a design system came up, he was genuinely confused by the urgency. The corporate style guide already existed. It covered typography, color, logo usage. What exactly was missing?
What was missing was everything that happens after the PDF ends. Which, in digital, is everything.
Without his support, the design system had no mandate. And without a mandate, one of the largest product squads made a decision that was entirely rational given the circumstances. They stopped waiting. They built their own visual language — their own components, their own patterns, their own interpretation of what the brand should look like in a digital product.
By the time the product launched, it looked like it came from a different company than everything else in the portfolio. Because functionally, it did. The portfolio landing page looked like a Christmas tree — every product a different color, a different type scale, a different interpretation of what the brand meant in a digital context.
That wasn't a creative decision. That was the direct consequence of a style guide that ended where the PDF ended.
Nobody in that squad did anything wrong. They needed a system. No system arrived. So they built one.
That is the Project Mindset at the leadership level. Not malice. Not negligence. A fundamentally different definition of what "done" looks like — one that was correct for a different medium and catastrophically wrong for this one.
A project has a start date, a budget, and an end date. You build the components, hand them to engineering, and go back to your real work. That sequence makes complete sense for most deliverables.
It makes no sense for a design system.
Because a design system doesn't end when the components are built. The brand refreshes. A squad needs a complex table with sticky headers and mobile behavior nobody planned for. A new browser standard drops. An engineer asks why the documented component doesn't match what's in production. And because the project is over, nobody is left who knows the answer.
Not because anyone failed. Because nobody stayed. Those are different problems. Organizations are remarkably talented at confusing the two — especially in retrospectives.
The system rots. Not dramatically. Quietly. The way all neglected things do.
What Changes When You Treat It Like a Product
Products don't have end dates. They have lifecycles. Roadmaps. Versioning. Support queues. Most importantly — they have users.
When you treat your design system like an internal software product, the question changes. You stop asking "When will this be done?" and start asking "How is this solving our users' problems today?"
That shift sounds small. It isn't.
Your design system has users. Not just stakeholders. The moment you treat them like customers — everything changes.
You have three distinct user groups. They want completely different things.
Product Designers
They want speed and freedom. If your system is too rigid, they will detach your components and build it themselves. A high detach rate is not user preference. It is a product failure signal.
Front-End Developers
They don't care about your Figma file. They care about API surfaces, prop naming consistency, and accessibility built in. If your coded component is harder to implement than writing it from scratch, your product has failed them. That's a diagnostic, not an accusation.
Product Managers
PMs care about velocity. They control adoption budgets. If you can prove your system cuts sprint time by twenty percent, they won't just support it. They'll mandate it. Give them the number. Nothing else.
Your Value Proposition Is Not "Because Leadership Said So"
Every internal product needs a value proposition. Not a vision. A specific, measurable reason for a senior engineer who has spent five years writing custom React to use your Button component instead.
"Because leadership said so" is not a value proposition. It is the most common answer given in adoption conversations. Which is why adoption stalls at three percent. And stays there. Politely.
This is a value proposition:
"Our Button handles hover states, focus rings, dark mode, and screen reader aria labels automatically — saving you three hours of QA per sprint."
One sentence. Specific. Measurable. Worth switching for.
How to Start Measuring Like a Product Team
Open your Figma analytics. Go beyond insertion counts. Find the detach rate. If your Card component is detached eighty percent of the time, that is a product failure. Fix that use case.
Treat your documentation site like a landing page, not a storage closet. Connect analytics. Are developers searching for "modals," clicking your docs, and leaving in five seconds? That is a usability problem. Measure it the way you would measure a checkout flow.
Filter your bug tracker for UI-related issues. Compare the rate before and after a squad adopted the system. If adoption reduces UI defects by thirty percent, that number belongs in every roadmap conversation from this point forward.
The Quick Win: Write the Product Brief First
Before the next component. Before the next sprint. Write a one-page product brief.
Four things only:
- The problem statement — specific and observable, not aspirational
- The target personas — designers, developers, PMs, and what each one needs
- The core value proposition — one sentence per persona
- Three success metrics — measurable, not "teams seem happier"
Share it with your engineering lead. Ask them one question:
"Does this sound like a product you'd want to use?"
Their answer will tell you everything.
The Argument
Building a design system is the easy part. Getting people to use it is the job. And the job starts with a decision about what the system actually is.
"Without governance, without ownership, without infrastructure — you don't have a design system. You have optimism wearing components."
Optimism, for the record, is not a scaling strategy.
Disagree loudly. Inspire boldly.
And remind me — falsely if needed — that somewhere a design system is actually being used the way it was intended.
Which user group does your design system serve worst right now — designers, developers, or PMs?
Comments ()