June 16, 2025
June 16, 2025
June 16, 2025
The Museum Effect: Why Your Expensive Design System is Gathering Dust
Most design systems launch with a party and die in silence. It’s usually not because the components are ugly, but because the system feels more like a prison than a toolkit. Here is how to fix the rot.
Most design systems launch with a party and die in silence. It’s usually not because the components are ugly, but because the system feels more like a prison than a toolkit. Here is how to fix the rot.
I see the same tragedy play out in almost every organization. A team spends six months building a "perfect" design system. They name it something cool like "Polaris" or "Nebula." They launch it with a big Town Hall presentation. Everyone claps. And then, six months later, I open the codebase and see five different shades of blue and three different date pickers. The system didn't fail because the buttons were ugly. It failed because it was treated like a museum exhibit instead of a toolbox.
Let’s look at the five most common mistakes and how to avoid them. The issue is rarely the algorithm itself—it’s how the technology is framed, introduced, and measured.
1. You Built a Prison, Not a Playground
The number one reason developers ignore a design system is that it is too rigid. I’ve seen systems where changing the padding on a card requires a three-week approval process from a "Governance Committee."
That is insanity.
If your system makes it harder to ship code than to hack it, people will hack it. Every time. We often over-engineer these systems in a quest for consistency, locking down every prop and variable until the component is useless for anything other than the specific use case it was originally built for. A good system needs to be flexible. It should handle 80% of the use cases and get out of the way for the weird 20%. If you try to police everything, you end up governing nothing.
2. The "Source of Truth" Lie
Designers love to say, "Figma is the source of truth." No, it isn't. The browser is the source of truth.
There is often a massive drift between what is in the design file and what is in the React repository. The designer updates a toggle switch in Figma, but nobody tells the engineering team. Two months pass. Now the design team is using Version 2.0, and the dev team is using Version 1.0, and they are literally speaking different languages. If your system doesn't have a synchronized pipeline—where a change in design triggers a ticket or a conversation in engineering—it’s not a system. It’s just a sticker sheet.
3. It’s Too Hard to Find Things
You might have the best documentation in the world, but if I have to click through four layers of navigation to find the "Secondary Button Hover State," I’m not going to do it. I’m just going to guess.
We often structure documentation the way we structure our files, not the way people work. We categorize things by "Atoms" and "Molecules" because we read a book about Atomic Design once. But a developer isn't looking for a "Molecule." They are looking for "How do I make a list?" Your documentation needs to be search-first. It needs to be ugly and fast. If it takes longer to find the component than to build it from scratch, you have lost the battle.
4. You Forgot the Marketing
This is the part nobody talks about. A design system is a product. Your internal teams are your customers. And just like any product, you have to sell it.
You can't just drop a link in Slack and walk away. You have to do the roadshow. You have to sit with the engineers and show them how this saves them time. You have to show the PMs that using the system means they can ship features two days faster. If you don't articulate the value proposition, the team sees the system as "extra homework." You need to change the narrative from "You have to use this" to "You get to use this."
The right metrics build trust, because they tie AI to real business improvements.
5. It Stopped Breathing
The moment you publish "Version 1.0" is usually the moment the system starts dying. Teams often treat a design system as a project with a deadline. They finish it, high-five, and move on to the next feature. But software is a living thing. New needs emerge. New patterns are invented.
If there is no dedicated team—or at least a dedicated human—whose job it is to water the plants, weed the garden, and prune the dead branches, the system will rot. It needs maintenance. It needs to evolve. If users (your team) submit a bug or a request and they hear silence for three weeks, they stop trusting the system. And once trust is gone, it never comes back.
I see the same tragedy play out in almost every organization. A team spends six months building a "perfect" design system. They name it something cool like "Polaris" or "Nebula." They launch it with a big Town Hall presentation. Everyone claps. And then, six months later, I open the codebase and see five different shades of blue and three different date pickers. The system didn't fail because the buttons were ugly. It failed because it was treated like a museum exhibit instead of a toolbox.
Let’s look at the five most common mistakes and how to avoid them. The issue is rarely the algorithm itself—it’s how the technology is framed, introduced, and measured.
1. You Built a Prison, Not a Playground
The number one reason developers ignore a design system is that it is too rigid. I’ve seen systems where changing the padding on a card requires a three-week approval process from a "Governance Committee."
That is insanity.
If your system makes it harder to ship code than to hack it, people will hack it. Every time. We often over-engineer these systems in a quest for consistency, locking down every prop and variable until the component is useless for anything other than the specific use case it was originally built for. A good system needs to be flexible. It should handle 80% of the use cases and get out of the way for the weird 20%. If you try to police everything, you end up governing nothing.
2. The "Source of Truth" Lie
Designers love to say, "Figma is the source of truth." No, it isn't. The browser is the source of truth.
There is often a massive drift between what is in the design file and what is in the React repository. The designer updates a toggle switch in Figma, but nobody tells the engineering team. Two months pass. Now the design team is using Version 2.0, and the dev team is using Version 1.0, and they are literally speaking different languages. If your system doesn't have a synchronized pipeline—where a change in design triggers a ticket or a conversation in engineering—it’s not a system. It’s just a sticker sheet.
3. It’s Too Hard to Find Things
You might have the best documentation in the world, but if I have to click through four layers of navigation to find the "Secondary Button Hover State," I’m not going to do it. I’m just going to guess.
We often structure documentation the way we structure our files, not the way people work. We categorize things by "Atoms" and "Molecules" because we read a book about Atomic Design once. But a developer isn't looking for a "Molecule." They are looking for "How do I make a list?" Your documentation needs to be search-first. It needs to be ugly and fast. If it takes longer to find the component than to build it from scratch, you have lost the battle.
4. You Forgot the Marketing
This is the part nobody talks about. A design system is a product. Your internal teams are your customers. And just like any product, you have to sell it.
You can't just drop a link in Slack and walk away. You have to do the roadshow. You have to sit with the engineers and show them how this saves them time. You have to show the PMs that using the system means they can ship features two days faster. If you don't articulate the value proposition, the team sees the system as "extra homework." You need to change the narrative from "You have to use this" to "You get to use this."
The right metrics build trust, because they tie AI to real business improvements.
5. It Stopped Breathing
The moment you publish "Version 1.0" is usually the moment the system starts dying. Teams often treat a design system as a project with a deadline. They finish it, high-five, and move on to the next feature. But software is a living thing. New needs emerge. New patterns are invented.
If there is no dedicated team—or at least a dedicated human—whose job it is to water the plants, weed the garden, and prune the dead branches, the system will rot. It needs maintenance. It needs to evolve. If users (your team) submit a bug or a request and they hear silence for three weeks, they stop trusting the system. And once trust is gone, it never comes back.
