Instructional Design Basics



If you are unfamiliar with the above acronym then I must say you are quite lucky. You see the acronym stands for Cover Your Ass and it illustrates a working environment that is not very productive or safe—here you CYA by documenting everything.

Thankfully my current position is not like this—yes the skies are bright and the world is fresh and new—however, I still have to deal with some documentation.

Our field deals with technology and this technology can be a source of problems. By documenting potential technical problems up front you can lessen the risks associated with them. Today I’ll talk about a few experiences I’ve had with this area and about how proper documentation can help you avoid similar issues.

Project Scope—What are the Media Requirements
I once worked on a project that consisted of 20+ Captivate tutorials. Here a group of us developed the tutorials and then the project manager sent them out to the client for a review. The client quickly got back to us with a big concern,

“We have a problem here—voice audio was supposed to be included with all of the movies and you only had it in 6 of them.”

This was definitely a big concern and caused us to go back to the scoping documentation. However, this documentation was not very clear with the requirements and only referenced, “…the Introduction videos will have voice audio.”

Further communication with our client showed that they had email correspondence, which indicated that all the tutorials would have voice audio. Since our final scoping document did not dispute this requirement, our client argued that we had to honor the emails.

Ultimately we did this as they had a good point and we didn’t want to lose the client for future work. This mistake caused the team 80+ hours of work and added two weeks to the project schedule. In addition to this our other project work was impacted, as we had to shift resources to account for the new media requirements.

My lesson learned here was that detailed media requirements are needed with the final scoping documentation. This scoping documentation needs to be signed off by everyone on the project.

Project Environment— What are the Backend Requirements
Another day and another project centered on Captivate tutorials. Here we developed a series of tutorials wrapped around a main menu page. The nice thing with this menu page was that an administrative piece was added to it that allowed for text updates. Here an administrator could update the text on the page by using a WYSIWYG form. This administrator feature was way cool but the technology used for it would require some backend server requirements that had not been documented.

So we had this cool piece but didn’t know whether we could use it or not. Further we were supposed to conduct a demonstration of the product to the client in a couple of days and I didn’t want to show them something that we could not deliver.

To address this problem I initiated several calls to find out about their server environment. Here I didn’t have much luck, as I could not get a hold of their real tech people—I was talking to project managers and subject mater experts that had no idea what I was talking about. After several conversations it was “determined” that they did not have their servers setup to support this feature.

So we had to scrap the menu page and build a new less cool one. This issue wasn’t as severe as it could have been because we caught it relatively early in the development cycle. This issue probably cost us around 20+ hours of work.

My lessons learned here was to document any special backend requirements and to identify an appropriate IS point of contact before moving on to a development cycle.

Project Tools—What are the Development Capabilities
On another project it was decided that we were going to use an in-house tool to build the course. I was familiar with this application so moved on to storyboarding the content.

After a couple of weeks, we came to an internal storyboard review cycle. Here I noted an inconsistency with the heading levels used within the storyboards. With online courses it is important to use consistent styles as it helps the user navigate and organize information so this inconsistency was a cause of concern.

I quickly investigated the matter and noted that the other designer on the project had not reviewed the functionality requirements of the course building tool. This was important as the tool only supported two heading levels and they had used three in their storyboards.

So we arrived at a crossroads with this project—did we need to rewrite their storyboards for two levels or rebuild the course tool and all the storyboards to support three levels? We went with the last option and had to spend about 40+ hours in extra development time. Since, we were still at the storyboard level; these updates did not impact the project timeline much.

My lesson learned on this project was to require the team to review functionality requirements for any course building tool.

Project FAIL—What should You Do
Now you may not have to worry about the above areas, as your course building activities will probably focus on using standard industry tools and templates. Such tools often have existing documentation to support your project needs. If this is true, then this is great and will help you avoid potential problems.

If however you are building custom courses and or trying something new, your level of documentation might need to address the above areas. In saying this though I want to remind you that projects are complex and no matter how much documentation you have there will always be bumps in the road.

You can plan for these bumps by creating some milestones in your projects. Having a formal style guide is one of these milestones, as it should define the media requirements of your projects. Taking this guide a step further by developing a prototype will provide an even clearer picture of the media requirements as well as answer the backend environment and tool capability questions. In this regard a prototype or even a pilot can be an especially useful milestone.

Additional ways to plan for these bumps is to add a little extra time on your projects—if something should take a week then add a few extra days to it just in case there is a bump for that task.

So you have planned for these bumps by creating some milestones and added some additional time on the project, but what happens when the unexpected problem occurs. Well it’s simple, just admit to the mistakes and move on. Some projects get bogged down with people trying to point fingers, spin the issue or even shift the message.

