are design systems in the trough of disillusionment?

Hey, Elyse here!

Thanks for being an early subscriber to On Theme, my new design systems podcast! I’m 🤩 thrilled that since releasing the trailer, there’s already 100 of you subscribed.

I’m putting together a seriously exciting list of folks to interview on the podcast, from designers to engineers to execs to product folks. We’ve already started recording and I’m counting the days til the first episodes can go live!

While we’re waiting, I figured I should introduce myself, so this is the first of a few minisodes that are beaming straight to early subscriber ears only!

🎧 Listen now on your fave podcast platform (13 minutes). (Or keep reading… but tune in to the audio for quotes from upcoming guests!)

Here’s the tl;dr — I’ve been in design systems since before it was design systems, and I think this industry is due for a major reinvention moment.

The other day, Luke Murphy at Zeroheight posted about where design systems are on the “Hype Cycle”:

I gotta say, I was pretty surprised to see DS at the “peak of inflated expectations” — I would have put us already in the “trough of disillusionment”!

Luke says, “I think we’re already starting that slow slide into the trough of disillusionment. Since 2022, we’ve seen countless examples of mass layoffs, design system de-prioritization, and an industry asking how they show value to the people who will give them money and agency to actually build and support a design system. …we’ve done ourselves a disservice by failing to gain a foothold within our organizations.”

I couldn’t agree more, and that’s one of the main reasons I’m starting this podcasts. Design systems are just how we build UI now — big company or small! What needs “rethinking” isn’t whether or not design systems should exist.

What needs rethinking is the idea that there is one ideal true way to make a design system, and everyone should do it that way, and that if you simply have a design system and you shake it hard enough, efficiency falls out.

✋ Let’s back up. How did we get here? For those of you who don’t know me, my name’s Elyse, and I’ve been working in design systems for… basically my entire career.

I graduated in 2007, in the height of that recession, with a design degree and five years of experience in Geocities websites. Design Systems didn’t exist back then but in hindsight, it’s pretty obvious how I got here.

At one of my first jobs, I took a gigantic garbage fire of a CSS file that came with every instance of our white-label product and refactored it into a commented and organized template, free of background: red !importants.

That project reducing design implementation time on new projects from 35 hrs… to 12 hours. That was my first taste of the systems life.

At RetailMeNot, I helped create a proto-design-system called Roux, which we used to ship a site-wide redesign. We hand-rolled an Express app docs site to deliver sets (“pantries”) of Handlebars-templated components we called “ingredients.” These days you’d just spin up a npm package and a Storybook instance, but it was all hand-crafted back then. Bless our hearts. (Seriously, check out these excellent old talks!)

After the 2008 recession had eased and companies were growing again, we saw a proliferation of tools. Bootstrap in 2012, React got big after 2013, Material UI launched in 2018.

(p.s. go listen to the minisode to hear quotes from Dan Mall, Brad Frost, and ToniAnn Drenckhahn, some of my early podcast guests!)

 2015 to 2016 was really the beginning of Design Systems as we know it now: isolated packages of code components, publishable design libraries, tokens, contribution models. Nathan Curtis published his now-infamous contribution model article in late 2015; the first ClarityConf was in 2016.

In 2017, I was tapped to start the first Design System at Indeed. The first set of components we built made it possible for eng teams to stop writing frontends in Java and instead switch to React.

We later used the system to coordinate the rollout of a new visual language across the product, converting everyone from Sketch to Figma. From there, as PM, I managed a rewrite of the original React components (that over 150+ teams loved to hate!) to a more modular system.

Now, I’m team of one at a much smaller healthtech company, Color Health, and I’m trying to break free of all the design system shoulds, and figure out what the next decade of design system works looks like.

I’m telling you this less to establish my bonafides and more to say that it’s really different now. I’ve seen Design Systems go from a twinkle of an idea to an established niche that new grads actively try to “break into”. 

The problems we’re solving now, in 2024, going in to 2025, are so different than the problems we were solving a decade ago. This whole niche was spawned from the frustration of literally having to update the hex color of a Button across 80 different page files.

Design systems and the idea of making a career building them grew up in a zero interest rate decade. Investment money was basically free, literally zero interest, and the idea of business success was rapid growth and figure out monetization later.

Design systems work was an outgrowth of our tools developing rapidly, our needs changing, our growing ability to solve our own pain points. We were basically going, Whoa, what if we could keep design and code more in sync and then building tools to make it happen.

This long view perspective matters, I think, because if you just look at what's out there now, you can get the idea that a design system is a collection of Figma plugins and code libraries and tokens and arguing on the internet about the broken promises of systems.

