I have recently taken on a new client. The bulk of the work will be e-learning modules on new software implementations. I would like suggestions on how to NOT just do screen shots over and over. Maybe I should be asking, when doing new software implementation via e-learning, what are some best practices to follow? What are the common pitfalls?
Also, should all of the different software implementations have the same pattern as developed in the first one - help the learner due to familiarity of the presentation of new information?
I love Michael's recommendations, but I have a cautionary tale, well... two actually, but the moral is the same.
I had two recent projects in which we used one or both of those approaches.
In the first project, they changed the system. We had to record new video and replace steps in the Try It scenarios. In the second project, they changed the process. We had to (you guessed it) change the steps in the try it scenarios. We also had to replace a video, but instead of recording a new video I did a series of timed screenshots to simulate he appearance of a video.
The moral of the story is: consider how much re-work will be created if the content changes (even a little).
I will second Simon's warning. We have developed courses, demos, job aids using the system and the week before or days before something will be different so we've have to rework many of the deliverables. It's just a fact something will change, be aware of how that will affect what you are delivering.
Change at the last minute is common in the software development industry. This causes headache for many people. What happens is that the company wants to get the program out by a certain time (often to coincide with tradeshows). A schedule is drawn up and the programmers and developers get going. They are allotted a certain amount of time. It then heads off to Quality Testing and Assurance, QA stays up all day and night for days trying to find all the bugs and problems. It goes back and forth between development and QA until it is done (or as close to done as it is going to get). Meanwhile marketing is trying to get images for their campaigns. The technical writer tries to get as much stuff written up and writes up the help files. Once the final build is released the technical writer often has to re-write almost everything they have done. The changes from early versions to the final release can be quite dramatic. My ex-girlfriend was as Technical Writer, on more than one occasion she would work a 30-hour shift.
Michael's advice is great. Just be prepared to be flexible and make changes at the last minute.
I am currently designing training using the demo and try it features. This was a huge consideration beforehand so I decided to break the systems down into several scenes as opposed to one large one which makes much easier to make changes if necessary.
6 Replies
Instead of doing screenshots over and over, you could opt for screen recordings that show a How-To procedure, e.g. how to create a new inventory item in a ERP system. Besides demos, you could also create TryIt simulations that allow learners to practice the various software functions. See some info here: https://community.articulate.com/series/4/articles/recording-screencasts If you do want to make screenshots more interesting, see this recent eLearning challenge here for examples: https://community.articulate.com/articles/interactive-screenshots-online-training#comments
Thanks Michael
I love Michael's recommendations, but I have a cautionary tale, well... two actually, but the moral is the same.
I had two recent projects in which we used one or both of those approaches.
In the first project, they changed the system. We had to record new video and replace steps in the Try It scenarios.
In the second project, they changed the process. We had to (you guessed it) change the steps in the try it scenarios. We also had to replace a video, but instead of recording a new video I did a series of timed screenshots to simulate he appearance of a video.
The moral of the story is: consider how much re-work will be created if the content changes (even a little).
I will second Simon's warning. We have developed courses, demos, job aids using the system and the week before or days before something will be different so we've have to rework many of the deliverables. It's just a fact something will change, be aware of how that will affect what you are delivering.
Change at the last minute is common in the software development industry. This causes headache for many people. What happens is that the company wants to get the program out by a certain time (often to coincide with tradeshows). A schedule is drawn up and the programmers and developers get going. They are allotted a certain amount of time. It then heads off to Quality Testing and Assurance, QA stays up all day and night for days trying to find all the bugs and problems. It goes back and forth between development and QA until it is done (or as close to done as it is going to get). Meanwhile marketing is trying to get images for their campaigns. The technical writer tries to get as much stuff written up and writes up the help files. Once the final build is released the technical writer often has to re-write almost everything they have done. The changes from early versions to the final release can be quite dramatic. My ex-girlfriend was as Technical Writer, on more than one occasion she would work a 30-hour shift.
Michael's advice is great. Just be prepared to be flexible and make changes at the last minute.
I am currently designing training using the demo and try it features. This was a huge consideration beforehand so I decided to break the systems down into several scenes as opposed to one large one which makes much easier to make changes if necessary.
This discussion is closed. You can start a new discussion or contact Articulate Support.