October 16, 2016

8 Ways to Make or Break a Software Training

I've spent a lot of time facilitating, observing or receiving software training. For example, teaching someone how to use an LMS, a CMS, or a mysterious internal software. Today I want to share this:

 8-Step Plan for the Worst Software Training


  1. Sit down at the "teacher's desk" in front of the audience projecting your screen on the tiniest projector possible.
  2. Bonus points: make sure the projector is slightly out of focus, and flashes messages about the lamp needing to be changed, or other  technical errors.
  3. Be very apologetic about the complex subject matter and repeatedly remind the audience that "This is a lot to take in at once". 
  4. Bonus points: humorously blame it on "them", who didn't give you enough time to prepare or forced you to stick to a poor lesson plan.
  5. Start explaining every single element of the user interface one by one, going from left to right.
  6. Bonus points: explain EVERY SINGLE element/feature. Even those nobody is using. Make sure to talk about an element for a while, then say: "But we're never going to use it, so don't be afraid if you can't remember it".
  7. More bonus points: show and explain even the most obvious elements of the interface. Everyone needs to hear that "Save" button saves the document or that "File name" shows the name of the file. Throw in a knowledge check, too!
  8. Even more bonus points: cheer the students up by saying: "Don't worry, nobody can understand it from the start, it takes time". Or "Nobody expects you to memorize all this, I'm sure it will all become clear with time". Let them wander why are they listening to you now, rather than getting that experience.

If this sounds familiar and you want to stop apologising for your training, do this:

8-Step Path Towards Better Software Training


1. Stop placing the blame and do your job. 

This sounds harsh, but this is where you start. Don't make excuses about the quality of training! If you are an instructional designer, it is your job to take the raw subject matter in its primordial form and  transform it to make learning possible. That's what instructional design actually is. If you are the trainer, it is up to you to make the best of the material and work with the developers to make it better. In any case, any conflicts between you and the "them" have no place in the training room.

2. Stop telling learners how complex the tool is and how nobody can understand it.

This  does not motivate anyone. Stand in front of the mirror and tell yourself that you will definitely fail, but it's ok, everyone does. Does that provide a sense of relief?

3. Make a list of tasks that learners should be able to do by the end of the training.

Stop thinking "Tool training" and start thinking "Task training". In other words, forget about "They need to know..." and focus on "They need to do...". It is highly likely that the real goal of the training is not "to know the tool", but to perform specific tasks. For example: find data, correct data, cancel orders, save documents, etc.  Find out what these tasks are and write them down. Did you notice that I didn't say "learning objectives"? This is to prevent objectives like "Will be able to understand the elements of the user interface".

4. Rank the task list.

Depending on your context, you may end up with a huge list of tasks the learners need to do. In this case, talk to SMEs and the actual users of the tool to find out which tasks they do more often, or which tasks are more critical. Keep in mind that SMEs may not be reliable in their feelings about task frequency or importance. If you have access to data - use it as well. For example, in a call center, you will most likely have information about contact drivers. Map the most popular contacts to the tasks done in the tool.

If applicable, compare what you've learned from SMEs with the vision of the management who asked you to develop the training. Highlight any discrepancies. Make sure these are discussed and cleared before you proceed with the training design.

5. Design the activities that match the tasks. 

If you identified the tasks that should be performed, you probably have a good idea on what activities you need. The main challenge here is often a sequence of activities, particularly for complex tools.

To design a sequence of learning activities I consider the following about the task I am teaching: frequency, ease, tool elements and functions used. As a hypothetical example: opening a customer's account is easy and is done very often. Investigating a fraudulent activity on a hacked account is complicated and rare. Thus, opening customer's account should be the first task/activity to learn in this case.

Keep in mind the cognitive load as well. The learners should be comfortable with the basics of the tool before dealing with tasks that need analytical thinking or creative application. For example, for those who have never created an e-learning, leaning how to create simple shapes and inserting pre-made buttons in Storyline should probably precede learning how to create custom buttons with your own triggers.

6. Engage your learners early on. 

Provide instructions and guidance for anything that's not obvious, but let learners figure out information that is more obvious. With some tools, what the learners need to know is the procedure: the sequence of actions they should do. What they can often (well, depending on your tool) figure out is to how to do these actions in the tool. In this case, give learners the list of actions to do, such as:

  1. Open customer's account, 
  2. Open customer's address 
  3. Change address 

and allow the learner to find  the right buttons. Especially if the buttons names are "open account", "open address", "change address". If you're making an e-learning, add an option to get a hint on demand. In the classroom encourage peer support between  advanced learners and focus your attention on the others.

Another option to teach a tool is to provide a step-by-step written guide (think tutorials) and ask the learners to follow the steps in the actual tool on their own. In an e-learning, consider adding on-demand videos for learners to play if they need help. Instead of only watching someone doing something, learners will actually be doing it themselves. The benefit of this approach in a classroom is that it frees you up from lecturing and lets you manage the class by walking around and helping learners as needed.

7. Include activities that learners will complete on their own.

Activities should be relevant to the learning objectives and rely on what has been learned, but should be slightly different from what has been taught in the course. These should be completed without guidance. The purpose of this is a) to practice and b) to verity the learning. These activities does not have to happen immediately. In fact, distributed practice works even better.

8.Encourage your learners. 

Instead of constantly highlighting that everyone is an idiot (and that's what the 'encouragement' like "nobody can understand it the first time" really says), highlight their successes, reassure them that they are doing great (if they do), provide developmental feedback, if they don't.


Got any more ideas to make or break a software training? Disagree with something? Let me know in the comments or Twitter - @GamayunTraining

No comments:

Post a Comment