Storyboards - techniques/suggestions

So I've been hearing a little bit about storyboards and I'm wondering how you guys do it. And is it really necessary? Is there a definite payoff to spending the time on storyboarding when you're using a rapid tool? I just don't want to spend more time on stuff than I need to, yet it seems like storyboards are pretty standard practice with the e-learning developers I've met so far. Anybody have a good format to share?

13 Replies
Natalia Mueller

Hi Cindy,

When I'm creating a course I keep my storyboards very simple. The SMEs I work with are only involved with the course content, not the design. Once I have a basic outline I'll use a simple table structure to add in topics/content and identify/capture where interactions will add the most value and any graphic ideas that come to mind while working with the content. This helps me approach the project as a whole with an intentional design strategy without spending a ton of time with how the storyboard itself looks. (I'm pretty sure the one I've adopted I got from the downloads here.) I'm also a fan of white boards and post it notes to get a plan in place before starting in the tool. I know a lot of people storyboard straight into Storyline but I found that cumbersome if I'm still working with SMEs at that stage. 

That said, when I'm on the receiving end and working with an external vendor I greatly appreciate a well constructed storyboard that includes an element of the graphic plan. This allows me and the SMEs I send it to for review to get a great picture and feel for both the content and the course as a whole. We would much rather make edits at this stage before dealing with drafts in Storyline.

My favorite I've ever received is from community hero, Nancy Woinoski. They include the intended graphic, voice over script, any on screen text and a brief explanation of any animation/interaction planned. These clearly take longer to construct but from a client stand point, they are fantastic. Maybe we can get her to chime in on her process... :)

Fairul Emry

Hi Cindy,

I started out using Word during the early days of ID and have only moved to PowerPoint about since a couple of years back. Just like Christine mentioned PowerPoint provides a much better visual to the clients than Word (ie having to have a Description section with descriptive Text). It's so much better during development because the client already can 'see' how it will more or less look like. During my Word days, most of the time what we end up with is far from what was initially written.  

Scott Wiley

We have found storyboards to be a crucial part of the "process" in designing/developing online training. In any case, it is helpful to separate the design documents from the development tool, even if you use PowerPoint for both.

However, you will want to think through what the purpose will be.

- Communicate ideas to your SMEs/stakeholders: A more visual approach, such as PowerPoint or Storyline can be best. This can help limit the amount of text content they tend to want to include on a screen. Prototyping interaction can be implemented to communicate an activity.

- Communicate with designer/developer on your internal team: Microsoft Word is our preferred choice. Screen content can be separated from instructions or narration scripts, etc.

- Later reference and searchability: Microsoft Word can also be best in this case. Even once high-level designs and content has been decided upon with SMEs, using the "Track Changes" tool can help communication with them in word-crafting or correction of mistakes, copy editing, etc.

Also, "when" you storyboard can be based on what development model you use.

- ADDIE (waterfall) approach: Storyboarding tends to happen up front, prior to development. The course can end up different from the original storyboard, through review/revise steps and may need updating later for reference.

- SAM (Successing Approximation Model or other "agile") approach: Prototypes guide the design and later help backwards engineer storyboards that most closely represent the actual course.

Jerson  Campos

It really depends on the course I am building. If I am building a software simulations course I don't bother with storyboarding the steps. If the course is a soft skills course then I create a storyboard for it. The first drafts usually have no graphics in it just some text stating some ideas for visuals. At the beginning stage I focus mostly on the script or context to make sure I translated everything that was captured during the initial meetings. If I have an idea on where I want to visuals to go, I usually supply some sample mock up screens. This will save me a lot of time down the rode If I really like the idea for a certain look, but the client doesn't like it and wants it to look different.

I use word because it is easy to track the changes made by either party. For the format, I usually stick to a basic design, but I make modifications to it as necessary.  There will never be one format that will work for every course. 

I use storyboards because we do a lot of our own voice overs. Creating the storyboards and making sure that the script is correct saves us a lot of time compared to developing it SL and then making changes later on. If we were doing Text-to-Speech or just text, then going ahead and starting development in SL would be more practical and can easily be changed. 

Nancy Woinoski

Thanks so much Natalia, I don't think my process is much different then what has already been discussed. I just include the elements that I think will make sense to the viewer. When I am creating a storyboard for stakeholders, I write the narrative first and then focus on how to best present it visually on screen. I only include basic information about how interactions will work because I find that most people don't really get that part until they see a working version of the course.

If I was creating the storyboard for a developer I would make it less visual and put more instructions about what interactions are required and how the nav should work.


Jonathon Miller

Wow! So much great info here. I will incorporate some of it myself.

Here is my two bits about my process. 


Once I have had my initial meeting with a SME, I will turn to a story boarding process. I will lay things out right in Storyline and use the notes section for much of the information that would normally be included in a story board. I allows me to get approval on look and feel, as well as content using the same document.

I will then publish the Storyline project as a Word file. I can make what adjustments and add what info I need using Word. That then gets sent out to the my SME and anyone else that I need approval from. That way everyone can make their edits and track changes right Word.

When I get it back I can copy and paste any changes to the copy. As far as changes to the graphic design, I either get notes back in the Word doc, or a hard copy with sketches/changes on it. 

If it is important to demonstrate navigation, I will either take screen shots of the Story view in Articulate or sketch it out in Microsoft Visio.

Hope this helps.

Jeff Batt

Excellent ideas everyone! When I was working for eLearning Brothers I had used Balsamiq to detail out as much as I could about the game or interaction. I made notes of what every button would do and how things should function. I found this sped up time tremendously.

If I was handing off the development to another developer I found there was less back and forth between myself and the developer and even graphic designer knew what needed to be designed. The developer and graphic designer were clear on what needed to happen and could get the development done quicker. Even if I ended up doing the development myself, I knew exactly what needed to be developed and didn't have to think through the basics.

In programming sometimes you write sudo code which is basically just writing in plain english what needs to happen in your program. Doing a storyboard or wireframe is essentially sudo code working through the logic and content in plain english so you can translate it easier into the software later. 

For example, here is a wireframe PDF or one of the games I designed and developed while I was at eLearning Brothers.

Cody Salinas

Hi, Cindy.

I take a slightly different (some may see it as antiquated) approach to storyboarding.

When I work with SMEs (or develop company content myself), I take it back to grade school and reiterate the importance of telling a story using a journalistic approach (inverse pyramid). If the written content can be totally visualized while reading it, the actual development of the course material is a breeze and comes naturally.

The first couple of courses the SMEs develop, I ask each to write a complete story verbatim as though those words are the ones he or she will be narrating on screen. It's not the most efficient tactic when it comes to storyboarding, but it's effective and absolutely teaches the importance of explaining "The Why" behind the content.

Once SMEs have found their rhythms, I let them create content as fluidly as possible based on their individual styles. Some continue to storyboard by crafting a complete written story, and some can develop content off the cuff. 

Generally speaking, I think storyboarding - whether it's written on paper, drawn as sketches, or developed on the fly in Storyline - is a critical aspect to developing relevant, effective training.

Daniel Brigham

Hi, Cindy: So many different ways to storyboard and thus many opinions. If you've got access to there's an Elearning Essentials: Storyboard course, created by yours truly. If you don't have access to lynda, here's a condensed version of what I do. 3 Ways to Storyboard Some downloadable templates are included in this post.

A few other posts I've found very helpful:

Hope that helps a bit. --Daniel