Laddered Metrics Framework
| Of The System DS Performance | By The System Productivity Impact | From The System DS Impacts on Users | For The Organization Outcomes |
|---|---|---|---|
Component Library Size Component Library Growth Rate Team Usage Usage Velocity | UI cycle time of product teams which allows them to:
| Better and more consistent user experiences | Achievement of annual objectives internally & externally:
|
Production Usage UI Coverage | Brand experiences enabled by UI Design | Number of unique problems solved (Customer satisfaction) | NPS score and brand equity metrics |
Download the the table above:
How to read this table:
The columns from left to right expand from the design system itself to the impact at an organizational level. The more your team is able to link the design system (DS) work to a broader impact, at a system or enterprise level, the better it is to truly showcase value, secure funding and create a compelling narrative for the design system in your organization.
From top to bottom, the first few metrics are nice to track, but ultimately the metrics at the bottom of the table are the most critical metrics to measure.
Let’s take the example of the design system performance:
Being able to keep track of the number of components that you have is good in internal communications with leadership or product teams (although ensuring that everyone has the same definition of a component is important). Component library growth helps the DS team test its staffing model, and ensure that it can keep up with building the foundation of a DS in a reasonable time.
Ultimately though, the metrics that matter the most at a design system level are:
UI coverage, or what percentage of a product, an app or a site can be built using the design system.
The higher this percentage, the greater the potential impact and value of the DS, and the greater is the attractiveness of using a DS for a product team
Low percentage across multiple products can either mean that more components need to be built, or that the target has divergent user experiences, creating too many homebrew (one off use cases) that hamper the ability of the organization to reuse components across products.
The target itself can vary between organizations, with a higher target promoting consistency and reusability and a lower target promoting creativity and customized experiences by product.
Production usage is meant to track adoption of the design system. A DS brings value to the organization when it is adopted and used.
Rangle recommends automating adoption tracking, check out our Radius tracker open source tool for more information. Radius tracker enables you to automatically measure adoption, see how it trends over time and drill deeper to understand which components are being used (or not used) and by which team(s).
A low usage across the organization can mean that the product teams are not aware that the DS exist, or how to use it, or that the DS is not fulfilling the needs of product teams and providing them with the value that they are looking for
Last updated
