Practice — Design Systems, Components, and Dev Handoff (9 questions)

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."

1. Using the style guide / component library / design system distinction, diagnose what this team actually has today.
2. What's the root cause that let five buttons diverge over eighteen months, despite a "Design System" file existing?
3. Propose a concrete first step (not "build a full design system") that would start closing the gap within a couple of weeks.
4. What governance practice would you put in place to prevent this from recurring once the first step ships?

Brad Frost's atomic design methodology orders UI components into five levels of increasing composition. Between "molecules" (a search field: label + input + button) and "templates" (page-level layout with placeholder content), which level comes next?

Three different product teams have each independently built their own version of a "confirm this destructive action" dialog.

Per this subject's contribution-model heuristic, what does this specific count signal?

A token set defines blue-500: #2D6CDF (a primitive) and color-primary-500 (a semantic token pointing at that primitive), rather than components referencing the hex value directly.

What does this extra layer of indirection make possible?

A component library has reusable, implemented Figma and coded components that any team can drop into a new screen.

Per this subject's distinction between a component library and a full design system, what question does the component library alone still fail to answer?