What Bad Usability Costs: Six Hidden Types of Cost and How to Calculate Them

Monday morning in the support team of a mid-sized online shop: dozens of emails have come in overnight, again. “Where can I find my invoice?”, “I can’t get into my account”, “Why do the shipping costs only show up at the very end?” The team answers them on autopilot, just like every Monday. Nobody in the company would book these emails as “the cost of bad usability”. They’re just part of the job.

That’s exactly the problem. Poor usability, meaning a product that is hard to use effectively and efficiently, never appears as its own line item on a balance sheet. It hides in support budgets, in drop-off rates, in developer overtime and in customers who quietly move to a competitor. So if you want to win support for UX work in your team, “but it’s awkward to use” is rarely enough. You need a sense of what awkward actually costs.

This article shows the different ways bad usability costs money, which of the frequently quoted numbers hold up and which don’t, and how you can calculate the cost for your own product step by step.

Why bad usability rarely shows up on the bill

A server outage is visible. There’s a point in time, a cause and usually a figure for how much revenue was lost in that hour. Usability problems work differently. They don’t cause big outages, they cause lots of small bits of friction that add up over months.

Three things make them especially hard to pin down:

• The cost shows up somewhere other than the cause. An unclear form in the product leads to calls in support. The product team never sees the calls, and the support team doesn’t know the form.
• Lost customers rarely complain. People who abandon checkout don’t usually email you to explain why. They’re just gone.
• Habit makes you blind. Internal teams have learned to live with workarounds. Three extra clicks every day eventually start to feel normal.

That’s why a systematic look pays off. Broadly speaking, the costs fall into six types.

The six types of cost from bad usability

1. Lost revenue and conversions

The most direct type of cost: people want to do something, like buy, book or sign up, and fail. The metric for this is conversion, the share of visitors who complete a desired action.

E-commerce shows how big this lever is. The Baymard Institute regularly reviews studies on shopping cart abandonment and arrives at an average documented abandonment rate of just over 70%. Not every abandoned cart is a usability problem, since many people are just browsing. But the reasons Baymard collects in its survey include classic UX issues: 18% of respondents abandoned because the site wanted them to create an account, 17% because the checkout was too long or complicated, and another 17% because the website had errors or crashed. 19% didn’t trust the site with their credit card details, which often has to do with design and trust signals as well.

Based on its usability testing, Baymard estimates that the average large online shop could increase its conversion rate by around 35% through better checkout design alone. That’s an estimated potential, not a guarantee. But it shows the scale: this isn’t cosmetic, it’s a significant share of revenue.

For what these improvements look like in practice, the article Forms Nobody Abandons walks through a checkout example.

2. Support costs

Every question an interface doesn’t answer on its own ends up in support sooner or later. And support is expensive. In 2019, the research firm Gartner compared the cost of different service channels: live channels such as phone, live chat and email cost an average of 8.01 US dollars per contact, while self-service through a website or app cost about 0.10 US dollars.

The same Gartner research also shows how rarely self-service actually works: only 9% of respondents said they had resolved their issue completely on their own. The gap between those two costs is, at its core, a usability question. If someone can’t find their invoice in their account, a contact worth a few cents turns into one worth several euros.

An example to illustrate: an online shop receives 250 requests a month because resetting a password is confusing. If the team calculates internally with 6 euros per handled request, that’s 1,500 euros a month or 18,000 euros a year, for a single problem. The numbers are assumptions, the method isn’t. With the real figures from your ticketing system, you can put this calculation together in half an hour.

3. Lost productivity in internal tools

With software that employees use every day, the cost doesn’t show up in revenue but in working time. Internal tools are often treated with a “as long as it works” attitude. Yet every second here is multiplied by the number of users and the number of tasks.

A worked example, clearly meant as one: a service team of 120 people handles 40 cases per person per day. Because the CRM spreads important customer data across three tabs, every case takes 30 seconds longer than it needs to.

• 120 people × 40 cases × 30 seconds = 2,400 minutes, or 40 hours per day
• 40 hours × 220 working days = 8,800 hours per year
• 8,800 hours × 40 euros employer cost per hour = 352,000 euros per year

Half a minute sounds like nothing. Scaled up, in this example it adds up to several full-time positions. On top of that come effects that are harder to put a number on: mistakes from entries in the wrong field, longer onboarding for new team members and frustration that drags down morale.

