Blog Post

Articles
3 MIN READ

E-Learning: Storyboard vs. Prototype

CommunityTeam's avatar
10 years ago

If you’re new to e-learning, you may have heard people throw around terms like storyboard and prototype without daring to ask the question: What’s the difference? Well, don’t worry, we’ve got you covered! In this article, we’ll walk through the definitions of both as well as some advantages and disadvantages of using one over the other. Let’s get to it!

E-Learning Storyboard

A storyboard can act as a blueprint for developing custom, interactive e-learning in apps like Storyline 3/360. Using a storyboard helps you lay out the visuals, multimedia, text, audio elements, interactions, and navigation details (where does the learner go next?) of each and every slide in your course.

By viewing the storyboard, the stakeholders should be able to understand what learners will see, hear, and do during the course. 

Often, storyboards are created with Microsoft Word or PowerPoint. While this makes it easy to share the course content and design with stakeholders, the drawback is that it can be harder for them to imagine what that experience will be like. For people who have never been part of an e-learning project team before, storyboards can feel a little abstract. However, the more experience stakeholders have with e-learning, the easier it is for them to look at one and imagine what the finished course will be like. 

Advantages

  • Helpful way to get stakeholder buy-in.
  • Quick and easy to create and edit.
  • Puts focus on the content itself instead of functionality and layouts.

 

E-Learning Prototype

We like to think of a prototype as a halfway point between a storyboard and the final version of a course. Like a storyboard, it lays out all the course content. And like a finished course, it’s clickable, so stakeholders can interact with it. That way, instead of having to imagine what that experience will be like, they can actually click through for themselves and get a feel for the flow of the course.

Sometimes, prototypes include branding elements—like the customer logo, colors, and fonts—which allows the stakeholders to approve their usage. However, unlike a finished course, prototypes usually contain only mockups of graphics, and not the final versions. They also don’t include the final version of the voiceover audio. In fact, sometimes they don’t include any audio at all—just the script that’ll be used to record it later on. Other times, designers will include text-to-speech audio to allow stakeholders to hear for themselves what the audio script sounds like when read aloud. That way, if stakeholders notice anything that sounds awkward, they can request changes before the audio is recorded.

Advantages

  • Often easier for stakeholders to understand.
  • Gives stakeholders a preview of what the entire course experience will be like.
  • Saves the designer time by getting approval before developing the final course.

 

More Resources

Some e-learning designers swear by storyboards, claiming it’s an essential step in the course creation process. Others skip straight to prototyping, saying it’ll save them time in the long run by helping stakeholders better understand what the final course will look like. In the end, there’s no right or wrong answer here, it’s all about personal preference.

Looking for more storyboarding and prototyping tips? Check out these helpful resources.

Articles

Downloads

Based on the definitions of storyboard and prototype above, what do you think are the pros and cons of each? Do you always create a storyboard, or do you prefer to skip straight to prototyping? Leave us your thoughts in the comments!

Follow us on Twitter and come back to E-Learning Heroes regularly for more helpful advice on everything related to e-learning.

