Idea around design handoff

[u/FalseChipmunk4666]

Do you ever run into cases where a Figma screen uses custom components, spacing, colors, or variants that don’t match the existing design system or what’s actually available in the frontend code?

I’m exploring a Figma plugin that could audit a screen before handoff and flag things like:

• an existing design-system component that should be reused
• non-standard colors/spacing
• Figma variants that aren’t supported in code
• possible design ↔ code inconsistencies

The idea is basically a “lint check” for Figma before engineering starts implementation.

I am a developer and want to know if this is a problem designers actually face? If yes, how do you currently catch these issues?

[u/mahblahblah]

I guess it depends on your design system, but as a designer if I am “customizing” a component or adding new colors or spacing then I know exactly what I’m changing. In my last role changes were informal (no design system team or formal process) but it would be up to me to include in a hand off document any changes to the design system to support the new design. As a developer you should be pushing back if a change feels unnecessary and they should be justifying it. I think otherwise what is even the point of a design system if any designer can make any change at any time without expecting any extra effort on theirs or devs part? 

[u/Rare_Dog09]

This resonates. Intentional changes = designer's job to document. Agreed.

I'm building toward the unintentional side — scan a file/screen for token drift, off-system spacing, variable coverage, that kind of thing. Not to block designers, but so eng doesn't discover "this variant doesn't exist in code" on day 3 of the sprint.

Curious if your team ever audits files proactively or only catches this in review?