In a design system, how would you measure whether product teams have actually adopted it, and why is counting package installs not enough?

## What adoption means for a design system A **design system** is shared UI run as a product: tokens, components, patterns and guidance consumed by several product teams across the web, native mobile and a design editor. **Adoption** is the degree to which those teams actually build their shipped interfaces from it. It is not one fact but several: whether a team depends on the system at all, how much of its interface the system supplies, how often the team works around it, and whether the people using it would choose it again. Interviewers ask this because the obvious number is the wrong one, and because a system team that cannot show adoption struggles to keep its funding and its influence. ## Why install counts mislead A **package install** or download count proves that a dependency was declared. It does not prove that the product renders the system's components, that it uses a current version, or that its designers start from the shared library. Common ways an install count overstates adoption: - A team installs the library for one icon or one helper and hand-builds every screen. - A team pins an old major version and never upgrades, so it consumes a system that no longer exists in that shape. - A team wraps system components in local copies whose styling is overridden until nothing of the system is visible. - Download numbers can be inflated by build servers re-installing the same dependency on every run. The count can also understate: a native mobile team that consumes the system's tokens as generated platform constants may never install the web package, yet be thoroughly adopted. ## The signal set | Signal | Where it comes from | What it shows | Blind spot | |---|---|---|---| | **Component usage in code** | A scan of each product repository for imports and instantiations of system components | Which components are used, where, and at which version | Counts references, not what users see; misses local look-alikes | | **Component usage in design files** | The design editor's library analytics: inserted and detached instances | Whether designers start from the shared library | Design files are not the shipped product | | **Coverage of product UI** | Sampling shipped screens and classifying each region as system-built or local | The share of the interface the system actually supplies | Labour-intensive; needs a sampling rule | | **Detached or overridden instances** | Design-file analytics and code scans for style overrides | Where the system does not fit a real need | A high rate can mean missing variants or careless use | | **Satisfaction survey** | A short recurring survey of consuming designers and engineers | Whether adoption is willing or forced | Self-reported; subject to survey fatigue | | **Service health indicators** | The system team's own request queue and release data | Response times, open defects, version lag | Measures the team, not the product | No row is sufficient alone. Usage without coverage overstates; coverage without satisfaction can hide a mandate that teams resent; satisfaction without usage can be a small, happy minority. ## Reading the signals together 1. Establish a **baseline** per product before any push for adoption, so later numbers have something to be compared with. 2. Report **per product and per platform**, not one global percentage: an average hides the one large product that has barely adopted. 3. Watch **trends** across releases rather than absolute values; the direction tells you whether an intervention worked. 4. Investigate **outliers**: a product with high usage and low satisfaction, or a component detached far more often than its peers. 5. Pair each number with the decision it informs, so nobody optimises the number for its own sake. ## An example: a customer-support ticketing tool Imagine the system serves a customer-support ticketing tool with a web agent console and a native mobile app for agents on call. Every team has the system installed, so the install metric reads 100%. A code scan shows the ticket list and the settings pages use system tables and buttons, but the reply composer, the screen agents spend most of their day in, imports only the system's icons; its toolbar, canned-response picker and attachment chips are local. The design-file analytics show the composer's buttons detached in most recent files because the system's button has no compact size. The survey shows the composer team rates the system poorly. Together the signals say something the install count never could: the most-used screen is outside the system, and the cause is a missing variant, not reluctance. ## Pitfalls - Treating one number as the goal invites gaming: a team can raise its import count by wrapping everything without changing the interface. - Mandating adoption raises usage while it can lower satisfaction; the survey is what reveals that. - Counting only the web platform ignores native mobile consumers of the same tokens and guidance. - Collecting metrics nobody acts on spends the consuming teams' goodwill; each measure should feed a decision about the roadmap or the support the system team gives.