Elearning Storyboarding 101

This guest blog post is by David Becker, an Articulate user and owner of Becker Consulting, based in Melbourne, Australia. He’s been designing and developing e-learning and blended learning for nearly 15 years.

Suppose you’ve hired me to build a house for you. We sit down, have a chat about what you want built, and then I explain that my approach is to just start building, making it up as I go along, and we’ll just see how things come out. This is, of course, absurd, and yet some e-learning developers do that very thing. But, like the blueprint for a house, e-learning development should derive from a carefully crafted plan. This plan is called a storyboard.

A storyboard is like a script with actors, dialog, and directions. The dialogue can be either on-screen, spoken, or both. And the actors are not people, but rather on-screen elements like text boxes, images, videos, and things the learner clicks.

The value of storyboarding

The storyboard’s primary value is that it forces you to have a reason for, and a consistent approach to, everything you do. The storyboard is your plan for sequencing the content, applying a consistent style, designing meaningful activities, providing feedback or instructions to the learner, and so on.

When I develop a course, I typically have my client sign off on the storyboard before I begin my development tasks. This way, the storyboard allows clients, subject matter experts, developers, and other stakeholders a chance to have a say in content development. And storyboards often help reveal issues over scope, wording, technical limitations, and so on before more expensive development is underway. By the time the storyboard is signed off, I have a clear document, agreed to by everyone and detailing exactly what needs to be done.

TIP: When submitting your storyboard for review, ask reviewers to use Microsoft Word’s track changes feature to make it easy to see their feedback. If there are multiple reviewers, it’s also helpful to require the client to consolidate the feedback in one document. This ensures the client retains responsibility for stakeholder consensus.

If you work in a team, once the storyboard’s approved it can be easily broken up and distributed to the voice talent, graphic designers, media producers and so on, so that they can do their bits simultaneously, shortening the overall development cycle.

Here’s a downloadable storyboard to get you started

So, how do you storyboard? First, your storyboard should be founded on sound instructional design and pedagogy. But that’s a massive subject, so let’s assume you’ve already done your due diligence and that you roughly know what learning activities you plan to build and their sequence.

Next, you select or design a storyboard format. There are many storyboard formats and approaches out there, including visual mindmap-style mockups, highly structured templated formats, and everything in between.

Today I’ll share with you a common approach I’ve used that is simple, flexible, and easy to adapt. It’s a straightforward tabular format created in Microsoft Word, in which each screen is represented as one or more rows in a table. The table is divided into columns. Each column documents a key element, such as text, media, dialog, or developers’ notes. Feel free to download the sample Word file of this format so you can adapt it for your own needs. If you prefer, you can open a PDF version by clicking here.

The format you end up using ultimately comes down to your personal preference and whatever client standards you need to meet. As long as the storyboard is easily understood by others and you are consistent in applying an approach, then everything should be cool.

A closer look at the table

Since the table format is an easy one to get started with, we’ll focus on that one for now. Let’s break things down and take a closer look at the kind of information that goes into each column:

• Ref: The first column is a screen reference. It gives you an easy mechanism for discussing and tracking specific screens. This is helpful when you’re having development discussions or review meetings with stakeholders or team members, so that everyone’s clear on what screen is being discussed.

TIP: If you can embed your storyboard screen references on the slides of your course prototype or alpha build, it’s a nice cross-reference when tracking bugs or feedback, making it easy to trace things back to the storyboard stage.

• Text/script: The second column is for any text you’ll use in the course to communicate your content, including screen headings and on-screen text. Some designers also use this column to contain the script for voice talent, or video scripts, but for brevity I tend to reference these and put them in a separate document.
• Interaction: The third column is optional (some people like to split this stuff between the Text/script column and the Dev Notes column, while others like to put this info on separate rows; it’s all personal choice really). I use the Interaction column to display any on-screen text that is interactive, such as the choices for a multiple-choice question, drag-and-drop text, checkbox options, correct and incorrect feedback, etc.
• Dev Notes: The fourth and final column describes any animations that will be applied, images needed, existing media or weblinks to be included, any branching references, and so on. This is also where I describe Engage interactions or Quizmaker quizzes that will be inserted onto the slide, and any related properties (for example, the contents of the quiz results slide, the behavior of the quiz’s Finish button, etc.)

TIP: If your course’s branching becomes complex, consider drawing a sitemap at the top of the storyboard document, using the screen references from the storyboard.

How does all this look when you turn it into published output?

Glad you asked! Check out the published sample below to take a look. This is a quick mock-up of course content that I built from the example storyboard referenced above. View the published sample and the storyboard side-by-side to see how the elements relate:

View sample course

How much detail is enough?

The storyboard example I’ve shared here is intentionally detailed. I’ve defined a fair bit of the animation, positioning of elements, and so on. You’ll need to strike your own balance for how much detail is appropriate to include for your own project. Once again, it is personal preference.

You’ll also notice I have not storyboarded every detail, like timings for animations. I find that some specifications are too hard to guess during storyboarding (or there’s not always a lot of need or value in documenting such granular detail), so these items are best determined on-the-fly while developing. This is especially true when you’re using rapid e-learning tools like Articulate Studio ’09, because it’s often quicker and easier to develop and fine-tune a prototype of certain aspects of your course, rather than spend time writing and revising a lot of minutia in a storyboard.

If you take a close look at the text in my storyboard, you might’ve also noticed that I use a sort of shorthand in some places — for example, “nav bar” refers to the navigation bar at the bottom of the first screen. “Position screen right” refers to where I want the image to end up. “Iso” refers to the image being isolated on a transparent background and saved as a PNG. If you use shorthand like this, it’s important that you and your team members (as well as clients or other stakeholders who will see the storyboard) understand what is meant. It’s best if you and your team and/or clients agree on abbreviations like this ahead of time so there’s no confusion.

Some other formats you might want to explore

We’ve looked at the table approach in detail above, but if you’re curious about other formats, here are a few more you can check out if you like:

• The template approach includes a detailed single-page Word document template for each screen type. It describes screen elements, their attributes, and sometimes instructions to the developer. It’s a good tool when you need to enforce consistency across multiple instructional designers and developers. Many designers also use a corresponding style guide in concert with this approach. (When you download the files, the .dot files are Word templates, and the .doc files are sample documents with data already filled in, so you can see how that would look.)
• The specification approach is a format that includes wireframes of each screen, and every on-screen element is represented as a field in an input table. I’ve used this approach when I’m doing the instructional design and sequencing the screens, but my client is writing the content. It’s meant to help them visualize what they’re writing and conform to standards, word limits, prevent unhelpful creative license, and so on.

An investment with payoff

I want to finish by saying if you have one or more stakeholders to whom you answer — whether they’re internal or external — it’s infinitely helpful to gain signoff on a storyboard before you start building anything. Storyboards have, on many occasions, saved me time and money, because they make the client (and me) accountable for decisions about how the course is made.

Would you like to discuss storyboards some more? You might want to start by checking out this thread in the Articulate Community Forums where several folks (including myself) recently shared quite a few samples and thoughts on storyboarding. And also feel free to start a new thread in the forums if you have a specific question about storyboards or how to use them. Just go to one of the forums (the Articulate Presenter forum or the General Discussion forum is a good choice) and click the New Post button.