4. Rework in design and development

A usability problem that only surfaces after launch is more expensive than one discovered on a paper prototype. After release, code has to be rebuilt, tested and shipped again, documentation and training need updating, and sometimes data models or interfaces depend on the wrong decision.

This point is often backed up with a specific number: a defect fixed after release supposedly costs up to 100 times as much as one fixed during design. The source usually given is an “IBM Systems Sciences Institute”. Be careful with that number. Research reported by The Register, among others, concluded that there is no traceable study behind it, only course notes from an internal training program whose underlying data can no longer be verified. The basic idea remains plausible, but you shouldn’t present the factor of 100 as an established fact.

Here, too, your own numbers are the better choice. How many tickets in your development backlog trace back to problems an early test would have caught? How many person-days did the last major post-launch rework take? Figures like these carry more weight in your company than any industry statistic.

5. Operating errors with major consequences

Sometimes bad usability doesn’t cost lots of small amounts, but a huge sum all at once. A widely discussed example comes from banking. In August 2020, Citibank, acting on behalf of the cosmetics company Revlon, meant to send an interest payment of around 7.8 million US dollars to lenders. What actually went out was around 900 million US dollars.

A large part of the cause lay in how the loan software Flexcube had to be operated. According to accounts in the later court case, the intended transaction could practically only be entered as a full repayment, with the principal redirected to an internal account. That required overriding several fields. Only one was filled in. Three people reviewed the transaction under a “six eyes” principle and approved it. The interface didn’t make clear enough what would actually happen on submit.

Some of the money came back, and around 500 million US dollars ended up in court. A federal court in New York initially ruled in 2021 that the recipients could keep the money. Only in 2022 did the appeals court overturn that decision. Whatever the outcome, the case shows that when an interface doesn’t clearly show what will happen during high-stakes actions, even several layers of review don’t help much.

In practice, this means critical actions need a preview of the result in plain language (“900 million US dollars will be transferred to 315 recipients”), sensible defaults and a confirmation step that consists of more than just “OK”.

6. Trust, churn and barriers

The last type of cost is the longest-lasting. Bad experiences stick. In a global PwC survey from 2018 with around 15,000 participants, one in three (32%) said they would walk away from a brand they love after just one bad experience. Usability isn’t the only part of that experience, but it’s a big one.

This becomes especially clear for people with disabilities. The UK’s Click-Away Pound Survey 2019 found that 69% of disabled respondents leave websites they find difficult to use. The team behind the survey estimated the resulting lost online sales in the UK alone at 17.1 billion pounds a year. That’s an extrapolation from a survey, not an exact measurement, but the direction is clear.

In Germany, there’s a legal dimension as well. Since 28 June 2025, the Barrierefreiheitsstärkungsgesetz (BFSG), Germany’s implementation of the European Accessibility Act, has applied to many online shops and digital services, among others. Under section 37 of the BFSG, violations can lead to fines of up to 100,000 euros. Accessibility is therefore not just a question of good usability, but also one of risk.

Be careful with numbers from the internet

Search for the cost of bad usability and you’ll quickly find impressive statistics. Some are solid, many are not. Before you put a number into a presentation, ask three questions:

• Is there a primary source? If a number only appears in blog posts that quote each other, treat it with caution. The factor of 100 for software defects is the best-known example.
• How old is it? In 2008, the Nielsen Norman Group (NN/g) analyzed 72 case studies and found an average improvement of 83% in key metrics through usability work. An earlier analysis had even found 135%. These figures are interesting, but almost two decades old, and NN/g itself pointed out at the time that gains get smaller the better the starting point.
• Does it fit your context? An abandonment rate from US e-commerce says little about a B2B tool for tax advisors. An estimate for the UK can’t simply be transferred to Germany or the US.

Industry numbers are a good way to start a conversation. But decisions should rest on numbers from your own product.

How to calculate the cost for your product

The good news: for a convincing calculation, you need neither a large analytics team nor a year of data collection. Four steps are enough for a first, honest estimate.

Step 1: Pick one specific problem

Don’t start with “our UX is bad”, start with a single, clearly observable problem. Good candidates can be found in support tickets, in analytics data with noticeable drop-offs or in the results of a usability test. How to set one up is covered in Your First Usability Test.

Step 2: Measure how often it happens