In hindsight, 2020 to 2022 feels like peak Design System saturation. Big teams were hired, Token Studio and similar tools launched, and communities like Into Design Systems 💞 blew up. From the inside, was this the Peak of Overhyped Expectations?

I got back into the DS space about a year ago, after a career break, and realized, design systems are just how UI gets built now, and we’re over here having an existential identity crisis!

Yes, layoffs were brutal, but… if we aren’t delivering on the promises of design systems, what are we doing? (And who is making these promises, anyway? Oh right, …us.) What do you mean, we are struggling with adoption? What is this work all about, if it’s not about tokens and rectangles and Figma plugins?

I really like how PJ Onori put it in his post “Design Systems are a People Job”: “Building a design system is tough in the best of times. It’s all the more difficult in large orgs with disparate/disconnected teams. That’s ironic as they’re where systems can provide serious value. You’re going to push up against human dynamics like skepticism, disagreement and territorialism. You’ll face nuts-and-bolts challenges of making a system that actually works for all involved. There will be hiccups, mistakes, misunderstandings — you name it. You’ll struggle with the transition pains as teams move to your new, fledgling system. None of these fall within the realm of “fun” — for anyone.”

Design Systems started as designers and engineers just building tools for themselves, that helped them codify and simplify the design to eng handoff process. These days, there’s an incredible breadth of abstractions, libraries, and tools.

But one thing hasn’t changed: we’re still figuring out how this whole “design systems” thing is supposed to work.

The problem is, there’s no one right answer. A startup functions differently than a global enterprise. A SaaS software platform needs different components than a consumer-facing app. A React shop needs different tech tools than a multi-platform multi-brand organization.

Most saliently, we are NOT trying to solve the problem of having to update button instances across 80 different pages.

The problems we’re trying to solve these days are more like, create visual consistency in two very disparate products after an acquisition, oh and one of them is a massive 8 year old legacy codebase. Or, make our iOS native and Android apps look and function like the webapp.

We’re Staff Designers and Senior Software Engineers; we’re Design System Directors and Design Ops and people managers. We’re supposed to know what we’re doing!

But at no point did I receive a handbook on this!

Our hard-won early efforts were fruitful: components are normal now. We understand that a design system, whatever that means to you, is a valuable and necessary part of a modern tech org.

What we’re trying to sell into our orgs isn’t about components or libraries or design abstractions. We’re selling design-eng iteration, UI and code quality. We’re selling “if you have this, we’re not a cost center, we’re going to help our teams be more effective, we’re going to save money and time.” We’re selling organizational behavior change.

But as practitioners, I hear us asking questions like these:

• How do we explain to leadership that the design system is never “done”?

• How do we balance design and product innovation with consistency?

• Is it a tool, or a process, or a product, or infrastructure, or what?

• Why are we having to do yet another frontend framework refactor?

• Do we let mocks get out of date or do we spend designer hours updating old mocks with new changes?

• How do we work with content, or brand and marketing?

• Why are the engineers so unwilling to upgrade the library?

• Is there a way to prove that design and eng handoff is better now? Is it better now?

• How do I keep my team from getting laid off?

Every conversation I have with a design system practitioner seems to conclude with, and we need to do things differently because there's a ton of value in design system, But we're missing something.

I think we’re missing something… and I think it’s a skillset that has nothing to do with design or engineering.

In the early days, we were just engineers and designers. Now, we’re a critical bridge between disciplines, the owner of tools that save companies millions of dollars, blazing a trail of how UI gets built. I’m just not sure we’ve fully internalized that yet.

From our counterparts in product, we need to learn to be outcome-driven (and prove it); from our buddies on the sales side, we need to learn to be storytellers and build relationships. From our experienced engineers, how to spelunk in legacy codebases and ship incremental improvements. From our vaunted design leaders, how to see the whole forest and not just the trees. We aren’t just designers and engineers: we’re Design System people.

There’s still no handbook—but there are a lot of extremely experienced Design System practitioners out there.

Collectively, I think we do have an idea of how this whole design systems thing works. We’ve been shipping for a decade. We’ve seen economic highs and lows. We survived the redesign, the reorg, the rebrand. We’re out there doing the damn thing, and we can learn a ton from each other.

It’s time we write the handbook, don’t you think?

We might be in the trough of disillusionment when it comes to the broken promises of design systems, but you know what’s next on that hype cycle rollercoaster? The slope of enlightenment.

I think the future of design systems is bright: I think we’re going to get fully integrated into design and eng delivery processes in new ways, but only if we stop building the best design systems and start building systems that work for our teams.

I can’t wait to drop the spicy takes, wisdom, and experience of On Theme guests into your ears in January.

Talk soon!

💓 Elyse

p.s. Where do YOU think design systems are in the hype cycle? Email me back, I want to hear your thoughts!