On Theme S1 Minisode 1

Are design systems in the trough of disillusionment? Elyse explores the past decade of design systems and what we're missing in this pre-season one minisode. 

Transcript

Elyse: 0:01

Hey, Elyse here. Thanks for being an early subscriber to On Theme, Design Systems in Depth. I'm so thrilled that since releasing the trailer, there's already a hundred 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 am counting the days till the first episodes can go live. While we're waiting, I figured I should introduce myself. So, this is the first of a couple minisodes that are beaming straight to early subscriber ears only. Here's the TLDR. 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 on LinkedIn, Luke Murphy at Zero Height posted about where design systems are on the hype cycle. This is from Gartner's 2024 UX Hype Cycle Report, and the hype cycle is innovation trigger, Peak of inflated expectations, trough of disillusionment, slope of enlightenment, and plateau of productivity. If you haven't heard about this, go check it out. I've got to say, I was pretty surprised to see design systems at the peak of inflated expectations. I would have already put us 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, deprioritization, 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 was starting this show. 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 then if you simply have a design system and you shake it hard enough, efficiency falls out.

Dan Mall: 1:54

What a lot of teams do is they start design systems by trying to solve any imaginable UI problem. Let's make cards, avatars, breadcrumbs, grids, dividers, all those things. And then what ends up happening is your design system gets 1 percent adoption because out of 100 components that you just created in advance, one of them gets used. And I think that discourages teams. I think it's actually like a psychological problem more than it is a technical problem. I think it's like, man, we spent. We spent six months working on this, and only one out of 100 components are getting used.

Elyse: 2:25

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 important. That project reduced design implementation time on new projects from 35 hours to 12 hours. And that was my first taste of the system's life. At RetailMeNot, this was in like 2013, I helped create a proto design system called Roux, and we used this to ship a site wide redesign. We hand rolled an express app doc site to deliver sets, which we called pantries, of handlebars, templates, and components that we called ingredients. These days, you just spin up an npm package and a storybook instance, but it was all handcrafted back then. Bless our hearts. 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.

Brad Frost: 3:42

Those tools came out then. Things like ES modules that actually allowed us to deliver these things as consumable components That was like 2016 or something like that. There's these kind of CSS people who are like putting this stuff together JavaScript is still kind of gross and lacking some pretty core things, but great tools like jQuery and then jQuery UI came there was a lot of the whiffs of what was to come in that era. And then, yeah, the tooling caught up and things got created that allowed for the waters that we swim now to be possible where you're able to be like, cool import button from from our design system and it just shows up.

Elyse: 4:27

That was Brad Frost, and you'll get to hear more about the story of early design systems in upcoming episodes with him and Jina Anne. 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, and 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 engineering teams to stop writing the front end in Java and instead switch to React. We later used the system to coordinate the rollout of a new visual language across the product and convert everyone from Sketch to Figma. From there, as PM, I managed a rewrite of the original React components that over 150 teams love to hate, to a more modular system. Now I'm a team of one at a much smaller health tech 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 work looks like. I'm telling you this less to establish my bona fides 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 into 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 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. 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. 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, similar tools launched, and communities like IntoDesignSystems blew up. From the inside, was this the peak of overhyped expectations? I got back into the design system space about a year ago after a career break. And I realized design systems are just how UI gets built now. And we're over here having like 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're 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. He says, building a design system is tough in the best of times. It's all the more difficult in large orgs with disparate and disconnected teams. That's ironic as that's 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 bolt challenges of making a system that actually works for all involved. There will be hiccups, mistakes, misunderstanding, you name it. You'll struggle with transition pains as teams move your new fledgling system. None of these will fall in the realm of fun for anyone.

ToniAnn Drenckhahn: 8:14

I've worked on some really amazing design systems, some really technically cool design systems that are doing really unique things. I've worked on very basic design systems. And at the end of the day, none of them would be successful without figuring out how it works for everybody, without figuring out what your operations model is and who you're talking to, and if the people who are consuming your system actually trust you at the end of the day. We can fix components. It's a lot harder to fix relationships that are broken once they've gone down that path.

Elyse: 8:46

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. And 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 anymore. 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 eight year old legacy codebase. Or make our iOS, native, and Android apps look and function like the web app. 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 organizations 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 an infrastructure or what? Why are we having to do yet another front end framework refactor? Do we let our design mocks get out of date? Or do we spend designer hours updating old mocks with new changes? How do we work better with content or brand and marketing? Why are the engineers so unwilling to upgrade the library version? 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 really need to do things differently because there's a ton of value in design systems, but we're missing something. I think we are missing something, and I think it's a skill set that has nothing to do with design or engineering. In the early days, we were just engineers and designers. Now we are a critical bridge between disciplines. We are the owners of tools that save our companies millions of dollars. We are blazing a trail of how UI gets built. I'm just not sure we 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 code bases and ship incremental improvements. From our vaunted design leaders, how to see the whole forest and not just the trees. We are not just designers and engineers. We are 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 system 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 are out there doing the damn thing, and we can learn a ton from each other. Don't you think it's time we write that handbook? 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 roller coaster? 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 trying to build the best design system and start building systems that actually work for our teams. I can't wait to drop the wisdom, the experiences, and the spicy takes of on theme podcast guests into your ears in January. Talk soon.