Recently, I was asked to give some training to a group of software developers/analysts and others who work with software and then train others how to use that software. They wanted a "train-the-trainer" course.
During the course, I gave some suggestions for effective learning sessions, first teach three things
- How to exit out of the software entirely. Learners HATE to be stuck in a software program that they cannot escape from.
- How to "go back" a screen or to the main menu. If a learner gets lost, he or she needs to go to the first screen or main menu screen to get re-oriented.
- The HELP key. Not enough time is dedicated in software training to teaching the learner how to find help and information on his or her own. I suggest in every software training class you spend an hour teaching the Help system. Why? Learners tend to overlook the information in help and tend to use it in the most cursory way.
Combat this by teaming learners up in groups of two. Learners will not want someone looking over their shoulder when they check email, so team them up and have them do exercises together on the computer...it aids learning via collaboration and cooperation and it avoids email checking.
Finally, give learners plenty of time to practice on with the software. They should have hands on experience using the software for 90% of the class. Weave the background information, concepts and other information into the spaces between the various scenarios you should be asking them to perform while learning the software.
Telling someone how software works is never as effective as letting them try the software and then guiding them to the proper steps.
Please, add some suggestions of your own for teaching software in a stand up training classroom environment.
__
Recommended Games and Gadgets
Recommended Books
Content Guide
Posts
9 comments:
Excellent guidance on software training; I'd love to see more. In the meantime, here are a couple more thoughts on software training in the classroom.
While these ideas apply mostly to training employees on a piece of software they need to do their jobs (e.g., an ERP, CRM, Sales Force Automation, Accounting package, etc.), they do make sense in other situations as well.
1. Require pre-work. This comment might be a bit out of bounds because it doesn’t really help once you're actually in the classroom. However, it can have such a profound impact on the classroom experience, it’s worth mentioning.
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.
Even better than on-line help, an Electronic Performance Support System (or EPSS), that illustrates how the software functions within the company's business process. But again, that's a bit more than the classroom trainer has in her control.
I’ve probably over-stayed my welcome in your comment box … I’ll go to my own backyard to continue this rant. Thanks!
Jon,
This is great stuff! Thanks! Pre-work can be so helpful in setting the stage...and understanding the business context helps in so many ways with the training including motivation.
If you are ranting somewhere else on this topic (and not your literal backyard), let us know the link so we can follow the discussion.
Thanks
Great stuff guys! I have nothing to add, except a link to Jon's blog:
http://www.dashe.com/blog
Karl: I've had success with helping the users learn "how the software thinks". I help the users get an understanding of:
1) what the software assumes you're asking for
2) why the software reacts that way and not another
3) what the software does not know about your intentions
4) what the software forgets from the last time you did this
With this agenda, their hands-on practice is like an interrogation of a suspect. They are investigating the thought process of the software as if it thinks strangely, but needs to be understood. They develop a theory in their own minds that predicts what the software will do, why it responds peculiarly and how to get a different response from it. This cuts down on their frustrations when moving out the steep learning curve.
Thanks Cammy, for providing the URL. My ambitions for our blog currently far exceed my available time (and ability!). Still working on getting the requisite photos, bios, etc. posted there.
Meantime, I'm learning a ton from you, Karl, et al - both about blogging and the learning biz in general. Thx again. Jon
Karl:
In my experience, learners hardly ever need as much "infrastructure" information as trainers (or managers) think they do.
For example: file and folder hierarchy. To a computer novice, these make no sense, and won't, until the person has created something that has value for her and that she wants to saved.
So, you don't teach file structure or folder hierarchy at the start. And you don't teach them when you teach email. You don't really save stuff in email -- to the casual user, it's just there.
When a person finally gets to learning an application that logically includes saving personal documents -- a word processor or a spreadsheet -- that's the place to introduce files and folders.
As in, "you can save it, but you have to tell the computer where to put it."
I second Jon's on-target comment that adults in a work environment have to see any computer application (and, really, any application of computers) in the context of business.
I'd go further to say "in the context of things they need or want to do." In other words, most folks don't want to "use Excel" (or Dreamweaver, or Flickr, or whatever) -- they want to analyze the budget (or create the online catalog, or find a quality photo they can use to illustrate X...).
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.
As head of a project that delivered over 12,000 student-days of hands-on training in a 17-week period, I learned to focus on one reliable method. That was the menu route, which encompassed all the tasks students would learn.
Not all the tasks had keyboard shortcuts, so people would have had to learn the menus anyway.
If students asked about shortcuts, the instructors confirmed they'd work and would accomplish the same end. They also pointed out where to find a job aid listing the shortcuts, and did not prevent anyone from using them. But any new topics followed the menu-based route. Back on the job, people unsure about some task could always just skim the menus for a half-remembered command -- something I do quite often myself.
Great comments, thanks for all the insights and ideas.
There could also be something about the computer itself. I know with creating training for healthcare, there are a lot of people out there who don't even know how to turn on a computer so sometimes we have to provide a Windows Basics course to teach the learners the basic functionality of a computer and mouse, before they even set foot into the software.
I saw Cammy's point to this post, and will add here what I was adding there, too:
I've often argued that you should focus on the underlying conceptual model that guides the structure of the software (how things are done, why things are in particular places), present them with a few examples of 'how to do x' that show how the model predicts what to do, and have them exercise the model by having them do a couple of 'ok, how would you do y?' until they can use the model to predict how to do something. The benefit should be (assuming a good underlying model, if not it's an interface design issue, not a training issue ;) that it takes less to get them up to speed, and they're more robust in the face of failure. I agree with other comments that it should be very much focused about tasks, not the software (except the model prediction bit).
You can support the model with quick reference sheets, diagrams of the model, what have you, but by focusing on the bit that gives you inferential power, you get more leverage.
Post a Comment