How often does the problem occur? Count tickets with a certain tag, drop-offs at a specific point in the funnel or tasks per day in an internal tool. If you don’t have an exact number, use a cautious estimate and note where it comes from.

Step 3: Determine the cost per incident

This looks different depending on the type of cost: for support, it’s the effort per ticket; for internal tools, lost working time multiplied by the hourly rate; for conversions, the average order value or the value of a lead. Finance, sales or the head of support usually know these numbers. Ask instead of guessing.

Step 4: Scale it up and stay conservative

Multiply frequency by cost per incident and project it over a year. The important part: don’t assume the whole problem will vanish. If you claim an improvement will win back every single abandoned checkout, you’ll lose credibility at the first critical question. Calculate with a small share instead, and say clearly that it’s a cautious assumption.

An example from start to finish

A made-up but realistic scenario: an online shop for outdoor gear sees in its analytics that around 20,000 people start checkout every month. At the “Shipping” step, about 2,400 of them drop off, far more than at any other step.

A short usability test with five people provides the explanation: three participants searched in vain for the shipping costs, which only appear after the full address has been entered. Two of them said they would normally abandon at this point.

The team’s calculation:

• Frequency: 2,400 drop-offs per month at the shipping step
• Cautious assumption: only 10% of them can be kept by showing shipping costs earlier, so 240 orders
• Value per incident: average order value of 45 euros
• Result: 240 × 45 euros = 10,800 euros per month, around 130,000 euros in revenue per year

On the other side are a few days of design and development work to show shipping costs in the cart. Putting the two side by side makes the decision easy, without anyone having to “believe” in UX.

After the change, measure the result: does the drop-off rate at the shipping step really go down? Which metrics work for this is explained in Measuring UX: Task Success, Time on Task, SUS and Conversion.

How to use the numbers in your team

A good calculation on its own doesn’t convince anyone. What matters is how you present it.

Speak your audience’s language. Leadership cares about revenue and risk, the head of support about ticket volume, engineering leads about rework. The same usability problem can be expressed in each group’s own metric.

Connect numbers to real people. A short video clip from a usability test, in which someone spends a full minute looking for shipping costs, often has more impact than any spreadsheet. The number shows how big the problem is. The video shows that it’s real.

Be open about your assumptions. Note for every number where it comes from and what’s estimated. That makes the calculation open to challenge, but also trustworthy. And if someone has a better number, even better: then you keep calculating together.

Start small. A single problem, properly calculated, fixed and measured again, convinces more than a big slide listing twenty issues. Every documented success makes the next discussion easier.

Conclusion

Bad usability costs money, it just never appears on an invoice. It’s spread across lost orders, overloaded support teams, wasted working time, expensive rework, rare but serious operating errors and customers who don’t come back.

Industry figures like those from Baymard or Gartner help you understand the scale. But the argument only becomes convincing with numbers from your own product. With one specific problem, an honest estimate of how often it occurs and a cautious projection, you make visible what used to be just a vague feeling. And then UX is no longer a matter of taste, but a traceable investment.

Checklist

• Support tickets searched for recurring questions the interface could answer itself
• Drop-off points in the funnel identified in analytics
• Time per task and number of tasks collected for internal tools
• One specific problem selected and confirmed with a short usability test
• Frequency, cost per incident and annual projection documented
• Cautious assumptions made and stated openly
• Industry figures checked for primary source, age and context
• Critical actions protected with a clear preview and confirmation
• Accessibility and legal requirements such as the BFSG taken into account
• Effect measured after the change and compared with the baseline

Sources

• Baymard Institute: Cart Abandonment Rate Statistics
• Baymard Institute: Checkout Usability Research
• Gartner (2019): Press release on self-service resolution and cost per contact
• The Register (2021): Everyone cites that “bugs are 100x more expensive to fix in production” research, but the study might not even exist
• Banking Dive (2020): Citi’s “six eyes” come under fire as trial begins over $900M error
• TechSpot (2021): Report on the Flexcube interface in the Citibank case
• Alston & Bird (2022): Debtholders Are Not Entitled to Keep $500 Million
• Adobe Blog (2018): Summary of the PwC study “Experience Is Everything”
• Click-Away Pound Survey 2019: Press release
• Nielsen Norman Group (2008): Usability ROI Declining, But Still Strong
• Section 37 BFSG: Provisions on fines (in German)