Software Product Design - what is the ROI of good UX?

8 min read

Product Design, QA

Let’s say you’re dealing with a software development project. You’re trying to develop an app or any other software product. Here’s how the story usually goes:

Your project is approved. Check.

You’ve assembled your development team. Check.

You’ve allocated your Product Design budget… Have you?

Wait, what? We are already behind on this project. We need to go straight to development.

- the average Project Manager’s response to allocating a design budget

This kind of reasoning is unfortunately still quite popular in digital projects.

I understand where this is coming from. It can be really tough to see the value of user-centered product design.

It’s especially tough when you’re only measuring your project cost in hard cash, disregarding increased or more efficient feature use and higher user satisfaction.

At the end of the day, you might even say that it is possible to create software without a dedicated design team but not without developers, right?

Well, of course, it is. The same way you can learn how to play the piano by just playing.

But let me ask you one additional question: is this the most effective way?

A case-by-case demonstration of the ROI of proper Product Design

In this post, I’ll make a business case for Product Design and put my money where my mouth is by showing you some serious numbers behind it.

My ROI calculations were inspired by a great white paper by S. Weinschenk: Usability: A Business Case. But there are also plenty of resources which you can use to calculate different ROI’s from the perspective of User Experience and Product Design - check out those calculators.

So let’s talk money and start crunching the numbers.

Case #1 - Design work prevents usability problems and missed use cases


Design will cost you less than development. Correcting a problem at the development stage is generally 10x more expensive than fixing the same problem during the UX design phase. If the product goes into deployment, the cost of correcting the problem is multiplied by x100. This is also known as the rule of 1:10:100.

To put this into perspective - by correcting usability problems in the design phase, before development, American Airlines reduced the cost of those fixes by 60–90%.


While building an advanced search engine, two important use cases were overlooked because the end users were not included in the discovery phase of the project. Now those use cases need to be added to the next development sprints. But it turns out that the new use cases disrupt the flow of the rest of the searching activities.


# of changes - in this case the number of overlooked use cases

avg. hrs/change - time to create code for the use cases or to resolve them through design

employee cost - hourly rate per employee (designer/developer)

project maturity factor - let’s follow S. Weinschenk and assume that it is ‘only’ 4 times more expensive to make the changes during the development than during initial design


(# of changes) x (avg. hrs/change) x (employee cost) x (project maturity factor) = cost savings


Please note that the hourly rates that I assume here are only for demonstration purposes.

(2 changes) x (30 hrs each) x ($40/hour) = $2,400 if noticed and fixed during the design phase by Product Designers

(2 changes) x (30 hrs each) x ($40/hour) x (4 due to opportunity cost, lost sales, etc.) = $9600 if changed late by the developers

total savings: $7200

Case #2 - Design Work makes developers more productive


If you establish clear design system rules and introduce proper design handoff practices, you can increase developer productivity drastically. This will also help you avoid unnecessary explanatory meetings as the designer can show and explain some functionalities through mockups and prototypes - and people tend to be visual thinkers so it is much easier for them to wrap their heads around it.


While working on complex intranet software, a design system was established in order to give the developers easy access to all design specifications up front - without forcing them to dig deep into design source documents or make assumptions about spacing and measurements. The developers were notified about all changes across all elements in design and were able to adjust the code accordingly. This allows each developer to save 8 hours of work monthly.


(time worked monthly) x (employee cost) x (# of employees) x (# of months) = cost


Again, please note that the hourly rates here serve only as a hypothetical example to illustrate potential savings.

Cost of hiring a part-time product designer:

(80hr/month) x ($40/hr) x (1 Product Designer) x (12 months) =  $38 400/year

Savings due to established design system:

(8 hr/month) x ($40/hr) x (30 developers) x (12 months) = $115 200/year

total savings: $115 200 - $38 400 = $76 800

Case #3 - Design Work helps focus development on relevant features


70% of user-interface design features are never or rarely used. Early design involvement helps you make better decisions, prioritize dev tasks and create a clear product roadmap. In other words, development time can be reduced by building the RIGHT features right from the start instead of pivoting and and abandoning already developed features.


A fintech startup wanted to build an MVP with an internally established set of features. Those features, in the startup’s opinion, were necessary to provide value to their customers. The features were validated with end users through a series of prototype test workshops. It turned out that the solution seemed too complicated for the context of use and could benefit from simplifying the flow and cutting back on a couple of functionalities. In the end, the MVP was much cheaper and faster to develop.


(# of features) x (# of developers) x (average hrs/feature) = total MVP software cost


This time we'll limit our calculations to just work hours. I think they will still illustrate the point clearly.

Without product design support:

(6 features) x (4 developers) x (40h) = 960 hrs

cost: 960 hrs for the original MVP

With product design support:

Let’s assume that we validate the idea using the Google Ventures Design Sprint Methodology

(4 designers) x (8 hr/day) x 5 days = 160 hrs

and the development work:

(2 features) x (4 developers) x (40h) = 320 hrs for the MVP after the prototype testing

cost: 480 hrs for the MVP after the prototype testing

total savings: 960 hrs - 480 hrs = 480 hrs

As you can see, user-driven design is not just about creating positive experiences for the customers - it’s also a smart business move.

And there you have it...

As Tom Greever once stated: “The design of your software will happen one way or another. It is up to you whether it will be created purposefully by a skilled team of designers or by accident by developers trying to make their best guess.”

I’m saying this with all due respect for the developers - their role is essential. But they should not be forced to take over all of the responsibilities of a designer.

Product Design perceived as pixie dust sprinkled on the project at the very end to make it pretty and effortless is a misconception. And this misconception needs to be dealt with.

Of course, if you don’t include Product Design in the original estimate, your budget will look great on paper. However, in the long term, it might turn out that skipping this phase was more expensive than introducing it to the budget in the first place.

Some professionals believe that Product Design is just the cherry on top of the cake. But in fact, it is the main ingredient of the dough recipe - the one that holds everything together. Without it, there is a huge risk that you will end up with a sad, flat layer of cream.

Our recommendation? Hire a Product Designer - or a couple of them. Stop wasting your precious time and money on unnecessary features and superfluous developer work. Help your team reach peak productivity, and make your product the best it can be for the end users.

If you’d like to know more about how User Centered Product Design sets the right direction for the development process at STX Next, just give us a shout. You can always reach us at or via our (freshly updated) Contact Us page.


nearshoring ebook

Marcin Siemieński

Product Designer

More articles about Product Design, QA