I’ve designed and developed software training for 15+ years, at three different companies. Through the years I’ve learned some best practices from trial and error, advice from mentors, and witnessing what works and what does not when the training is rolled out.
Let’s look at three things to be aware of and how they could become sticking points.
Time is (not) on my side
In an ideal world, software developers build the software, sign off that it is complete, and then instructional designers (IDs) and subject matter experts (SMEs) build the training for the said software. Unfortunately, this is rarely (if ever) the case. The problem is two-fold.
- Management expects the training to be built and ready to go at the same time the software is released so that customers can get up and running quickly.
- The development process has a freeze date when no further development is done. The problem here is that it is frequently too close to the product release date, which doesn’t provide the training team adequate time to develop accurate and helpful training. This also means that the training team must build the training while the developers are still building the product. We call this “building the plane as we are flying it.”
Building the software and the training at the same time causes unnecessary tension between the two teams. The developers are in the midst of building and the training team (IDs or SMEs) frequently needs answers to how something works in the software. Both teams are stretched thin for time and want to focus on their own responsibilities.
What this means for the training team is limited access to the developers, so they have to build the training and either guess at what the functionality will be or make the first iteration of the training content basic and generic. This isn’t always the case. Sometimes the stars align and the training team is able to incorporate all the functionality into the training content in time for the initial release. But often this is not the case.
(Un)necessary evil
Another potential hazard when developing software training is the add or subtract issue. Sometimes software developers cannot get a part of the functionality to work correctly before the development freeze date. This could lead to that functionality being removed for the first iteration.
Or a piece of functionality that wasn’t planned for the initial release is suddenly production-ready and is added to the scope of the first release.
Both of these scenarios play havoc with the training team’s learning content, especially if the function that is being removed has a ripple effect through other parts of the training. Either way means additional training materials.
Freeze frame
Screenshots of the software that are used in the training materials can also become a nightmare. If there is a UI change after the screenshots have been captured, this means going back in and re-capturing new ones. Depending on the number of screenshots, this can take a fair amount of time. On each of the teams I was a part of we tried to minimize the amount of screenshots to avoid this scenario.
Software screenshots often have personally identifiable user information that needs to be blurred or removed. This is an easy thing to forget when time is short. It also adds more work when you have to re-capture screenshots as previously mentioned.
Finally, you need to make your screenshots accessible by adding alt text to each. Alt text is descriptive text that can be read by a screen reader to users with visual disabilities. If you have to re-capture all new screenshots due to a UI change, this means you need to add the alt text back to each image. You also might need to edit the alt text to reflect the UI change.
Think about these three things if you are tasked with developing software training. They aren’t the only things to watch out for, but they are the most common things I’ve dealt with when building software training. Feel free to contact me for additional help.