One of the common objections I hear to using storytelling in training is that “stories don’t work for all kinds of training.” Those who are skeptical of storytelling often use software training as an example where stories don’t work. However, I think stories can have a place in some (but not all) software training.
When to avoid stories and focus on features
Sometimes, software training should be just about the features. In that case, you’re often doing more technical writing than instructional design. Just get in, show the features, and be done. Short tutorials and demos are great for that, and they don’t always need a story. If your goal is to create 5 minute tutorials to help people solve a problem at the apply or solve moment of need, they’re already motivated and engaged. You don’t need stories in that case.
Stories as training structure
We often provide software training in advance of the need though. Instead of something learners seek out to solve their own problems, we’re training them about what they’ll do in the future. That training is often much longer; instead of 5 minutes, we might spend hours reviewing everything software can do.
Have you ever gone through software training that was just a list of features with no context? How helpful was it? Did you wonder WHY you might use certain features or why a software update would help you? In those situations, with training in advance, a story might provide a organizational structure to help people remember and apply the training. Build the training around the structure of how a user would solve a problem with the software, from start to finish, rather than how features appear from left to right in the interface.
Examples as stories
With a few exceptions, nearly any training can benefit from examples. Those examples are often stories. When I taught Microsoft Office as a classroom trainer, I often told stories as examples. I had a collection of stories about colleagues or past students who had solved a specific problem like this one.
“One of my past students had a spreadsheet that needed to be updated every day. She added new data at the bottom, and then she sorted the spreadsheet. The way it was set up required significant manual cleanup. She spent at least an hour or two every day making manual adjustments to the spreadsheet.
During our training, we found several ways to adjust the structure of the spreadsheet so nearly everything was automated. Instead of one or two hours, the new process only took her about 15 minutes a day. With a bit of initial work to set up the spreadsheet, we saved her at least 5 hours a week of wasted time. That’s why this information I’m about to explain about setting up your spreadsheet for sorting and filtering is so important.”
That’s a real story (it’s the only time in my training career where a student literally jumped up and down with excitement at the end of the course). When I was training Excel, I didn’t just tell students, “It’s important for you to set up your spreadsheets to make it easier for sorting and filtering.” I gave them the example so they understood why it was important and why it would matter to them. I made it concrete and relevant.
Stories to increase motivation
When we create software training, we want people to change their behavior. We want them to use the software and use it in specific ways. We want them to be motivated to use the software effectively.
This is especially important when software is updated and people need to change how they use it. It’s not always enough to just say, “here’s a new feature.” Sometimes we need to show people why that feature is going to make them better. Stories and scenarios put those features in context so users are more motivated to try them.
Hands-on practice with scenarios
As a software trainer, the books I taught from included examples that were often scenarios. Excel pivot tables are much easier to understand if you have a realistic project where you need answers from data. Those projects are usually short scenarios, whether you’re teaching in a classroom or creating elearning.
I could use the example of the poorly formatted spreadsheet above and convert it to a practice scenario. Instead of simply giving people a set of steps to follow, the scenario provides some context.
Why and when to use features
If you’re creating software training to help people solve a problem while they’re in the middle of working, then microlearning focused on just the features is a good approach. If you’re creating software training to help people use complex software, including selecting certain features or tools in the right situations, stories can be helpful.
For example, layer masks are a critical tool in Photoshop. It’s not always obvious to novices why they’re important though. This tutorial puts layer masks in context by creating a realistic scenario (merging together two wedding photos for a client). The author even starts by explaining how to merge the photos with an easy but incorrect and destructive technique.
This shows the benefits of using the right technique and addresses a common mistake. Plenty of tutorials out there explain various features of Photoshop. Not so many explain how to select the correct tool for the job–that’s what’s valuable in this example. While that tutorial uses an old version of Photoshop, you can still see the training technique. (Plus, this tutorial helped me finally understand layer masks!)
In complex software, it’s often not enough to know how to use various features. Sometimes you have multiple options for an action, each with pros and cons. In Captivate, you can use a regular Advanced Action or a Shared Action. Depending on your needs, one or the other may be a better choice and make your development more efficient. Stories and scenarios help learners understand how to choose the right tools.
Model the Thought Process
Stories can also be helpful for modeling the thought process that accompanies using software. For example, I once created a software tutorial on how to troubleshoot a particularly problematic task in an LMS. We wanted the online instructors to do some basic error checking themselves before contacting technical support. While I could have simply provided a PDF document with the steps to troubleshoot (and I did provide that as a job aid), I also created an interactive simulation.
In the simulation, an instructor (represented with voice over plus character photos) narrated how she solved the problem. She walked through each step of her thought process. The actual story was pretty thin (an instructor has a problem in the LMS), but the character gave learners enough to relate to. This training gave learners more confidence that they could troubleshoot it because the process was modeled by a character similar to themselves.
How Do You Use Stories and Scenarios?
How do you use stories and scenarios in software training? Do you have a great example of your own? Share it in the comments or reply to this email.
If you’re developing software training and are feeling stuck, feel free to share that in the comments. We can brainstorm together ways to use stories to make your training more relevant and engaging.