Creating and Using Storyboards

Storyboards are an essential tool when designing computer-based training systems. They help keep developers, graphic artists, and subject matter experts all on the same page while working together. This can save you large amounts of time and money while avoiding truly unpleasant surprises. Tony Leonard explains all the elements of storyboards, and how to use them.

Remember when you were a kid and you read picture books? They were mostly pictures and not much text. It was pretty easy, most of the time, to figure out the meaning of the words simply by looking at the pictures. Then as you got older the pictures in the books you read went away and you used your imagination instead. You may have even discussed some of you imaginings with some of your schoolmates and found that there were differences in what you and the other students imagined.

Storyboards for interactive training are more like picture books than books without pictures. You should not have to use your imagination to figure out what a storyboard is telling you. In fact, using your imagination could be dangerous for developers and clients alike, as no two people “imagine” the same thing.

The moral of this story is that storyboards play a very important role in designing and developing interactive training tools and are the primary communication tool for all involved. Consequently, there is a dilemma; how do you create storyboards that don’t require imagination to use and don’t require drawing skills, and can be created in the most efficient way (usually electronically) so that they can be viewed by everyone involved and kept up-to-date? Well, that’s the story.

First, we’ll cover what storyboards are and what roles they play in the design and development process. Then we’ll cover what types of storyboards you need, what their important components are, and what support information you may need to use them efficiently and effectively. Finally, we’ll cover some of the ways to create storyboards.

{mospagebreak title=What is a Storyboard?}

For brevity’s sake, I’ll use CBT (computer-based training) in place of interactive courseware for the remainder of the article. Just remember that this article applies to all types of interactive courseware: CBT, multimedia, and Inter/intranet or Web-based training.

A storyboard is a packet of information that conveys all the necessary components of one screen of interactive courseware. Not surprisingly, several of them together are called storyboards. The main point here is that it’s usually not just one form or piece of paper for each screen. Imagine what it would be like to describe all the components on one CBT screen, including the text, graphics, media (audio, video, animation), question text and answers, feedback, navigation, hyperlinks, progress meter, and glossary terms on one piece of paper. If you can, then you’ve got a pretty good imagination!

Essentially, storyboards are meant to tell the story of each screen of CBT, and are meant to communicate between the instructional designer and several different people. The three primary storyboard audiences are developers, graphic artists, and SMEs (subject matter experts). 

Storyboards must tell the developer everything he is supposed program or build right down to the module title font, hyperlinks, and navigation of all buttons or other clickable objects. For graphic designers, they convey the story of what graphics are needed on a screen or as part of an animation. In fact, I like to create a separate list of what graphics are needed on what screen for production purposes. It’s faster for the graphics person to refer to this list than to flip through the many storyboards that would make up a course.

For SMEs, storyboards are the main deliverable that they review and approve before building begins. For this group, the storyboards must be crystal clear. It’s not unheard of for SMEs to use their imagination when reviewing storyboards. And it’s not unheard of for them to be surprised when they see the final product. I’ve heard many a client say things like “Oh, that’s what you meant by that! Now I see.”

And it doesn’t take a lot of imagination to see that statements like this can easily lead to changes that impact budgets and schedules.

{mospagebreak title=Storyboards as Documentation}

In addition to communicating information, storyboards are also the documentation for what you build. If you need to fix, change, or re-do something, you need the storyboards to figure out what was done. I know this is common sense, but when you’re in the throes of production, it’s easy to let things slip. Besides, you designed it, right?  You should be able to tell someone what was done. That may be true for up to a month after the project is over, but not much longer. And what happens if you leave that department, or go to work for another company, or just throw up your hands in disgust and leave the working world for a tropical island? What then?

For example, I’m working on a project now where I have to take a finished project and reverse engineer it to reproduce it in another authoring tool. There are no storyboards available from the last time it was built.  There’s no list of graphics or interactions or navigation branches. I have to look at the tool screen by screen and make notes about what the screen does. Fortunately, this isn’t a complicated project, but you can imagine that I would have been able to quote a lower cost if the storyboards were available.

What Makes Up a Good Storyboard?

For the projects I’ve done, I’ve developed a list of things that made storyboards good for each project. Some of these things worked better than others, depending on the team and the content and the project as a whole. The message here is that what follows worked for some projects, and in fact may work for you, but is by no means an exhaustive list. You should use these elements as guidelines and think through what you may or may not need.

I use at least seven different “storyboard” forms. They include a basic form, question form, video script, audio script, animation form, and glossary list. I’ll briefly describe each of these and what’s on them.

{mospagebreak title=Basic Form}

The “main” storyboard has a place for a sketch for showing the placement of text and graphics, the actual text, and a sketch of the needed graphic. It also includes the following information: date storyboard was created or updated, screen name, course name, lesson name, storyboard number, attachment number, page number, the window title, the menubar, the navigation buttons, the author’s initials, the programmer’s initials, the revision number, an area for a text description of what’s happening on the screen, a place for additional instructions, and to and from navigation. Whew!  By the way, this form is done in a word processor so that all but the sketch of the graphic can be done electronically.

I’d like to explain some of these items starting with storyboard number, attachment number, and page number. Because storyboards can be added, deleted, and rearranged, it’s best to number your storyboards using increments of 5. In other words, use 1, 5, 10, 15, etc.  That way you can add in storyboards without having to renumber any of the following ones. Attachment number refers to the type of storyboard. In this example, attachment A was the basic storyboard form. Attachment B was the audio script, Attachment C was the video script and so on. This refers back to the “packet” concept where it takes several storyboards to describe one screen.

