Let’s get this out of the way up front; most software training sucks. No wait…it REALLY SUCKS!
Having spent a significant part of my training career at various software companies, I certainly saw more than my share of software training approaches. Some were good, but most of them – not so much. So let’s talk about what makes for good vs. bad approaches to software training, and how you can make your next software training course effective and enjoyable for your learners.
Why Is Most Software Training So Bad?
I hate to blame an inept approach on the tool people use, but our tools can definitely lead us astray if we let them guide our design decisions. Let’s take a tool like PowerPoint as an example. It is possible to design outstanding, compelling, gorgeous slides in PowerPoint. However, the default bulleted templates steer most novice designers to create walls of text-based screens. It’s not the tool’s fault for bad design decisions, but it is to blame for making bad screens so easy and tempting to create.
In much the same way, Adobe’s Captivate is to blame for the lazy approach you see most often. For over a decade, Captivate has made it easy to create step-by-step “training” with a simple click. The problem is, most people stop here and use the default output. As other tools have joined the mix, they’re all trying to make it easier to create training.
Guess what: The software tool you’re using isn’t very creative, so letting it do all the work results in a pretty bad result.
The Typewriter Approach
My first training job was as a software trainer, and this was a term I started using as I observed other software trainers. Think about how a typewriter works. If you’re a young’n that doesn’t know what a typewriter is, check Wikipedia.
Anyway, a typewriter goes left to right and top to bottom, over and over again. This is how I would see people explaining screens, one field at a time, from left to right, left to right, etc. Just like a typewriter. This typewriter mentality has persisted into an eLearning approach of defining every field in this same manner. The problem is, we don’t use the actual software this way. Explaining screens this way takes every field out of context and forces the learner to memorize each field for what it’s for, regardless of if/when they might use it. Painful!
Simon Says: Click HERE
The other common problem I see with the typical software training approach is they provide no opportunity for learners to use their brains. By default, all the tools that make creating software training quicker and easier (Captivate, Storyline, etc.) do so by putting callout boxes next to the field the learner is supposed to interact with, instructing them what to do next.
-Hey learner, which button do you think you’re supposed to click next?
-Um, I don’t know Mr. eLearning narrator, could it be the one with the huge arrow pointing to it?
This follow the callout box approach robs the course of any challenge. If learners aren’t asked to apply knowledge in any meaningful way, the likelihood they learn anything is minimal.
Screenshot Visuals: A Blessing AND A Curse
One of the biggest challenges novice designers have designing an eLearning course are the visuals. Not only figuring out what they are going to put on the screen, but determining a look-and-feel that is client aligned and supports the learning efforts. One of the good things in a case like this is that software training solves the what am I going to put on the screen dilemma for you, by giving you a big screenshot to put on the screen. The problem with this is that software training forces you to put a big screenshot on the screen. For the seasoned designer wanting to create engaging visuals, or the savvy developer looking to add additional functionality, a giant screenshot can be a real obstacle to including anything other than the software screen.
Workflows Equal the What
With all this negativity, and the countless brutal software training courses you’ve undoubtedly seen over the years, it can be easy to feel that quality software training is merely a fantasy. But alas, there are some main components that can turn your next software training course around. The first of these are workflows. A workflow is the series of steps that are needed to perform a particular task or job function. Let’s compare the typewriter method to a workflow-based approach for a tool like Microsoft Word.
The typewriter approach would start with the Home tab and explain each individual button. Next it would talk about the Insert tab and all the buttons there. Etc. Etc. Etc. Now, I’m really good at using Word, but I don’t know what every button does. Frankly, there are some features I’ve never used and others I didn’t even realize are there. To this end, the workflow approach doesn’t try to explain every function, it explains the steps needed to accomplish particular tasks. So maybe I have a task of writing a business letter, which would include steps to set the margins, and change the font, and other things needed specifically to compose that letter. This helps place steps within a framework of what they do in meaningful tasks, rather than in an unrelated memory exercise.
Scenarios (Stories) Equal the Why
It’s great to string steps into tasks, as this will make them easier to remember as they perform something tangible. And luckily, this is something Captivate and Storyline do a decent job at capturing. However, unless those tasks are tied to something relevant to the learner, they won’t care. As with all good training, we need to explain why.
The best way to accomplish this is to put learners in a realistic situation. Use a common story learners will encounter in their job, and put them in a position to address their role in that story using the software you’re training on. A great example of this is CRM (client relationship management) training in a call center. Call center employees need to look up information and enter new information on client records all day long. Why not simulate customer phone calls as the prompts for the trainee to interact with the software? What better way to provide the relevance than by thrusting learners into realistic job scenarios, forcing them to use the software in its intended ways.
Tell Me, Show Me, Let Me (Fail)
Finally, you need both passive and active components to the training, but that’s not the biggest key. Most of the tools we’ve discussed allow for show and do type presentations, but we need to ensure they maintain the challenge. “Click this here and type that there” doesn’t get it done. Give people the same types of information they’ll be provided on the job and turn them loose to interact with the software from there. Provide them with a hand-written Post-It note, a completed patient intake form, or whatever will be relevant in their job role. Then tell them the task they need to accomplish with that information and turn them loose.
This will force them to build the same mental connections as doing the real job and will lead to actual learning. Allowing them to fail something challenging and try it again is a good thing, so don’t go too easy.
Storytelling Wins in Software Training
The bottom line here? Your software training should have a narrative rather than just robotically moving learners through the course. Let them get hands-on with their training, and the overall experience will be much more meaningful.