Your Client's Design System Needs a Health Check, Not a Rebuild

Six months after handoff, a client calls. "The design system isn't working anymore. Can you rebuild it?" Usually, the answer is no, it doesn't need a rebuild. It needs a health check. The components are mostly fine. What has happened is drift: detached instances, one-off colors, new screens built outside the library, and an RTL version nobody has opened since launch.

This month, Figma made drift much easier to see. It added Design System Analytics, agent-driven compliance checks and library repairs, and then connected its agent to published libraries. As ZURB Radar put it, Config put a number on design system debt, but it didn't hand you the budget. That's where an agency can help.

Why handed-off systems drift

When an agency builds a design system, it's at its healthiest on handoff day. After that, the client's team starts using it under real deadlines. Someone detaches a card to add a badge. Someone picks a hex value because the right token was hard to find. A new feature gets built by a contractor who never opened the library. None of this is malicious. It's just what happens when a system meets production.

AI agents add a new factor. If an agent builds screens from the library, it reproduces whatever is in it, including the inconsistencies. If the library is clean, the agent's output is clean. If the library has three slightly different buttons, the agent will happily use all three. Figma's decision to connect its agent to published libraries makes library quality matter more than before.

What to measure

A health check doesn't need dozens of metrics. These are the ones I find useful:

Adoption

What share of the product's screens use library components rather than local ones? Low adoption in a specific area, such as settings or onboarding, often points to a missing component, not a lazy team.

Detachments

Which components get detached most often, and why? A component detached frequently is telling you it lacks a property or variant people need. That's a design problem to fix, not a rule to enforce.

Token usage

How often do files use raw values (hex colors, pixel spacing, font sizes) instead of tokens? This is one of the clearest signs of drift, and it matters for theming and dark mode.

RTL and variant coverage

This is the metric most teams forget. For bilingual products, check:

• Do components work in RTL with auto layout and logical spacing, or were they only ever tested in LTR?
• Are Arabic type tokens actually used, or do Arabic screens borrow the English type scale?
• Are icons that must not mirror, such as media controls, marked as such?
• Do new components added since handoff have Arabic examples at all?

In my experience, RTL coverage is where drift hides longest, because the English version is what gets reviewed day to day. My posts on RTL rules for AI-readable design systems and Arabic typography for UI cover what good looks like.

Using Figma's analytics and agent checks without trusting them blindly

Figma's design system audit tooling and the October updates summarized by SpyingBee give you numbers you used to collect by hand. That's a big improvement. But automated checks have limits:

• False positives. A detached instance isn't always a problem. Sometimes it's a deliberate, documented exception, like a marketing page.
• Missing context. A check can tell you a raw color was used. It can't tell you whether that's because the token is missing.
• Blind spots. Most checks don't know your RTL rules or your Arabic type scale unless you've written them down.
• Repairs need review. Agent-driven library repairs can save hours, but someone who understands the system should approve them before they're published.

I treat the automated numbers as a starting point for a conversation with the team, not as the final score.

Presenting the score to a client

Clients don't need a 30-page audit. They need to know three things: how bad is it, what's the risk, and what will it cost to fix? I structure the report around those:

1. A simple score per area (adoption, detachments, tokens, RTL coverage), shown as healthy, watch or fix.
2. The risks in plain language. "Arabic screens are using the English type scale, so text is cramped and will get worse as the agent generates more screens."
3. A fix plan in priority order, each item with a rough effort estimate.
4. What happens if they wait. Not to scare them, but because drift compounds. The longer it runs, the more screens need fixing.

This turns a vague feeling that "the system isn't working" into a scoped piece of work the client can approve.

[Waleed: add a screenshot of a health-check summary page, with client details removed.]

Packaging the health check as an agency retainer

For agencies, the health check is also a good service to offer after handoff. It keeps you close to the client without the cost and commitment of a full retainer. A structure that works:

• Quarterly check: run the metrics, review the RTL coverage, and deliver the short report.
• Fix allowance: a fixed number of hours each quarter to handle the top items on the fix plan.
• On-call questions: a channel where the client's team can ask "is there a component for this?" before they build their own.

It's easy for clients to approve because it's predictable, and it protects the work you did at handoff. It also tends to surface bigger projects, such as a new module or a rebrand, earlier than they would otherwise come up.

Closing thoughts

Most design systems don't fail. They drift. A rebuild throws away good work to fix a problem that a regular check-up would have caught early. Now that the tools can put a number on drift, agencies can offer something clients actually need: a clear picture, a short fix plan, and someone who knows the system well enough to judge which numbers matter. For the naming side of keeping a system healthy, see my post on naming components for bilingual teams.

Sources: Config 2026 put a number on your design system debt (ZURB Radar), Design system audits (Figma), Figma product updates, October 2026 (SpyingBee).

FAQs