Design Systems Designer

You design the system other designers design with — the components, tokens, and rules that keep a product coherent across fifty screens and five teams. It's the infrastructure discipline of design: less glory, more leverage, better pay. Here's the honest picture.

Median pay (US)

~$120k / yr

Typical range

$90k–$165k+

Degree required?

No — systems work wins

What the job actually is

Design systems designers build and maintain the shared foundation a product's design runs on: component libraries with every state and variant specified, token architectures (color, type, spacing, elevation) that make theming and dark mode possible, documentation that teams actually use, and the governance — contribution rules, deprecation paths, versioning — that keeps fifty designers from fifty interpretations. The daily work is half craft (designing components that survive every edge case) and half diplomacy (getting busy product teams to adopt, contribute, and stop detaching instances). You're judged not on screens shipped but on consistency at scale.

Is it actually you?

You'll probably love it if

You're the designer who reorganizes the Figma file nobody asked you to
Naming things well feels like a real skill to you (it is)
You'd rather make 50 designers 10% better than ship one feature yourself
Edge cases — RTL, translation swell, error states — interest you instead of annoying you
You can talk to engineers in their language about tokens and props

Maybe not, if

You need user-facing wins — your users are other designers and devs
Evangelizing and re-explaining the system weekly would exhaust you
You want creative freedom; systems work is deliberately constrained
Documentation feels like the chore, because here it's the deliverable
You're early-career — most systems roles want product experience first

The real day-to-day (no hype)

Adoption is the job; the library is just the artifact. A beautiful system nobody uses is a failure. The real work is making the system the path of least resistance — office hours, contribution models, and relentless, patient evangelism.
You live in the seam between design and code. Tokens, component APIs, Figma variables mapped to code variables — the role rewards designers who can read a pull request and argue about prop naming. Pure visual designers struggle here; hybrid thinkers thrive.
It's a seniority game. Companies fund dedicated systems roles once design teams hit ~8-10 people, and they staff them with experienced designers. The common route: product designer who kept gravitating to the system until it became the title.
AI made systems MORE valuable. AI design and code generation is only as good as the system it draws from — well-tokenized, well-documented systems are what make AI output usable at all. Companies investing in AI tooling are investing in systems people to feed it.

How people break in — or switch in

Almost nobody starts here — you grow into it. The path: work as a product or UI designer, volunteer for the systems work everyone else avoids (the component audit, the token cleanup, the documentation), and build the case study. That one deep systems project — 'I unified 14 button variants into 3 and drove adoption across 4 teams' — is worth more than any portfolio of screens. Front-end developers with design sensibility also cross in successfully; the role's code-adjacency is a feature for them.

If you're already the unofficial keeper of the components file, you're doing the job without the title or the pay band — the case study is sitting in your version history.

Your application, already half-written

Here's a question every Design Systems Designer application asks, answered the way pirch would — in a real voice, grounded in real experience:

“Tell us about a design system you've worked on.”

I became our systems person by accident: I audited our product and found 14 button variants, 9 grays, and three different 'primary' blues. I pitched two weeks to fix it and it became my next year. The rebuild was the easy half — tokens first, then components with every state specified, documented as I went. The hard half was adoption: I ran office hours, made migration guides per team, and — the thing that actually worked — made the system components faster to use than detaching them. Eighteen months later, 90% of new screens ship on-system and our dark mode took days instead of months, because the tokens were right. I want to do that again, deliberately this time.

pirch's co-pilot writes answers like this for your background and the exact job — try it free →

pirch finds the systems roles that are actually you

Dedicated systems team, first-systems-hire, or product role with systems scope — the maturity of the company changes everything. Tell pirch who you are and it hunts down real, still-open design systems roles that fit the whole you, with a tailored cover letter already written. No spray-and-pray. No dead links.

start your free hunt

first hunt free · we never auto-apply · you stay in control

Common questions

What does a design systems designer actually do?

They build and govern the shared design foundation — component libraries, design tokens, documentation, and contribution processes — that keeps a product visually and behaviorally consistent across teams. The deliverable is other teams shipping faster and more coherently.

How much do design systems designers make?

Roughly $90k–$165k+ with a median around $120k — typically above equivalent-level product designers, because the role requires cross-disciplinary skill and companies fund it at the senior/staff level.

How do I get into design systems work?

Through product design, almost always: volunteer for the systems work on your current team (audits, tokens, documentation), drive adoption, and turn it into one deep case study. Dedicated systems roles hire proven systems contributions, not potential.

Do design systems designers need to code?

Reading code and speaking it matters more than writing it — you'll define token architectures and component APIs with engineers, so fluency in how components are built (props, variants, states) is core. Actual front-end skill is a genuine bonus, not a requirement.