"How can I design good training for new software? What's the right balance between help screens, job aids, and training?"
That's a common question, so let's go at it.
Here's part 1, in which I say, "Try everything but training." We'll cover needs analysis, job aids, help screens, and the radical idea of making the software easier to use.
Later, I'll publish part 2. In that part, we'll look at how to design practice activities for times when the everything-but-training approach isn't enough.
1. Justify your work with a measurable goal
Action mapping begins with identifying how the organization will benefit from the project. The goal justifies the existence of the "training" (and of your job).
Here's a template:
To identify the measure for new software, you might ask, "Why did we buy this software? What problem will it solve? How will we know it worked?"
For example, if the organization is installing a new customer relationship manager, why? Have potential new customers been slipping through the cracks? If so, maybe your goal is this:
Sales to new customers will increase 5% by [date] as all sales reps correctly use NewCRM to identify new prospects and build relationships with them.
If your stakeholders refuse to commit to a business-performance goal, you might try a weaker but still useful type. For example, you could measure the strain that new software can put on productivity. For example, if the new software is already in place and causing confusion, you can try to reduce the number of calls to the help desk.
If you doubt the usefulness of this kind of goal, imagine the alternative. A too-common "goal" is "All sales reps will be trained on NewCRM by [date]." This says, "We don't care if the training actually works. We'll just take attendance. Now give us money."
For more on setting goals, see:
- How to create a training goal in 2 quick steps
- Write a strong goal: Sell it to Scrooge
- 5 ways to become an L&D hero
2. Ask, "What do they use the software to DO?"
List the most common tasks that people will use the software to complete. Also consider what might make each task difficult.
For example, is it obvious how to complete the task in the software? Are people working under time constraints?
This flowchart helps you consider all the angles.
For more on this, see the discussion in "Technical training: What do they need to DO?"
3. View training with suspicion
Many people assume that every new system must be introduced with formal training. But is that always necessary?
"New" doesn't mean "requires training"
Just because the software is new doesn't mean that people need to be trained on it. The likelihood that training will be necessary depends on a lot of things, such as:
- How different is the software from what they're using now?
- How tech savvy are the users?
- How complex are the tasks that the software is used to complete?
- How horrible is the outcome if someone screws up when using the software?
- How clumsy is the software interface?
- How much help is built into the software?
"Hard to use" doesn't mean "requires training"
If the software is clumsy and its help system is unhelpful, that doesn't mean that you have to develop training. It means the software should be made easier to use.
L&D staff are often surprised to discover that they can request changes to software -- but they have to ask. Don't assume that it's too late to change anything.
If the software is from a third party, making it easier to use would help their sales. If the software was developed internally, there's no excuse for refusing to make it easier. Clumsy software hurts performance.
Make a list of changes that will reduce the need for training. Take screenshots and scribble on them. Write the help blurbs that are missing. Point out where there are too many steps.
"They won't change it" doesn't mean "requires training"
If the software is hard to use and the developers have rejected your requested changes, that still doesn't mean that formal training is your only hope. How about some job aids?
4. Try some job aids
A job aid is a reference that gives you just enough information. It can be a piece of paper, a page on the intranet, a short how-to video, a help screen, or anything else.
We can use Moore's Machete of Awkward Oversimplification to divide software job aids into two groups.
Type 1: Task-based job aids
These are handy guides that quickly tell you how to complete job tasks using the software. Some examples:
- A short article in a knowledgebase shows you how to record a partial refund in the accounting software.
- A quick video shows you how to create a template for your marketing emails.
- The built-in help system highlights the commands you need to use to escalate a customer complaint in the CRM.
- An extensive, structured document helps you install WordPress, as deconstructed by Dave Ferguson in his handy site about job aids.
These are all aids that help you complete tasks. They aren't the painfully ubiquitous tour of the menus or alphabetical list of all commands.
Type 2: Code and command references
If users need to type in codes or non-intuitive commands, group the most common ones in a quick reference. As above, try to group the commands by what they achieve. Don't just list them alphabetically. Some examples:
- A cheat sheet for Excel, organized by task
- Gmail shortcuts organized by task (see the tables)
- A blog post that lists basic HTML codes that you can copy and paste into your own web site, organized by what you want to do
Let people choose how much information they need
Don't force-feed everyone with information in your job aids. Let experts skip ahead while novices read deeply. Here's an example from Dave Ferguson of a job aid designed to satisfy both groups.
Help screen or job aid?
A common practice is to use a help screen to give a quick overview of how to complete a small task. For longer tasks or more detail, the help screen could contain a link to a video, knowledgebase article, or other reference.
People should be able to use the software and view the reference at the same time. For example, a reference that opens to the side is way more useful than one that opens in the same window as the software and blocks it.
For a lot more about job aids from real job aid experts, see Job Aids and Performance Support by Allison Rossett and Lisa Schafer.
5. Test your job aids before designing training
Test your job aids on a sample of future users and tweak them as necessary.
If it looks like the job aids alone will get people up to speed, release them into the wild. Tell everyone where they are, make them super-easy to find for the people who missed the memo, and provide a quick feedback mechanism so users can tell you how to improve them.
Let the job aids do their thing for awhile, and then check the measurement in your goal. Has it improved? Also, have managers reported better use of the software? Has the help desk seen a decrease in the number of calls? If so, you might be done. You can make sure you're done by using Robert Brinkerhoff's Success Case Method.
In part 2, we'll look at what you might consider if you decide formal training is necessary.