None of this will help solve the problem and these activities are ultimately detrimental to the team. Besides, no matter how much finger pointing you do, how you spin it or shift the message the team members will know who messed up. In addition, your team members will quickly learn who doesn’t play nice in this regard. And when people continue to act this way then a couple of things may happen: either people will avoid working with those individuals or everyone will soon become very familiar with the CYA acronym.


Being Lost Isn’t Always Bad

A couple of months ago I went to Chicago and while there decided to meet some family friends. I’ve only been to Chicago a couple of times so this was a great occasion to break out my GPS unit and let it guide me to my destination.  So I plugged in the address and proceeded to drive.

Now you may not know this, but these units are not always 100% right as often there is construction or an odd street that will throw off your planned route. This is ok though as you can jump on a side street or take some other detour and the GPS will automatically recalculate your route.  If you do this enough times you will eventually get to your destination.

Well it just so happened that this trip had some unplanned construction located near the end of my route.  So as I neared my friend’s house, I ran into the construction and was forced to take a detour, a detour that made the trip much more meaningful.  You see the original route was all highways and main roads—it was the most efficient route to my friend’s house.

Fortunately for me though, this detour forced me into my friend’s neighborhood.  Here I got to drive around and see the fun little shops, restaurants and houses that made up their experience in Chicago.  I would have missed this with the original route and wouldn’t have understood why they liked living there so much.

From this experience, I learned that sometimes it is nice to jump off the planned route; especially if you have a tool that will eventually guide you back to your destination.  This is a lesson I can apply to my e-learning projects as well as I have been doing these for a long time and have identified some direct/efficient routes to follow.

Today I’ll talk about one type of project in particular that I have had a lot of experience with. Here I’ll share with you a route that will quickly get you to your destination. However, while using this route, don’t be afraid of the occasional detour as they can offer valuable experiences.  Also remember that your projects are unique and this uniqueness may require a detour as well.

Software Training Initiatives

We live in a technical environment and a common training need is software training—there is always a new piece of software or a new website that is designed to make our lives easier.  And if you are in a training/education role, you will probably have to develop a solution for this one day.

Fortunately, screen capturing software has made it easier to develop rich training content for software training initiatives. With relative ease a person can create demonstration movies of software procedures and functionality. Additional capabilities (tutorials and simulations) are included with many of these screen capturing tools and with them you can create powerful interactive environments for your users.

So with screen capturing software you have a tool for your solution but what about your content—what do you need to do here in order to get to your destination?

Knowledge Types

In previous posts I’ve talked about knowledge types, which are basically categorizations of the content you will develop in your course.  These categories are based on the objectives you have defined for your solution. You use these objectives and your knowledge type categorizations to guide you on what and how to develop your course.

And with software training initiatives you will need to address 4 key knowledge types:

A small but important part of your training should focus around selling the software. In this type of solution you are trying to get your users to buy into the idea of using the new software. Here you are trying to change their attitude—you want them to accept the new method of doing things.

Now this may not seem like a big need as users often don’t have a choice—the software is being implemented so they have to use it regardless if they like it or not. This may be true but with training you should think of potential stallers.

Phrases like “This software sucks” and “The old system was better…” are not uncommon with software implementations and if not addressed this attitude can derail your training.  Simply put, your users are not going to learn your content unless they have been sold the need for it or you have answered the “What’s in it for me” question. Failing to answer this may mean higher numbers of help desk calls once the software is implemented or that your users fail to use the software to its full potential

A significant percentage of your overall course objectives will be conceptual knowledge types; however, this will not transfer into a large percentage of your course content.  With this knowledge type you are basically describing the purpose of the various forms, pages, and reports that the user will use within the software. This is important information as it can be used to help sell the software being implemented and focus users on key values to use in the system.

For significant upgrades or new system implementations, cross tables can help users organize this information. Here you will want to indentify the old form/page that users used for a particular purpose and what the new form/page is in the software.

This knowledge type will probably be the bulk of your content and with it you will need to define the fields within the software as well as the data/values used within the fields.  Key values such as what not to enter or codes that trigger specific events need to be highlighted and noted with this content.

Since this is a large chunk of factual content, performance support tools can help your users transfer this knowledge once they complete their online training. To address this you should create additional materials that users can access after training is complete. Materials that users can print like job-aids and manuals can be useful in this regard.  Help files are an additional option that can be used here.  These files can be an especially useful as you can connect your content directly with the software by using context sensitive help functions.

This knowledge type will represent a large percentage of your overall course objectives and content. This content is where you define the specific steps and procedures users need to follow in order to use the new software.

