I once walked into a project for a mid-sized SaaS company that had spent roughly $50k on a high-end design system. They had the Storybook, the Figma tokens, and a dedicated Slack channel. On paper, it was perfect. But here’s the kicker: the dev team was still shipping “one-off” CSS files for every new WooCommerce feature. Total nightmare. They had the sustainable design system culture of a wild west startup, despite having the artifacts of an enterprise.
My first thought? I’ll just be the enforcement officer. I set up strict linting rules in their CI/CD pipeline and even wrote a custom CLI tool to block any Pull Request that didn’t strictly use the system’s utility classes. And yeah, it “worked” for about a week—until a critical checkout bug needed a hotfix, and the devs just used !important everywhere to bypass my blocks because they didn’t have time to “learn the system.” Not good. I realized I was trying to solve a cultural problem with a technical hammer.
Why Your Design System is Collecting Dust
As Ben Callahan points out in his research, culture isn’t just the donuts you buy for the office or the mission statement on your wall. It’s the “basic underlying assumptions” of your team. In my case, the team’s assumption was: “Using the design system makes my job harder and slower.” You can have the best CSS architecture in the world, but if your devs feel like they’re fighting it, they will win by breaking it. Period.
To fix this, we had to move from “enforcing” to “integrating.” We needed to align the system with the dev’s actual workflow. In WordPress, this often means moving away from massive external libraries and into native tools like theme.json and block variations that make the right choice the easiest choice. Check out how we started prefixing our tokens to avoid collisions while keeping things simple:
/**
* bbioon_register_design_tokens
* Registering custom block styles so they show up
* directly in the Gutenberg sidebar.
*/
function bbioon_register_block_design_tokens() {
register_block_style(
'core/button',
array(
'name' => 'bbioon-primary-action',
'label' => __( 'Primary Brand Action', 'bbioon' ),
)
);
}
add_action( 'init', 'bbioon_register_block_design_tokens' );Aligning Artifacts with Reality
A sustainable design system culture happens when your “artifacts” (like your code) align with your “espoused beliefs.” If you say you value speed, but your system requires 15 steps to add a button, your culture is weak. We fixed the SaaS client’s mess by creating a “contribution bridge.” Instead of blocking their PRs, we created a way for them to submit “proposed tokens” directly from their feature branches. It shifted the assumption from “this is a barrier” to “this is my tool.”
This is exactly what the Maturing Design Systems excerpt discusses. You have to recognize the subcultures in your team. Your designers care about consistency; your devs care about build times. If you don’t bridge that gap, you’re just writing expensive documentation that nobody reads. This is similar to how September’s core updates focus on making block development more intuitive—it’s about reducing friction.
The Reality Check: Is Your Culture Scalable?
If you’re constantly adding “policies and procedures” to force people to use your design system, you’ve already lost. A strong culture guides decisions organically. Your team should reach for a component because it’s faster and more reliable than writing it from scratch, not because they’re afraid of a linting error. This requires understanding the deep psychological model of organizations, often cited from theorists like Edgar Schein.
Look, the sustainable design system culture stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work with a system that actually grows with you, drop me a line. I’ve probably seen this exact disaster before and helped teams navigate out of it.
Are you building a system or just a collection of components? The answer usually lies in your last Slack argument about a padding value.
Leave a Reply