The Economics of Design Systems: Why Cost Should Be Your Focus
A Product Design Management Case Study
Throughout my career I’ve worked with several design systems in a variety of companies from small startups to huge multinational corporations. I’ve seen some that have been highly successful and some that have been abysmal failures. In all cases I’ve seen one thing that the successful systems all had in common where all the failures missed the mark.
In this article, I’ll share some of my experience using, creating, and managing design systems, and I’ll delve into a fundamental question: What should be the central focus of a design system?
I’m going to assume that I don’t need to explain the importance of a design system. Any company that is creating digital applications should be using one, or in rare cases, several. Most experts will agree that a robust design system is as basic a need for your product development teams as the desks they sit at and the computers they work on.
While I agree that a design system is essential, that doesn’t mean that it should never have to justify its own existence. When making the case for a design system, there’s a fairly standard list of reasons why a company should invest in one:
- Enhancing Consistency
- Streamlining Collaboration
- Reinforcing Brand Identity
- Improving Usability
- Scaling Design Efforts
- Ensuring Accessibility Compliance
- Accelerating Development
- Onboarding New Team Members
While these are all important reasons, what if I told you that focusing on these objectives is the very reason I’ve seen design systems fail? In my experience, whether you’re making the case to obtain budget approval for a design system, unifying existing design systems, or you’re evaluating the current state of an existing system, this should be your list of top considerations:
- Cost reduction
- Cost reduction
- Cost reduction
Cost reduction is the only thing that can truly justify the expense of a design system. Cost reduction is not just an objective; it’s the single most important reason for any design system to exist at all. It’s really this simple. Design system projects that have cost reduction as a top priority succeed. Projects that lose sight of this will fail.
If you do happen to be in the position of needing to get funding for a design system project, I’ve even created a handy slide deck for your presentation.
Okay, I’ll concede that your higher-ups might want a little more than that. So let’s revisit that list from earlier and revise it slightly.
- Cost reduction through enhanced consistency
- Cost reduction through streamlined collaboration
- Cost reduction in brand identity enforcement
- Cost reduction through improved usability
- Cost reduction by scaling design efforts
- Cost reduction by ensuring accessibility compliance
- Cost reduction through accelerated development
- Cost reduction in onboarding new team members
Hopefully you’re seeing a trend here. But if simply announcing, “we’re going to focus on reducing costs!” were to make it so, no project would ever fail, right? The reality is that declaring your focus and maintaining your focus for the duration of the project are two very different things.
In order to help you avoid straying from the path, I’ve outlined what I’ve found are the most important things you can do throughout your design system project.
Be clear in your objectives
The eight points above can not only be guideposts for the development of your design system, but they should serve as objectives to measure its success. To see how, let’s dive deeper into some of these points.
Points one and three have to do with brand enforcement, which usually is justification for a design system in itself. So why should you refocus on cost reduction rather than just brand enforcement? I’m not challenging the importance of branding and design consistency. But is that really even the objective of the UX or product design team? To answer that question we have to go back to the basics and ask, “what’s the difference between a design system and a style guide?”
Style guides have been around since long before UX designers. The preface of the NASA style guide from 1976 says, “This manual is a reference book for NASA designers. It is the official policy document regarding NASA identification (use of logotype), communication in general and sets the tone and level of quality for all NASA graphics.” In other words, the purpose of this print document in 1976 is what most people (incorrectly) would say is the purpose of a design system today.
So when someone says the number one reason for a company to adopt a design system is for branding and design consistency, what they’re really saying is that the company needs a style guide, not a design system.
Am I just splitting hairs over who-cares tech jargon? No. Because while a design system serves much of the same purpose of a style guide, the difference is that a design system shouldn’t just tell a designer how they should use a visual asset, it provides the visual asset in a reusable format (more on that later).
So we’ve established there’s a clear difference between style guides and design systems, and the reason this is important is they have two different objectives. The objective of your style guide is to enforce the brand, but the objective of your design system should be to reduce the overhead that’s associated with enforcing the brand.
As we look at the rest of the objectives they are all important even without the “cost reduction” prefix. But as you look at each one of them through the specific lens of “how is this a design system objective?” you can see that each one comes down to cost savings or cost mitigation.
Make sure you know who your stakeholders are
One of the pitfalls of design system projects is not knowing who you’re building it for (hint: it’s not just the designers), and who should be considered a stakeholder.
One of the more obvious groups that has a stake in the project is the engineering department. At some point the developers are going to have to build what the design team hands over to them, so it should go without saying that they need a seat at the table. In my experience, collaborating with the dev teams early and often not only brings an important technical perspective into the discussions, but it dramatically improves adoption when they feel like they have a vested interest.
One of the often overlooked stakeholders that should be included in the project is the marketing department. I’ve established that when it comes to creating a style guide and deciding how the brand is going to be represented, that’s not really a function of product design (as hard as that may be for some product designers to admit). The marketing department is the arbiter of the brand and corporate identity. At some companies I’ve been with, marketing has welcomed the opportunity to collaborate with the product designers. Others, not so much. But either way, if there’s any hard-earned wisdom that I can pass on it’s this:
Never go to war with the marketing department.
Whether they do or don’t want any design input from our side, marketing typically has the final say on what’s “on brand” and what isn’t. And it can be incredibly frustrating when product and marketing disagree on this, especially when you’re already well down the design and development path. The style guide is a product of the marketing department, and the design system, for the sake of cost savings and mitigating expensive reworks, MUST be informed by the corporate identity style guide. That means the marketing department should be involved early in the development of your design system.
Collaborating with marketing can be difficult because at many companies there’s a wall between product and marketing, both literal and metaphorical. If your company doesn’t have this, great! If you know exactly what I’m talking about, then swallow your pride and start reaching out. In the long run it will save you time and frustration and will save the company money.
Never create a design system in a silo
At one of my former companies (a large multinational corporation), after much pleading, groveling, and cajoling, our department had obtained budget approval to create a design system to unify our North American brands. With limited internal resources we decided to outsource the project to a firm that specializes in creating design systems. We met with the contractors weekly to provide direction and oversee the progress. We provided them with a copy of the corporate style guide and provided samples of what our corporate “look” should be.
Over one year and $150,000 later, we had a design system that we were quite proud of. We thought it checked all the boxes and were excited to see it be adopted and used throughout the corporation. However, when it was rolled out to the rest of the company it landed with a thud. No one was happy to have it.
What happened? For starters, the culture at that company was highly transactional and territorial. There was a stated effort to unify the brands, but most of our subsidiary brands had come into the fold through acquisition, and were therefore used to a certain level of autonomy. Everyone liked the idea of aligning the brands, but the unspoken (and sometimes spoken) caveat to that was, “as long as that means everyone else aligns with us.”
Because of this it was decided early on, that it might be better to keep the design system project low-key, almost skunkworks-like, until it was ready to be used, and at that time it would simply be distributed to the company with the mandate that all subsidiary design teams and contractors start using it. When I asked, “how are we going to encourage adoption?” I was told, “don’t worry about that. We’ll just tell them they have to.”
But as the saying goes, you catch more flies with honey than vinegar. And despite representing the top level of corporate design, we didn’t have a stick big enough to force the other design teams around the world to comply. Even if we did, is that really how you want your system to be adopted? If it’s forced upon them and they had no input or involvement in its creation, would you expect any other team to happily disrupt their current paradigm to accommodate your new system?
The design system was used on a few new products, but quietly went the way of many design systems, which is in the folder of legacy designs that are occasionally referenced but rarely used. The companion code library was never built, and the linkable, reusable visual components were never used in a way that increased design efficiency and scalability. In other words, we had built a style guide, not a design system. I had to accept that the project had objectively failed both in terms of what a design system should be, and in what it should deliver.
In retrospect, the major failing of our design system project was its narrow focus on brand enforcement and compliance, overlooking the crucial aspect of cost savings. Had we centered our efforts on demonstrating how the design system could lead to significant cost reductions, the outcome might have been different. Here’s how a cost-centric approach could have saved this project:
1. Early Involvement and Buy-In Across Departments
By highlighting the cost-saving aspects, we could have involved other teams early in the process. Demonstrating how the design system would streamline workflows, reduce time on revisions, and accelerate project completions could have piqued the interest of various departments. This approach would have fostered a sense of ownership and collaboration, rather than the resistance met with a top-down enforcement.
2. Demonstrating Tangible ROI
Instead of solely focusing on brand compliance, emphasizing the return on investment from a cost perspective could have made a more compelling case. For example, showcasing how the design system reduces the need for external design resources or cuts down on the time-to-market for new products would have clearly illustrated the financial benefits, making it an attractive tool for all teams, especially the subsidiary brands that were used to having autonomy.
3. Adapting to Diverse Needs While Reducing Costs
Recognizing the diverse needs of different divisions and subsidiaries, the design system could have been developed with flexibility in mind. This approach, coupled with the primary goal of cost reduction, would have allowed different teams to see how they could adapt the system to their specific needs while still reaping cost benefits.
Had the focus been on demonstrating the design system as a tool for cost reduction and efficiency, rather than merely a means for brand compliance, it could have been perceived as a beneficial, value-adding tool across the company. This shift in focus might have led to its successful adoption and long-term utilization.
Buy it, don’t build it
One of the first questions when considering how to approach a new design system is usually, “should we build it ourselves or get one off the shelf?” To answer that question you need to consider the primary objective of any design system.
Say it with me… Cost reduction!
I’ve told you about a bespoke design system that was built from the ground up that was an expensive failure. But some time later I started with another, much smaller company, and I asked about their design system. “We don’t really have one.” Alarm bells started going off. How can they possibly be working without a design system? “We just use Tailwind.”
That was my first introduction to Tailwind, and I’ve since adopted the mantra that, “Tailwind is always the answer.” If you don’t know, Tailwind UI is a robust component library created around a utility-first CSS framework. Yes, it’s a code library. So why would the design team start with a code library? Because of cost reduction! Tailwind is cheap! Compared to what it would cost a dev team to build a similar set of custom components, it’s a steal.
But a code library doesn’t help the designers, does it? Actually it does. A lot! Remember, the difference between a design system and a style guide. A style guide tells you what something should look like, whereas a design system should provide you with the components to build it. This applies to the developers as well as the designers. Developers shouldn’t be building one-off components with each new project. Ideally they should be able to look at the design that’s handed to them and be able to break each page into its core components, then assemble the code from an existing repo. Component libraries like Tailwind make that possible. And by starting with the needs of the developers already being met, you’ll have far more luck driving adoption than throwing dozens of new components at them and saying, “here, make these. We might need them someday.”
Just to be clear, Tailwind isn’t for designers, which is why you need a companion visual library like Flowbite. Flowbite gives the product designers all the Figma components that go along with Tailwind. So yes, you’ll have to buy licenses to both Tailwind and Flowbite, but trust me, it will be tens of thousands of dollars less than what it would cost to build it yourself.
In the car enthusiast world there’s a long-running joke. “Miata is always the answer.” What should my first project car be? Miata. What should my first track car be? Miata. What car should I buy for my teenager? Miata. Why is Miata always the answer? Because it’s cheap, easy to customize, and it has enough power to have fun without getting yourself into too much trouble. Tailwind + Flowbite is the Miata of the design world. It’s cheap, it’s easy to customize, and it’s powerful enough to do what you want. If you ask me where to start with your design system, Tailwind + Flowbite is always the answer.
What if you’re not starting from scratch?
Maybe you already have a semi-functional design system and you’re not looking to start over. Or perhaps you have multiple design systems that you’re trying to unify. Is the answer still to buy an off-the-shelf system? Probably.
Like most third-party component libraries, when you buy the Flowbite library it’s very generic looking. This is intentional because it’s up to each individual user to apply brand colors and specific styles to the components. In my experience, even if you’re unifying components from existing systems, it’s more cost-effective to buy a library and adapt it to look like your existing components than to start copying components and trying to mash them together.
Even if you have a single, mostly-complete design system, my decision on whether to continue with what you’ve already got vs. buying something new would depend largely on the quality of the existing system and its components. Are they properly nested and linked? Do they follow Figma’s best practices? Are your styles tokenized using Figma’s newest dev mode features? If there are existing code components, are those properly documented and linked to the visual components? If the answer is anything less than a confident yes, you’re better off buying the third-party system and adapting it to match your old design system. That can be really hard when it feels like you’re throwing out months of good work, but it’s not a case of throwing the baby out with the bathwater. It’s a case of letting go of a sunk cost.
Let go of sunk costs
When I was hired at another multinational corporation, I was asked to help finish their design system. I gave them my “buy it, don’t build it” pitch but it was too late for that. The genesis of this project was the need to unify multiple design systems that were in various states of completion, and long before I was involved the decision was made to create a new, bespoke design system. By the time I came onboard, this custom design system had been an ongoing project for nearly two years, with 2 full-time designers and an entire dev team working on it. It was 90% complete and a lot of the design components had already been coded by the dev team.
The estimated costs for this system were now in the seven figures, but there was still so much left to do that it might have been cheaper to start over with Tailwind. But if they were to throw out the work that had already been done, it would essentially be admitting most of that money was wasted. It was a precarious position and the pressure from the top was mounting. The feeling was, “if we can just put a few more months of work into it then we can get it to a point that we can justify all the previous expense.”
In business school they teach a concept called sunk costs. This is the idea that money already spent should not unduly influence current decisions, as these costs cannot be recovered. The trap of sunk costs is a common pitfall, leading companies to continue investing in projects that are no longer viable simply because they have already invested significant resources. In the case of this design system, the company was facing a classic sunk cost dilemma.
There were many reasons that this project had turned into a tar pit, not the least of which was the lack of a clear roadmap, which had led to massive scope creep. When you’re building a design system it can be tempting to look at something like Material Design, Fluent, or Fiori and say, “we need everything they have.” But those systems have evolved into their current state over nearly a decade with millions of dollars in support. They’re also built for specific ecosystems that may or may not be relevant to your product lineup. When you compare a system like Tailwind+Flowbite to these systems, it looks miniscule in the amount of components it contains. But this is a good thing! The components included in a third-party system will cover 90% of your use-cases. Not only will it give you a clear, flexible framework to build on, it will help avoid the pitfall of endless scope creep.
When I was promoted to management, ownership of this design system project fell on me. My first order of business was to stop pumping more money and resources into it. There were a lot of factors that I considered, but ultimately I said, “90% done is 100% good enough.” The system wasn’t perfect but it was robust enough to do the job.
Another thing you learn in business school is that the difference between a product and a project is that a project should have a clear start and end, while a product’s life is indefinite. I wasn’t killing the product, but I was putting an end to the project. There will always be new one-off components that are needed, and design system governance requires finding the balance between allowing these one-offs vs. requiring that designers stick to the basic components. In this sense, no design system is ever really complete. Trying to build every conceivable component into the initial release of your design system is an expensive mistake. And as for the ongoing development of the components, we would have those built and checked into the design system repo as they came up in individual projects. As great as it was having a dedicated dev team doing nothing but building out system components, the expense had defeated the main purpose of even having a design system. That purpose, in case you’ve forgotten, is to REDUCE COST.
Conclusion
Writing this article has given me the chance to reflect on the many different design systems I’ve worked with, and the different design system projects I’ve been a part of. The cost of some has been in the thousands while others have literally been in the millions. It’s interesting that the least expensive have been the most successful. But that shouldn’t be all that surprising when considered in terms of ROI. Although investment in a design system is a necessity for any tech company, there is most definitely a point of diminishing returns. Investing conservatively and strategically will help your company avoid reaching that point.
At the beginning of this article I posed the question, “What should be the main focus of any design system?” Hopefully the answer is clear: cost reduction. Whether you’re starting fresh, unifying old design systems, or updating an existing system, by using cost reduction as your north star you’re far more likely to build a design system that meets the company objectives and makes you look like a rockstar!
The design systems mentioned aren’t show here because they are proprietary and not available to the public. Generative AI was used to create the graphics for this article.
