Storyboards as Documentation - Practices

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.