E-Learning: Storyboard vs. Prototype
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!
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.
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.
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.
- 11 Best Practices for E-Learning Storyboarding
- Storyboard Like a Pro with Storyline 360 and Review 360
- What Information Do You Include in Your Storyboards?
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.
You are so right Troy. We follow exactly the same process as you for every development job that we undertake. One of the biggest problems with elearning is that most client don't know what they want until they see it, so we develop the prototype at the quote stage. We go tot the effort of building a 5 slide concept with client logos and branding. From a sales perspective this works very well as they feel like the course is already theirs. It does take a bit of effort, but we secure 95% of the quotes we put out because of this effort. Not only that but when you 'win' the job it is very easy for my designers to jump into the project and know form the outset what is expected of them. Funnily enough we don't 'storyboard' at all anymore (we have been in the development business for 10 years). W... Expand
I'm a 1-person development team (but I work with our Marketing Team), so I probably do things differently than some. I actually develop backwards according to traditional methods - I create an "Instructional Design Model", then sort of translate that into a first-round prototype. Then it's incredibly simple to screenshot all my placeholder objects/text/graphics, and copy and paste text to create a storyboard in Google Presentations (this makes it accessible for different stakeholders to edit text directly or comment on graphics/anything else in the modules). This also makes it easy to step between design and development, so if it turns out there's an easier/faster/better way to do something, I just modify the prototype directly and demo for any stakeholders. Rounds 1 & 2 typically re... Expand
Hi Alyssa Whether it saves time probably depends a bit on whether you're building something for someone for the first time, or whether it's part of an ongoing relationship with the commissioners of the work. I.e. you get a good feel for each other's expectations as the relationship matures. The size of the piece of work might also sway me as to whether a storyboard or prototype was going to be more useful. Generally I'd prototype for commissioner agreement on wider functionality (e.g. look and feel/navigational metaphor, particularly on early projects with the commissioner) or to win the commissioners' hearts, then storyboard for the content in a format that the SMEs can easily amend or comment on right there in the storyboard. If there was a particularly complex screen, i.e. one wit... Expand
Very interesting discussion we have here. Well, throughout my 18 years of developing e-learning content, I should say that 90% of the time, we would go through the Storyboarding process. Why? 1. Like Nicole said, "the storyboard is essentially the blueprint for the course being developed. The storyboard lays out the visuals, multimedia, text, audio elements, interactivities, and navigation details of each and every slide in your course. Throughout my experience, even though with the Storyboarding process in place, there will tend to be changes, and changes made by Subject Matter Experts every now and then. So, the Storyboards help us in the "versioning" process and to keep track of the "performance of the Subject Matter Experts" (SME)s. In my e-learning exposure, we dealt with tremen... Expand
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... Expand
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 s... Expand
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 Stakehold... Expand
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 represen... Expand
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 ... Expand