Auditing a Product with Five Slightly Different Buttons
You join a mid-size product team and discover the app has five visually different primary buttons across different screens — slightly different corner radius, two different blues, inconsistent padding — each built by a different feature team over the past eighteen months. There's a Figma file called "Design System" with some components in it, but nobody currently owns it, and engineers say they mostly rebuild buttons from scratch per feature because "the Figma one doesn't quite match what's already shipped."
- Using the style guide / component library / design system distinction, diagnose what this team actually has today.
- What's the root cause that let five buttons diverge over eighteen months, despite a "Design System" file existing?
- Propose a concrete first step (not "build a full design system") that would start closing the gap within a couple of weeks.
- What governance practice would you put in place to prevent this from recurring once the first step ships?
1. What they actually have today
They have, at best, an unmaintained component library — a Figma file with some components — not a design system. It fails the "design system" bar on two of the three layers: there's no working token layer (two different blues in production means color isn't a shared, referenced value, it's been hardcoded and drifted per team), and there's no governance (nobody owns it, and there's evidently no contribution or update process, since engineers have stopped trusting the file enough to reference it at all). Calling this a "design system" in an interview would be describing the artifact that exists, not the thing that's actually happening on the team.
2. Root cause of the divergence
The Figma file isn't the single source of truth in practice, even though it's labeled that way — with no owner and no process for keeping it synced with what's actually shipped, it silently went stale, and each feature team, under their own deadline, found it faster to rebuild a button that matched their immediate screen than to reconcile with a file they'd learned not to trust. This is the predictable failure mode of a component library with no governance: the system degrades into exactly the inconsistency it was meant to prevent, because there's no mechanism keeping it accurate or enforcing that new work reference it.
3. A concrete first step
Don't attempt a full governed system rebuild immediately — start by
auditing the five buttons currently in production, picking (or
designing) one canonical version with the team's input, defining it
as real tokens (color-primary-500, radius-sm, spacing-md) so
the values are data rather than eyeballed per team, and shipping it
as one real, coded component that at least one or two teams
immediately migrate to. This is scoped small enough to complete in
weeks, it produces something engineers can immediately verify
matches production (rebuilding trust in the file), and it's the
seed a broader system can grow from rather than a big-bang rewrite
that risks stalling before it ships anything real.
4. Governance to prevent recurrence
Assign an explicit owner (even part-time) accountable for the canonical Button and any future components, and put a lightweight contribution rule in place — proposed changes or new variants go through that owner for review rather than being built ad hoc, and a pattern needed independently by three different teams is the signal to formalize a new variant rather than let each team keep forking. Just as important: make sure the canonical component in Figma and the coded component in the app reference the same token source, so the two don't drift independently the way the old file and production already had.
Share this question