The UX Cost You Don’t See on the Project Budget

When UX gets deferred to hit a delivery date, the cost doesn’t necessarily disappear. It may simply move somewhere else.

Over the past two years, working across three different large organizations, I have watched variations of the same situation play out. A product is moving toward a PI delivery or MVP, development needs to keep moving, requirements have been committed to, budgets have been allocated, and leadership understandably expects progress. Somewhere during that process, UX identifies a problem or many problems. Maybe a workflow is unnecessarily complicated. Maybe similar applications behave differently. Maybe a design-system component is being used in a way it was never intended. Or perhaps research has shown that users don’t understand something the way the project team assumed they would.

Often, nobody is arguing that the UX concern isn’t valid. The problem is that there is a deadline, and eventually the conversation becomes, “We’ll address it later.” Sometimes that is absolutely the correct business decision. Products need to ship, budgets exist, and an MVP doesn’t need to be perfect. UX professionals also need to understand that business realities sometimes require compromises. What concerns me is when organizations interpret that decision as having saved time or money, because from what I have observed, the cost doesn’t necessarily disappear. It simply moves somewhere else. Let me explain…

Making the Delivery Doesn’t Make the Cost Disappear

Organizations understandably measure delivery. Leadership wants to know whether the team made the PI commitment, hit the MVP date, completed the feature and released when it said it would. Those measurements matter, but shipping on time does not automatically mean that we created the most efficient experience. If a UX issue is intentionally deferred to make a delivery date, the organization may simply be transferring the cost from product development into business operations.

Instead of spending additional hours addressing the problem during design and development, hundreds or thousands of users may now spend additional minutes navigating that problem every day. An employee takes slightly longer to complete a task. Someone needs another attempt. A customer calls support. Another employee develops a workaround. Documentation has to explain an unintuitive process. Training materials compensate for something the interface doesn’t make clear. None of those individual events is likely to trigger an executive alarm, and they probably won’t appear as a large expense on the original project’s budget. Collectively, however, they can represent a significant operational cost.

Consider something as simple as an inefficient workflow that adds only three unnecessary minutes to a routine task. That is easy to dismiss during development, particularly when a delivery date is approaching. Now imagine that the workflow is performed twice each working day by 1,000 employees. Those three minutes become six minutes per employee per day, which across approximately 260 working days represents about 26,000 employee hours annually. At an illustrative loaded labor cost of $50 per hour, that is approximately $1.3 million in employee time every year.

I am not suggesting that every three-minute UX problem costs an organization $1.3 million. The numbers are intentionally illustrative. The point is that UX problems operate at scale, and that is something I believe organizations sometimes fail to calculate when deciding what is important enough to fix before release. A few additional minutes multiplied by enough people, transactions and years can transform what looked like a minor design issue into a significant business expense.

“Don’t Worry, We’ll Train the Users”

There is another phrase I have heard during product development that should cause teams to ask a follow-up question: “Don’t worry. We’ll train the users once it launches.” Training absolutely has a legitimate role in enterprise applications. Complex business processes, regulations, security requirements, specialized professional responsibilities and organizational policies may require education. UX cannot — and should not — eliminate the need for people to understand how to perform their jobs. The problem begins when training becomes the solution for an unnecessarily difficult interface.

If users require a training video to understand basic navigation, documentation explaining where commonly used information is hidden, or a step-by-step guide simply to complete an everyday task, we should ask whether we are training people on the business process or training them to compensate for the design. Those are two very different things, and they carry very different implications for the organization.

When the response to a usability issue is “we’ll cover it in training,” the cost hasn’t disappeared. Someone still needs to develop the training strategy, write the documentation, record the videos, create learning modules, involve subject-matter experts, administer the program and maintain those materials as the application changes. Employees then have to spend time completing that training, managers may need to track it, and support teams may need documentation to help people navigate the same experience.

Consider 5,000 employees completing a one-hour training module because an application is unnecessarily difficult to understand. Before those employees have performed a single productive task in the system, the organization has consumed 5,000 hours of employee time. At an illustrative loaded labor cost of $50 per hour, that represents $250,000 in employee time before accounting for the cost of creating, administering and maintaining the training itself. And after the training is complete, the original UX problem may still exist. The employee has simply learned how to work around it.

This is why I make an important distinction when organizations talk about training: training should teach people how to perform their work; it should not have to teach people how to survive the interface. If a relatively small UX problem could have been corrected during design or development, but instead creates years of training materials, employee hours, support calls, documentation and workarounds, leadership should at least understand the complete cost of the decision it made.

The UX Cost You Don’t See on the Project Budget was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.