As you create materials for this knowledge type you need to highlight the steps within the procedures. This information should list the specific forms, fields and values users need to process within the system.  As with the factual information, job aids and help files can be useful support tools for this type of content. Such treatments can be especially useful for complex procedures and for procedures that users do not encounter often.

With your procedural content, you should take care to develop realistic scenarios and make sure that any screen shots or simulations do not have junk or sensitive data displayed.

Getting to Your Destination

The following table will help you develop content for each of the above knowledge types:

Knowledge Types for Software Training Initiatives

Addressing the 4 knowledge types should provide you with the content you need to create effective training for software training initiatives. In essence this guide is your quick route to get you to your destination. And as you use it, just remember to keep an eye out for detours.


More Happy Little Trees

Speed Painting is a popular internet meme that shows time lapsed videos of artists creating their work—and like Bob Ross, these artists make it look so easy.  Some examples are:

Annoying Song

Awesome Songs, Annoying Actress

Annoying Superhero

Now that you have some tricks/tips with using screen capturing software you can create your own version of this meme—after all, who wouldn’t want to see a time lapsed movie of someone creating a training tutorial?

Well if that does interests you, you might want to consult the Venn diagram I referenced in a previous post to find out what type of person you are and you might also want to check out the following tips on using Captivate.

Recording Tips
The following recording tips will help ensure your capturing sessions go smoothly in Captivate.

  • A common recording problem is fat fingering. This happens when you enter the wrong information or click the wrong button on accident while you are recording.  Your initial reaction may be to stop recording at this point and start from scratch; however, this isn’t necessary.

Captivate has a manual print screen option, which when pressed, will take a screen shot of your current screen.  Because of this you can correct any fat finger mistakes by continuing the recording session and stepping back to the screen where you made the mistake.  Once you get back to the area where you made the mistake, simply use the manual print screen option to get a clean screen shot and then continue your recording.

When you get to the editing stage, you will further correct your fat finger mistake by deleting any incorrect frames that were shot.

  • Modes in Captivate determine what is captured and built in the project. Edit your Mode options before recording your screen captures to avoid having to change your Caption and Highlighting styles later on in the project. Having an approved style guide or prototype is useful here.
  • Whenever you have finished recording a screen capture you should immediately save your file as a separate RAW file.  Once your start editing your movie, save this version under a different name.  It useful to have a separate RAW file in case you ever need to go back and get screen shots from the original recording session.

Use the following editing tips to maximize your editing cycles in Captivate.

  • Use the Import/Export Captions feature to facilitate review cycles. The Import/Export Caption option allows you to export your text captions into a word document, which can then be sent to others for review.

During this review, you can use Word’s Track Changes, Find and Replace, and the Spelling and Grammar tools to create the final text content for your movies.  Any edits made in the word document can then be imported directly into your movie— here Captivate will automatically apply the edits when it is imported back into the project.

As you become more skilled with this functionality you can begin to merge the storyboarding phase with the build phase, that is, you can record your movies and place text holders for the content.  During the review cycles your SMEs can then hash out the exact content to be used in the text holders. Combining these phases can save you a significant amount time in your project.

  • During the life of you project, it is likely that you will capture bad data (sensitive information or junk data) or that you may have to update your screen shots because of an interface change (new field or button added to the recorded software).

If this is the case you can find the specific background(s) that needs to be updated in the movie by looking in the Library.  From the Library you are given an “Edit with” option. This option will allow you to open up and edit the image in a graphics program (Photoshop, Fireworks,…).  When you are finished with your edits, you can save the image and the image will automatically be updated in the Captivate project.

To use this feature:

  1. Select the slide that needs a new background.
  2. Right click on the slide and select Find Background in Library.
  3. Right click on the selected library image and select the Edit with option.
  4. Edit and save the image.
  • As you work with your movie, your Captivate project can become quite large with old images and other resources that are no longer used or associated to any slides.  This information can take up a lot of space and cause some performance issues; however, there is an easy way to delete any old/unused files.

To use this feature:

  1. Access the project Library.
  2. Click on the Select unused items icon.
  3. Click on the Delete icon.

Use the following publishing tip to help your users internalize the information covered in your movies.

  • Job aids can be a powerful tool for your students—having materials that they can print out and have on hand will help your users transfer skills. Use the Publish to a Word options (Handouts, Lesson, Step by Step) to create these files and edit them as needed.  Once you have your job aids finalized, create links to these documents.

These tricks/tips should help you create fast and easy software/website tutorials with Captivate. If anyone has other Captivate tricks or tricks with other screen capturing software like Camtasia please share them with everyone by using the comments area.

Tagged as: No Comments

