A few weeks ago I wrote a post asking if it was possible to create engaging software training (spoiler alert: the answer is yes). That post focused on instructor-led, in-person training. Several people reached out to tell me they liked that post but were curious how it could be transferable to eLearning.
Why Do We Really Train on Software?
The most essential thing to keep in mind when developing any type of training on how to use software is that it’s not really about the features of the software at all. Engaging software training must be about what people ultimately do with the software. For example, nobody really cares about all of the tabs in Salesforce or all of the features available in the Cornerstone LMS. They will care about how to create a campaign in Salesforce or how to generate a course completion list for the annual compliance training modules in Cornerstone.
4 Ideas for Engaging Software Training
So how do we cut through superfluous information and features on software in order to get to what people really need in order to do their jobs better? Here are four ideas:
1. Review the vendor-provided training as part of the purchase decision.
I’ve seen way too many vendors ask their engineers (or salespeople) to put together basic user adoption training. They’re not instructional designers and they rarely know how to design participant-centered training, so they train on what they know: every feature in the system.
Until customers spending tens of thousands, hundreds of thousands or even millions of dollars on software system purchases begin to demand better vendor-supplied training, they’ll either be left holding the bag in terms of having to develop their own training to supplement what the vendor offers, or they’ll be left with bored and frustrated software users trying to make their way through poorly designed vendor training.
2. Create a mocked-up interface with limited features.
Introducing new software system users to bite-sized chunks of the system by grabbing screen captures and inserting hot spots and triggers only on certain features can help new system users grow familiar with key features without overwhelming them.
Inserting simple tasks to see if learners can click in the right areas or on the correct buttons followed by feedback on why the area of the system they selected is correct or incorrect is a way to build confidence and reduce the intimidation factor of the new system.
3. Give them tasks they’d be doing in addition to using the software.
Sometimes people use software systems in isolation of any other task. More often, people are doing other things, too. For CRM or other database system, people are taking data from other sources – sheets of paper, electronic files, etc. So, why not simulate these actual tasks in the system?
This builds upon point #2 (above) and challenges new system users to either download data electronically or print out data to simulate the steps they’d actually need to take to use the system.
In one new electronic medical record training we built for medical professionals who had to get basic health information (blood pressure, height, weight, etc) and enter it into the system, we created a scale (using the slider feature in Storyline) to “weigh” a patient, and then learners had to take that information and enter it into the system.
4. Give them real-life scenarios for which they’d need to use the software.
Some people who use new software systems are simply called upon to enter data and must do it accurately. Having three or five or ten scenarios in which learners need to accurately enter data as a sort of “final exam” may do the trick.
Other people need to generate reports and find key information. Several years ago I designed an eLearning-based software training in which managers were challenged to use a new system to generate reports, identify areas of strength and weakness in key performance metrics and actually have simulated coaching conversations with an avatar.
Beyond eLearning-based training, job aids and just-in-time resources such as checklists, flowcharts and FAQ documents can help new system users in their moment of need.
The main point here is that software training needs to be designed according to what the users should be able to do with the system. It is much more likely to be engaging software training when it is addressing what your learners have to do in their daily work. The biggest problem I’ve seen with software training design is that it’s too often designed with all of the features and navigations and engineering marvels in mind.
What’s missing from this list of ideas for creating engaging software training via eLearning? What would you add?