< back to all blog posts

Stop calling your design system a “product”

For years, the design community has referred to design systems as products. We tried to gain more leadership support and investment in creating and maintaining design systems by calling it a product. That makes sense; design systems are similar to software products made by designers and developers. If leaders understand the importance of products, they’ll realize the importance of design systems, right? Theoretically, yes, but realistically, that depends on their product experiences.

It is rare for products to launch smoothly or iterate at an ideal rate (if ever). Leaders who have experienced this might think the same applies to design systems. Here are some reasons why saying a design system is a product is a mistake.

Illustration of a person wearing a design system police shirt gesturing stop

(⚠️ Depending on your past experiences creating features, apps, or sites, this might be a little triggering, so feel free to skip this part.)

traffic cones in a line

One-and-done

Some companies have released products or features and never iterated on them again. Perhaps a future iteration was intended, but it never happened for several reasons. Even though the user experience could be better, it hasn’t caused the app to go down, and security vulnerabilities haven’t appeared. To some, this seems “good enough.” Let’s imagine stakeholders apply this mindset to system design. If that’s the case, then a basic design system would suffice–after all, it won’t crash the app. It doesn’t pose a security threat, right?

An MVP is fine… for a while.

Sometimes features get scaled back, and the company releases an MVP, which feels good enough for now. As with one-and-done thinking, stakeholders may focus on just launching the MVP to iterate later. However, as we know–later never comes. While there might be an intention to iterate on an MVP design system, it can become a lower priority than other things.

Design systems can easily get deprioritized compared to money-generating features.

Products need to provide business value

Some believe that only revenue-generating products or features deserve attention. A company needs to make money to stay in business, so many choose to invest in new products or features to sell. That mindset makes sense, but when stakeholders look at design systems through that lens, design systems don’t directly generate revenue. So there is no perceived business value, even though we all know that’s not true. Design systems can easily get deprioritized compared to money-generating features.

Passion/hackathon projects don’t need funding

Some believe that if people are passionate about creating a feature, the business won’t need to invest in it. It’ll get done anyway. Many teams often create design systems out of necessity–to make things more efficient in their day-to-day work as designers or developers. Many teams also fit this in with other project work, picked it up on the side, or even worked on it in the evenings and weekends. When stakeholders learn that the design system was a passion project, they’ll see they were able to get something for “free.” If they got something for free, then it’s not something they have to resource (i.e., invest in) because people will continue to do it out of their passion.

traffic cones in a line

Let’s refer to design systems as infrastructure

When stakeholders perceive design systems as products, it’s too easy for them to justify not investing in them. Instead, we need to refer to design systems as a crucial investment. We should be referring to design systems as infrastructure.

In general, infrastructure refers to the services, facilities, and systems necessary to function for governments, economies, companies, and so on. If we didn’t have an infrastructure to provide internet, then businesses couldn’t operate. If we didn’t have utilities like electricity and water/sewage, our households wouldn’t function.

Likewise, framing design systems as infrastructure connotes how essential it is for the company and how important it is to resource it properly.

traffic cones in a line

Why infrastructure resonates better

Infrastructure resonates better with stakeholders because of the mental models they already have around the term. Let’s look at how this perspective can help.

  • Stakeholders might already be familiar with DevOps teams, which provide infrastructure and support to their software development teams. DevOps teams ensure the behind-the-scenes support needed is up and running.
  • Like any utility, once installed, it will need maintenance to keep running. It can’t be an MVP that we can forget about iterating on. It’ll provide resources to manage its evolution and maintenance.
  • Infrastructure also implies that it’s essential for the team’s success. Companies need to resource crucial functions, not get them for free as passion projects. If electricity were a passion project, we’d all be in trouble!
Illustration of a worker with a saw representing an infrastructure builder

Transitioning from using “Product” to “Infrastructure”

Rather than referring to your design system as a “product,” try referring to it as “infrastructure” and see where that takes you. Making the shift isn’t too tricky, and you can start now. If you have a design system team, tell them about the switch. Be sure to mention the importance behind the “why” for the change. It’s not a matter of semantics; it’s a matter of being accurately recognized and resourced. From there, let the teams that consume your design system know–designers, developers, content writers, marketing, brand, and so on. I recommend mentioning this shift at a team or organization-wide meeting to get the visibility this deserves. It doesn’t have to be a lengthy presentation, but an announcement along with an explanation of why. Visibility is essential for this cultural shift. An email announcement will only get ignored. As you meet with leadership, phrase the design system as infrastructure and explain why. If they question you, you have this article in your back pocket to reference.

How I got traction by calling our design system “infrastructure”

At a previous company, I walked executives through our design system, including a proposal of where we needed to take the design system. Because we needed more engineering resources and I was talking to our CPTO, I referred to our design system as “frontend infrastructure.” This term resonated well as no one flinched or disagreed with its purpose. Without getting into too much detail, they agreed to give this more attention and provide an engineering counterpart to my role to help streamline things on the code side and increase adoption.

Do you think we should call design systems something other than “infrastructure?” I’d love to know! If you try making this shift or pitching design systems this way, let me know how it goes. You can always reach me on zheroes, our Slack community. Sign up here for free.