I once walked into a project at a mid-sized SaaS company that had spent roughly $50k on a high-end design system. Storybook, Figma tokens, a dedicated Slack channel. On paper it was perfect. The dev team was still shipping “one-off” CSS files for every new WooCommerce feature. They had the artifacts of an enterprise and the sustainable design system culture of a wild west startup.
My first thought was to become the enforcement officer. I set up strict linting rules in their CI/CD pipeline and wrote a custom CLI tool to block any pull request that did not use the system’s utility classes. It “worked” for about a week. Then a critical checkout bug needed a hotfix, and the devs sprayed !important around to get past my blocks, because they had no time to “learn the system.” 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 is not the donuts you buy for the office or the mission statement on the wall. It is the “basic underlying assumptions” your team works from. In this case the assumption was “Using the design system makes my job harder and slower.” You can have the best CSS architecture in the world, and if your devs feel like they are fighting it, they will win by breaking it.
The fix was to stop enforcing and start integrating, which meant lining the system up with how the devs already worked. In WordPress that usually means moving away from massive external libraries and toward native tools like theme.json and block variations, so the right choice becomes the easiest choice. Here is how we wired our own options into the editor sidebar, with a prefixed name so nothing collides:
/**
* 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 shows up when your artifacts, meaning your code, match the beliefs you claim. If you say you value speed but your system needs 15 steps to add a button, the culture is weak. We fixed the SaaS client’s mess with a “contribution bridge.” Instead of blocking their PRs, we gave them a way to submit “proposed tokens” straight from their feature branches. The assumption moved from “this is a barrier” to “this is my tool.”
The Maturing Design Systems excerpt makes the same point. You have to see the subcultures on your team. Designers care about consistency, devs care about build times, and if you never bridge that gap you are paying for documentation nobody reads. It is the same reason September’s core updates aim at making block development more intuitive, which is really about removing friction.
The reality check: is your culture scalable?
If you keep adding “policies and procedures” to force people to use your design system, the argument is already lost. A strong culture guides decisions on its own. Your team should reach for a component because it is faster and more reliable than writing one from scratch, not because they are afraid of a linting error. That takes understanding how organizational culture actually works, which is the model Edgar Schein laid out.
The sustainable design system culture problem gets complicated fast. If you are tired of debugging someone else’s mess and you want a system that grows with the site instead of fighting it, drop me a line. I have seen this exact disaster before and helped teams get out of it.
So are you building a system, or just a pile of components? The answer is usually in your last Slack argument about a padding value.
