Karl Kapp put together some nice guidance on software training last week in his post Tips for Teaching Software to Others.

Of course, since teaching software to others is pretty much at the core of our business, I couldn’t resist leaving a terribly long-winded comment, which I will excerpt below.

But first, I want to point out another comment in the thread, by Dave Ferguson that I absolutely love:

With newcomers (to an application, or to computers generally), I also try to avoid alternative-itis, a disease pandemic among enthusiasts. Many actions have a menu route, a keyboard-shortcut route, and sometimes a mouse-action route. Telling someone three ways to save doesn’t usually facilitate learning. Mostly, it increases cognitive load.

While Dave makes a lot of other great points, this one has always bugged me. I’ve often said that software training courses should follow this sequence: 1. Get trained; 2. Use it for 30 days; 3. Get trained on all the hot-keys and shortcuts!

Finally, this probably violates about 25 blogospheric codes of conduct, but I am actually going to quote myself from Karl’s comment box. Here are some of my own tips for training software to others:

1. Require pre-work. A couple of concise web-based intros (or quick Captivate modules, or even Powerpoint slides), prior to arriving in class can yield a huge return in terms of what you can accomplish in the classroom. This kind of pre-work serves two purposes:

A) It brings widely disparate skill levels to a base level of understanding (logging on, basic navigation, simple searches). This is a huge time-saver in class, and greatly appreciated by faster learners.

B) Done right, it can reinforce for students why it matters that they learn the software. There’s nothing worse as a trainer than having to “justify-on-the-fly” the employer’s rationale for moving to the new software platform in the first place.

2) Place every software function in the context of a business process. This requires genuine preparation on the part of the trainer, and of course the curriculum developer. Software training that focuses on clicks and screens (like most “out of the box” curricula) loses steam every time. Start training people on how to do their jobs, and everyone gets engaged.

Remember when you first set out to learn Excel (or Lotus)? I remember pulling up that first blank spreadsheet and thinking to myself, “what the h*** am I supposed to do with this?” Once I had a problem to solve, though, I was hooked.

3) Spend way more time than you think teaching on-line help. I know I’m just reiterating your point, but it’s such a good one that I think it deserves repeating. Most software learners won’t have a need or an opportunity to put their learning to work for days, weeks, or even months after class. By they time they need it, they’ve forgotten it.

If classroom training gives learners a proverbial fish (allowing them to eat, or remember, for a day), then teaching the on-line help gives them a handy, if cliché, fish-pole.