Instructional Design Basics


Educational Videos: Creating Them for Conceptual Objectives

* This post originally appeared in elearning industry.

Recently I read a fun Mashable article that disparages several recent trends in startup videos.  A colleague and I discussed this article and came to the conclusion that with a few tweaks, it could easily be an article on how to create a good startup video.

Rather than making those tweaks though I am going to use it to discuss ways to make an educational video for concepts.  As to why this will work, you must first consider the startup video. Here they are basically covering a concept with the following elements: There is a problem, We have a solution and Our solution easily meets your needs.

With that in mind, let’s get started:

1.  Hipsters

These startups identified young people as their main audience for their products.  Being smart marketers, they know that including people in their videos that fit into their marketing demographics is a good idea—thus we see hipsters in the videos.

Understanding and defining your audience is a key component to creating educational materials.  With videos you should use language, images and content that applies to your audience needs.  In this regard, your content should be relevant and fit into the real world of your audience.  Doing this will aid transfer and internalization of your content.

2.  Happy claps

These upbeat sound tracks set the mood and help energize these videos. For startups, this strategy is aimed at one thing—selling.  As part of their pitch, it adds to the idea of “we have a solution and that solution easily meets your needs.”

In educational videos, music can be a distraction from your message and may affect your learner’s cognitive load.  Stories are a powerful though and can help your learners internalize content. In this regard, music (harmony, dissonance, tempo,…) can add something to your story that simple dialog and images can’t.  Just make sure to use it wisely and watch out for the cognitive demands you are placing on your learners. With educational videos make sure your use of music, effects, dialog and shots are relevant and needed as extraneous information can interfere with your message design.

3.  Animation

Concepts are often difficult to represent; for example, Time Management contains several abstract ideas that are not easily translated with concrete examples. To help illustrate their concepts these startups create graphic metaphors and analogies for their videos. Related to this is production value—high quality is needed and doing this well with full motion can be an issue.  As such many startups look to animation as it gives you abilities that can’t easily be duplicated with full motion.

These concerns are true with educational videos. And in relation to this, visuals that are less complex and detailed can lessen your student’s cognitive load and allow you to focus greater attention on your message. Other common animation techniques you may try for conceptual content are stop animation and whiteboard animation.

 4.  Meet Bob, Romance and Save the World

Startups need to grab the attention of investors and consumers quickly.  They can do this with stories as they are a powerful way to cover content. Meet Bob, Romance and Save the World are formulaic themes that have been proven to work and are why they continue to appear in these videos.

Stories are great at setting context and when this is related to relevant and real world applications, their use in education videos will help with internalization and transfer.  In addition, stories activate prior memories as good ones represent something that we can all relate too.  This activation can increase motivation and internalization of the content.

In this regard, motivation and emotional engagement can be critical to getting users to change behavior. In training we recognize this need by covering WIIFM (what’s in it for me). Getting students to value and accept your content is critical in order for students to transfer knowledge into their working world.

5.  Flat Design

These startups are selling an idea that they are hip, innovative and know what’s coming—using a dated style/template would conflict with this message.  As such flat design elements should be expected in their startup videos.

As to educational videos, this practice may conflict with common instructional design principles.  Here cognitive load and basic UX (user experience) ideas emphasize the need to limit distractions.  In this regard, a novel or complex style/template requires more working memory than a common or simple style/template.  Since our working memory is limited and is involved in storing information into long term memory, requiring less working memory makes sense.

Giving the prevalence of mobile and other technologies, our students’ familiarity with flat designs is being addressed. So if you want to appear hip, innovative and in the know, you are probably fine using a flat design in your videos for now.

Designers Don’t Need to be Creative—They Need to Design Well

Being creative and original is fun, but shouldn’t keep you from designing well.  Sure your video might look like something else and there may soon be a post on Reason Why Training Videos for Concepts All Look the Same but that’s ok.  In this regard you are using valid strategies to guide your designs rather than the latest fads.


Watch Out for Big 01000100 01100001 01110100 01100001


