NPS for Design Systems: Smoke Alarm, Not Scorecard

WHY IT EXISTS: Design system teams often drown in quantitative usage data like component imports or Figma insertions, but those numbers hide a critical signal: resentment. Engineers may use your button because they have to, not because they want to. NPS was borrowed from customer experience to surface this emotional dimension. It exists to detect voluntary advocacy, which is the leading indicator of a healthy system before adoption or contribution rates decay.

THE MENTAL MODEL: Think of NPS as a smoke alarm rather than a thermometer. A thermometer gives you precise temperature; a smoke alarm only tells you something is burning and you should investigate. NPS will not tell you which component is broken or which documentation page is confusing. It tells you whether the relationship between the design system team and its consumers is warming up or catching fire.

HOW IT WORKS: You ask a single question: How likely are you to recommend our design system to a colleague? Respondents score from 0 to 10. Scores of 9 or 10 are Promoters, 7 or 8 are Passives, and 0 through 6 are Detractors. Your NPS is the percentage of Promoters minus the percentage of Detractors, yielding a range from negative 100 to positive 100. In practice, design system teams run this quarterly across consuming product teams, often anonymously, and always pair the number with an open-ended follow-up asking why the respondent chose that score.

WHEN TO USE IT: Use NPS when you need a pulse on internal sentiment that raw usage cannot provide. It is most valuable during periods of rapid growth, after major breaking changes, or when you suspect shadow libraries are forming. It also helps justify headcount or roadmap prioritization by translating designer and engineer frustration into a metric leadership understands.

WHEN NOT TO USE IT: Do not use NPS as a product scorecard for individual components or as a performance metric for design system team members. It is too blunt to guide specific feature work; a low score does not tell you whether to fix tokens, rewrite docs, or change your release process. Also avoid it if your sample size is tiny or response rates are under twenty percent, because the result becomes a vanity number driven by the loudest voices.

ONE CANONICAL EXAMPLE: A mature design system at a mid-size tech company surveys forty consuming teams each quarter. Over two quarters, NPS drops from plus thirty-five to plus eight. Usage metrics are flat, so leadership assumes all is well. The open responses reveal that a recent theming migration forced heavy manual work and broke several custom overrides. The design system team pauses new features to ship codemods and repair trust, and the next quarter NPS recovers to plus twenty-eight. Without the score, the team would have kept shipping while resentment silently built.