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.