Learning is tough, no matter how hard you try to make it easy. This is especially true when it comes to learning highly complex software. And even if the software itself is not complex, because it was designed so well, the job people perform using the software is complex, so the complexity exists and must be learned. Software trainers often struggle with students who find it difficult to learn complex topics. Trainers are constantly looking for ways to make learning software easy. After all, critical to customer success is the ability to get customers to learn your software and start getting their jobs done.
I am often asked about methods that can be used to teach people complex software, as I was during this Ask Me Anything on Inbound.com. In this post, I address four ways to address teaching complex topic in your software training.
This is not a popular or usual "best method" for conducting software training, but I am compelled to cover it because I frequently "see" its absence. Too often, software training courses start with a brief introduction of the instructor and the right into the first topic. By the time we get to the second topic, learners are checking their phones. Many learners started thinking to themselves, "What is this? Why am I learning it? Don't we already do this every day? Why am I here, again?'
Any training course, but especially a course on a complex topic, needs to start with context. The course should begin by addressing four questions:
Consider this: The people in the training class are not likely to be the people who purchased the software, so they will often join a class with very little context for why they are there.
Once you have the context covered, the next thing to consider is the amount of time to commit to training. The time necessary to learn anything with at least a medium amount of complexity is often underestimated (vastly). Do not underestimate the time it will take people to learn complex software, especially if you insist your product is designed so well people will not need much training. This argument reminds me of the quote, which I paraphrase:
If you don't have time to meditate for 20 minutes, mediate for an hour.
More than once, I have proposed training courses that should be fairly long (from several hours to several days) and was told by customers and managers, "No way. That's way too long to expect people to attend training." Guess how often students, customers, and managers complained people were not given sufficient training?
Exactly.
As you design your training courses, take the time to consider how often it will really take people to learn your software.
If your customers don't need more than 30 minutes to learn your software, give them 2 hours to learn it.
- Bill Cushard
Now, just because I say that you should have longer training classes, doesn't mean it is possible. You (and your customers) will have time constraints, even if you both acknowledge more time will be needed. But don't worry. There is a way to address this. You need to resist the urge to cover everything in the training. When you design a course, you must make tough decisions about what really needs to be covered on the class.
The question to answer is, "What core tasks does a customer need to learn now to get up and running?" Asked another way, "What are the fewest, high value tasks that customers need to learn first?" When you answer these questions, cut the list in half and cover those tasks in the training course.
Another angle on this topic comes from Nir Eyal, of Nir And Far and author of the book Hooked. I spoke with him about this topic, and he would add that the training should cover tasks that would be used most frequently. Eyal covers in his book that frequency of use is critical in forming a habit. So, if you have cover the tasks in your training courses that people will use most frequently, you can sort of get around the complexity issue by "hooking" people with the core functionality they need. The rest can be learned over time.
The more complex a topic is, the more hands-on the learning experience should be. After you have addressed the context, dedicated the right amount of time, and focused on the core, high-value (and most frequently use) tasks of your product, you want to make sure your customers have a chance to apply what they have learned. In software training, the way this is normally handled is with hands-on lab exercises during which learners practice using your software.
Nothing new here to be sure.
However.
It does matter how you design lab exercises for maximum impact. The best way to do it is to have each exercises build on each other and through out the course of the course, a complete "work product" is produced. Then there could be a final exercises during which student produce the final "work product" on their own.
For example, let's say your course is teaching how to plant a tree, and your course covers the four steps to plant a tree:
Each of these tasks would be covered in a separate module. For example, digging a hole could be accomplished in more than one way. And some of those methods would be taught in that section. The exercises in section one would be, "Now you try it. Dig a hole." And that would be it for that section. Just dig the hole. This process would be repeated throughout the course until a tree has been planted. The point is only have people try one thing at a time so we don't overwhelm people.
Cognitive overload is a real thing.
The final exercise would be to have student do the entire process at once.
By breaking it up into steps, you can help overcome some of the complexity. Then by asking people to do a final exercise, they can experience some of the complexity in a structured exercise.
.png)
