Bad usability is like a leaky pipe or driving or a road riddled with potholes.

I am famous for my car analogies. Most people get them immediately because they all have experience with cars, and I've been able to come up with some good examples that helped people understand some really complicated things.

Here's a great non-car analogy from 90 Percent of Everything: bad usability is like a leaky pipe.

The author explains that if there are too many opportunities for the user to get lost or make mistakes, then you might not see as many customers completing the transactions you were hoping for at your web site. This is applicable to applications too.

The article includes a graphic that shows how a lot of water might drip out on its way to the tap. Each drip represents a usability "leak" such as "What does that error mean?" and "What do I do next?" What you get at the end is not the complete volume that was supposed to come through but just the amount that managed not to drop out along the way. Imagine losing 60% of your customers simply because they got lost on the way to completing the sale! What is the likelihood of them coming back for more?

My car analogy would probably be about potholes, and I'd say something along the lines of...

If the drive to your store is always characterized by potholes, detours, traffic, or other undesirable incidents, then drivers are likely to choose much more comfortable alternate destinations even if those destinations only offer a portion of the things the original destination promised.

In other words, your store might lose a sale, and maybe a customer for life if your product's usability stinks.

It's bad enough when heavy rains cause the potholes, but it's worse when the potholes are of your own creation.

It's easy for a programmer to become oblivious to usability holes. The assignment might have been broken down into tangible sub-tasks, and somewhere along the way, there is no check to evaluate the whole solution to see whether it is "correct" in all dimensions. It may employ the best possible algorithms and a pass a peer review, but what about the user's review? Does the solution work for the user?

Users don't care why your program is fast or slow, they just know that it is.

Users don't care why something can't be clicked or can't be scrolled, they just know that they'd like to click or scroll those things.

What they care more about is not whether your task was completed on schedule and budget, but whether theirs will be.

It's especially bad when a competing product or service might do a better job at providing those same features, because the user will need more justification to keep using yours. As stated by Raymond Chen at The Old New Thing blog, "it doesn't matter how great your 1.0 system is if you don't survive long enough to make a 2.0."

No matter how magnanimous your supervisor claims or wishes they could be, the reality of life is that you have to meet deadlines and get some code turned in. Do what you can to ensure that you are truly solving the customer's problems and not just your own, or else there may not be any customers/clients, and eventually no deadlines at all because there's no product to work on.