Every research leader eventually has to answer this in a budget meeting, and the honest answer, "it depends," does not survive contact with a CFO.
So let us do better than that. Not by inventing a ratio, but by walking through what the benchmarks actually tell you, why they break, and how to build a number you can defend.
Start with the benchmark, then stop trusting it
Nielsen Norman Group's staffing research puts the typical arrangement at roughly one dedicated researcher per hundred developers, alongside one designer per twenty.
Two things are worth noticing. First, that is a description of what organizations do, not a recommendation of what works. Second, the researcher ratio is five times thinner than the designer ratio, which tells you something about how research has historically been valued relative to design, and neither number was arrived at through analysis.
So use it as a reference point rather than a target. If you are at one researcher per four hundred engineers you are unusually thin and that is worth saying out loud. If you are at one per thirty you are unusually well resourced and should expect that to be questioned. Anywhere in the middle, the benchmark tells you almost nothing about whether you are staffed correctly, because it does not know what your product is or what decisions it generates.
The number that actually matters
Research capacity should be sized against decision volume weighted by risk, not against engineering headcount. Engineering headcount is a proxy for decision volume, and a bad one: a hundred engineers on a mature internal tool generate far fewer novel user-facing decisions than thirty engineers on a new consumer product.
The exercise that works, and it takes an afternoon:
Take last quarter. List every decision that was genuinely consequential and genuinely uncertain. Not every ticket. The ones where reasonable people disagreed, where being wrong would have cost real money or real trust, and where the answer was not already known.
For most teams that list runs to somewhere between fifteen and forty items a quarter. Then mark which ones had any evidence behind them.
The ratio you get is the real number. Not researchers per engineer, but decisions per quarter that deserved evidence and did not get it. That is the gap you are staffing against, and unlike a benchmark it is specific to your organization and impossible to argue with, because it is a list of things your own leadership already agreed were important.
Why the coverage gap beats the principle argument
The standard headcount case is an argument from principle: research reduces risk, understanding users is important, here is a case study from another company. Every function makes an argument like this, and finance discounts all of them equally.
The coverage gap is a different kind of claim. It says: here are eleven decisions from last quarter that this leadership team called strategic, seven of them shipped with no user evidence, and two of those seven came back as rework. That is not a philosophical position about research. It is a description of risk the business already owns.
The zeroheight Design Systems Report 2026 shows what happens when the argument stays philosophical: 56 percent of design system teams name staffing as their biggest challenge and only 23 percent say they have adequate resources. Those teams are not bad at their jobs. They are making principle arguments against functions that arrive with numbers.
What structure does to the number
Before hiring, check whether you have a structure problem rather than a capacity problem. NN/g's survey of 557 UX and design professionals across 356 companies found the field roughly evenly split: about 29 percent centralized, 32 percent decentralized, and 31 percent hybrid. There is no consensus, which is itself informative.
The three models fail differently.
Centralized research becomes a queue. It protects quality and gets you consistent methodology, and it turns research into a service teams request and wait for. The failure mode is that fast-moving teams route around it.
Decentralized researchers embedded in squads get proximity and speed, and lose methodological consistency and the ability to see patterns across the product. The failure mode is five researchers discovering the same insight separately.
Hybrid is the most common answer and the hardest to run, because it requires someone to own standards without owning the people.
If your researchers are spending most of their time on recruitment logistics, scheduling and repository maintenance, you do not have a researcher shortage. You have a ResearchOps shortage, and one operations hire will return more capacity than two more researchers.
Democratization is a headcount strategy with a catch
The default response to a coverage gap is to enable PMs and designers to run their own studies. This is now standard practice, and AI tooling has made it far more viable by compressing transcription, synthesis and clustering.
It works for volume. It introduces a new liability: research quality becomes distributed across people who were not trained for it, and a badly run study produces confident wrong answers rather than no answer. That is a worse outcome than the gap you were trying to close.
If you go this route, budget for the thing that makes it safe. Someone has to own templates, review study designs before they run, and keep a repository that stops five teams re-asking the same question. That is a real role and it is usually the one that does not get funded, which is how democratization turns into decentralized guessing with a research vocabulary.
A number you can walk into the room with
Put four things on one page.
Coverage. Consequential decisions last quarter, how many had evidence, and which strategic initiatives are currently running with none. This is the headline.
Where the time went. The split between actual research and logistics. If logistics is above a third, name it, because it changes what you are asking for.
What the gap cost. One or two specific instances where absent evidence produced rework or a reversal. Not hypothetical risk. Things that already happened, with the cost attached.
What you are asking for and what it buys. Stated as coverage, not as bodies. "Two researchers takes strategic-initiative coverage from four of eleven to nine of eleven" is a proposal. "We need two researchers" is a wish.
The reason this is hard is not that the argument is weak. It is that assembling those four things means reconstructing a quarter from memory, calendars and scattered documents, at exactly the moment you are busiest. Which is why most research leaders show up to the budget meeting with a principle instead of a number, and lose to functions that have their numbers waiting for them.