Organizations building a design system face a challenge in determining the impact it has on the organization’s portfolio. A design system is not a standalone, value-generating product, but it does accelerate how fast an organization can ship on-brand features and products. Once the design system is built, organizations struggle to justify the investment and even its existence, as it’s not easy to use traditional profitability metrics like ROI to justify the investment.
If this first-choice metric is not readily available, then how do you measure the success of a design system?
Lots of businesses get it wrong. Attempts to measure the design system's success by analyzing time savings produce suboptimal results if the adoption is not monitored. Anything slowing down the adoption must be analyzed and used as a source to improve the process, and the overall design system.
Within the organization, a design system competes with other solutions — external component libraries such as Material UI, or “homebrew” custom components, for example. Beating this “competition” signifies success for the design system, and this can be directly measured as the market share of the design system within the codebase.
A component with a low market share is an excellent starting place for conversations with product teams to better understand what is preventing adoption. Frequent interactions will support adoption by collaboration rather than by policy enforcement. The product team will build trust and confidence as long as their concerns are heard and addressed in a timely manner. Further adoption will impact the lean metrics — like cycle time and throughput — which can later be translated into a case to justify the design system to the business.
Lean metrics are the best way to measure the success of a design system. Market share is a driver of improving the results, making it the second-best metric to measure the success of a design system.
Codebase market share
The traditional way to measure performance against the competition is by looking at the market share. Organizations can apply this concept to the design system consumption in the product. Product teams leave a perfect trace when shipping features: the codebase. Not everything in the codebase is relevant to calculating the market share of a design system, but all the usages of the design system components would be in the codebase.
In this context, the market consists of the total usage of all components in the codebase. Subsequently, market share is the percentage of design system component usages against all component usages.
Ideally, we would measure the direct influence on the product value. For the design system, however, that value is impacted by the value of the product itself. Separating the impact of the design system is costly (if at all possible), making it difficult to implement as a repeatable analytics process.
The design system’s market share in the codebase is not a direct measurement of value. However, there is a connection: the incentive for product teams to use a well-crafted design system is efficiency, therefore the component library from the design system prevents the re-investment of resources on implementation.
Efficiency is transferable: time shaved off of one task can be invested in another. Although it's hard to track the direct impact on time saved, product teams choosing the design system will lead to improvement in the lean metrics. As a result, growing market share of the design system within the product is a proxy metric of improved time-to-market.
Displacing the competition
Evolving a product is often an exercise in adding new features or enhancing existing ones. The product’s success is affected by how fast the team can implement, test, and validate the changes with customers. The pressure created by this scenario is typically when product teams start creating custom components because the current library provided by the design system is not enough to satisfy the requirements. Over time, this leads to an out-of-date design system with even lower adoption rates.
Expecting the design system to evolve as fast as the products it serves is unrealistic, and the challenge exponentially increases with the number of products in the portfolio. Introducing components is an exercise in evaluating the needs of all products, as creating one-off components to serve a particular product need at the design system level is an anti-pattern. Changing existing components requires considerations of backward compatibility — otherwise, this can create issues for the entire portfolio. Those factors should be an incentive for product teams to use existing components, rather than be an excuse for creating custom solutions.
However, this is often the point where adoption fails, and the ‘competing’ solutions like custom components or existing, third party design systems creep in. This has a direct impact on user experience.
As an example, there is no question about the value-generation capabilities and overall success of the Steam platform. However, the platform could benefit from cost-optimization and branding improvements by reducing competition within their product. In the illustration below, you’ll see that Steam has a number of different implementations that serve the same purpose.
Source: Reddit, u/HobbylosUwU
If design system components are high quality, simple to use, and able to solve problems, product teams would have no problem choosing them over the alternatives. The collaboration between product teams and the design system team is not just about reducing these one-off implementations, but also as a source to improve the overall design system. The market share of the design system, visible to all teams consuming the system, is an instrumental tool to foster conversations and improve the governance model of the design system.
Measuring market share
Measuring the market share in a portfolio of projects is not a trivial task. The challenge is that complexity also grows when projects use different frameworks and libraries to build the final product. Ideally, the reports would be generated automatically as the codebase evolves. The reports also should be centralized, so that evaluation of the products’ portfolios can be performed easily. Having the results at hand also allows the teams to establish goals and monitor progress.
At Rangle, we are working on a proof of concept tool to automate the measurement of the market share as part of Radius — our quick start tool for your design system. Our goal is to have a plug-and-play solution that teams can adopt without requiring extra work — not even instrumenting the codebase. We are aiming to have the beta version publicly available by Q3 2022. The PoC will target React-based design systems at first, so we can validate the concept. Angular, Vue and Web Components are in the roadmap for support. You can learn more about Radius in this presentation recording from Web Unleashed 2021: Building Change Into Your Design System.