The U.S. Federal Reserve has a dual mandate of promoting maximum employment and stable prices, but the main thing it’s been monitoring lately (last 40 years) is inflation. Not because inflation is inherently evil, but because unpredictable, runaway inflation is bad for the economy. It lowers trust, decreases investment, and eventually leads to Guillotine Tuesdays.
But the Fed doesn’t try to reduce inflation all the way to zero. It aims for a stable, predictable 2%.[0]
(source: https://www.federalreserve.gov/economy-at-a-glance-inflation-pce.htm)
This is because a little inflation means our economy is alive and breathing. Zero means something’s broken.
Healthy detachment, like healthy inflation
Just as the Fed targets 2% inflation rather than zero, design system teams should target an optimal detachment rate rather than complete compliance.[1]
Like inflation, a little detachment is healthy. Some teams have truly unique needs, while others are experimenting and pushing the brand forward. Also, detachment totally beats non-usage, as it signals we’re at least helping teams make progress towards their desired destinations.
But what about when detachment spikes? When everyone’s reinventing buttons and tweaking border radii and ignoring our layout grid and using gamboge for that AI feature?[2]
Not only does this mean our company’s customers probably aren’t enjoying a consistent experience across our product suite, but also our customers — our colleagues — aren’t finding our product valuable enough to buy. They have to make too many compromises. The tradeoffs aren’t worth it. Ultimately, they’re not adopting our system, because the price for doing so is too high.[3]
If some detachment is healthy, what’s the optimal rate?
Our target detachment rate depends on our company’s current growth strategy: 1. Is it looking to expand into new products, platforms or regions, which will require increased experimentation across product teams? Expect higher detachment rates. 2. Has it solidified its product line, and it’s now trying to tighten things up and smooth out that customer journey? Expect (or at least hope for) lower detachment rates.
OK, but what about the ideal rate? Like, precisely? Depends on where the company is in terms of growth, expansion, or consolidation. And even then, I don’t think it’s a single number, but more likely a range.
The Design System Detachment Curve
Taking a lesson from those who actually govern (not just design), we shouldn’t even look a precise number. Instead, we should aim for a healthy band of divergence: a balance where teams mostly stay within the system because it serves them well, while at the edges they thoughtfully adapt.
No individual instance of detachment matters — we’re playing a macro game. Team A over here detaching? Sure, reach out to them to understand why, but don’t get concerned. Half the teams detaching over half of the components? Yes, sound an alarm. But even all teams detaching 2–5% of the components they use, and not even the same components? Probably healthy, but still, do your own research.
Embrace detachment
Product teams are responsible for creating the conditions under which users choose to stay with their product. Design system teams are therefore responsible for creating the conditions under which downstream product teams choose to stay within the system. Not because they’re forced to, but because it’s the easiest path for them to achieve their desired product outcomes.[4]
When the design system isn’t their easiest path, teams shouldn’t use it. We’re not the IRS or the FBI. We’re not here to ensure compliance. And with the burgeoning capabilities of AI to generate design token and component sets, we’re not even the Treasury anymore.
We’re the Fed. And like the Fed with inflation, our job isn’t to eliminate all detachment. Instead, it’s to create conditions where teams choose to stay within the system because it serves their goals better than any alternative. We monitor, adjust, and respond, always aiming for that healthy band where innovation flourishes within a coherent framework.
So, if you’re tracking detachment at your org, please don’t obsess over absolutes. Watch the curve, learn the causes, and try to stay within the band.
Notes
[0] https://www.federalreserve.gov/economy-at-a-glance-inflation-pce.htm
[1] Detachment = how often downstream product teams fork, override, or generally decide that our perfect components aren’t perfect enough for them, and thus need to be detached then customized.
[2] Jk nobody would ever use gamboge in that scenario.
[3] Not everyone lives in the “Design systems are products, too” camp. If you’re one of those non-residents, then this post isn’t for you. Peace & blessings.
[4] Here’s a little knowledge for those design system PMs out there: Only when customers can choose, or at least have the perception of choice, can we employ jobs theory. So, if your organization mandates design system usage, don’t even bother with JTBDs. They won’t help you do your product work.