Published 10 years ago
Version 1.0
  • I think I do a "pared down" version of a storyboard based on what I've read in the discussion so far. I have two columns in my storyboard (in Word). The first column is content. I put all the written content for a course (audio and written text) into this column. This is what I focus on with the SMEs. I actually don't start developing in Storyline until I get sign-off from the SMEs on this column in the document, which I call a storyboard. I explain to my SMEs that I need a relatively finalized version in order to develop most efficiently (e.g. if I develop with 3 bullet points...and then the SME adds a fourth...I may have to redesign the slide entirely). I find that SMEs don't really care about the final navigation, as long as it flows...which I typically show in an iterative cycle (usually a few slides for the first meeting, and then a couple more times throughout the process to make sure I don't go too far without buy-in). As I go through development, I take a screenshots of my content and put them in the second column in my storyboard called "graphics." If there are multiple layers, I typically just put in one as a sample. Since my SMEs don't have access to Storyline, I find this "Storyboard" document a great way to get feedback. I typically ask my SME to use "track changes" for any content changes and comments for any feedback on graphics. It has worked great for me!
    • NicoleLegault1's avatar
      NicoleLegault1
      Community Member
      Thanks for sharing your process, Jennifer! I like your approach of starting with just straight up text and information... then moving along to graphcis... and then adding the comments directly into the document. Nice. Sounds like it's working well for you, and that's the key.
  • Like many of the others that have responded to this thread, I tend to want to storyboard right in the tool and get started with the big picture. It helps me to build a screen when I find just the right image or graphic that expresses the thought or concept I'm trying to portray on the screen. This normally helps with my process to produce a narration and on screen text or interaction. The problem with skipping the storyboarding phase is that you can get caught in the trap of entering into "the zone." "The Zone" is where you put effort into putting something together like editing the graphic, maybe adding animations, or interactions because you are in the tool and you think, "this is just what I want." However you forget that the storyboard is supposed to be building and end product which should be what your customer wants and gives them a chance to read/interpret how you've understood their content and what you think may be the best way to present the information. The trick is finding a storyboarding format that gives the reviewer enough information to really know what the screen will look like and how it will act, that contains all the elements that your team may need to be able to produce all the different pieces after the storyboard is approved, and that can accept comments in a logical way that whoever is responsible to make edits can go back and do them as quickly and easily as possible.

    I do like the idea of a prototype for look and feel for anyone reviewing a storyboard. A small portion of any course should be functional so that when something is described in the storyboard the reviewer has a visual image as a reference point.
    • NicoleLegault1's avatar
      NicoleLegault1
      Community Member
      Great points Danelle, thanks so much for sharing them here. I think the key is that its impossible to really determine one storyboard style that will work for all, or one prototype style that will work for every project. It all depends on the players involved and the variables that are specific to that project ... in my opinion :)
  • RobAnderson1's avatar
    RobAnderson1
    Community Member
    Prototype, test, refine and get in the hands of the learners... You should always go into life assuming nothing will ever be 100%... better to test and learn... or test, fail and learn... Some of my best stuff has come from an early prototype...
    • NicoleLegault1's avatar
      NicoleLegault1
      Community Member
      I must say, I like your approach to testing Rob, and I agree. You just never know how it will look and behave in the final environment so testing is CRITICAL!
  • JuanPrimo's avatar
    JuanPrimo
    Community Member
    I came up with a mashup between the two that has worked really well for me. It allows me to include some functionality when necessary, and also generates really cool storyboards that I can customize for the clients to see.

    I posted this in a previous thread, including the instructions on how to do it.

    Here is the link to this mind hack: https://community.articulate.com/discussions/building-better-courses/using-storyline-to-storyboard-projects?page=2#reply-31259
  • TerryCoe's avatar
    TerryCoe
    Community Member
    This is a great article that explains the difference and usefulness of both the storyboard and the prototype. However I use a third method when developing my story.

    1) I get my general story approved. This isn't a 'word for word' script, more a general idea of the main topics.

    2) I get into a developing frenzy. Using Storyline I develop as much of the course and script and lines as I can, using the main topics of the general story. I make sure to develop everything except sound to make the course come alive to the stakeholders.

    3) I then print to Word to present to my Stakeholders as a storyboard. Now they can edit everything that is included in the course with one swoop. I have always felt that getting feedback about individual items could become cumbersome to SME's and Stakeholders.

    At least using this method, it is really easy to edit the stylistic choices of the course and drive home the reality of the course.
    • PeteBrown1's avatar
      PeteBrown1
      Community Member
      I agree with your point 1, Terry. Depending on the circumstance (e.g. how comfortable I am with the client or content), I'll make a flowchart, with each node of the flowchart representing a screen.On each node I'll just have a title (will probably become the screen title), and a sentence or two describing, in the broadest sense, what would be covered on that screen - not how it will be represented or how it will look, but the concept(s) to be addressed. I'll usually do this flowchart in Powerpoint or Visio and, for example, a 30-minute module might have around 20 nodes describing the flow.

      This high-level flowchart can usually be put together very quickly (in a few hours) and is a useful tool/step that:
      1. Helps get agreement that all of the material that has to be covered is represented.
      2. Helps crystalise how the navigation and chunking will hang together/flow.
      3. Gives me confidence that the next stage (maybe prototype, maybe storyboard, maybe direct build) won't be too far off-piste.
  • ChrisPurvis's avatar
    ChrisPurvis
    Community Member
    Hi Nicole,

    Wow, its been over a year already when I looked and commented on this article. I thought I'd give an update on Prototyping vs Storyboarding based on my experience. I have been using the Prototyping method more and more and hardly use the traditional way of Storyboarding anymore. Reason being that using the new SAM model vs ADDIE Model this works a treat. This gets the SME's and Stockholders involved with the actual concept on interaction, animation and learning paths within the course and find that our development time reduces quite significantly.

    Hope this helps and happy with innervation and change of e-Learning!
  • AlandaPettit's avatar
    AlandaPettit
    Community Member
    For me it all depends on the internal client. What works for one does not for another. I tend to start in Storyline so that I am not duplicating my effort. In one project, I worked in an iterative process. I met with the SME and we reviewed the overall concept. As I began to build out the course, he wanted it in a Word document. No problem. I used Storyline's Word output. I dropped in comments to clarity aspects that do not come across in a one dimensional way.

    For another client, we met and discussed the content--in pieces because it was very complex. I figured out the type of interactions that would work and met again. I shared my screen with him and we reviewed what I created and then next I sent him a link via tempshare so he could play around.

    This went on until we covered all the bases of what was needed.

    Still another client needed a storyboard with all the audio written and potential images to use. I created a storyboard in Word before I opened Storyline.

    So that is my 10 cents!
  • This is a great article and some great views on prototypes and storyboards. I like to create a functional prototype more like a proof of concept, to get an approval on the design, interactivities and other effects like the audio treatment, animation and navigation. This can then be used as a guideline to be followed as far as the design part is concerned. I have always been a storyboard kind of a person, since it allows you to describe the multiple treatments for a scene like the animation, graphics, voiceover script and on screen text. This makes development easier if there is a team of developers. I believe it standardizes the development process to ensure consistency in design.

    I think if a team isn't involved, prototyping can be a better way.
  • AlisaRasputna's avatar
    AlisaRasputna
    Community Member
    Hi Nicole,

    Thank you for this article. I still try to figure this out, which I believe most people who reads this article try to do as well. What would really be useful is couple examples, which we can look through to fully understand and appreciate the differences.
    Any chance you can add it?

    I am sure, all the readers (especially the visual type) would really appreciate that :)