The designer’s guide to design system ROI & success
Identifying and measuring the return on investment for your design system.
By its very nature, a design system is a product that serves products. It is a product that your internal staff consumes directly and your end users use vicariously.
A successful enterprise design system delivers cohesive, scaleable features in a way that’s efficient for both design and development. It is a comprehensive effort built on investment in infrastructure, process, governance, and people — and it is the essential ingredient to remain competitive in a hyper-evolving digital market.
A design system is a managed source of truth for product design, process, and governance. It is an engine that catalyzes innovation by allowing teams to implement and deliver experiences to customers.
A successful and enterprise-level design system has:
- A synchronized source of truth between design assets and production code
- Process and governance to manage change and experimentation
- Accountability and rigor to ensure design and code efficacy
- Engineering and design buy-in: both engineers and designers use systemized components when possible
- Full executive support and company buy-in
Inherently, a design system is very complex. To get it right, it requires significant time, investment, expertise, and iteration. So, as an executive, how do you justify the investment? How do you accurately scope the level of effort, timelines, and a structure for accountability?
And, once the system is implemented, how do you measure success?
1. Increased product development efficiency and efficacy by 25%
At its most fundamental level, product development is the translation of design intent into live product experiences. It is the ability to deliver value to your customers and, hence, derive increased value for your business.
A systemless company will often have a disjointed and inefficient product development process. Why is that?
Typically, systemless companies have multiple product teams designing and architecting experiences using divergent style and interaction patterns. This creates two big problems:
- Designers will have to focus on creating custom and nuanced elements, rather than customer experiences.
- Developers will have to recreate one-off elements and maintain multiple versions of each element — making reusability difficult.
Together, these problems significantly slow your team’s ability to deliver customer experiences.
With an effective design system, designers can focus on crafting new and innovative customer experiences using systematized building blocks and established patterns. Similarly, developers can reuse these blocks to build the experiences, allowing them to focus on feature performance and not pixels.
Going from systemless to system, a successful design system should increase your product development efficiency and efficacy by at least 25% (time and money) — with increasing returns as the system matures. This metric also applies to product efficacy by reducing the number of production user interface bugs.
Going from systemless to system, a successful design system should increase your product development efficiency and efficacy by at least 25% (time and money) — with increasing returns as the system matures.
While 25% is not a scientific benchmark, it is derived from my experiences building and implementing design systems. This efficiency gain also assumes that your team has invested in the appropriate infrastructure to support such a system, and that your tech stack doesn’t unduly hinder a design system rollout (from a code perspective).
You can use these indicators to measure against the 25% benchmark:
- Before and after survey results: often, the perception of speed and efficiency still yields increased morale and productivity, even if features are not necessarily delivered 25% faster. A simple survey can measure the perceived speed of delivery over time and gather qualitative data to help clarify the underlying perception and reasons.
- JIRA / Project Management tracking speed: even though many factors (tech caveats, time of year, resourcing) impact speed to completion for stories/tickets, it could help to compare a before/after speed completion for stories with similar point weights and scopes. For example, a pre-system 8 point feature took 6 weeks to design and develop, but a similar post-system 8 point feature took 4 weeks to design and develop.
- Feature Bugs/Enhancements: while bugs are inevitable, reusing production-tested components should yield less bugs than building something from scratch. Measuring the difference in bug reports from before and after a system could help measure component efficacy.
2. Cohesive customer experiences enable durable and scaleable products
The ability to scale feature and product offerings is essential for high yield growth and product diversification. In the rush to build new experiences, systemless companies will often scrape together disparate design stacks (divergent libraries, tech stacks, and processes) to deliver new experiences as quickly as possible.
However, this rush often leads to disjointed experiences: the way your customer interacts with Product A diverges with Product B. Similarly, the way your designers and developers build for Product A diverges from Product B. This creates two points of usability friction:
- Relearning and context switching: Your customers will have to relearn your product’s interaction patterns as they switch from product to product or feature to feature. This creates unnecessary friction, which yields frustration and disempowerment. Interacting with a product is inherently a visceral experience, so even slight friction becomes more salient the more someone interacts with a product. For example, if product A uses a different “Filter” icon than product B, then the user can not transfer the learned affordance from product A to product B. The user will have now have to remember two interaction patterns, instead of one. Multiply this by 100 and you’ll have introduced substantial friction. Similarly, designers and developers that switch teams or switch from Product A to B will have to relearn new processes and pattern libraries — which increases ramp up time and churn, while negatively impacting morale.
- Disjointed information and feature architecture: By their very nature, systematized design patterns are generally built to scale. They are meant to accommodate different use cases and themes, and evolve as the product and feature set evolves. If you have multiple products using very rigid components or patterns, then new features and themes will inherently break the design paradigm. Consider for a moment that we built a web app with a data table that easily supports 30 records. Our initial customers who only had 10–20 records were perfectly supported by this initial use case. However, suppose we were now able to scale the product to a new customer demographic with 100’s or 1000’s of records. If we used a systematized data table, then we could more easily scale the user interface to accommodate the increase in records, without having to teach users a brand new table pattern (or teach designers/developers how to rearchitect it). We would also not have to support two different feature architectures: one for simple users and one for complex users.
In the rush to build new experiences, systemless companies will often scrape together disparate design stacks (divergent libraries, tech stacks, and processes) to deliver new experiences as quickly as possible.
A successful design system anticipates future needs by providing a library of scaleable, theme-able, and extensible web/native components. This means that you may not ever need to do a full redesign just to accommodate one new feature.
Of course, there will come a time where you will want to revisit your product suite. This is where theming comes into play. Components should be able to flex and accommodate theming changes without actually refactoring the full interface. To your customers, the design may seem brand new, but internally, much of the underlying code is the same.
Design system components should be able to flex and accommodate theming changes without requiring your teams to refactor the full interface — allowing your product(s) to maintain a cohesive feel, even while rapidly scaling.
You can measure cohesiveness in a few ways:
- Percentage of shared components between screens or between products — is the primary button in product A the same primary button in product B? The buttons can be themed differently, but are they leveraging the same underlying library?
- End to end journey mapping — recreate similar use case task flows in product A and product B, and measure the interaction pattern cohesiveness between the two. For example, try to change an account password in product A and then change the password in product B. Do these experiences diverge? Where? How? Why?
Take Aways
Investing in an enterprise design system will gradually yield more and more returns over time. However, the measures for success must be implemented as early as possible for the system to succeed. These metrics help drive the vision, process, and infrastructure that’s required to implement a design system at scale.
The metrics also help mitigate design paralysis. A design system should not be a style guide exercise. If your teams are hyper-focusing on colors and small nuances, then they are losing sight of the larger systemic picture — and you’ll not get the expected ROI.
A successful enterprise design system delivers cohesive, scaleable features in a way that’s efficient for both design and development. It is a comprehensive effort built on investment in infrastructure, process, governance, and people — and it is the essential ingredient to remain competitive in a hyper-evolving digital market.
