Design Systems Burnout

Yesterday I got coffee with a pal who I used to work with on a design systems team that no longer exists. And, as we were talking, we both realized that everyone we worked with no longer even does design systems work these days. They might still be interested in the subject, might still write about it, but they no longer actively work on a team that’s dedicated to design systems.

That’s weird! Why is that?

My pal mentioned that it’s just exhausting: design systems work isn’t like regular front-end development where you have a problem, a business objective or goal and then you go out and build something to fix it. When it comes to front-end development—or activities that now seem to fall under the umbrella of “design engineer”—you don’t have to explain why that work is worth doing: I make you money, the design engineer can argue, because your website has value for your business and I fix these problems.

But when it comes to design systems work you often have to explain to folks why your job is worth doing in the first place. As a product designer or engineer you might have to argue for a feature or even fight for the existence of a team if you’re unlucky, but you rarely have to deal with the existential threat that your whole career shouldn’t exist.

From my experience, and the experience of this pal of mine, the pain of those arguments about design systems still hurt. Deep down they open up this well of insecurities: maybe this work isn’t worth doing? If we fix these colors, if we refactor these three pages to use this new component, does that really help? Or is the whole field, our entire careers, built on doing busy work for a paycheck?

I remember walking into a meeting with my manager back then with a giant spreadsheet of everything that I’d worked on for the last two weeks. This, and this, and this, I excitedly told my manager. I deleted these three duplicate components and rewrote all this documentation. I paired with five teams about how best to contribute to the library and I added these assets. I came up with typography guidelines and fixed this urgent bug that customers had discovered. Look at how everything is 1% better now.

My manager looked at me and, in the corner of his eye, I could see what he couldn’t say out loud:

So what?

What I didn’t understand then, but I’m painfully aware of now, is that a lot of folks in management don’t get this kind of work. They can’t sell the work to leadership because folks in management often don’t use the product they work on. And they can’t see progress made because they’re not building the same thing that you are. They’re not building software, they’re building a giant spreadsheet of numbers.

It sucks, it’s wrong, it’s bureaucracy at scale. But, sure, I get it. Managers aren’t incentivized to care for these details. You’re not really on the same team.

My pal and I slammed our coffees as we ranted. We moved our hands wildly as we dug up old, long-gone drama that no longer matters. It was front-end-trauma-bonding at its best. But then we realized together that everyone we worked with on design systems has now left the field. They’ve either jumped ship into product design—like I did several years ago—or they’ve dived head first into software development or product engineering or whatever we’re calling it this week.

(Every time I hear the word “growth engineer” a part of my soul evaporates into the aether, never to return.)

Moving away from design systems work was what’s best for me and my mental health, for sure—I’ve never felt happier doing design work and making a big complex website—but it’s sad that it feels as if design systems work can’t be done without this enormous metaphorical sword hanging over our heads. It means our interfaces will be slower, more inconsistent, less accessible. And that means that software won’t care for us as much as it ought to.

On this note, Jack Cheng caught my attention in his newsletter earlier today when he wrote that “all work is care work” and holy shit yes to all of this:

Not a statement of fact, more an outlook, a mindset. What if you asked, of your tasks and projects, “For whom am I caring?”

Extremely yes! Oh, sorry to interrupt you, Jack. Please continue...

Maybe true care, even when directed, turns out to be warmly concentric. By caring for one whom, you’re also caring for many other whoms. Maybe true care has no hard edges; it radiates outward.

That’s precisely how I see front-end development! But design systems asks a similar question of us: how do we care for things at a great scale? How do we make processes/tools/interfaces that make it easier and faster for us all to care in the same direction?

How do we make empathy the default?

Jack then links off to Mandy Brown’s post earlier this week that kicked my ass and I haven’t been able to stop thinking about. Mandy wrote about a unified theory of fucks and what it means to care for our work:

I used to tell this story, about my theory of fucks. The theory goes like so: you are born with so many fucks to give. However many you’ve got is all there is; they are like eggs, that way. Some of us are born with quite a lot, some with less, but none of us knows how many we have. When we’re young, we go around giving a fuck about all kinds of things, blissfully unaware of our ever-dwindling supply. Until one day, we give the last fuck we’ve got, and we notice that the invisible bag of fucks we’ve been carrying around all these years is finally, irredeemably, empty. We have no more fucks left to give.

(This, I think, is the best definition of burnout I’ve ever read.)

This is how I feel about design systems though! I once had this enormous, intergalatic-sized bag of fucks to give. I could rant and rant and rant about all these tiny fucks and I would jump out of bed and glide to work on my city-sized bag of fucks. I would look into my team’s eyes and see how my fucks pale in comparison to theirs. Their bag of fucks encouraged me to hold on tight as we consolidated our bag of fucks into a thing of pure energy: raising the standards of interface design, refactoring code, building a system.

But now? All gone. The sad thing is, I know design systems is work worth doing. Every part of an interface is worthy of our care and attention! Every line of code and every button, every duplicate card component that needs to be thrown in the trash and replaced with a singular, better one. Worth it. Do it. Go.

Design systems is the work worth doing!

But as I was sat there ranting with my pal about old nemeses and old design systems drama I realized that this work is only worthy doing because the people who use our software are worthy of our care. But first? Above all that?

We gotta take care of ourselves.

See you in the cascade,
Robin

(P.S. next week’s edition won’t be so grumpy, I promise.)