measure-design-system-adoption

name	measure-design-system-adoption
category	data
description	Measure design-system use, coverage, quality, and outcomes without relying on package installs alone. Use when maintainers and product teams need evidence for investment, migration, support, or retirement decisions.

measure-design-system-adoption

Procedure

1. Define the decision, consumers, supported surfaces, measurement window, and system boundary.
2. Build an authoritative consumer inventory with owners, products, versions, and criticality.
3. Define adoption as meaningful use by component, token, pattern, documentation, or service.
4. Distinguish installed, imported, rendered, current, customized, compliant, and abandoned use.
5. Collect repository, build, runtime, design-file, documentation, support, and survey evidence with privacy limits.
6. Measure coverage, version currency, duplication, exceptions, accessibility, defects, satisfaction, and migration effort.
7. Normalize denominators and retain unknown consumers or unscanned repositories.
8. Segment by platform and risk without ranking individual performance.
9. Reconcile automated findings with a consumer sample.
10. Publish a dashboard and decision log with targets, uncertainty, and review actions.

Guardrails

• Do not equate dependency presence with correct adoption.
• Never use adoption metrics to punish teams for evidenced system gaps.
• Protect repository and employee-sensitive detail.

Done

• An adoption model defines populations, states, metrics, and evidence sources
• Automated results reconcile with sampled consumers
• Dashboard coverage, uncertainty, exceptions, and decisions are recorded