Driving and measuring design system adoption

WHAT THIS TESTS This assesses whether you can think beyond building the system to actually getting heterogeneous teams to use it, and whether you can instrument adoption rather than assert it.

A GOOD ANSWER COVERS The strategy has two halves: encouragement and measurement. To encourage adoption, reduce friction. Provide excellent documentation and live examples, offer incremental migration paths so teams can adopt component by component rather than rewriting at once, ship codemods to automate mechanical changes, and supply hands-on support such as office hours or an embedded champion. Demonstrate value with faster delivery and consistency rather than only mandating from above, since pure mandates breed resentment and quiet non-compliance. To measure adoption, use concrete signals. Package telemetry shows how many projects install the library and at which versions, revealing laggards on old majors. Static analysis or a linter can scan codebases to compute the share of UI built from system components versus bespoke code, and count overrides or hardcoded values that bypass tokens. Design-side, track usage of the shared design library in the design tool. Aggregate these into a dashboard and trend them over time.

COMMON WRONG ANSWERS Mandating adoption with no migration tooling or support leaves teams stuck on legacy code. Measuring nothing means you cannot prove value or find laggards. Counting only installs ignores teams that install but barely use components. Forcing a big-bang rewrite is impractical for legacy products.

LIKELY FOLLOW-UPS How do you measure the share of UI using the system, perhaps via custom lint rules or AST scanning? How do you handle a team that refuses? What is a good north-star adoption metric? How do overrides indicate API gaps? How do you sunset legacy libraries?

ONE CONCRETE EXAMPLE A platform team ships codemods and a migration guide, runs weekly office hours, and adds a linter that reports the percentage of components imported from the system per app. A dashboard shows app A at 80 percent and app B at 20 percent still on an old major; the team targets app B with support, and overrides on the Button reveal a missing variant, which they then add.