Stop policing your design system

Measure health, not compliance

Design systems break without warning. Teams detach components, bypass tokens, hardcode values, and the system degrades without anyone noticing until it’s too late. You catch violations during code review if you’re lucky. More often, you find them months later when someone asks why there are five versions of the same button in production.

I’ve watched this play out across every design system I’ve worked on. You ship a new component, document it thoroughly, and announce it in Slack. Three months later, you discover the old version is still living in the checkout flow. Someone needed “just a small tweak” and duplicated the whole thing rather than submitting a request. Now you’re maintaining parallel implementations that will never sync up.

Manual governance doesn’t scale. You can document standards, run quarterly audits, and trust teams to follow guidelines. But entropy compounds faster than you can catch it. By the time you notice drift, you’re managing the symptoms rather than preventing the disease.

The feedback loop is broken

Traditional design system governance operates on trust and periodic verification. You publish components, write usage guidelines, maybe add some ESLint rules. Then you hope teams implement things correctly. When violations occur, you find them through code review, if someone happens to notice, or during those dreaded quarterly audits where you manually inspect implementations.

This approach has fundamental problems. First, the feedback is too slow. Weeks or months pass between implementation and discovery. By then, the problematic code is shipped, in use, and becomes technical debt that’s expensive to fix. Second, it’s inconsistent. Review quality depends on who’s reviewing and how rushed they are. Third, it’s reactive. You’re always playing catch-up with problems that already exist.

But there’s a bigger issue. This model treats your design system like a set of rules to follow rather than infrastructure to maintain. That framing shapes everything about how you think about governance, and it’s the wrong mental model entirely.

What production engineering learned

Software teams solved this problem decades ago. They don’t rely on developers promising to write performant code or manually reviewing every deployment for memory leaks. They instrument systems with continuous monitoring, automated checks, and real-time feedback loops that provide constant visibility.

When your API starts returning 500 errors, you don’t find out during the next sprint review. You get an alert within seconds. When database queries slow down, dashboards show exactly where performance is degrading. When server memory usage spikes, automated systems notify the team before users experience failures.

This isn’t about catching every possible issue. It’s about continuous visibility into system health. Engineers treat infrastructure as something that needs monitoring because they know it will degrade without constant attention. They’ve built entire disciplines around observability, treating it as critical as the systems themselves.

Your design system is infrastructure. It’s a dependency that hundreds of features rely on. When it degrades, everything built on top of it becomes inconsistent, harder to maintain, and more expensive to evolve. But unlike your production systems, it probably has no monitoring, no health dashboard, and no automated alerts when something breaks.

Measuring what actually matters

The design system community has gotten better at tracking metrics. We count component usage, monitor adoption rates, and measure time saved. These are useful, but they’re lagging indicators. They tell you what happened, not what’s happening right now.

Health metrics are different. They measure the integrity of your system in production continuously. Component detachment rates tell you where your components aren’t meeting team needs. Token usage patterns reveal where teams are bypassing your system. Spacing consistency across implementations shows where documentation isn’t clear enough.

These aren’t vanity metrics to show stakeholders. They’re diagnostic tools that tell you where your system is failing. Teams like athenahealth have adopted this mindset. Their Senior UX Designer, Veronica Agne, explained their approach to Figma: “If someone in our organisation is detaching a component, I want to know why. It can mean one of three things: there’s a bug, people want an enhancement to the functionality that isn’t there, or people are combining existing elements in ways I didn’t expect”.

That’s health monitoring. A high detachment rate isn’t a compliance problem to be fixed through stricter reviews. It’s a signal that your component has a feature gap. Token bypasses aren’t rule violations. They’re evidence that your system lacks the flexibility teams need. These metrics change the conversation from enforcement to improvement.

The infrastructure mindset

Treating design systems as infrastructure changes how you approach governance entirely. You think in terms of health and sustainability rather than rules and reviews. Feedback loops replace enforcement.

Production systems have SLAs, uptime monitoring, and automated alerts. Design systems can have component integrity scores, token consistency tracking, and automated checks that run on every pull request. Production systems have dashboards showing performance trends over time. Design systems can have dashboards showing adoption patterns and drift indicators.

This isn’t about adding more tooling for the sake of it. It’s about getting the feedback you need to maintain something at scale. When you have 50 components used across 200 features by 30 engineers, manual oversight becomes impossible. You need automated systems that surface problems before they compound.

Infrastructure thinking also changes your relationship with teams. You’re no longer the compliance police checking that people followed the rules. You’re providing a service, and your monitoring helps you understand where that service is failing. When teams bypass your system, that’s not defiance. It’s data showing where your system doesn’t meet their needs.