Awhile back I read an interesting article about Target and how they were able to figure out that a young woman was pregnant before her father.  This weekend I read another interesting article on companies that are screening potential employees based off application surveys.  These and other articles have me thinking about Big Data and what it means for our field.

Destiny is Bunk

In previous posts I’ve touched on aspects of this idea when talking about recommendation engines. Here our personal data is collected and used to determine training that we might need.  This is great as big data is acting like a guide; however, this tool becomes scary when it used for more than guidance. Those companies that are using it as a screening tool have stepped over this boundary.

In this regard, I understand that you can save your company substantial money if you weed out employees that might steal, get injured or quit, but using it as a screening tool seems highly unethical. To me, experience and hard work should determine who gets a job and not a predictive score that illustrates a potential future. Here I believe in people and that with proper training we can improve anyone’s performance.  This belief is why I got into education and training.  I suspect that many of you hold similar positions and encourage you to watch out for how your companies implement and use big data.

As to this data, if your company is not already using it with application surveys, they soon may start which is why it is important to begin working with your leaders to define how to use it fairly. One way to do this may be to use this data to improve your learning recommendation engines.  Here if your screening process identifies someone that is likely to get injured, you should push additional content to that person on safety and procedures.  And if you identify a person that might take additional sick days, you should push content to them that sells your company—these employees need to value their work and see their impact to the company.

Besides using it as a way to push content it can also be used to change environmental factors. So if you identify someone that is likely to quit because their commute is too long, look at incentives that might keep them or counter that potential issue.  Here you could give them flexible hours to avoid peak traffic times; allow them to telecommute; or compensate them for their commutes (paying for parking or paying for their bus/train passes).

Changing environmental factors may be crucial as this is often a main reason for why training fails.  In this regard, it doesn’t matter how good your training is, if it isn’t supported or rewarded behavior will not change.  The same is true here, that is, if your environmental factors are off it doesn’t matter who you hire as they will likely quit, steal, or call in sick.


In order to get big data to work with your recommendation engines you will need collaboration between your learning professionals and your talent management groups.  This collaboration and data can add value to your learning recommendations by highlighting positive data as well.  So you could setup your systems to push content to high potential employees or to steer people to critical to full positions.

This last thought is something that we struggle with a lot in healthcare—there are constant shortages in some positions.  So in this regard, if the screening process highlights personality traits that fit critical to fill positions then content can be pushed to these employees that may lead them to pursue these activities.

Some specific activities to follow with big data use are:

  1. Get your application data into your Learning Management System (LMS)
  2. Map your learning objects (LOs) appropriately with meaningful metadata. This metadata should connect to your application data.
  3. Develop positive mappings like high potentials and critical to fill areas as well as the negative mappings.
  4. Use these negative values to identify environmental factors that might need to be adjusted (support and reward mechanisms).

If used correctly Big Data can help your company protect itself from potential problematic employees and remain an ethical and fair tool to hire great employees.


Can’t Touch This


The den was once my man cave—my safe place to go and watch TV or get some work done. Lately though this has become Max’s playroom.  And if you saw it, you would note a series of pillows, blankets and other obstructions strewn around the room.

These steps are necessary, as Max sometimes focuses on the wrong thing. In this regard an angry cat or an expensive Smartphone can be more interesting than toy blocks.
So to keep Max focused on the right things I have found that a little guidance is necessary.  Hiding things from him works for now and making access difficult is also a good solution—so a nice gate is handy, but even that is temporary. As I continue to interact with him, I can tell that this is a battle we’ll have for many years to come.

Unfortunately this is also a battle we as designers may have to face with our project sponsors, that is, how do we keep them focused on the right thing?

Today I’ll talk about some of my war stories with sponsors.

I Know What I Want

Project Sponsors are the ones that come to us requesting services so without them and their needs we wouldn’t be building training initiatives. Because of this I can’t bag on them too much, but as a designer I know that I need to watch out for them as they can set us up for failure.

Here sponsors may come to us with preexisting ideas on what the problem is as well and how it needs to be fixed. Often these sponsors are subject matter experts so it is a good idea to listen to them in this regard.  Just know though that their expertise can lead to tunnel vision and may cause them to focus on only a narrow portion of the problem.

