Getting Engineering Buy-In on a Design System Change¶

"It's just changing the button component" is a sentence that sounds small from a design tool and can mean something entirely different from inside a codebase, where that button component might be referenced in forty places, several of which have quietly diverged from the documented spec over the years, none of which show up anywhere in the design file. The disagreement that follows usually isn't actually about whether the change is a good idea - it's about two people looking at two completely different pictures of what "changing the button" actually involves, and never having compared those pictures before the conversation turned into a disagreement.

Where the Friction Actually Comes From¶

Visual scope and implementation scope aren't the same thing, and design tools don't show the difference. A designer sees one component, updated once, propagating instantly everywhere it's used - because that's how the design tool represents it. An engineer sees every place that component (or something that used to match it and has since drifted) is actually implemented, which is rarely as clean as the design file suggests, especially in a codebase that's accumulated a few years of shortcuts and one-off overrides.

"Small" is being measured on two different scales. Small to a designer usually means "simple to describe" - a color, a spacing value, a border radius. Small to an engineer means "low effort to implement safely across every place it's used, including the ones nobody remembers building." A change can be simple to describe and expensive to implement safely at the same time, and neither side is wrong about their own read - they're just answering different questions with the same word.

What Actually Closes the Gap¶

Bring the change to engineering before it's already decided, not after. A change presented as "here's what we're doing" invites a fight, because the only thing left to discuss is whether to comply. A change presented as "here's what we're trying to solve, what does implementing it actually involve" invites a conversation, because there's still a real decision left to make together - which tends to surface the scope gap early, while it's still cheap to adjust for, rather than after a delivery date has already been set publicly.

Ask directly how many places the change actually touches, before assuming the answer. "How many components/screens would this actually affect once we account for drift from the spec" is a question most designers never ask, because the design file doesn't make drift visible - only someone working in the actual codebase can answer it, and the answer is often larger and messier than either side assumed going in.

Separate "the visual outcome we want" from "the specific way we're proposing to get there." Engineering often has a cheaper or safer path to the same visual outcome than the first implementation approach a designer assumed - but that alternative only surfaces if the conversation stays anchored to the actual goal rather than getting locked onto one specific proposed solution too early.

Size the change explicitly before committing to a timeline. "This should be quick" is a guess, not a scope estimate, and treating it as settled before anyone's actually looked at the blast radius is what turns a reasonable design change into a missed deadline and a strained relationship with the team that now has to explain why it took longer than promised.

The Pattern Behind Most of These Conflicts¶

Almost every version of this friction traces back to the same root cause: a decision that looked complete from the design side before anyone with visibility into the implementation side had a chance to react to it. The fix isn't a better pitch or a more polished mockup - it's moving the conversation earlier, while it's still a genuine two-way discussion instead of a request for approval on something already treated as decided.

FAQ¶

What if engineering pushes back on every design system change, big or small?
That's usually a sign the gap above has been happening repeatedly without ever getting named directly - worth raising the pattern itself in a retro rather than re-fighting the same friction on every individual change as if it's new each time.

Should designers learn enough about the codebase to estimate implementation scope themselves?
Not to the point of estimating independently, but understanding roughly how a design system is actually built (tokens, component variants, how overrides happen) makes the conversation with engineering faster and more concrete, since you're asking a more informed question rather than a completely open one.

How do you handle a change that's genuinely urgent and doesn't have time for this back-and-forth?
Even under real time pressure, a two-minute "here's what we need and why, what does this actually touch" conversation is faster than discovering the scope mismatch mid-implementation - skipping it to save time upfront usually costs more time later.