I wanted to know if I was just imagining it, so I analyzed 256 design system roles from two sources: the In the Design Systems job list and a year’s worth of messages in the Design systems are weak community, which has more than 28,000 members. The distribution was consistent across both: 70% focused on design, 26% focused on technology. A ratio of 3:1.
If we break that down, of the 228 individual contributing roles, design outnumbered engineering 170 to 58. Again, almost 3:1. The 26 management and leadership positions were also design-oriented (15 to 11), although with such a small sample it is difficult to draw firm conclusions. What is clearer is the IC picture, and I suspect that is where most of the hiring takes place anyway.
In the week since I conducted this analysis, another 10 positions have been added to the Into Design Systems job board. 7 designers, 2 engineers, 1 product. The pattern continues.
That raises an uncomfortable question: If the industry hires three designers for every engineer, who actually does all this design work?
Where the value comes from
Design systems need great designers. A well-designed Figma library creates shared language, accelerates design iterations, and aligns teams around common patterns. That’s real value.
But that value has a ceiling.
A Figma library, no matter how extensive, mainly helps designers. At the time a project is implemented, engineers translate those designs into code. Every time. For every function. In every team.
The real value comes when patterns exist in the production code. When a component is present in your codebase, any engineer building your product can use it. When you update it, that change ripples across every screen it’s deployed to. When you need to make a major visual change or accessibility improvement, you do it once, centrally, instead of hoping that dozens of teams all update their local deployments correctly.
This is the promise of design systems: efficiency and consistency at scale. That promise is ultimately fulfilled through code.
Users cannot interact with your Figma library. They communicate with what is sent in code.
What I saw working
In my last team, our design systems team worked with an intentionally high ratio of engineers to designers. Originally around 6:1 and then reduced to 4:1 after a few layoffs.
Both our design and engineering results created value, but not equally. We understood that a significant portion of our value came from code implementation, and we staffed accordingly. Our system was highly automated, with algorithmic token generation, advanced tools and infrastructure that required significant technical investment to build and maintain.
Our system would not have functioned without designers, but it required a significant team of engineers to build and operate it.
If that ratio had been reversed, with four designers per engineer, we would have generated a lot of design value. But the greater value, the part that actually reaches users, would have been permanently compromised.
So what actually happens?
When I look at that 3:1 figure, I keep wondering what’s happening behind the scenes. A few possibilities (i.e. educated guesses):
These are all new design systems that are still early in their maturity. If you’re just starting out, it may make sense to lay a design foundation before bringing in technical capacity. Design first, implement later. But if you read a lot of these job descriptions, most of them are for positions that work on existing design systems. And how many organizations have been in that ‘early maturity’ phase for a year or more?
Designer roles have higher turnover. Perhaps the ratio of open positions doesn’t really reflect the composition of our teams. If designers change roles more often than engineers, more designer roles would be advertised, even if team compositions are more balanced. The labor market may be distorted by turnover, not by the way teams are actually structured.
Feature teams do the implementation. Design system designers create the specifications, and product team engineers build the components. This can work, but it means platform work falls to people whose primary job is shipping features. That’s a recipe for inconsistent quality and competing priorities.
The systems remain in Figma. Some organizations may be comfortable with design-only systems, and that is a valid choice. There is real value in it. But it’s worth being honest about the trade-off: without code implementation, you’re missing out on significant potential value. Your organization could get so much more value from your system.
Engineers exist, but are not hired as “design systems engineers.” Look at the design roles and you’ll see specialization: ‘Design System Designer’, ‘Product Designer – Design Systems’, titles that recognize this as a separate discipline. The technical equivalents are rarer. Do organizations hire engineers to work on design systems, but advertise them as general frontend or platform roles? If so, what does that say about the way the technical side of this work is valued? Is Design System Engineering treated as something that any engineer can pick up, while Design System Design is treated as a specialty?
Teams are simply severely understaffed on the technical side. Organizations see ‘design systems’ and think ‘design problems’. They hire designers. The implementation backlog is growing. The system never delivers on its promise. I really hope this isn’t the case.
A few bright spots
It’s worth noting an interesting trend I’ve observed among the leadership roles advertised. As I reviewed the job descriptions, I found several leadership roles that explicitly welcomed a design or engineering background. They recruit for design systems leadership, not design leadership. 😍
This was encouraging to see. It suggests that at least some companies understand that this discipline spans both worlds and are hiring leadership accordingly.
But honestly, these felt like outliers.
The awkward question
Design work is undoubtedly valuable. But code is how you get the most value out of your design system. So why are 70% of roles design-oriented?
Or most organizations are getting far less value from their design systems than they could be. Or there’s a huge amount of invisible technical work happening somewhere that doesn’t appear in the job titles. Or the industry has collectively decided that design systems are a design discipline, and we all just go along with that.
I don’t have a decent answer. But I do know what worked at scale: investing heavily in technical capacity, treating implementation as the core work rather than a downstream task, and recognizing that the source of truth is what is sent to users.
The next time you’re planning staffing for a design systems team, it might be worth asking yourself: Are we building a design system, or are we just designing one?
#design #design #systems