Design systems have become a standard in the digital industry. Virtually every big player uses one — from Amazon over Google and Airbnb to Uber. There have been numerous studies and reports on their efficacy in improving productivity, reducing bugs, and improving digital products (e.g., Boehm & Basili, 2001; Klüver, 2019; Loomer, 2016; Ray, 2018; Slack, 2019; Sparkbox, n.d.). And yet — as we have experienced in various jobs firsthand — it’s still a common situation that the value of having a design system has to be proven again and again.
For many features implemented in digital products, a simple competitive benchmark is enough to convince management, particularly in e-commerce. “If everyone else is doing it, we can just copy with pride,” is an often-heard statement. But the same standard seems not to apply to design systems.
This is most probably due to the fact that, at least at first, design systems are perceived as a very abstract investment — the value they’ll ultimately produce is not immediately visible and noticeable. On top, the upfront investment can seem huge to management compared to smaller, more concrete features design and development teams could be working on that produce more graspable value (and technical/design debt) more quickly.
Hence, the necessity to prove the value of a new design system beyond a simple competitive benchmark is a reality everyone who wants to get started with this topic must face, as Ben Callahan has already noted in a previous article on the topic (Callahan, 2021). We’ve personally done it time and again.
To make this reality more manageable for everyone, based on our experience, we’ve devised a general formula to approximate the return of investment (ROI) of a design system with a minimum of parameters. We see this as a handy complement to the great but a little more strategic advice Callahan (2021) already provides on how to sell a design system.
In the following, we will first give a very brief introduction to design systems. Subsequently, we’ll introduce our formula, elaborate on the assumptions we made, and explain the different parameters you can tweak. We’ll conclude with a specific example of how to apply it.
A Very Brief Introduction To Design Systems #
A design system is a “collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.” (Fanguy, 2019). Examples of design systems are Material Design by Google, Lightning by Salesforce, and Polaris by Shopify. Zalando also has a design system, about which they regularly write on Medium. In general, it is safe to say that design systems have become a staple in every serious digital organization, independent of the kind of industry.
It is important to note here that design systems should not be confused with mere style guides or simple component libraries (Speicher, 2020). A true design system spans the whole organization in terms of interaction and visual design, engineering, brand design, content, and so on. It introduces clear guidelines on how and why to use them, particularly in combination, on top of the ‘simple’ components.
“A design system [sometimes also called a ‘design language’] is a set of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels.”
— Fessenden, 2021
It allows for creating and replicating design work quickly and at scale, alleviating strain on design and development resources. It leads to less repetitive work, which enables a focus on larger, more complex problems, more creativity, more innovation, and therefore has a wide range of advantages:
- More quality and consistency (cf. Wong, 2019);
- Reduced time inefficiency;
- A unified language within and between cross-functional teams;
- Visual consistency across products, channels, and departments;
- An educational tool and reference, e.g., for quicker onboarding;
- A single source of truth for designers, developers, and all other stakeholders.
We believe that if Henry Ford lived today and worked on a digital Model T, he’d use a design system.
There are different ways a design system can be built and maintained within an organization, the two most popular ones being the centralized model and the federated model (Curtis, 2015). We base this article, and our formula, on the federated model, which means that designers and developers work out “what the system is and spread[ing] it out to everyone else. Without quitting their day jobs on product teams.” (Curtis, 2015) We do this for two reasons.
First, if you have trouble gaining management buy-in in the first place, arguing for a centralized model — with a dedicated team taking care of the design system — might only complicate the mission further. A federated approach is a good starting point because designers and developers can simply get working on the design system ‘on the side.’ It can then be transformed into a centralized model — or a hybrid one (cf. Manwaring & Mateo, 2018) — once the value of the design system has been recognized.