Finally, page number is simply a sequential page number. This was put in at the request of a client that used these storyboards for review. They were having a hard time dealing with the increments of five and wanted sequential page numbering for their review copies. That gets away from the impact of adding, deleting, rearranging that the incremental storyboard numbers was trying to prevent, but it helped in the review process and wasn’t as painful as you might think. Those of you that are Word or WordPerfect mavens could insert a page number field that does this automatically. If you do that, you wouldn’t have to have both a storyboard and a page number.

{mospagebreak title=Question and Feedback Form}

After the basic form, the question form is the most complicated. It includes places to record much of the information mentioned above. In addition, it provides places to record the question stem, up to four answer choices, and unique feedback for each answer choice. It also records, for documentation purposes, the names of the media files used for the question and feedback audio and sound effects that were used for this project. “Hmmm…” you may be saying to yourself, “I thought you had an audio script form?” Yes, there is some overlap between storyboards sometimes. For this project, we used both text and audio for feedback. The question form had the text and any graphics that were to be shown as part of the feedback, and the audio script had the same text as the question form. The only difference was that what was on the audio script form included some additional information that was specific to the final audio files.

Animation Form

This form resembles the basic form except for a small block in the upper right hand corner of the sketch area. This form is used to describe any animation and to show what the screen looks like as various things happen or in various states. The small block records a letter to show the order of the different sketches. For example, the first form, A, would show the initial state of the animation. B would show the first thing the animation is to do, such as moving a piece of paper from the printer to the trash can. C would show the next state, and so on. This level of detail is necessary whether the animation will be created right in your authoring tool or in an animation tool.

The Rest of the Forms

The rest of the forms are pretty self explanatory. The audio and video scripts have the same header and footer information as well as a more traditional split page format with the stage directions on the left and the text of the script on the right. 

The glossary form simply includes a list of terms and their related definitions that would be put in the glossary. It also was used by the developers to search the authored screens and make sure they’d found all the instances of the term that were to be hyperlinked.

{mospagebreak title=How do I Create Storyboards?}

The examples included in this article show how a word processor can be used. However, using these examples, there was still a need to do a sketch of the graphic on the basic and animation form. Frankly, I don’t see any way around that. I know some of my colleagues say that words can adequately describe a graphic, but there’s still that old adage: a picture is worth a thousand words. My only problem with using just words for this component is that it does take a lot of them. One of the things I’ve learned about interfaces is that when it comes to buttons, the most effective way to label them is to use words and pictures, and I think that applies here. You don’t have to be van Gogh, but a sketch and words will make it easier to understand and requires fewer questions on the back end.

Other ways I’ve seen people create storyboards have included using databases and automated storyboarding tools. The database option was a custom database that used special forms on the screen that instructional designers used to input their information. Much of the input is exactly the sort of stuff that I described previously. Then, special report formats were created that pulled all this information out of the database and printed it for review.

The biggest problem with this approach was that it was a custom system that needed constant tweaking. Despite the developers setting standards and using templates, there were always exceptions that didn’t fit and required the screen forms and report formats to be updated quite regularly. Or they required that fields on the screen form be used for purposes other than what was originally intended, which caused a problem for the benefits of such an approach.

One benefit was that if you wanted just the audio scripts, you could print out a report with just the audio scripts. Another benefit was that you could import the screen text from the database instead of retyping it from scratch. In certain authoring tools it also meant that there was an external source of the text that, when updated in the database, caused the CBT to be dynamically updated as well. This last benefit would make the large effort this approach required worthwhile. However, if your authoring tool can’t do this, I’m not sure I’d go this way initially. It might be more practical to wait until you have done a project or two, using something like the word processor forms to see if you’ve captured what’s needed for your type of project, then use those forms as the basis of the database, screen forms, and report formulas.

{mospagebreak title=Automated Storyboard Tools}

Another approach is to use an automated storyboard tool. One such approach I’ve seen is to actually use an authoring tool to create a custom system. This system allowed instructional designers to import screen prints, highlight screen components, and include procedure steps and feedback to interactions. It also had a “sticky note” feature that reviewers could use when reviewing the storyboards. In case you’re wondering: yes, the storyboard reviews were done on the computer using this tool. There was no paper being shuffled around.  The biggest benefit of this approach is WYSIWYG – What You See is What You Get. It completely prevented that “Oh, now I know what you meant” problem. It also saved some time because the files were sent electronically.

The Rest of the Story!

In addition to the storyboards themselves, I’ve found it necessary to create a screen-by-screen flowchart of the course. This should represent the courseware’s navigation and a user’s path through the screens. Sure, there are places to describe this on your storyboards, but it’s back to that adage: a picture is worth a thousand words. It’s essential to create a standards document that really gets into the nitty-gritty by specifying fonts, colors, naming conventions, media quality standards, and the like. It’s also important to create a programming standards document that indicates what’s necessary for the code, such as commenting code and naming conventions for variables, or where to go to get common code so that the quality and productivity are maintained and folks aren’t reinventing the wheel. Regardless of your storyboarding approach, these supplemental documents are required.

Storyboards are the blueprints of your interactive courseware design and development process. The more detailed they are, the better they are at fulfilling their communication and documentation roles. Making sure that your storyboards are complete and accurate can minimize questions that cause delays, assumptions that cause confusion, and errors that cause rework.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye