In my experience, an Instructional Designer’s strength does not lie in what they already know, but in their ability and willingness to enter a subject as a complete novice and absorb the information presented. In the last year and half, I have worked on multiple software training projects that were increasingly complex and more technical than I had previously encountered. During that time, I collaborated closely with people who will always know far more about the material than I could ever hope to grasp. Despite this, since I was the ID, they still expected me to take what they knew and design a curriculum and develop content to teach people how to use their software.

Starting a software training project can be a daunting process, due to the myriad of features and systems you must learn and then subsequently train users on. As a result, I have taken to heart a couple lessons that helped guide me through the most challenging, and sometimes frustrating, types of courses to create.

Understand to deliver the content, not to master the content

The above statement might seem confusing, but it was a valuable piece of advice I received from a colleague midway through an incredibly difficult utility mapping software course. This was a system that still had not been officially rolled out by the client, and large parts of it were still undergoing updates. Because of this, even the subject matter experts were uncertain about pieces of the program. Knowing this, even the most seasoned software training professional might struggle to determine how to approach building training for an extremely complex and changeable application.

First, Instructional Designers (IDs) must accept that it’s impossible to fully grasp the entire suite of features associated with the software. The role of the Instructional Designer is to:

  • Gather the critical information your learners will need to be successful
  • Define the learning outcomes
  • Decide how to organize and structure the material
  • Define what exercises, interactions, job aids, and other modalities are needed to reinforce the concepts
  • Develop content and materials that align to the learning outcomes

Your job is not to become a subject matter expert (SME). Most SMEs have likely developed their knowledge and experience over months and years, and the same will be true for your learners. Your role in the process is to create content and materials that provide a foundational knowledge and baseline understanding of the application that can be built on in the days and months to follow.

Start at the beginning

Take a deep breath before you start tackling the software training. Exhale. Now think about how to approach it. The Golden Rule here is, start at the beginning. Before getting into the nitty gritty of the material, start with a very high-level overview of the training you are about to create. At this stage of the development process, it’s far too easy to get bogged down in the details of the training, taking a step back and assessing it at its most fundamental level is paramount. Begin with the very basics:

  • Build your learning outcomes
  • Detail out the critical tasks and activities
  • Define the process or methodology
  • Create an outline of the topics and sub-topics

Establish with the client and subject matter experts what you need to specifically train in the software and what your training is expected to accomplish. What is your goal, and in tandem with that, how are you going to achieve that goal? What kind of practice and scenarios are the learners expected to go through? How will they ultimately demonstrate their knowledge of the material?

This stage lets you know what parts of the software you need to show the learner. This initial stage provides you with a roadmap of not only how you are going to structure the training, but also how you are going to learn it for yourself. It is from this early foundation you can begin to move forward.

With a definitive course and direction set to tackle the training, you are ready to venture onward. You have an idea by now what the learner needs to be shown in the training, so start with the first set of topics the training will cover. This will usually cover the basic summary of the software and the simplest, most easy-to-execute software functions the learner needs to know.

Here’s how you do it:

  • Review any source materials the client has sent over and identify which parts of it relate to the training you are making
  • Focus your analysis of the materials on how to execute specific tasks in the software that the learner will be expected to accomplish
  • Jot down all of the stages of the processes you want to show, from beginning to end in meticulous detail
  • With the steps laid out, practice on the software itself, making note of any gaps you have in your understanding

If there is anything I can impart here, at this most basic stage, it is to build for yourself a logically-ordered sequence of events. While you might not know everything yet, your familiarity with the software will build from these small kernels of knowledge. From there, you can begin to design a basic rough cut or storyboard for the training. Any part, step, or piece of terminology you are not certain of is noted for subject matter expert clarification.

Take your time with your SMEs

I have discussed previously how to work best with your subject matter experts, but regarding software training, the role of the SME—and your ability to transcribe what they tell you—is crucial. When it comes time to meet with the SMEs, more than anything else, be patient and take your time with clarifying information. You are the one who will be taking this information and turning it into training, so gaining a baseline understanding of the software is of the utmost importance. When working with your SMEs you should also:

  • Have a rough storyboard based on the topic in question already developed. While it will not be complete, it is helpful to have something prepared you can show to the SME. That way you and the expert can visualize the software or process
  • Go over each part of what you need explained, asking the SME to make clear anything you did not catch. I have learned the hard way that missing even a small piece of information can cascade, negatively affecting the rest of the process
  • Record all of your SME sessions so you can go back to watch them later

I would be remiss if I did not mention this last piece of advice when working with SMEs. While you have their time, bring up the software itself and walk through each step of the application while they watch and guide you, I even recommend taking part in User Acceptance Testing (UAT), which is the final stage of any software before it goes live. As a good Instructional Designer, you need to put yourself in the shoes of the learner first before you even begin to create the training. It is one thing to learn enough to train on the software, it is entirely another thing to walk through the software with your learner’s eyes and see where you trip up and what confuses you. Then you can anticipate what a typical learner may need.

Gathering input and managing reviews

Understand that getting these steps down is fundamentally an iterative process, needing continual revision and oversight from the subject matter experts. This part is a give and take, where you revise, then revisit, and then revise again based on their input. This process is repeated until every single part of the training has been signed off as correct by the SME. Iterative Design in Learning and Development follows a very structured process:

  • Create an early storyboard of the training (mentioned before) that the SME can view and provide feedback on. You must have something down on paper for the SMEs to look at for their input rather than them starting with a blank page
  • Use brightly colored boxes to indicate placeholders or missing information
  • Structure the feedback in phases so you don’t overwhelm yourself (and the SME) with continual changes and edits
  • Focus your SME’s attention by specifically marking areas for their input. Have any parts you are uncertain of or need review specifically marked for feedback.
  • Be accepting and open to the feedback you receive, but also keep in mind the scope and focus of the training as well as what is best for the learners
  • I’ve said this many times before, be sure to revise and revisit the training with the SME as many times as you need, hammering down all the steps and processes until everything is correct.

Conclusion

In the time I have worked on software training projects, I have discovered that taking a slow, steady approach is crucial to my success. An Instructional Designer should utilize the above strategies to avoid feeling overwhelmed and to create a roadmap through what can be extremely complicated content. Once you have the workflow down for one or two of the simpler processes, you will soon delightfully discover through diligent practice of the software and critical reflection on it, you have gained at least a working knowledge of what you are training on. Another benefit will be all that jargon you once always asked them to repeat and define has become a part of your vocabulary. Even as the complexity increases, the training you are creating will become far more manageable.