This is the case I experienced awhile back when one sponsor voiced a need to get their students using specific codes in a software application.  These codes were important as they helped identify trends and problems in their workflow. This identification then allowed analysts to come in and figure out ways to maximize efficiencies and or cut costs.

When the sponsor approached me she had it all figured out—her users were not entering the right codes so they just needed additional training on them. And her solution focused on step-by-step training on each of the codes.    However, as I talked with her it became apparent that this solution wasn’t going to solve the problem.   In this regard these users had already received step-by-step training on the codes and it didn’t work.

So I talked with her some more and discovered that users were given a codebook to help them with their processing activities. This codebook was a large job-aid that listed all of the codes and appropriate use cases for each. This was a great performance tool, but it wasn’t being used much.  In addition I discovered that the end users didn’t really understand how these codes could save the organization money—they didn’t see what an error meant for the company and themselves.

So the ultimate solution didn’t focus solely on the codes, rather our total problem and solution, focused on the need to get her students using their codebook as a performance support tool and connecting the use of codes to losses and savings within the organization.   From that focus we then came up with a game that users played.  This game covered the most common problem areas with the codes and had the users interact with them in a simulated environment.  Here users saw the connection of the codes to the company.

Can’t We All Just Get Along

Besides focusing on the wrong thing you may encounter a situation where the sponsors can’t sign off or agree on the goals/objectives of a solution.  This is a real problem as you can’t start building the training until these goals and objectives have been finalized.

This is the case I experienced early in my career when I had to work with two sponsors from different divisions. This project surrounded a training initiative for case processing software. This project was complicated by the fact that several groups made up the user audience.  And here my sponsors represented each group and advocated for their specific needs relating to the training.

As I worked with the sponsors I discovered that one of them wanted training surrounding the step-by-step processing requirements in the software and the other wanted to focus on the factual and conceptual content within the software.   These differences caused some tension within the group and kept us from agreeing on the goals and objectives for the course.

As I continued to work with them I discovered that they wanted similar things when I pushed them on it—here they agreed that they needed all of this content as part of the solution. So they recognized each other’s needs but they couldn’t agree on which was more important.  This reignited the fighting in the group and as this fight continued tunnel vision set in—my sponsors only saw what was important to them.

This went on for several weeks and I employed a variety of strategies to try to get them to agree—I met with them together, I met with them one-on-one, other designers were used to facilitate discussions, I laid out the similarities, I advocated for each need, … all to no avail.  We were stuck and we were soon at a point of no return as the implementation date was fast approaching.

Ultimately I was able to get them to agree and move forward by moving around the sponsors. Here I met with key managers in their areas and explained the situation.  These managers were then able to champion and sell the need for the total solution in a way that worked.  The sponsors finally agreed and we able to develop a solution with steps-by-step processing as well as conceptual, factual and attitudinal information.  This last knowledge type I added to the project as it is a need that is often overlooked   (See knowledge types for software training for more information).

Leading a Horse to Water

Max's Interest Levels

As these stories illustrate your project sponsors can get stuck focusing on things that can derail your training initiatives.  Here they may be blinded to the real problem or may not see the full needs of their audience. Regardless of the type of project sponsor you have it is your job to guide them back to a safe place.

Fortunately your interactions with these sponsors are usually limited to the front end analysis part of your projects. Once the goals and objectives have been finalized these sponsors usually go away—leaving you stuck to deal with SMEs, Project Managers, and the occasional ID.

Max is a different story—I’m stuck with him for a while and as the graph shows I’ve got a lot of distractions to deal with here; however, I’m looking forward to these challenges!


My Bad

I've been there before—I've made decisions that seemed wise at one point; only to have those decisions quickly turn bad. I know this is something that will probably happen again, but that’s ok. After all, I know that our failures can be our biggest learning opportunities.

So today I am going to talk about some of my failures or instances where an Instructional Designer (ID) caused a problem with course development.

Getting Lost

A few years ago I worked with another ID on a project. Here she was the lead designer and contact person with the client.   For this project we were tasked with developing a simulation at the end of the course.

