Every design leader can tell you their headcount. Almost none can tell you, accurately and without a week of work, where that headcount actually went last quarter.
Those are different questions, and only the second one matters. Headcount is a budget line, negotiated once a year. Coverage is a decision that gets remade every week, usually by accident, and it determines what your organization is actually capable of.
Allocation drifts, and nobody watches it drift
Here is the pattern, and it is close to universal.
A quarter begins with a plan. Four designers on the new onboarding initiative, two on platform, one supporting growth, one on the design system. That plan is real for about three weeks.
Then a launch slips and pulls a designer sideways. A VP asks for "a bit of help" on something that turns out not to be a bit. Somebody goes on leave. A partner team loses their designer and yours starts covering both. A high-visibility exec request lands and gets absorbed by whoever is nearest. None of these are unreasonable individually. Every one of them is a reallocation, made locally, recorded nowhere.
By week ten, the actual distribution of your people bears little resemblance to the plan, and the drift is invisible because no single decision caused it. There was never a meeting where anyone said "let us take the design system down to zero." It just happened, one accommodation at a time.
The organization finds out at the end of the quarter, when the design system did not move and someone asks why.
Ratios are not a target, they are a diagnostic
The staffing literature is often read as prescriptive, which is the wrong way to use it.
Nielsen Norman Group's research puts the typical ratio at roughly one dedicated designer per twenty developers, and one dedicated researcher per hundred. Other benchmarks land tighter, with product-led companies running one designer to six or eight engineers. The spread is enormous, and arguing about which number is correct is mostly a waste of a meeting, because the right ratio depends on surface area, domain complexity, and how much of the product is user-facing.
The useful move is to stop treating the ratio as a target and start treating it as an instrument. What matters is not whether you run 1:8 or 1:15 across the org. It is the variance between squads, and whether that variance is intentional.
A design organization at a healthy average ratio can still contain a squad running one designer against fourteen engineers on the company's most strategic initiative, while another runs three against nine on something in maintenance mode. The average conceals both. The average is almost always the least informative number in the building.
The three questions worth being able to answer
Which priorities have coverage, and which have a name on a slide? Every company publishes a list of what matters this cycle. The interesting exercise is putting your actual staffing next to it. The gaps are rarely where anyone expects, and the exercise usually surfaces at least one strategic initiative being carried by a single person who has not told anyone they are drowning.
Where is the ratio out of line, and was that a decision? Squad-level ratio variance is fine when it is deliberate. It is a problem when it is emergent. The distinction is entirely about whether anyone chose it.
What is absorbing capacity that nobody planned for? Every design organization has a shadow backlog: the exec requests, the partner-team favors, the recurring meeting nobody can cancel, the design system requests handled informally because there is no queue. In most orgs this is a double-digit percentage of total capacity and appears in no plan. It is also the single easiest thing to fix once it is visible, because much of it turns out to be work nobody actually wanted done.
Why "just track it" does not work
The obvious answer is to have people log their time or maintain an allocation tracker. Every design leader who has tried this knows how it ends.
Time tracking fails for a specific reason, not a cultural one: it asks the people doing the work to maintain a second, parallel record of the work, purely so somebody else can read it. That record decays immediately, because the person maintaining it gets nothing from it. Within a month the tracker reflects the plan rather than reality, which makes it worse than having nothing, since now it is confidently wrong.
The zeroheight Design Systems Report 2026 illustrates what happens downstream. 56 percent of design system teams name staffing as their single biggest challenge, 61 percent say they do not have enough people, and 16 percent of design systems are maintained by exactly one person. Those teams are making a resourcing case in a language the business does not accept, against functions that arrive with numbers.
The record already exists
The thing worth noticing is that the evidence for allocation is already being generated, continuously, as a side effect of people doing their jobs.
Files get edited in Figma by named people, on named projects. Tickets get assigned in Linear or Jira, against epics that map to initiatives. Reviews get requested. Studies get run. Threads get opened. Every one of these is a timestamped record of a person spending attention on a piece of work.
What does not exist is the connection between them. Figma knows who touched the file but not which initiative it serves. Jira knows the epic but not that the designer on it is also carrying two other squads. Nothing holds the shape of the whole organization, so the only way to see it is for a human to assemble it, by hand, from memory and interviews, once a quarter, at which point the quarter is over.
That is the actual gap. Not a missing metric, a missing model: something that reads across the tools, links the work to the people and the people to the priorities, and can tell you a squad has drifted the week it drifts rather than the quarter after.
Allocation is the highest-leverage decision a design leader makes. It deserves better than a spreadsheet rebuilt from memory four times a year.