E-Learning Challenge #48: Storyboard Templates for E-Learning

This week’s e-learning challenge is an interesting one…one that is often glossed over in discussions, but which has also been discussed at length (if you look for it): Storyboard Templates! Hooray! I’ve chatted about storyboarding vs. rapid prototyping here and created a jaunty time-lapse demonstration of the development of a very basic storyboard template here (along with a downloadable template – wahoo!), but I’m going to go through David’s questions and maybe even include some downloadable sample templates. GET EXCITED!!!

The Concept

Share an example of your preferred storyboard template and answer the following questions:

1. How do you define scripting, storyboarding, and prototyping? Which method do you prefer?
2. Do you use different types of storyboards? When do you use each?
3. How do you storyboard interactivity?
4. What are your top three storyboard tips for new course creators?

The Method

First, I considered my storyboarding preferences and sifted through my hard drive to locate some samples. I realized that I had previously included my preferred storyboard template (and by preferred, I mean most commonly used and/or adapted for use) here.

Then, I considered each question and jotted down some note for each.

The Result

By clicking here, you can download my preferred/most commonly used and/or adapted for use storyboard template.

1. How do you define scripting, storyboarding, and prototyping? Which method do you prefer?
   • I previously defined storyboarding and prototyping over here, so I won’t bore you with a re-ramble of that post.  As far as scripting goes, I would consider this to be including verbatim onscreen text, narration, and or media element scripts for other developers (and/or yourself as an organization tool). When scripting audio narration, I also would define aspects of the script to clarify the verbatim narration (e.g. pronunciation).
   • I prefer rapid prototyping overall, but find it most effective with smaller projects, requiring less sign off from other individuals. With larger courses/products, I prefer to storyboard in a Microsoft Word template as it’s much easier (and cost effective) to modify a Word document than a developed file.

2. Do you use different types of storyboards? When do you use each?

   • I do you different types of storyboards, but it really depends on the clients needs. If they’re able to visualize the overall course based on a detailed Word storyboard, I’ll do that. If they need something more visual, I’ll develop a visual storyboard in Microsoft PowerPoint or Articulate Storyline. If a complex branching scenario is used, I’ll refer to a Word storyboard in a task analysis template (e.g. where each cause and effect task is branched out appropriately). If the client requires an Excel template, I’ll cringe and comply (and sob).
3. How do you storyboard interactivity?
   • My typical method for storyboarding interactivity is to create detailed accounts (occasionally supplemented with mocked up visuals – for complicated media descriptions) of the media and interactivity to be included on that screen. This tends me be adequate, but sometimes clients (or Subject Matter Experts) need more of a visual, in which case, I’ll do a visual storyboard using PowerPoint and include descriptions of the interactions or mock them up as much as possible (using animation effects) to convey a similar look and feel of the end product.
4. What are your top three storyboard tips for new course creators?
   1. BE CONCISE in your onscreen content – no one likes scrolling (too much).
   2. Ensure all aspects required for development are accounted for within the storyboard (e.g. navigation, introduction, conclusion screens, interactivity, audio script) – it’s good to have a one-stop-shop approach to your storyboard templates.
   3. Be as detailed as possible in your media descriptions; often times in larger organizations, the storyboard gets handed off to a media developer and then maybe a programmer, and you want to be as detailed as possible to avoid back and forth communication regarding elements. Doing this will save you time, money, and frustration. AND – everyone will be on the same page (e.g. the media developer can get added context for a screen by reading the onscreen text, and the programmer has a better understanding of how to program the media interactivity by reading the media description). All aboard!