Thoughts to consider when pursuing a career in design systems
There was a moment during my recent layoff when I thought: do I want to do this work anymore? And it kind of led to a bit of a career identity crisis. Acknowledging that, while I preach the reverse, I sometimes find myself defining my personal identity around the work I do — when you spend 80% of your waking hours doing “a thing” it's hard not to.
Working in design systems is not all sunshine and rainbows — but what job is? When “the going gets tough” or I find myself arguing the same topic yet again, I like to remember: you’re being paid money for this, breathe, it’s not that serious, “they’re just rectangles on the internet” (thanks, Lauren!). And then I take that money and buy avocado toast, or whatever other thing-of-the-moment my generation is “accused” of ruining by spending our hard-earned money on…but you didn’t come here for that. You came here for warnings and well wishes about pursuing a career in this space.
Design systems work is hard and often draining, but it ain’t all that bad. Let’s talk about it. Here are some things you should know:
There aren’t many other disciplines (at this particular point in time) that REQUIRE a mixed-elevation perspective.
Generalizing here: most folks' roles either sit at the forest or the tree level, depending on the scope of their work. The view from the forest is a very overarching, strategy-focused, long-tail vantage point — think leads, strategists, or director+. The view at the tree level is focused, scoped, and goal/problem-driven — think team/squad members or more traditional individual contributors.
Design systems (DS) work requires practitioners, no matter their discipline, level, or specialization, to have an eye on both elevations simultaneously — not only in the literal sense (ie. how does this asset fit into our roadmap, and who does it help?) but in the abstract, as well, driving cultural and process change all along the spectrum to make “work” more efficient and objectively better. This is a position of significant power and influence, and I don’t think DS practitioners recognize that enough.
Mixed elevation work isn’t for everybody, and that’s okay. So, challenge or opportunity? That’s for you to decide. Organizations, products, and teams need individuals at both levels to be successful. Plainly: organizations need folks to lay the strategy and keep things pointed in the right direction, and they need folks to build each piece of value along the way. A good systems practitioner knows how to float between elevations to make sure their work is best serving their consumers.
Systems thinking and concepts aren’t new (like, at all), but a formalized discipline that’s recognized across industries and verticals IS.
This makes being a practitioner at this particular time and place highly unique — we’re on the ground floor of this evolving specialty. Does that make it hard at times? Absolutely (insert every “selling design systems to leadership and consumers” article here). But it also bakes in a lot of freedom — when there’s no single way to do or achieve something, it means exploration (and, ambiguity) is built into the work by default.
This also makes staffing and training a team really hard, no matter the capacity model or team type you aim for. The challenge has two layers: vetting and hiring practitioners as well as the “who do they report to” discussion.
Hiring
There is no standardized way to “test” systems skill sets during an interview, especially if there aren’t practitioners already at the organization to serve as subject matter experts. That’s not to say that someone with a “systems thinking mindset” can’t learn as they go and do the job but using typical front-end engineering test projects, for example, are an inadequate way to analyze the systems-specific capabilities of an engineer. Organizations at different stages of maturity are hiring systems practitioners (which is great!) but vetting systems people properly is often a knowledge gap, particularly in less mature organizations. Not to mention gauging their performance and supporting their growth once they make it through the door (enter: the career pathing article I promise I’ll finish soon).
Org Model
Once that first set of practitioners is onboarded, who they report to is often the next challenge. Product? Engineering? Design? Ops? Janitorial? Seems we’re often tasked with cleaning up cross-functional messes (janitorial, get it? 😉), but when the team, or individual team members, report up to competing verticals prioritization and scope become really muddy. We often hear about the “triad” (product, design, and engineering) owning the output of the team since they are the core consumers. On paper, however, every employee needs a place to live and it doesn’t seem like we’ve quite figured out what feels like home.
The community isn’t large enough yet to have hit the toxicity inflection point.
Using Design Twitter as an example: there are not many places more negative and gatekeep-y — both in the sense of shitposters filling the airwaves with trash and self-absorbed critiquers who seem to thrive on trashing others’ questions, approaches, work, and decisions. Note: there is a lot of bad design out there, especially online, but there are ways to provide feedback or commentary without being a dick.
But in the design systems online community, I’ve met some of the most supportive, interesting, and generous people who are genuinely interested in helping think through problems, vet approaches, or simply lend a kind ear with a “yup, I’ve been there” pat on the head. There’s something to be said about solidarity (and trauma bonds, but that’s for another article). And when those folks meet in real life at, say, a conference, I’ve experienced nothing but open arms and meaningful exchanges of ideas.
Hey DS community: don’t change.
Our “customers” are our coworkers!
In design systems work we have direct access to our users all the time and have the chance to iterate, improve, advise, overrule, discuss, and collaborate with people at every stage of [insert company product process here] simply by the nature of the work. Many organizations (and product/UX designers, specifically) claim to be “user first” or that “we test our decisions.” From the friends and experiences I’ve had thus far in my career, I can confidently say these claims are often super fluffed and misdirected. Most often, phrases like “we are user obsessed” or “user empathy is at our core” tend to allude to user research and testing…but it doesn’t actually happen (for reasons I’m not going to unpack now). For us systems folk there’s no usertesting.com memberships needed, no budget requests, no loops and hoops to jump through; want feedback on the usability of a system asset? Reach out to a consuming coworker. Or, check the latest bug reports. Done and dusted — a perk of our users being a DM or email away!
Design systems work is “education” work.
This one might be a bit more personal for me since my undergrad was in tech education. But what isn’t unique to me is the balance of communication and teaching versus asset curation in systems work. I showed two slides during my Schema talk (shameless plug): one that showed the “average day” of a DS practitioner from a time-spent perspective and another that showed my take on the “design systems iceberg”; both are below.
There’s a huge misconception that design systems work is merely asset curation work (whether that’s code, UI kits, documentation, what-have-you). While that’s the most visible output of this discipline, the “untracked work” and less visible side is the teaching practioners have to do — the slack messages, emails, meetings, questions, “hey do you have a sec” requests, bug reports, “oh shit, we did that wrong” moments, breaking changes, release notes, newsletters, and demos to help consumers along. These exercises act as the “bummock” of the iceberg beneath waterline that keep the “hummock” afloat — ie. the less visible parts that keep design systems alive. The takeaway here: new component work slows over time and the job shifts to a support role for the assets you’ve shipped. This means less time designing and coding and more time maintaining and explaining.
Were you expecting this “education” section to be more focused on maintaining a learner's mindset? Surprise! That’s also part of it due to the “ground floor, no single way” nature of this budding discipline. We have to be in constant intake mode — intake of new tools, new methodologies, new processes — so that we can try to stay ahead of the curve and evolve as our consumers, and their products, evolve. It can be overwhelming; like when Figma added auto-layout, or when the WCAG 3.0 Working Draft began circulating.
Again, challenge or opportunity? Your call!
Leadership usually understands the value conceptually, but sometimes it can be hard to track.
Most teams tend to go through the Tuckman Stages of Group Development and sometimes have the freedom to stumble along through some of the harder stages. Design systems practitioners don’t have the luxury of doing so in private which means struggle (and success!) are typically very public events. Even when leadership “gets it” there will still be supporters and dissenters throughout your organization that have strong voices, and influence, within their domains. And since you’ll likely cost more than you’re saving in the beginning, and certain metrics aren’t in your control (like adoption), the “dollars and cents” of it all can seem concerning.
My suggestion? Initially, focus on what you can track (and control) — like consumer sentiment pre- and post-system, usability improvements both to the resources you maintain and within the products that absorb those resources, as well as any accessibility wins. As in, literally keep a text file where you assemble these things (quotes, screenshots, notes, etc); the rest will come in time. If you have a lead/manager that’s worth their salt, they’ll not only provide you and the team air-cover as you build that foundation but they’ll help you decide not only what’s important to track, but how to track it. Additionally, they should serve as eyes and ears on the ground bringing back commentary shared by other leads/managers heard from their teams or direct reports that wasn’t delivered directly to you or the team.
This leads me to…
DS work is long-game work — and the ”building the plane while flying it” metaphor is all too real.
No matter how many articles you read, podcasts or talks you listen to, or methods/frameworks you learn, only some of those things will actually work at your organization — you have to be ready for that. And that can sometimes, err, often, feel defeating.
You may also feel pressure from leadership or other parallel teams to fit the mold of other delivery-based teams; DS work does not fit cleanly into typical product cycle models (or team structures, in my experience). That’s not necessarily a bad thing if you’re able to help others understand why. Systems, whether they’re treated like products, practices, or services, don’t have an “end” — they are living and evolving ecosystems that grow alongside an organization and their products.
This means, more often than not, design systems teams have to stay nimble and shift gears based on sometimes-immediate consumer needs, occasionally breaking the “approved roadmap,” quarterly plan, or upcoming release. Or, which has happened many times to me, have to go back and tweak/change/update something previously shipped because of new information, or architectural decisions, that come up as the work progresses (breaking change policies, anyone?). All in a day’s work, as they say.
It’s almost never enough; and the system is never “done.”
There’s always a backlog — always another feature request — of things you wished you’d get to or would love to spend time on but seemingly never enough bandwidth to get it all done. And when a DS does have a release, they aren’t treated or celebrated the same way as product launches or other releases are.
That silence, and mounting list of “wish we could dos,” can be deafening and even lead to burnout. Part of me says “well, that’s just the nature of the beast” and another part of me says “well, sometimes this requires a lead/manager to stick their neck out and strongly advocate for this work” not only because it’s important, but because it has a direct correlation to team health and happiness. While it’s sometimes considered a dirty word (phrase?), I like to tuck this stuff into “Maintenance Mode” periods — the design systems flavor of “cool-downs” in the Shape Up framework — but I’ll detail that within a different piece of content later.
The TL;DR here is that internal tools simply don’t get the love, time, and acknowledgment (nor budget or headcount) they deserve — and this isn’t exclusive to design systems, to be clear. And it’s not something we talk about enough, in general, but is something you should know before diving in.
All that said: this work is hard and often thankless, but “hard and thankless” does not equal “bad.” If you’re into helping others and enabling their success, it can be really rewarding.
To be a design systems practitioner is to be a builder, communicator, and educator.
Do I ever want to write another description of a button for a piece of documentation? No. Do I get sick of fussing with design tool limitations when building UI kits? Yes. But helping a consumer realize the power of a thing the team has built, a different way to solve a problem, or show them an already-established example to save them time is where the magic happens (and you shouldn’t want to AI or automate your way out of helping your friends, colleagues, or yourself grow). This magic is what keeps me coming back.
I’m Taylor, a North Carolina-based multidisciplinary creative and community builder that’s passionate about people, design, and all the intersections in between. I have a burning desire to collaborate with others to create exceptional work for people who give a shit.
Find me online @taylorcashdan everywhere; reach out — let’s be friends.
[Views expressed here, or any other platform, are my own and do not reflect the views of any past, present, or future employer]
