FEB 16, 2026

How Designers Can Successfully Use ROI Metrics to Greenlight Projects

ROI in design isn't a math puzzle - it's a translation challenge from design language to business currency.

As a product designer, I've celebrated UX wins like reducing task times, trimming steps, and increasing success rates for tasks. Those metrics prove real improvements in UX. However, on a service level, I found those metrics insufficient to get the business buying. Why? Because they refer to the design language, while the board demands pounds (or euros, or dollars).

Their favourite metric? Return on investment.

Here's the harsh truth about ROI in design: It's not a math puzzle. It's a translation nightmare. The ROI is a financial metric that looks very straightforward:

ROI = (Net Profit / Cost of Investment) × 100

Yet, it's especially tough to nail down. Why? Teams track what's easy - hours saved, tickets resolved, improved morale. Yet, finance wants currency: "Show me the revenue uplift or cost cuts." Without that bridge, great ideas die in endless meetings - I've seen it happen much too often.

In this article, I'll break down the most common challenges with calculating ROI and share practical tips to measure it effectively. You'll learn to speak "business" without losing your design soul, and getting projects greenlit faster.

What ROI horror stories have you faced? Drop them in the comments.

Compared to What? You Need a Baseline

You can't prove improvement if you never measured where you started. Think about that. You can't sell improvement if you don't know the starting line. Without that baseline, your ROI pitch turns into storytelling. You're hoping the numbers sound good enough, but there will always be someone in the room ready to challenge them.

I once got pulled into a service redesign where the current end-to-end process had never been documented. Even the 'happy path' had many exceptions, making it impossible to calculate the baseline end-to-end. Still, I was able to present to the stakeholders a monetary value of annual savings estimated at £100k–£200k.

What you can do

Pick one core unit of value. This could be an order, a case, or a customer onboarded. Something that you will be able to track consistently. Get everyone to agree on what "complete" means for your core unit. When is an order truly done? When is a case actually closed?

Run a proper measurement sprint (ideally for 2–4 weeks). Track real work if possible. Use calendar logs, system data, and time-sampling exercises. Actual data.

Calculate the full cost per person. If I don't have access to this data for my company, I use the market average. Just remember that a £40K employee in reality costs the business closer to £55–60K once you factor in overhead costs.

Measure errors and rework, not just speed. A process that's fast but produces 30% rework isn't actually efficient. It's expensive.

Validate everything in a cross-functional session. Get marketing, ops, finance, product - all in one room. Make them agree on the numbers. If people start arguing about your baseline six months into the project, you didn't align early enough.

Use AI. It can get some market average numbers for you if you don't have access to the finance data. It can also run the ROI analysis for you after supplying it with relevant details.

Don't overthink it. You are a designer, not a finance analyst. Your numbers need to be close enough to keep the conversation going, but don't have to be perfect. Show your calculation for transparency. Even if your numbers are 30% off, you are already speaking business, not design language.

When Work Crosses Teams, Nobody Actually Owns the Total Cost

Classic handoff hell: Marketing → Sales → Ops → Finance → Support cleanup. Each team polishes their little silo. Total end-to-end cost? Invisible.

Savings appear in one place, costs leak to another. ROI becomes politics.

What you can do

Map the full end-to-end flow. Not departmental, but system-wide. Assign (or ask to be assigned) temporary ownership just for diagnosis, even if it's messy.

Track every touchpoint, every manual workaround. That 4pm Excel download-reformat-upload ritual? That's bleeding money.

Look for the usual suspects:

• Handovers (delay + error magnet)
• Pointless approval layers
• Triple data entry because systems hate each other
• "Temporary" hacks (there is nothing more permanent that temporary fixes)

Build ROI end-to-end. Show total system impact, not "Team A saves £50k" while Team B eats £40k quietly.

Soft Benefits Are Real, But They're Not ROI Until You Translate Them

How often do you hear or mention: "It'll improve morale. The customer experience will be better. We'll be able to make changes faster in the future." I use these quite a lot as it is the first change you expect to see - and the most straightforward pain point.

All of that is true, and all of it matters. But it's not valuable to the board if you can't translate it into financial impact.

What you need to do

Soft benefits are real, but they're not ROI until you translate them. For every soft benefit, force yourself to ask: "Okay, but how does this actually show up in the numbers?"

Here's the translation:

