Last year, an investor we were talking to sent us a tweet that expressed her hesitancy about investing in products in the design systems space that went…

#DesignSystems are a zero-interest rate phenomenon

I dismissed this criticism as meme-of-the-day fodder. The idea behind the “[Trend] is a zero-interest rate phenomenon” meme is that [Trend] is only feasible when money is cheap to borrow or acquire. Examples of other zero-interest rate phenomenon from X-dot-com: Airbnb, DEI, React, and so on. Any [Trend] that costs more than it makes or has an indirect relationship to the profit machine is at risk.

Since that investor call and after months feeling the stale tech market, this idea resurfaced in my brain. I put value in design systems because I know there’s value in design systems, ergo there’s value in design systems. This logic is a perfect circle! It can’t be wrong.

So are design systems a zero-interest rate phenomenon?

No. Well, maybe. Depends on who you ask. If I need to build 5-10 pages, I can do those one at a time without much of a system. If I need to create or update hundreds or thousands of pages, or five different applications, then I need a system of components so that when I traverse those projects I don’t have to read a ten thousand page mystery to understand what the hell is going on. A handful (20~30) trusty components with some state-driven variants can power infinite applications with perfect consistency in a relatively short amount of time. That is certainly valuable.

To pull this off design should be working in components, development should also be in components, design and code should match, and it should all be well-documented, no problems, easy, dogs and cats living together! Turns out, not that easy. Behind the scenes it’s a lot of “getting on the same page” meetings and getting buy-in from the higher-ups.

“You’re going to spend how many months making components?”
“A lot.”
“And the app is going to look different?”
“Nope. Not if I do my job right.” (finger guns)

There’s no particular “hair on fire” problem that design systems solve that instantly sells to management. This can be frustrating to design system practitioners because we understand the intrinsic benefits of consistent UI over one-off solutions and maintenance nightmares. We trade immediacy in the short term for predictability over the long tail. In that way, design systems are a proactive solution to a whole host of likely problems down the road. Thus only forward-looking organizations can invest in design systems and to be forward-looking you probably need extra cash on hand… which might make it a zero-interest rate phenomenon.

But I believe design systems are an entirely different phenomenon all together. Times I’ve seen executive buy-in go smoothest are when a person in a position of power cares about design and says, “Our app looks like shit.” Now it’s a hair on fire problem.

Design systems are an event-triggered phenomenon

In Dungeons & Dragons and other action economies there’s a concept of “Event Triggers”. For example, a treasure chest looks like a normal treasure chest but turns into a monster when you try to open it. An event (opening the chest) exposed a problem (a monster) and now you need a solution (might and magic) to solve the problem. Design systems are a similar mechanic because the problems they solve are almost theoretical until you trigger an event.

Here’s some event triggers I’ve come across in my years of design systems work…

  • Marketing commissioned a new logo, brand, and design language
  • Oh, those brand updates rolling out in TV commercials next month
  • Oh, and we’re launching a new line of hardware tablet devices
  • The great re-platforming initiative
  • An accessibility lawsuit
  • A font license lawsuit
  • Good design, poor code implementation
  • Interface inventory reveals 60 different buttons and 12 site headers
  • The CEO gets fired and you need to remove his face from the entire site
  • 10 designers with high autonomy and no design review process
  • 10 engineers with high autonomy and no design review on code changes
  • One department with more autonomy than the other because it “makes the money”
  • Company wholesaled the entire off-shore team and 150 new people start next week
  • A year of heavy turnover and the time bomb of technical debt goes off

Once your party has stepped on a trigger and encountered a monster, the desire to be more proactive and prepared next time goes up. I’d love to know your design system dungeon crawling stories but the lesson is this: Design systems become a “hair on fire” problem and get buy-in when people in the organization encounter a catastrophic or near-catastrophic event. Design systems are not a cure-all, but they are an aspirin for a very common set of headaches.