Chris Strahl’s Post

Metrics come up all the time in talking about how to prove design systems value. The prevailing idea is that increasing adoption is the key to unlocking value. I disagree. I think it may be a part of success, but it is a bad way to express value. Here is why! Adoption is the kind of metric you get when you throw up your hands because you can't get the right data or you're more focused on building the design system than what you can build with it. It is the equivalent of "well, people seem to use it, so it must be great!" this can be fine if you're just starting out, but it doesn't tell you how your system is actually delivering value. Heck, NPS (which is also pretty imperfect), or a qualitative ask of product teams of "how valuable is the design system to your daily work?" or "what would change if the design system went away tomorrow?" is a better proxy for value than just "do people view some pages or login once a week?" Adoption can be pushed as a mandate. After seeing hundred of design systems up close, I can say definitively that high adoption doesn't differentiate between dream design systems and that 17 tool spaghetti monster that has documentation in Excel with hundreds of links to a private Git repo along with a 22 swim lane flowchart that you just... keep... scrolling... down. The only reason why adoption persists as a common metric is because even really bad design systems have the ability to generate significant value. So what's better? First, we need to hone in on the unit of repeatable value. This differs depending on the stated goal of the design system, but the vast majority of good design systems that operate at a significant scale are focused on how fast the organization can build products using the system (that's not the same as building components or designs in the system itself). At Knapsack, we tend to express this at this as cycle / iteration time from design to code across product teams that consume the design system -- either faster iterations or fewer iterations. We tend to focus on capacity because individual cycle velocity is often poorly understood and varies between product teams or disciplines. However, most teams have a fair handle on their capacity both for a single cycle and across a historical range of cycles. These can also be expressed easily as a relative percentage increase or decrease. It also accounts for a lot of secondary things (e.g. QA time) There is a goldilocks zone that consistently lands between 20 - 40% greater cycle capacity. For most of our customers, that's literally millions of dollars. If you're using adoption, you're not alone. We've heard time and again on the Design Systems Podcast that folks look at this metric ALL THE TIME as a measure of success, but it certainly doesn't paint the full picture, nor is it the north star for understanding value.