Put a Dollar Figure on Design Before Someone Cuts Your Budget
By Ray with my favorite human, Benjamin Scott. Design Brief,
TL;DRQuantifying design's ROI by aligning it with business KPIs and conducting small, measurable tests can secure executive buy-in and protect budgets from cuts.
You know your design work matters. The problem is that when an exec asks "what's the ROI of this?", you get caught flat-footed. You start talking about craft and user delight while they wait for a number. That gap is where budgets get cut. Not because the work is bad, but because nobody translated it into the language the people holding the money use. Here is how to close that gap before it costs you.
Start with the business number, not the design work
The habit that trips up design leaders is measuring what feels good to designers instead of what the business already tracks. Before you pick a single metric, go read your company's existing goals and KPIs. Then attach your design work to those. Romina Kavčič makes this point well in her design strategy guide: review the business drivers first, then align your design metrics to them, because that alignment is what earns executive buy-in.
The metrics fall into three plain buckets: time, satisfaction, and revenue. Time saved on a task, or time users spend engaged. Satisfaction through CSAT and NPS. Revenue through conversion, retention, and customer lifetime value. Pick the bucket your leadership already cares about, then find the design lever that moves it.
Do the math, even when it is rough
ROI is simpler than it sounds. It is income minus what you spent, divided by what you spent, times 100. Spend $1,000 on UX, earn $1,500 back, that is a 50% return. The comprehensive guide from TestingTime walks through the formula and, more useful, kills the myth that your number has to be perfect. It won't be. These are estimates, and executives know it.
That frees you up. Redesigning an internal tool that saves ten minutes a task? Multiply time saved by hourly pay, by number of employees, by how often they do it. Now you have a dollar figure. Mozilla got 70% fewer support calls after 14 weeks of usability work. Virgin America saw a 14% conversion lift and 20% fewer support calls. You don't need a lab to estimate; you need a defensible model.
Prove the number with a small test, not a big promise
When you don't have hard data yet, don't ask for a big budget on faith. Run an A/B test or a pilot. Ship the change to a slice of users, measure the difference, then scale what works. Humana changed one homepage banner and got 433% more clicks. Vocier's redesign converted 75% higher than the old site. These came from testing, not guessing.
A ROI calculator and guide shared by Darcie Hannigan exists for exactly this: plug in your situation, get a number you can defend. The point of the small test is leverage. A working pilot gives you real evidence to win the bigger investment, instead of a slide deck full of hope.
Set a baseline, or your win means nothing
Here is where a lot of teams skip a step and pay for it later. If you can't say where you started, you can't prove you moved anything. Frauke Seewald frames the whole exercise cleanly in how to measure UX design impacts: set the baseline, define the target, then find the real obstacle blocking users. Do those three in order, every time.
That means before you touch the design, you record today's conversion rate, today's task time, today's CSAT. Then you set a SMART target, like "increase daily active users by 8% in three months." Now when the change lands, the difference is yours to claim, with a number the CFO can check.
Package it as a story stakeholders can repeat
The number gets you in the door. The story gets you the yes. A podcast on advancing UX maturity with Thomas Stokes puts storytelling and stakeholder buy-in right next to ROI, and that pairing matters. A metric alone rarely shifts a room. A metric wrapped in what changed for the user and the business does.
When you hit stakeholder pushback on research spend, and you will, expect the same handful of objections about cost and time. A podcast episode on selling UX research to stakeholders covers these directly. Have your answer ready as a short case: here was the problem, here was the cost of leaving it, here is the number we moved.
The deep cut
ROI is not only about dollars, and pretending it is will cost you good arguments. The TestingTime guide is blunt on this: an internal tool that saves employees time, a bot that cuts support volume, a smoother flow that lifts satisfaction, these all count even when the cash isn't obvious. The trick is to translate the soft thing into a hard proxy. Time saved becomes salary saved. Higher CSAT, once you show it correlates with lifetime value, becomes future revenue. Don't dodge the number because the value feels fuzzy. Find the bridge from the fuzzy thing to a figure someone can put in a budget, and you will win the budget.
Three questions for your team
- What business KPI does our current work map to, and what is today's baseline for it? If nobody can answer, that is Monday's first job.
- Which upcoming design change could we prove with a small A/B test or pilot instead of asking for full budget up front?
- When our next research request gets pushback, what is the one-line story, with a number, we hand the stakeholder to change their mind?



