Making It Make Sense: Best Practices in Software Training

Cyber Image OL

I frequently design software training for adults who need to learn either a completely new package, or need to get up-to-speed on new versions of a familiar program, (for example, changing from Office 2007 to Office 365). While creating a specific training program varies with the software and the staff learning it, my general goals for preparing software training are the same:

  • Provide the learners with the rationale as to why this program will be useful for them to know and how it should help them in their daily work
  • Familiarize the learner with the processes of using the program
  • Build a learning scaffold so the student can identify problems and find the solutions

A key component of my courses involve the overview of the “why learn this”.  (And in my experience as a trainee, this piece is so often left out or given minimal attention.) I always like to approach it with “Why learning this will make your job faster, easier, and more accurate.”  You want the learner to apply the new knowledge in the real world. This portion comes at the beginning of the course, as an overview, but is reinforced at the end of the course with specific examples and give and take from the learners. This part of the training should include scenarios that are straight from the participants’ desks. You want them to see how the what they learned applies to their work day and work load immediately.

With any training, I understand that the learners generally come with a varied skill-set. Some members of the group are confident and proficient computer users; others may have a limited background and carry with them a more negative attitude about computers either from previous experience or from a lack of confidence. These varied backgrounds are usually all in the same room and will move through the training at a different pace. With a limited amount of time for training, the temptation is to make sure that all the learners know all the buttons they need to push as quickly as possible. This too-detailed approach results in training that either goes too slowly for the more experienced or too fast for the less confident.  You end up with some students off track on their computers while waiting for others to master the basics. Therefore, before I do any planning, I make sure I know why the software is being used, how the group is configured and how the program is going to support the staff in their day-to-day work. In other words, what is the big picture, what are the company goals? Then I design my objectives with these goals in mind.

The next issue is how much to cover when presenting the software. I fight the temptation to focus on making sure everyone knows all the buttons they need to push at one session. Learning new software does involve what Hurt, calls a systematic approach. However, what can happen is a “blah-blah-blah” demonstration that goes on forever. Your class needs to jump in and start “swimming”. You do have to show the students the beginning basics of the program, but beyond that, the learners need to be able to test drive the software so they can troubleshoot when the program doesn’t function as they expect.

When designing training, then, I like to design a portion of my course that focuses on some structured problem solving. For example, if I my course is training users to create hyperlinks in PowerPoint, I include a section where the user has to find the solution to hyperlinks that don’t work. If it is a face-to-face class, they can work through this in groups, if it is an online course, they walk through some examples that help them find the solution. For example, if I am learning to create a webpage, and the demonstration is clear enough, I may follow along fine and think I know how to work the program on my own. However, what often is the case is when I try to recreate the process is I find out I didn’t understand quite as much as I thought; “How did we do that? Wait, that didn’t happen in class.”

My method to avoid this disconnect is to design my training with experimentation built in. I want the students trying the software with the real-world examples they bring with them. If there is a question, the students can try to problem-solve it together, expanding on each other’s expertise. In addition, if they hit a wall, I am there to help them walk through the solution. That way the trainees leave with some confidence as well as learning to work the software.

As an instructional designer, I love creating successful training that meets the objectives and goals the client wants covered. Additionally, I want to know the needs were met and that long-term learning has taken place. Software training can be a challenge because the learner background varies, the amount of information to be covered can be quite steep, and for the learning to “stick” real-world application has to be part of the course. These goals are always part of my mission when I design software training. I want the course to “make sense” and be applicable to the participants of my course.

 

Leave A Reply

Your email address will not be published. Required fields are marked *