Measuring the Value of Design Systems
Weighing outcomes over output from design system teams.
If you work with design systems, here’s a scenario that may sound familiar:
You got buy-in to create a new design system, likely based on the promise of increasing the productivity of designers and front-end developers and improving speed to market.
You built a component library, UI toolkit, and documentation. You released the system “officially” and started sharing it with other product teams.
But as those who work on design systems know, building the system is only the start.
Adoption of the system is essential, but there are many adoption hurdles that must be managed across the teams intended to use the system, including prioritization, framework compatibility, and access to tools.
Even with mass adoption of system parts and pieces, the work on the system is not done — no digital system is ever really complete.
Like tending to a garden, systems are living and require constant care and feeding to really blossom.
Design patterns and brand aesthetics evolve, new accessibility guidelines are released, front-end frameworks are updated for better performance —so design systems must be adaptable, and be supported by a dedicated team to continue to grow and maintain the system.
To justify ongoing investment in your design system, you need to be able to demonstrate the value in a way that’s meaningful to the business.
And this is a perennial question I’ve come across while managing design systems: how do we measure the value and impact of the system?
We can measure the output of the team: the number of components created and shipped, the number of platforms supported, the number of tests run.
We can measure the adoption of the system: tracking component usage in Figma files and code repositories, and doing visual audits for consistent brand and UI elements.
These are great methods for tracking the health of a design system, and understanding what use cases it supports (and doesn’t support).
But there’s a big difference between delivering value, and just delivering stuff. A design system team can release a shiny new component, but if no one needs that component and it doesn’t get used, it just becomes one more thing to maintain.
And sometimes the value comes from not delivering at all. Reducing the number of component variants can make them more unified and easier to maintain. As system teams work to support multiple product teams, they also see where efforts are being duplicated and can encourage collaboration and reuse instead of endless one-off solutions.
So how do we know what is truly adding value, and how can we measure it?
“Value” is a tricky word. It’s often used vaguely and means something different at different levels: leaders consider value in terms of high-level impact, while teams doing the work consider value in the detailed level or output and outcomes.
For some customer-facing products, value can be easily measured and quantified — for example, an email newsletter can measure the click-through rate of a recent campaign, or a SaaS product can measure churn rates and the impact of efforts to increase retention.
Other initiatives, such as internal systems, often do not have this “culture of measurement.”
We can report progress in terms of features completed, but how do know if they’re valuable features, or if we’re stuck in a build trap?
One idea is that instead of focusing only on the output and shipping new features, we can consider the outcomes of the work itself.
In Joshua Seiden’s book, “Outcomes Over Output,” he defines an outcome as “a change in human behavior that leads to business results.”
Applying this lens to design systems, the question is flipped from ‘what features are you delivering?’ to ‘what new behaviors did your work create that are leading to good things for your company/organization?’
And though it’s trickier to measure, this is where design systems really shine.
Challenges of measuring design systems
Let’s look at some of the challenges that many teams face when evaluating the success of a design system, to better understand the complexity of reporting and measuring value.
Challenge 1: Grassroots origins
In my experience, design systems are often started as passion projects by designers and engineers, solving problems primarily for other designers and engineers.
These are the people who have felt the pain of designing the same UI component (Buttons, Modals, Inputs, etc.) on multiple projects or rebuilding a Card component for the fifth time, and long for more reusable solutions.
Sometimes technical limitations prevent code from being re-used on a new project, or an engineer moves to a new team and finds they have to decipher custom code leftover from a previous (undocumented) effort — which drives a desire for more consistently shared standards.
Some product owners are eager to create a new design language for their product and ignore the brand guidelines — or maybe there’s a lack of consistent brand standards, which results in a disjointed user experience.
Often, the root of these problems stems from inconsistency: as organizations grow and scale, product teams that are responsible for their discrete areas of a website or app often move quickly and define their own standards and processes.
This inconsistency in how teams work leads to inconsistency in how they solve UX problems — resulting in a fragmented experience for end-users and creating barriers to alignment that ultimately slows us down.
Without a unified language, all products drift toward inconsistency.
— Yesenia Perez-Cruz, Expressive Design Systems
All of these pain points lead to grassroots-driven efforts for the creation of a design system, advocated for by passionate system thinkers. To them, the benefits of time and cost savings seem obvious: make a component like a Button or a Card once, embed current brand color and typography with design tokens, centralize and distribute to multiple teams sharing the same front-end platform.
Since the creation of a design system is often a bottom-up effort, and not an initiative handed down from leadership — my hunch is this is where one challenge in reporting comes from. There is likely support for high-level goals such as cost savings and improved productivity, but there may not be any specific metric or target defined. With no specific metric identified to report on, teams often measure only what they can.
And the question remains — what does it mean for a design system to be successful? How can a systems team prove their work is delivering value when the employee pain points don’t always align neatly with known business metrics?
Quantitatively measuring a design system’s value is one of the top challenges for system teams.
Challenge 2: Reliable and consistent data
Let’s take the example of measuring time savings to understand the challenges of reporting on complex systems work.
To effectively report on time savings before and after a design system is introduced, there needs to be a consistent measurement of time spent ‘before’ to compare against. This is usually not tracked in the same way across multiple teams, if at all. Story points and sprint capacity are relative estimation techniques, meaning that the actual level of effort or time spent will vary by team, by team member, and by whatever other work is happening at the same time.
Time saved on solving for common UI and production work is often repurposed to solve challenges unique to a product team, so there’s not necessarily a net savings in time — one main selling point for design systems is that solving for common UI patterns frees up time for designers and developers to address unique challenges for their product or project.
Additionally, we have to consider the perceived efficiency over time. Initially, system users will feel a big gain in efficiency when using the system. Over time, however, as they get used to using the system and new tools, the perceived efficiency gains go down.
While the efficiencies are surely there and are shared anecdotally, there’s a real challenge in creating a baseline measurement that’s consistent across multiple product teams.
Challenge 3: Measuring the interconnections and intangibles
Design systems include tools such as a component library and corresponding documentation with usage guidance. These tools provide a foundation that everyone who is creating products and experiences for end users can build on top of.
But design systems are really about much more than just the tools — they go a step further to define the interconnections between different parts.
“A system is an interconnected set of elements coherently organized in a way that achieves something.”
— Donella Meadows, Thinking in Systems
To paraphrase the quote above from Donella: a system has parts, those parts are connected, and through that connection, they serve an overall purpose.
A component library is the set of parts — the Buttons, Cards, Tables, etc. A system is what connects those pieces, and defines how they work together to create a cohesive user experience.
Lego bricks are often used as a metaphor for design systems, as a familiar set of building blocks that can be assembled in near-infinite ways.
While this is an accurate comparison to a standalone component library, the most important aspect of Lego is not so much the bricks themselves, but the system of tubes and stubs that holds them together.
New bricks have been added to the system over the years, yet a brick manufactured today will still connect with one of the first produced in 1958.
This focus on interconnected elements is replicated in design systems.
Design systems have to take into consideration the broader aspects of a company’s operations, including tooling, governance, people, accessibility standards, technology stack, and workflow.
Introducing a system for design will often expose areas in the organization that need greater alignment, which presents a great opportunity to break down silos and help teams think in more cross-functional, interdisciplinary ways.
And so the outcomes of systems are more than just the output of front-end patterns or design tools — they lead to changes in how people work, and how they communicate and share that work.
“Goals are about the results you want to achieve. Systems are about the process that lead to those results.”
— James Clear, Atomic Habits
The effectiveness of systems relies on the people and processes and that use them. While the tooling is tangible, there are many intangible and human aspects of a system. Traditional measures of output lose the big picture.
If we go back to the definition of outcomes as the changes in customer, user, or employee behavior that leads to positive business results, we can better understand how design systems add value to an organization.
“A pattern library alone can’t create alignment across multiple product teams that are all working towards their own objectives” — Yesenia Perez-Cruz, Expressive Design Systems
So, what are the outcomes of a design system?
There are many benefits from having a design system and a dedicated team that is thinking holistically and making connections across multiple products and teams.
When we consider these benefits in terms of outcomes, the impact of design systems becomes more clear.
Since design systems are primarily used by designers and developers, we can consider what problems we can solve for them and what behavior changes will create value for the business.
What problems are we solving for product teams (our users), that will create value for the business?
A few examples of how design system teams might answer this:
- If we create a shared “UI” language and a single source of truth, it can help improve collaboration and produce higher-quality work
- If we solve for common design patterns, it will enable teams to focus on new and unique challenges
- If we provide a starter set of UI components, teams will be able to onboard and deliver new work faster
- If we centralize the maintenance of shared UI components, individual teams will have to spend less time managing design and technical debt
- If we apply design patterns and brand styles consistently, it will increase user confidence and trust in our brand
- If we apply accessible design patterns consistently, more people will be able to navigate and shop on our site
By focusing on the desired outcomes of systems work, and getting buy-in for that compelling vision of the future, design system teams can then work to define the features or output that they believe will deliver on those outcomes.
Leaders are usually more interested in the impact of the work, rather than the details of the execution. There is a level of trust needed to be able to communicate up in terms of outcomes, rather than plotting specific features on a roadmap, so a good starting point is demonstrating how certain deliverables tie back to desired outcomes.
Seiden suggests using OKRs to measure and report on outcomes, where your key results are the outcomes you seek, expressed as measurable customer/user behavior. I look forward to trying this method out as a natural extension of using OKRs to report out and up.
By framing the benefits of a design system in terms of outcomes, and how those outcomes will add value to the business, the story of why a design system needs ongoing investment becomes much more compelling than simply tracking the number of new components produced.
Design systems not only enable product teams to move faster while maintaining quality, but they also introduce a shift in thinking about how we work: operationalizing how we approach design and taking a more deliberate approach to creating reusable and durable code.
To understand the value added by a design system, tracking the health metrics and output of the systems team is important. Cataloging the components in a design system, understanding where they are being used, and where teams are breaking or customizing them all helps to inform the work that a design systems team does.
But the output of a design system only tells part of the story. To more fully realize the value that systems bring to an organization, it’s essential to understand the outcomes they drive, and how that leads to good things for the business. Outcomes are the difference made by output, and design systems can add great value in these terms.
I’d love to hear if/how you measure outcomes for design systems. Do these challenges resonate with you? Have you found success measuring and sharing outcomes? The design system community is so wonderfully open to sharing, as we learn together, I hope this can be a thought-starter and conversation we can continue to evolve together as we learn what works. Thanks for reading!
