Design System Metrics

Design System Metrics

  • Scale design
  • Manage your debt
  • Design consistently
  • Prototype faster
  • Iterate more quickly
  • Improve usability


How to gather a large body of data from our people — both qualitative and quantitative.

Understanding your Product Designers

  • Tools and Design Systems
  • Culture and Community
  • Training and Mentoring
  • Sharing and Visibility
  • Ways of Working

Understanding your Engineers

  • Their usage/adoption of our design systems
  • Level of experience with using a design system
  • Collaborative process with designers
  • Technical and general feedback

Eng Metrics Question

Actionable advice

  • Ensure you have a strong mix of participants: different platforms and different levels of experience and tenure. This covers any potential insights that you might have missed. For myself, I interviewed several within each platform/experience/tenure. We want to have a strong sample of participants.
  • Having a few ice breaker questions allows people to warm up and eases them into the more nitty-gritty questions.
  • It’s ok to not stick to the script. Go with the flow. You will uncover insights you would have missed otherwise. The script should be more of a guide than anything else.
  • Run your questions by someone. Then do it again. We’re guilty of constructing sentences that do not make sense to others. I find collaborating with a researcher on this one is super helpful. The main thing is to ensure our questions are neutral and have no bias in them.
  • When analyzing the findings, pull in everything that you find interesting. Anything. Group them into themes. Then group them again so you’re left with a set of high-level findings. Doing it this way means you always have a rich set of insights to fall back on.

Creating a baseline survey

Survey Design System


Tracking instances of components over time:
  • Tracking instances of deprecated components
  • Tracking usage of props on React components
Tracking progress of migration:
  • Migration of components
  • Migration of custom typography


What is great about this library is that you can access raw data from a scanner, which we use, and just slightly transform the data to fit your needs. In our case, this meant mostly adding IDs to reports and components so there is unique identification for every component in our data analytics tool, but more on that later.

Parity between our Figma UI libraries and our code-based component libraries

High-level insights around the adoption of your design system as well as inside your design tool.

Using Figma’s library analytics

[figma components + code-based components added this quarter] — [code-based components that are unavailable/in-progress] = value1

[value1] is what percent of [figma components + code-based components added this quarter] = value2%

Time and cost

High-level insights around your current ROI.

A big driver in using a design system is the ability to increase your product’s speed to market. This, in turn, returns engineering and designers' maker time back to the business, allowing them to solve the hard user problems more readily.

In an ideal world, you have a design system that has tracked the time spent on making each of its components. If so, I am incredibly jealous and this will make your lives 10x easier.

Minimum time estimates:

  • We could focus only on the minimum amount of time it would take to build that component from an engineering standpoint.
  • We could remove a ton of variables that are even harder to measure; testing, design QA, code reviews, accessibility checks, PR’s, etc.
  • While the number will be smaller, it is a more reliable number. Thus removing ambiguity and building trust with our stakeholders and others. It’s all about getting a ballpark number first, people.
  • Doing so would allow us to establish a set of year savings and projected savings.

Which components to estimate?

There’s a lot I could have included here, but for the sake of time (ha, get it?) I focused on establishing a core list of components. These are components that have a high chance of being used within any application.

Setting it up

Create a survey that includes your core list of components. Get your engineers involved. Get your team involved. Ask them to give their estimates in a unit that the business widely uses.

  • For designers, we included design system analysis, high-fi work, Figma component, specs + basic documentation. It excluded time spent on design reviews, iterations, and research.
  • For engineers, it only included the minimum time it would take to build each component.

Design System Time Estimates Template

The road ahead: 

A clear set of opportunities that can easily fit into our roadmap, backed by insights and aligned with the business.

  • DS Themes/KPIs from your survey eg. Confidence, Quality
  • Your focus area eg. Tooling, Accessibility
  • Company ambitions eg. Optimize operating efficiency
  • Principles, be it design or engineering eg. Automate the mundane
  • Rationale — an obvious one, but an opportunity to summarize the insights that have led to this decision, where everyone can see.