Instructional Design Basics


Every Dog

Next year Reservoir Dogs will celebrate its 20th year in release. This movie is pretty awesome and if you haven’t seen it then I suggest you give it a look.

As to why I enjoy it so much, this movie was one of the first films I remember watching that switched between past and present scenes. One moment the characters were in the present and then the next they would be in the past. And it didn’t stop there, as there were multiple instances of the past. For example, once scene would have the characters three weeks in the past and then in the next one they would jump back further in time.

This back and forth in the timeline presented an interesting storyline and allowed for deep character development within the movie. This type of story is something that more movies take advantage of now but back then it was unheard of—movies then were strictly linear.

In many ways our training initiatives follow a like construct; here we often see our training courses as strict linear content. We have topic A, B, and C and before we talk about B or C we have to cover all of topic A. Jumping back and forth between topics is not something we typically do.

Story elements not content chunks

This doesn’t have to be the case though and your first step in breaking this cycle is to stop thinking of your content as separate chunks of information.

Here there is a tendency to organize our information into similar groups—after all we want to help our users find and internalize information. So we come up with topics and present them one at a time. And a typical content outline we us to develop our content looks something like this:

Common infections
Ventilator associated pneumonia (VAP)
• Signs and symptoms
• Prognosis
Staphylococcus aureus
• Signs and symptoms
• Prognosis

Prevention Methods
Hand Hygiene
Personal Protective Equipment
• Gloves
• Gowns
• Masks

By following the above outline you would develop two unique content chunks that would be separate parts of the course.  Here you would have a page or two listing the common infections and their characteristics.  Then later on you would have a couple pages describing infection prevention methods. Such groupings are nice as they provide structure and organization for the student; however, they don’t follow real life or make for an interesting course.

To break this you should think about your content from a story perspective and instead of the standard content outline, you should be developing a storyline that the user experiences.

While developing a storyline you can use a Table of Specification to help you keep track of your story and content needs.  Here you can list your story ideas and match them up to your course objectives.

Story Elements Objectives Content
A Staph colony is somewhere in the building 1,2,4 Symptoms


Transmission routes—Contact

Hand Hygiene


The user needs to research MRSA 1,3 PPE—lab coats, gloves

Patient risk factors—weaken immune systems

A patient has Tuberculosis 2,4 Symptoms


Transmission routes—Droplet


Once you have these story elements documented you can start to develop a storyline that users will experience in the course.  And if you are careful with you documentation you will be able to ensure that all of your needed content is addressed.

In the next couple of posts I will show you some informal ways that the above content could be delivered. Hopefully this will help you develop your next course and while it might not be another Reservoir Dogs it will be better then your typical A then B then C course everyone else is doing.


Everything is a Nail

Awhile back my boss and I were asked to sit in on a vendor demonstration of some HIPAA courses that were being evaluated for use. After it was over we gave some general input and left.  When we got back to the office my boss asked me what I really thought of the course.

Up until this point I hadn’t figured out my boss— I didn’t know where she stood in the great ID war.  Was she one of the science guys that championed a theory or two or was she a practitioner of a holistic approach?  So I decided to play it safe,

“Well technically it was correct. They followed the Tell, Show, Do model, had some scenario based content and...”

At this my boss sat back and gave me a small frown. She then proceeded to go off on the course, which was a beautiful thing. It was beautiful in that it confirmed where she stood in the war and it clearly identified her as an ally.

Tell, Show, Do

Now it may sound like her and I had different viewpoints on the course.  After all my comments were positive, “…technically it was correct” and I still agree with that statement as there is science to support the strategies used.

The main strategy they used was to develop the content around the Tell, Show, Do model.  And to some extent this is a good model to use, as it is easy to remember; provides an outline for your content development needs; and provides structure and practice. All of which should help a person learn new content.

The basics of the model are that each objective will have the following content:

Tell: This content chunk will tell the user the exact behavior or task they will learn in the course.

Show: This content piece will then demonstrate the behavior or task that the user is expected to learn.

Do: The final piece will provide an opportunity for the user to practice that behavior or task.

Content development in this model is often expanded on or supplemented by Gage’s nine events. And as I said, such a model is a good strategy to employ for a person learning new content. However, the problem with the model and any model for that matter is the tendency to overuse it or the old, “…when you have a hammer, everything looks like a nail” problem.

Consider Your Audience

The nail in this course was the audience—here the developers of the course didn’t really know their full audience. Up front the developers should have spent some time defining all of the users that would eventually take the course. By spending time analyzing their audience they would have identified the following concerns:

Knowledge Levels
HIPAA is part of our compliance training which means that our users get some form of it every year. So in essence significant portions of the users taking this course already have some expertise in the content.  Yet the model used to develop the course was based on something for new users. So in this instance a large group of people would be forced to review a bunch of content that they didn’t need or that they already knew.

The impact of this can be highlighted when you break this down into time. This course only covered 5 or 6 objectives and with the Tell, Show, Do model employed, it would take 45 – 50 minutes to complete.  This is a lot of time to force someone to take when all they probably needed was a 15 – 20 minute refresher course.

To address this group the developers could have allowed users to test out of content, or used single source technologies to tailor content to each group’s (novice, intermediate, expert) specific content needs.

Reading Levels
Since HIPAA is required training for all levels of the organization a question that should have been immediately determined was the reading level of the content. When the vendor was asked about this, they indicated that it was written at an 11th grade level.

Generally newspapers try to write at an 8th grade level or below. These papers recognize that many people do not read at a high level.  In our organization we have a significant number of people that have similar needs and in order for them to internalize the information, content should be at a like level (8 or below).

Learning Styles
Because many users have taken this content several times, are required to take the content and may not be highly motivated learners to begin with, engagement is a critical need with our training.  The reality is that many of our students do not want to take this training.

This is typical of learners in all environments—rarely do you find the group that is excited by compliance training.   However, you don’t have to reinforce these feelings by making them take boring content.

A problem with the Tell, Show, Do model is that it can facilitate the creation of boring content. If you examine the model and apply it to an equivalent classroom format you will find it similar to a lecture (Tell and Show). And we all know how boring lectures can be, “Anyone.…”

As a learning style, few people prefer lecture-based content so if you are going to choose it, make sure it is interesting—make it scenario based, add humor, interesting ideas or whatever you need to do to gain and keep attention.

Your Projects Are Unique
Saying all of this, I want to restate that I don’t think the Tell, Show, Do model is a bad thing.  In fact with our user developed content, I would be thrilled to see its use applied to the courses. What I do you want you to take from this post is the need to fully look at your audience and to not let an approach blind you to your needs here.

This thought can be especially important when it comes time to view vendor products as they are typically done with models and templates like this.  Here the vendors may try to hide poorly designed courses behind the science.

“Our basic structure is Tell, Show, Do and we follow Gagne’s nine events…”

Remember your project is unique so when you see someone pull out a template or a model make sure you step back and really analyze your needs. Maybe instead of a nail your course is a peg or some sort of corner joint.