Sooner or later, someone in finance is going to look at your UX research team and ask what the company got back for the money. It usually lands during budget planning, when every team is being asked to justify its line item and the answers are getting a hard second look.
The problem is that most research leaders answer badly. They list how many studies they ran, how many people they interviewed, how many reports they shipped. Or they point to higher satisfaction scores. Those things describe activity. They don't tell finance what the work did for the business, and a skeptical finance partner reads them as a dodge.
This guide walks through how to connect a study to a decision, explain what changed because of it, and put a defensible dollar figure on that change before anyone asks. You don't need a complicated model. You need a number another person can follow, question, and check.
UX research ROI compares the money connected to a study against what the study cost. That money almost always comes from one of three places: engineering work you avoided, revenue you protected or grew, or business risk you reduced.
The simple version: ROI = financial value connected to research ÷ cost of the research.
Say a study cost $30,000 and helped the team avoid an estimated $150,000 in engineering rework. That's five dollars back for every dollar spent. Some finance teams prefer a percentage instead: ROI % = (value − cost) ÷ cost × 100. Using the same numbers, ($150,000 − $30,000) ÷ $30,000 × 100 = 400% ROI.
Ask your finance partner which format they want. The method matters far less than picking one and using it the same way every time.
Start with the decision, not the study. This is the single most important move in the whole process, and it's where most research leaders go wrong.
This describes an activity: we ran five usability tests. This describes a result: the tests showed customers couldn't finish account setup, so the team rebuilt the flow before development was done. The second version gives you something you can measure, because it ties the study to a decision.
Ask three questions. What was the team going to do before the research? What did the research uncover? What did the team do differently after seeing it? Then write the decision in one sentence, like: "Research showed customers didn't understand the new pricing flow, so the team changed it before launch." That sentence is the foundation for everything that follows.
Now describe the likely outcome if the team had stuck with the original plan. You're answering one question: what cost or problem did the research help the company avoid? That might be engineering rework, a failed launch, weak adoption, lost sales, higher churn, a flood of support tickets, or a compliance, accessibility, or safety problem.
You won't know the counterfactual for certain, and that's fine. Use the best information you have and say plainly that you're estimating. Talk to the people who'd know: the PM, the engineering lead, the support team, your finance partner. The goal is a realistic outcome the business can evaluate.
Proving research directly grew revenue is hard, because revenue moves for a dozen reasons at once: pricing, marketing, sales, market conditions. Avoided cost has a cleaner line back to a specific finding. You can often show that a finding saved two sprints of rework, or headed off hundreds of support tickets, or caught an accessibility problem that would have been expensive to fix after launch. That's much easier to defend when finance pushes back. The real cost of skipping UX research is almost always the cost of building the wrong thing and paying to fix it later.
Once you know what changed and what you avoided, sort the impact into one of three categories. This tells you which metric to use and makes the math easier to explain.
Use this when research helped the team avoid building or rebuilding the wrong thing: a feature changed before development, a rework sprint avoided, engineers pulled off a low-value idea. Measure it in engineering hours, sprints avoided, people involved, and cost per engineer. This is usually the easiest bucket to price, because a sprint has a known cost.
Use this when research touched adoption, conversion, retention, or churn: a fixed checkout flow, a churn driver caught early, onboarding that got people to value faster. Measure it in conversion rate, feature adoption, retention, renewals, or the revenue tied to that experience.
Use this when research caught a serious problem before launch: a compliance gap, an accessibility issue, a safety concern, a risky roadmap bet changed before the company sank money into it. Measure it in legal, remediation, regulatory, or recall costs avoided. This matters most in healthcare, finance, and manufacturing, where mistakes get expensive fast.
If you want a framework for spotting which risks actually predict failure, our Three Pillars of AI Adoption Risk breaks down the signals to watch.
| Research outcome | Metric to measure | Financial impact |
|---|---|---|
| Rework avoided | Engineering hours or sprints saved | Lower development and rework costs |
| Revenue protected or increased | Adoption, conversion, retention, or churn | Revenue gained or protected |
| Risk reduced | Compliance issues, accessibility gaps, product failures | Legal, remediation, or recall costs avoided |
A study can touch more than one bucket. Start with the one that has the clearest evidence, and only add a second when you can explain the connection cleanly.
Now put a dollar figure on what you avoided, protected, or gained. Keep it simple enough that someone else can follow every line.
Engineering rework avoided. Say rebuilding a feature after launch would have taken 5 engineers, 2 weeks, at $4,000 per engineer per week: 5 × 2 × $4,000 = $40,000 in engineering cost avoided.
Revenue protected. Say 2,000 customers use a purchase flow each month, average purchase $200, and the original design would have cut completion by 5%: 2,000 × $200 × 5% = $20,000 in monthly revenue at risk.
Support cost avoided. Say a confusing setup would have driven 1,000 extra support tickets at $15 each: 1,000 × $15 = $15,000 in support cost avoided.
Then, and this is what makes the number survive scrutiny, give research a fair share of the credit. Research rarely creates a result alone; PMs, designers, and engineers all touched it. Claiming the full amount is easy to attack. If a redesigned flow protected an estimated $500,000, say something like: "Research found the core problem and gave the team the evidence to change the flow. We estimate research contributed 20–30% of the outcome, or $100,000 to $150,000." A conservative number you can defend beats a big one you can't.
Finally, compare that value to the study cost. If research is credited with $50,000 of value on a $20,000 study, that's $2.50 back per dollar, or 150% ROI. State which format you're using so finance doesn't have to work it out.
Never hand over a number without the math behind it. A strong impact statement reads like this: "Research found a major usability problem before development finished. Fixing it after launch would likely have taken two more sprints across six engineers. Based on current costs, we estimate research helped avoid $150,000 to $220,000 in rework."
That shows what was found, what changed, what would have happened, and how the number was built. Use a range rather than one suspiciously exact figure. It signals honest uncertainty and reads as more credible, not less.
The teams that win this conversation every year aren't doing more analysis after the fact. They bake the estimate into the study readout on day one, as a required field. Capture these on every study:
Fill it in while the study is fresh and the people involved can still check the assumptions.
Put every study's impact in one place. A simple spreadsheet is enough. Track the study, the decision, the ROI bucket, the metric, the estimated impact, the research share, the cost, and who confirmed the numbers. Do this all year and you'll never rebuild the story from memory under budget-season pressure.
Then, at quarter or year end, group everything into the same three buckets and show finance the totals: "Over the past year, UX research influenced 18 major product decisions. On conservative estimates, the work helped avoid $1.2M in engineering rework, protect $800K in revenue, and reduce $2M in product and compliance risk."
Be ready to show the calculation behind each figure. A boring, defensible spreadsheet where every number ties back to a decision and a counterfactual is the strongest evidence you can bring. It holds up when someone asks the follow-up question.
The whole point is to stop rebuilding the ROI argument once a year. When every study already carries its decision, impact, attribution, cost, and assumptions, the evidence is sitting there before finance asks. Over time this changes how the business sees research. The conversation moves off "how many studies did you run" and onto the decisions, costs, and outcomes the work shaped. That's how a research team goes from defending its budget to arguing for a bigger one.
When your team is busy running studies across multiple product lines, it gets hard to keep track of the business impact of every project. That becomes a problem at budget time, because leadership usually wants a clear answer to a simple question: what did this research actually change?
Akraya helps make that easier. Before a study starts, our researchers make sure the team is asking the right question and that the work is tied to a real decision. If a study is unlikely to affect the roadmap, product direction, or another important choice, we say so early, so your team spends time on research that can actually influence what happens next.
We also match you with researchers who understand the kind of product you're working on, whether that's hardware, software, or AI. When someone in finance or leadership asks how the research affected a decision, findings from someone who knows the domain are far easier to stand behind.
The same researcher can stay with your team across multiple studies. Over time, they build a clear record of what each study influenced, so you don't have to piece everything together from memory when budget season comes around.
And because Akraya is accountable for the outcomes research produces, not the hours billed, UX research leaders walk into budget conversations with something concrete: a clear record of the decisions research influenced, and a stronger case for continued investment.