And at the start of the project, the simulation seemed like it would be an easy pursuit as the client had existing case data for the simulation. So with optimism and a fresh outlook, I jumped into the storyboarding. This attitude didn’t last long though as I quickly encountered problems.

Scoping proved to be a main challenge with this simulation as it changed several times.  Initially the simulation was set to cover 5 objectives; however, a couple of weeks into the project, the lead designer decided that the simulation would need to cover all ten course objectives. This change only lasted a few weeks though as she later decided that the original five objectives would meet the client needs.

Creating a simulation in this environment was challenging, but I thought I had it under control so I kept plugging away. In this regard, I started off ok as the scoping was clear and I was able to focus in on the course objectives.

The problem occurred as the scoping changed back and forth.  Here I had developed some pretty solid storylines and navigation schemes for the simulation. And as I made my changes I tried to maintain this content as much as I could.

In this regard, I slowly started focusing more on the storyline and the navigational structures within the simulation.  I soon got lost in this pursuit and failed to focus on the course objectives for the simulation.  So in the end, my final storyboards had an elaborate story and an engaging interface but did not truly cover the course objectives.

Ultimately the simulation was scraped as we ran into a time crunch and had to focus our resources on other course requirements.  I can’t help but think though that if I hadn’t lost focus here we could have had the time needed to build this part of the course.

Sure We Can Add that Content

There are few courses that really impress me, that make me question my abilities and wonder if I have what it takes.  Running into these courses can be humbling and several years ago this is what happened.

This course was a thing of beauty and to this day I don’t think I could have designed it. All of which is why this next project was so disturbing.  You see a few years later I was part of a team that got tasked with a redesign of that course—that thing of beauty.

Here the client had some new content that they wanted to add to the course.  This by the way was the second redesign of the course, a year earlier; the client had added other content into the course.

Some of you may see the problem already.

Courses are complex creatures; they have subtle traits and characteristics.  The original course had a well-defined storyline that followed a real world scenario.  It also had a style and flow that worked well within that scenario.  The first redesign had already changed that creature; made it something less cohesive. We were about to make it drastically so.

As we started adding content we soon ran into a problem. Here the original style was different then what was used with the 1st redesign, so each version had a slightly different look and feel.  The fact that there wasn’t any real style guide documentation for the two versions added to this problem. So as we storyboarded, we were forced to find pages/styles that seemed to fit with the new content needs and use those as our guides.

In this pursuit we didn’t always find a perfect fit, so we added our own style characteristics into the course here.  This ultimately meant that the course was built with 3 different styles. And from a user experience, this translated into an inconsistent course— one where navigational clues, language preferences, and even course features changed across the course.  This thing of beauty was now a Frankenstein.

The new content also influenced this outcome as it did not tie in well with the original story.  This new content added a level of distraction to the original storyline and was in essence a side story.  And from the user experience that followed, this side story felt a little forced or appeared to be an after thought, which is exactly what it was.

Serenity Now

Both of these examples point to a problem you may face in your pursuits—a reluctance to start over when you need to.  In this regard, you should always keep your basic course needs in mind as that will keep you focused.

With the first example, I let the story drive the simulation at the expense of the content.  The course objectives should have been the driving force for the simulation as following those would have ensured that the content focused on what mattered. Each time the scoping changed I should have stopped the storyboarding and revisited my needs here.

With the second example, the team let the new content drive the project at the expense of the overall course.  Here we should have started from the beginning and looked at the original course goals.  Here we should have determined how the new content fit into these goals and what they would mean for the story.  This questioning would have helped the team define a natural storyline that would drive all of the content.

Starting from scratch in this regard would have also allowed us to create a standard style guide to be used for the course.  And in the end we might not have matched the original thing of beauty but at least we wouldn’t have disfigured and or destroyed it.

As seen above IDs can cause some problems in your elearning projects and to help you get started on what to expect from IDs, I’ve put together a short table of Types of Instructional Designers you may encounter.

As you read it you can see that some IDs may be more apt to having a bad idea or two.  And if you encounter this, just think of it as learning opportunity.

If you have encountered other types of IDs please add comments to this post describing them.



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.