Measuring Adoption and Saying No

Two years into Northwind UI’s second life, I reran the color script from the interface inventory lesson. Sixty-four greys had become nine, and seven of those were primitives in the token file. That one number did more for the team’s funding than any presentation, because it was the same measurement, taken the same way, showing a before and an after. Measuring is how a design system proves it’s a product worth paying for, and how it finds out where it is failing its users.

What to measure

No single number tells you whether a system works. Northwind tracks four trends, reviewed monthly:

Together they resist gaming. A team could inflate adoption by wrapping everything in a system Box, but token coverage and satisfaction wouldn’t move.

Collecting adoption honestly

Import scans are the backbone. A script walks each repository, parses source files, and counts JSX elements whose component was imported from @northwind/ui versus components defined locally. GitHub’s code search gives a fast first answer for a single question, such as “where is the deprecated kind prop still used?”, which is how the deprecation lesson’s usage tracking works.

For production pages, every Northwind component renders a marker attribute:

<button class="nw-button" data-variant="primary" data-nw-component="Button">Assign driver</button>

A scan of the rendered page counts elements with data-nw-component against all elements of the same kind. The attribute matters more than it looks. The first version of our scan counted the nw-button class, and reported 94% Button adoption on the marketing site. Then we found three teams had copied the Button’s CSS into their own components, class names included. Only the real component writes the data attribute, so forks stop counting as adoption.

The numbers then roll up per team:

const scans = [
  { team: 'Dispatch', system: 412, total: 455, version: '5.2.0' },
  { team: 'Billing', system: 96, total: 180, version: '4.9.1' },
  { team: 'Marketing', system: 230, total: 251, version: '5.2.0' },
  { team: 'Reporting', system: 40, total: 160, version: '3.8.0' },
];
const latestMajor = 5;

for (const s of scans) {
  const percent = Math.round((s.system / s.total) * 100);
  const majorsBehind = latestMajor - Number(s.version.split('.')[0]);
  console.log(`${s.team.padEnd(10)} ${String(percent).padStart(3)}%  ${majorsBehind ? `${majorsBehind} major(s) behind` : 'current'}`);
}

Reporting’s 25% isn’t a reason to send an email to its manager. It’s a research question: what does Reporting need that the system doesn’t have? In Northwind’s case the answer was charts and dense tables, which became the next two quarters of roadmap.

Saying no

A system that says yes to everything turns back into the 64 greys, with extra steps. Northwind says no to one-team components, brand behavior changes, props that bypass tokens, and anything that breaks a principle. The skill is saying it in a way that keeps the team’s trust:

1. Name the reason, using the principle: “Per-component colors would break dark mode and Tidewater, and our principle is accessible before beautiful.”
2. Offer an alternative: a local build from system parts, an existing component with better docs, a documented escape hatch such as a component token.
3. Write it down in the decision log, so the next team with the same request gets the same answer and the same alternative.
4. Leave the door open: “If two more teams need this, bring it back to API review.”

Where you are now

You’ve followed Northwind UI from an audit of 64 greys to a system that forty teams use: principles and a team model, tokens in three tiers with themes and brands, components with composable APIs and accessibility built in, versioned releases with deprecation paths and visual tests, and a contribution model with governance and metrics. None of it is finished, and that’s the point of running it as a product. In the exercise, you write the adoption scan that tells you where to look next.