• Improved morale → People stop leaving → You avoid hiring costs (£15–30K per role, depending on seniority, and that's being conservative)
• Fewer complaints → Less time on service recovery → Free up capacity for actual growth
• Better visibility → Faster decisions → Revenue comes in sooner, or you avoid costs before they spiral
• Better customer experience → Churn drops → You keep more revenue (especially powerful if you're in any kind of subscription model)
• Faster resolution → Create capacity → Grow without hiring more people

If you can't connect a benefit to cost, revenue, risk, or cash flow, fine. Label it as qualitative impact. But don't call it ROI.

Time Saved ≠ Money Saved (This One Trips Up Everyone)

My colleague wanted to get the budget for the automation project. The numbers were impressive: a team of 20 saves 200 hours/month. The reply he heard: "We're not firing anyone. They'll just do other stuff. So… where's the cash?"

Brutally honest, but unfortunately accurate.

Time saved = capacity created. But without structural change, there is no financial return.

What you can do

Make it real with one of these:

1. Actual headcount reduction (rare, painful, clear)
2. Hiring avoidance ("30% more volume, same people")
3. Revenue expansion (freed time → more sales/orders)
4. Reallocation to higher-value work (with measurable output)

Ask hard: "If we save 2 hours/week/person, what structurally changes?" If the answer is "nothing much", it's efficiency, not ROI.

Model separately: cost reduction vs. capacity creation. Don't mash them.

The Best Returns Are Structural (But Nobody Wants to Wait for Them)

Are you dealing with legacy systems or UX/tech debt, and you crave some time to 'clean things up' to make it easier and faster to build new features? Do you have to keep explaining to the business why simple changes take so long? Yet, there are always more urgent priorities to pick up first. Why is it so challenging to win those types of projects?

Most models obsess over 6–12 months ROI. Yet, the biggest value is often structural:

• Foundation for future automation
• Better data → AI viable later
• Scale without coordinator bloat
• Faster/cheaper changes (no legacy fights)

Business wants payback yesterday. Structural changes may take years. Tension kills projects.

What you can do

Split the case:

Layer 1: 12-Month Operational ROI (direct savings, avoided hires, faster revenue) - gets approval.

Layer 2: Structural Enablement (data quality, debt reduction, scalability, key-person risk drop) - long game.

Quantify where you can: future hires avoided, next project faster/cheaper.

Be honest: "Short-term payback is moderate. Long-term capability is huge."

Honesty builds trust. Overpromise kills it.

If You Don't Define Success Upfront, ROI Becomes a Post-Launch Argument

I learned that the hard way. I was redesigning the App Homepage for increased return visits. Even though I did define the success metric up front, there was no commitment from the business. A/B test came back - some metrics went up, others went down. Surprise? Not at all - but it was enough to freeze the project for the next quarter.

If the success metric isn't crystal clear before you start, ROI becomes a debate after you launch. And you'll lose that debate because everyone's measuring different things.

What you can do

Before you model anything, run a 60-minute alignment session. Force answers to these:

• What metric actually decides success?
• What metric decides failure?
• What number would make us kill this project?
• What matters most: cost reduction, revenue growth, risk mitigation, or workload relief?

Make leadership pick ONE primary metric. Get everyone to commit. Document it.

Define what clear success looks like:

• "Success = 20% reduction in cost per case within 12 months"
• "Success = avoid hiring 2 FTE next year while handling 25% more volume"
• "Success = reduce customer churn by 3 percentage points"

If different stakeholders want different outcomes (they will), model them separately. Show the trade-offs. Make the choices explicit.

The App homepage project was successful. The business agreed on a core metric that has to increase, and which metrics they are willing to let go of. The new app homepage was released to 100% of users 6 months later. Not every project gets a second chance, though.

The Pattern Underneath All of This

When you properly map the current state, including time, cost, risk, and decision points, ROI becomes measurable instead of aspirational.

ROI becomes calculable when:

• The unit of value is clear (what are we actually delivering?)
• The system is visible end-to-end (no black boxes)
• The cost is explicit and fully loaded (no hidden expenses)
• The structural change is defined (what actually changes?)
• The success metric is agreed upfront (everyone measuring the same thing)

Most ROI failure is governance failure. Not maths failure.

The formula is easy. The translation from hours to pounds is hard. Getting alignment across stakeholders is harder. Having the discipline to measure what matters instead of what's easy - that's hardest of all.

But when you get it right? You build projects that actually deliver value, actually get funded, and don't become cautionary tales in next year's budget review.

If this kind of thinking resonates with you, subscribe to get more insights like this straight to your inbox.