What this looks like in practice

Several patterns have emerged for implementing observability in design systems. The most effective ones integrate monitoring directly into existing workflows rather than creating separate audit processes.

CI/CD integration is the foundation. Every pull request can trigger automated checks that verify token usage, component implementation, and accessibility compliance. These checks fail the build when violations occur, providing immediate feedback rather than discovering problems weeks later. This isn’t gatekeeping. It’s the same pattern your codebase uses for linting, testing, and security scanning.

Teams like Twitter’s Observability Engineering group demonstrated this approach years ago for their entire infrastructure. They built full-stack libraries and services that monitor service health, alert on issues, and support root cause investigation through distributed traces. Their charter was simple: provide the data engineering teams need to understand system state and diagnose problems.

Design systems can adopt the same model. You run automated audits on every push that check token usage, preset implementation, accessibility, spacing, typography, and border radius. A single CLI generates reports and a live dashboard shows system health over time.

The dashboard piece is particularly powerful. Instead of quarterly audits that produce static reports, you get continuous visibility into trends. You can see when a new component launches and track its adoption curve, you can identify patterns in which components get detached most often, and you can correlate system changes with implementation quality.

The key is making monitoring automatic and continuous rather than manual and periodic. Version control your design system configurations just like infrastructure as code. Use automated deployment pipelines that validate changes before they ship. Surface degradation through real-time metrics as it happens rather than months later.

The empowerment shift

This approach fundamentally changes power dynamics around design systems. Traditional governance often feels like oversight and restriction. Teams need approval for changes, face criticism when they deviate from standards, and experience the system as something imposed from above.

Observability flips this. You’re measuring service quality rather than policing compliance. The question becomes “is the system healthy?” instead of “did you follow the rules?”. The focus moves from team behaviour to system capability.

When your dashboard shows high detachment rates for a specific component, that’s not evidence of teams being difficult. It’s evidence your component has gaps. When token bypasses cluster around spacing values, that’s not teams ignoring standards. It’s your token scale missing values teams actually need. When accessibility checks fail consistently in one area, that’s not careless implementation. It’s your documentation or component design failing to make accessibility easy.

This reframing is crucial. Teams stop being policed and start being served. Your monitoring becomes a feedback mechanism showing where you need to improve rather than proof that teams aren’t following guidelines. You move from enforcement through reviews to improvement through data.

This shift would fundamentally change how teams engage with design systems. When teams know the system monitors itself and responds to gaps they encounter, they’d have reason to trust the feedback loop. They’d file issues knowing patterns in the data would validate their concerns. They’d suggest improvements knowing monitoring would prove whether proposals solve real problems. They’d adopt new components because the system demonstrates it evolves based on actual usage. Adoption thrives when teams feel empowered rather than policed.

From compliance to health

The most effective design systems aren’t the ones with the most comprehensive documentation or the strictest governance. They’re the ones that continuously adapt based on real usage patterns. They’re the ones that measure health rather than enforce compliance.

This requires changing how you think about your role. If you’re a design systems lead, you’re not building a comprehensive library that teams should use. You’re providing infrastructure that teams rely on. That infrastructure needs monitoring, maintenance, and continuous improvement based on production data.

If you’re treating design system governance like rule enforcement, you’re solving the wrong problem. Teams aren’t wayward children who need supervision. They’re dealing with real constraints, tight deadlines, and edge cases your components weren’t built for. When they deviate from your system, they’re showing you where it doesn’t work, not demonstrating poor discipline.

Observability gives you the data to see these patterns. High-quality monitoring surfaces the invisible work of maintaining consistency at scale. You can see which components are thriving and which are being worked around. The gaps between your system’s capabilities and team needs become visible. You get the feedback loops necessary to evolve something complex.

Most importantly, it moves you from reactive to proactive. You see trends as they develop rather than discovering problems during audits. The system improves based on continuous signals rather than enforcing compliance through reviews. Violations become data points guiding your roadmap instead of failures to punish.

Design systems need observability. Not because you need more ways to catch violations, but because you need better ways to maintain infrastructure that teams depend on. The question isn’t whether teams are following your guidelines. The question is whether your system is healthy enough to serve their needs. Monitoring is how you answer that question continuously, rather than discovering the truth too late to prevent entropy from taking hold.

---

Thanks for reading! Subscribe for free to receive new posts directly in your inbox.

This article is also available on Medium, where I share more posts like this. If you’re active there, feel free to follow me for updates.

I’d love to stay connected – join the conversation on X and Bluesky, or connect with me on LinkedIn to talk design systems, digital products, and everything in between. If you found this useful, sharing it with your team or network would mean a lot.