Happy Little Trees

Bob Ross and his, “The Joy of Painting” show ran on PBS in the 80s and part of the 90s.  This was a show that I would occasionally find myself watching as I didn’t have a lot channels back then—not like today where there are hundreds of channels and still nothing on!

Anyway, when I watched this show I was always fascinated by how fast he could create his work.    To me, art was something that took a lot of time and was something that only very skilled people could do; however, Bob made it look so easy.  In his show Bob started with a blank canvas and created a beautiful landscape in 30 minutes—this to me was simply amazing.

As I am older now I realize that for Bob and many other artists, there is nothing amazing about what he was doing, that is, once you have mastered the tricks and tips of painting, creating those scenes is fast and easy.  I also realize that if someone watched me doing my work they might be equally amazed, as I have mastered many useful tricks and tips in my field. Today I want to share with you a few of these tips concerning screen capturing software.  Specifically I will talk about some general tips that should help you create fast and easy screen capture movies regardless of the capturing software you use.

Screen Capturing Software
Screen capturing software has been around since the early 2000’s and really took off when Captivate came along. Captivate and other applications like it give you the ability to record screen interactions as you work on your computer.  You can then edit these recordings and save them as movies.  These abilities make these applications natural tools for creating software and website tutorials and as such, these are tools that many training professionals have come to know well.

My main advice with using these tools is to do a little planning upfront before beginning, as this can save you countless hours and headaches when recording or editing your movies.

In this regard I recommend the following:

  • Create and use style guides. You should have a document that has been signed off by everyone as the guide to use with your movies.  This guide should give a detail description of every aspect of your movie (Highlight colors, Text boxes to use, Specific language to use,…).
  • Create scripts that outline your capture data needs. These scripts should indicate the specific steps as well as the exact values to enter and buttons to click on while you record.   To ensure you have meaningful movies, make sure your scripts reflect real world use.
  • Set up a clean test area to record in, as sensitive or junk data that is captured will have to be edited later on in the back end.  These edits take time and may require extra graphic resources so plan ahead and limit the potential impact of this.
  • Create a prototype based off of the style guide.  For this, record a short movie demonstrating the style guide needs—this visual guide creates a powerful resource for the developers and testers later on in the process.

The above planning and documentation will help any users that may be unfamiliar with your project, the software you are capturing or the screen capturing tool.  This level of documentation is also critical when you are creating a bunch of movies at one time or you have multiple people doing the recording and editing.

Many tutorials created by these tools jump right into the steps of a process and forget about the normal orientation users need with training content.  You should think of these movies as little self-contained objects—objects that users should be able to interact with on their own.  To help users here:

  • Include intros and summaries in your movies that state what the movie is about, why it is important and the objectives that will be covered.  With your introductions frame these movies into real work scenarios to help your users internalize the information.
  • Add extra navigational features to help facilitate the user experience with your content. To do this:
    • Add links to outside documentation or other movies that expand on your content.
    • Add custom buttons (Restart, Skip Intro, …) that provide additional navigational features for your users.
    • Create interactions or menus that highlight questions to consider or key points within your content.
    • Develop a scenario pane that identifies the high level steps in your process.
  • Add custom images to your movies to highlight non-software related process steps (loading a tray, scanning a label) or to gain interest.

These tools give you the ability to create straight software demonstrations, tutorials, and simulations; however, you can also use them to address other types of content. For example with a little thought you can develop movies that focus on concepts, rules and other knowledge types.  Captivate in particular has additional capabilities that will allow you to develop branching scenarios for soft skill simulations.  By following these tricks and tips you should be on your way to creating fast and easy movies or as Bob would say, “Happy Little Trees.”

Tagged as: No Comments

I Need Dollar Dollar

For those working with tight budgets or experiencing some of the hardships associated with our current economy, the above song may hold special relevance to you.  Money is tough and we all need those dollars; luckily, today I have some links that may be just as good though.

Screen capture tools and recorders like Captivate and Camtasia can create engaging demonstrations and simulations of web sites and software applications; however, they can be costly.

For those without money to spare you may want to take a look at Jing, which is a free screen capturing tool that you can use to create small movies. This tool doesn’t have a lot of features, for instance, you can’t edit your files and you are limited in your file export options. Despite these limitations with a little planning you can create decent demonstration videos for your online courses.

Podcasts are a relatively new method people are using to deliver training.  Basically podcasts are audio files that people play from their media players.  In order to create effective podcasts you need audio capturing and editing tools. Audacity has these tools and is free so give it a look and start creating your own podcasts

Other Goodies
For other free software that might help you develop training courses or just make your life easier check out for their Best Free Software of 2010 article.