← Back to blog

Product updates

Reach and Frequency Are Now Badges, Not a Sentence You Have to Parse

DesignGuard AI3 min read

When we shipped reach-based severity scoring for unmatched literals — and the structural read of Figma's Variables API for mode coverage — the logic was right from the start. A literal's severity came from how many product-flow screens it reached, not how many times it repeated. A missing dark-mode token got flagged as "structural" when it came from real Figma variable data, or "naming fallback" when it came from a name-pattern guess. Both distinctions mattered. Both were also, for a little while, buried inside a sentence.

That's a real gap, not just a cosmetic one. A finding you have to read carefully to fully understand is a finding people skim past. If "reach: 5" and "frequency: 40" are both just numbers sitting in a paragraph, most people's eyes catch the bigger number and move on — which is exactly backwards, since reach is what should be driving how urgently you act.

What changed

Every unmatched-literal finding now shows two small badges right under the title: a Reach badge, styled with the same visual weight as the severity badge next to it, and a Frequency badge in a quieter, secondary tone. The visual hierarchy is deliberate — reach is what decides how bad this is, frequency is just a heads-up about how much work the fix will take. You shouldn't have to read a full sentence to tell those two apart.

Mode-coverage findings get their own badge: Structural when the gap was caught by reading Figma's actual variable-collection data, or Naming fallback when it was caught by inferring "light" or "dark" from a token's name because no structural data was available yet. That distinction was always in the summary text, worded carefully so nobody mistook a naming guess for a guarantee — now it's also something you can see without reading a full paragraph, on every card, at a glance.

Why this was worth a dedicated change

It would have been easy to leave this as-is — the prose was accurate, and accurate is most of the job. But a design system audit tool lives or dies on whether people actually act on what it surfaces, and "technically correct but easy to skim past" is its own kind of failure. The findings page is generic by design — every finding type renders through the same card, the same title/summary/recommendation layout, regardless of what kind of drift it is. That's a good default. But a couple of finding types carry a second axis of information — severity and effort, or a result and how confident you should be in it — and forcing that into a single sentence was asking readers to do parsing work the UI should be doing instead.

So this is additive, not a redesign: a small structured metadata field on top of the same finding record, read only by the two finding types that actually have a second axis to show. Every other finding type — missing Storybook coverage, orphan screens, weak handoff, all of it — renders exactly as it did before, because there's nothing new for them to say.

The summary sentence is still there underneath, for anyone who wants the full explanation. The badges are just for the two seconds before you decide whether to read it.

See it on your own design system

Run a DesignGuard AI audit against a real Figma frame or repo.

Open dashboard

More posts

Keep reading.

View all posts

Product updates

The Design Token That Never Became a Rule

Read post

Product updates

DesignGuard Now Re-Scans Your Figma Files the Moment You Publish

Read post

Code Connect

Figma Code Connect: A Practical Guide

Read post