Automating Design System Enforcement

Designers could still introduce hardcoded colors, arbitrary spacing values, or custom components that were similar to something already in the system. These issues were often invisible until someone carefully inspected a file during design review.

Over time, this created a familiar dynamic. Design leaders became responsible for auditing system compliance during reviews, which meant conversations that should have focused on product quality often drifted into token enforcement, component usage, and implementation details.

The effect was subtle but real. Reviews slowed down, designers felt scrutinized, and leaders spent time on work that didn't meaningfully move the product forward.

Design reviews were doing two fundamentally different jobs: evaluating the quality of the product experience and auditing adherence to the design system.

When leaders are forced to do both simultaneously, the conversation shifts toward small implementation details instead of bigger product questions. This also creates unnecessary tension inside design teams.

My first attempt at solving this was a Claude Skill.

I documented our design system rules in Markdown so Claude could understand how Step uses tokens and components, then created a skill that could review work against those rules.

It worked. More importantly, it proved that a lot of the knowledge I was applying manually during reviews could be made explicit enough for a system to evaluate.

Despite being useful this version had limitations. Designers had to leave their existing workflow and deliberately ask Claude to perform the review. I had automated the knowledge, but I hadn't solved the problem.

Instead of expecting designers to remember to run a separate review, I wanted compliance to be available where the decisions were actually being made. I used Claude Code to build SDS Audit, a Figma plugin that checks a designer's work against the Step Design System.

Designers can run an audit on an entire page or just their current selection. The plugin walks through the underlying layers and checks properties including fills, strokes, typography, corner radius, spacing, and padding. Anything already connected to an approved variable is left alone; unbound values are flagged for review.

When it finds a violation, SDS Audit doesn't just point out the problem. It recommends an appropriate design token and lets the designer apply it directly.

I didn't write the plugin code by hand. Claude Code did.

My role was defining how the system should work: what constitutes a violation, what properties need to be inspected, how the plugin should choose between possible tokens, what happens when token data isn't available, and what the designer should be able to do with the results.

That required translating years of experience building and operating design systems into explicit rules a system could execute.

I would define the behavior, Claude would implement it, and I would test the result in Figma — finding edge cases, changing rules, debugging unexpected behavior, and iterating until the tool worked the way I expected.

Finding an incorrect value is relatively straightforward. Deciding what should replace it is more interesting.

For spacing, radius, and font size, SDS Audit compares the value against the system and finds the closest approved token. For colors, it uses similarity matching with a threshold so it won't recommend a token simply because it's the closest of several bad options.

I also added a rule based on how I want designers to use our system:

If a value is close to both a raw color token and something like Background/Primary, SDS Audit favors the semantic token even when the primitive is numerically a little closer.

That's not a rule Figma gave us. It's design-system judgment that previously lived in reviews, now encoded into the tool.

I didn't want to build a linting tool that gave designers another list of things to fix.

When SDS Audit finds an unbound value, designers can tap the suggested token name and the plugin binds the appropriate Figma variable directly to that property.

The goal was to make following the system easier than ignoring it.

That changed the role of the tool from an auditor into something closer to an assistant — identifying problems, explaining the right system choice, and helping designers correct them without leaving Figma.

The Figma plugin isn't the end state.

We still maintain the Markdown documentation originally created for the Claude Skill. That same structured definition of the design system can become useful beyond design review.

The next step is incorporating it into our build process so the rules designers use in Figma can also provide context to AI and engineering workflows downstream.

That creates an interesting opportunity:

• —Design reviews can focus more on product decisions
• —Token violations are caught earlier
• —Designers can validate their own work before review
• —System adoption becomes part of the workflow instead of a management responsibility
• —Design-system knowledge becomes reusable infrastructure rather than static documentation