10 Apr 2013 by Gene Smith
Training vs. Design

A friend of mine, a mid-level manager in a large company, recently told me about his employer’s new expense tracking system. Like many big organizations, my friend’s firm designs and builds many of its internal applications. While rolling out the application, this company asked its employees to take a two-hour training session to teach them how to enter their expenses.

To say my friend is busy would be an amusing understatement. Naturally he was frustrated with the time commitment for training on such a mundane activity. I agreed that a two-hour lecture on logging receipts seemed excessive. But I was also astounded at his employer’s financial investment in training. If you count the costs for developing the training materials, delivering the sessions and the staff time, this organization probably spent well into the seven figures on training alone.

That’s a lot of money, right? You’d expect to see some serious results with that kind of investment. But my friend reports that the next time he went to enter his expenses–probably a few weeks after his training session–he was pounding his keyboard in frustration.

Was he the only one? No, in fact, almost *everyone* who had to do expenses regularly felt this way.

This story encapsulates a common problem we see in enterprise application development projects: spending a lot of money on training instead of making a small investment in design.

The Economic Consequences of Ignoring Design

There’s a simple and compelling economic argument in favour of design over training: design is a one-time investment; training is an ongoing investment over the life the product.

Not only do you incur training costs at least once for every user, the worse your user experience, the more likely you will incur those costs multiple times for every user (in the form of retraining and peer support).

Let’s go back to my expense-tracking friend. His company has already spent over a million dollars (by my estimation) on training to roll out their new system—but realistically they’re just getting started. Every new employee will need training at least once, and there will be support costs and lost time due to preventable errors. And let’s not forget intangibles like the unnecessary frustration and the lost goodwill of employees.

Most importantly, no amount of training will ever fix the design flaws in this system.

A better approach would’ve been to do some prototyping and evaluation of the application–iterative design, in other words—-prior to the build. But for a variety of reasons—-sometimes it’s organizational culture, sometimes it’s ignorance of iterative design methods—-we see organizations trying to correct their user experience problems with training.

What’s the Problem?

We’ve noticed three related issues that contribute to this problem:

  1. Training is disconnected from application development. It happens at the end of a project, the costs are often distinct from development, and the trainer is engaged when the product is finished.
  2. Training is actively used to compensate for poor or just unconsidered design. More than once we’ve heard “we can train them on it” as a way to justify confusing design choices.
  3. Ongoing training, user frustration and preventable errors are negative externalities–they’re not accounted for in project budgets or in application operating costs so project managers are often free to ignore them.

What Can We Do Instead?

The first thing we should do is recognize that there are different kinds of training.

The Training Pyramid

  • People need to acquire domain knowledge about the system and how it fits into their work. Someone who’s never worked in a large organization might need to know what kinds of things (e.g., meals, mileage, office supplies) she can expense.
  • People need to understand the business processes and policies that govern the system. This could mean anything from the approval process for expenses, to the time required to process a claim, to the deposit dates for direct payments.
  • In our experience, much training focuses on “how to” information–the key tasks and procedures that people need to complete when using the system. This is tricky because procedural knowledge is hard to learn and recall without practice.
  • Finally, people will train each other informally on how to use systems effectively. For software that isn’t intentionally designed to be usable, a significant amount of time can be sunk into peer support (“hey Sally, can you show me how to upload my receipts?”) or sharing workarounds (“if you open the expense codes in a separate tab you can cut and paste them easily”).

Generally speaking, domain knowledge is easier to acquire and share while procedural knowledge requires some practice to master.

The key thing to recognize is that good design can reduce the need for formal training by anticipating people’s most important tasks and guiding them through them. In the case of expense tracking, an occasional-use application for most people, thoughtful design will help people do the right things at the right time without much training at all.

Good design should also eliminate the need for informal training through research (looking at the workarounds people currently use and designing the system to accommodate those) and evaluation (testing prototypes to ensure people don’t need to resort to workarounds to complete a task).

How Do We Fix This?

There’s a difference between knowing that design can reduce training costs and doing something about it. So how do we address the three core problems I mentioned earlier? Here are some suggestions:

Redeploy your training budget

If you’re not already doing design work in the early phases of a project, you should redeploy a portion of your training budget to design work in the requirements phase (or inception phase if you’re doing an agile project).

Focus on using your design efforts to improve the learnability, memorability. efficiency and error rates for the application. These are standard usability quality components, but it’s important to call them out specifically because they all impact the need for training.

This redistribution of funds will pay off over the life of the application. Remember, design is a one-time investment; training is forever.

How much should you move from training to design? We think it depends on whether or not your users need to master the application. For expense tracking, mastery is not required, so a large portion of the training budget (perhaps 80% or more) could potentially move to design.

For systems that require mastery (anything from air-traffic control software to everyday point-of-sale systems) you will still need training as well as practice time for your users. But if you’re not doing design work you’ll get value from spending some of your training budget on design. I can’t give you an estimate for how much to spend–it could be 10% or 50% or more depending on how complex and critical the application is. The key is to assess how much a one-time investment in improving efficiency or reducing error rates could reduce lifetime training costs.


Use an iterative design process so you can improve the application’s design quickly and cheaply as early as possible. Iterative design means you produce at least one prototype of the system, test it with real users, and make changes. Many of our projects involve three iterations of the application; some involve more. And our experience has been that sketches, wireframes and small-scale interactive prototypes are the best tools for working through design options.

(Side note: Agile projects are only iterative if the team revisits and improves features in future sprints. Most agile enterprise application development projects we encounter are not iterative.)

After Launch: Fix the Simplest Non-functional Problems First

These two approaches above are great at the start of the project, but what about after an application has launched? The development and training budget are spent, but your organization is probably still absorbing the hidden costs (frustration, support and peer training).

One approach that’s worked for us is focusing on small non-functional changes to the most problematic features. On a recent project we worked with the application developer on minor adjustments–such as relabelling confusing fields and allowing users to move directly between two screens they often needed in sequence instead of closing one then manually opening another. These changes improved user performance and satisfaction but didn’t require major effort or any functional changes.

Depending on your organization you might be able to do guerilla redesigns or cafe testing as well.

Quantify the Negative Externalities

Another approach that might be useful is estimating the costs of ongoing training, peer support, frustration and preventable errors (the consequences of ignoring design that aren’t factored into project budgets or operating costs).

UIE has a helpful article on the Cost of Frustration that provides several ideas for how you might quantify these things. Here are two we like:

  • Rather than trying to establish a dollar cost for frustration, talk about what people could do with their time instead.
  • Trace the pain and find allies who can support your cause. For an expense tracking system, for example, a finance manager may spend more time than they want on fixing errors or taking support calls.

This approach won’t yield immediate results, but it can help create a culture where design is valued because it contributes to the organization’s success. It also makes an explicit connection between doing iterative design and employee satisfaction, cost avoidance and project success. Then, the next time a big internal systems projects comes around, the project manager will be more likely to do a couple of rounds of design and prototyping early (and will have a way to justify the costs since it can come out of the training budget).

21 Feb 2013 by Andrew Wright

When to apply UX effort in agile

When should you apply UX effort on an agile project to get the most out of it? Well, UX design skills are most valuable to agile processes at three key points: during modeling, during evaluation, and for facilitating day-to-day design … Read More

07 May 2013 by Andrew Wright

User Experience Debt

UX debt is real and every digital product has some to repay. Some of this debt is incurred intentionally because tough decisions have to be made. Some of this debt is incurred unintentionally because assumptions about end-users go unchecked. It's … Read More