“I can’t imagine creating an eLearning course without first drafting a storyboard!”
Storyboards help me define the flow of the course, scenarios, interactions, technical and graphic details, all in a single document which I can share with the stakeholders for review and sign-off. This exercise makes me feel confident to carry on with the development of the course and invest time and effort in creating the course assets. It also gives me an assurance that I have a buy-in from the stakeholders regarding the content and flow of the course.
But, now-a-days, we are observing a shift where the eLearning designers prefer to create a rapid prototype instead of a storyboard and build their courses from there, in small incremental steps.
Hmmmm… Interesting! So is it time to say good bye to storyboards and get straight into course development… I’m really curious to know that. Here’s something which points towards discarding storyboard development step from the eLearning project life-cycle and start prototyping. Read on.
Here’s an excerpt from Michael Allen’s Guide to eLearning book: “Functional prototypes have an enormous advantage over storyboards. With functional prototypes, everyone can get a sense of the interactive nature of the application, its timing, the conditional nature of feedback and its dependency on learner input. With functional prototypes, everyone’s attention turns to the most critical aspect of the design, the interactivity, as opposed to simply reviewing content presentation and talking about whether all content points have been presented.”
A LinkedIn discussion thread: “…you may want to re-consider storyboarding all together and consider a rapid prototyping approach – where you actually build the product in progressively higher fidelity iterations until it is ready to launch. You may find that this approach saves you time and can lead to more creative final learning experiences.”
Another interesting LinkedIn discussion: “The Humble Storyboard is almost 80 years old. Is it time for its retirement?”
These excerpts clearly indicate that rapid prototypes should replace storyboards in the eLearning design process. But, can it truly replace storyboards? A rapid prototype is a sketchy form of the final course and it may or may not include the entire course content. If you completely eliminate storyboard, how do you finalize the course structure, where do you add directions for graphic design and integration, how do you define the branching and ensure that all the scenarios are covered, and most importantly, how do you collaboratively work within a team to create the course.
So, here’s a question for all of us (including me): Should we continue creating storyboards for our courses or switch to rapid prototyping? Or is there some middle path?
Chime in to let me know your thoughts…
I’m involved in a software development process. The methodology being used is SCRUM. Stories are the center of the process. The stories carry the day. So imagine this kind of story. “The agent needs to answer the phone in an effective manner.” I recognize that sounds vague, however, if someone told you to write a story, a brief story, to summarize your process – such simple statements are the result. Here’s what really happens. ‘A call comes into the queue, the call is distributed to the agent, the agent answers from their queue, the pop-up screen gives detail and locates the customer in the CRM software if the customer calls from a known set of numbers in the customer record. The agent then answers using the appropriate script, opens a case and begins working on the issue.” Sound a bit more realistic? That’s what I don’t like about SCRUM and other rapid prototyping techniques. Group speak takes over. The reason the simple story rules the day is because use silly phrases like, “simple is better”, “keep it simple, stupid”, “I like simple” is what tends to rule the day. Complexity is seen as the enemy, exacting detail is sacrificed. Frankly customers don’t have time for storyboards because they don’t want to go through the work it takes to create good products or services period. The SDLC process that embraces rapid prototyping often creates JUNK – let me repeat – J-U-N-K. A good example is Facebook – it grows like a serpent – and it’s simply awful software. But that’s a good example of software that used rapid prototyping – and our e-Learning follows this same process. I’ve tried both – i’ve used Captivate and Camtasia, I’ve rushed to get it done. You know what customers do? They poke holes in your rough e-learning as you work through it. You dump a lot of the ineffective content because it’s overkill. I’ve watched nervously as I’ve seen e-Learning go the way of rapid prototyping. I would like to KILL the rush to “get ‘er done”, get it out the door. That doesn’t create great results, not even good results and quite often creates very poor results. The shiny object has become the center of our universe. Give someone a pretty, shiny object, that sounds and looks good and they’re wowed – UNTIL they start taking a closer look – and then they’re not happy.
I have found storyboarding to be a time-suck and a duplication of effort vs. rapid prototyping. It’s an added cost in an industry (training development) that is already highly scrutinized for cost and time. I also think it’s a worthy discussion of “what is a storyboard?” Is it a fancy template where every little detail is fleshed out, or is it as simple as some quick and dirty drawings on a cocktail napkin or whiteboard?
It is no longer 1998. We have e-learning development tools that are WYSIWYG and behave like PowerPoint on steroids. In this day and age, why in the world would someone create everything in a tool like Word only to copy/paste it into a development tool? How is that adding to efficiency or effectiveness?
What I DO see value in is creating a detailed outline. I can get a client to buy in and sign off on learning objectives, instructional flow, and instructional activities/interactions (I can simply say – “let’s do a drag-and-drop here” versus storyboarding the activity out verbatim. I can sit in a room (or via WebEx) with my stakeholders and in short order come to an agreement of what the overall learning strategy, flow, and learner experience will be, then I’m trusted to go make it happen.
Finally, the days of being a “pure play” instructional designer are over – especially if you are designing e-learning titles. There simply is no reason why one can’t build their skill sets to at least know the basics of a handful of authoring tools and technological limitations of the tool(s) themselves as well as the current possibilities/limitations of technology itself (mobile – iPad vs. Android, Flash vs HTML5, etc.).
I just finished the Captivate tutorial – “Adding Interactivity to eLearning Courses with Adobe Captivate 5” and I am wondering if you have a blank template to share (or a location of where a person could download it) of the storyboard you were
using for that learning demo.
I wrote an article on storyboarding and not-storyboarding for the 24Tips site (includes a storyboard template in PPT);
http://24tips.elearningnetwork.org/2010/12/storyboard-art-science/
[…] To Storyboard or Not to Storyboard! « Rapid eLearning | Adobe … Conversations on Captivate, Presenter and eLearning. Source: blogs.adobe.com […]
I’ve been creating e-learning for the government for awhile now. Longer than I am going to admit. I have always favored the rapid-prototype over a story board because it gets the process moving and I can make changes on the fly to the end users needs. Everyone seems more impressed with the capabilities being demonstrated than a sketch of how it will work. One time my team did a storyboard and it was a long drawn out process. What normally took us three to four weeks to deliver took us three months with the storyboarding process thrown into the mix. Our processes ensured that we covered all of the paths rather than relying on the storyboard to capture it. While the cost of the project may determine whether or not a storyboard is used, I think rapid prototyping will overtake it and creators will learn how to effectively demonstrate in prototyping what once was done with storyboarding.
Storyboards work well for my creative process. I often have a ton of ideas hitting me at one time that I don’t have time to prototype. So I try to draw out storyboards to capture the ideas. I find that some times if I try to immediately prototype that I will lose my context and some of my ideas as I try to place buttons and find clipart images. If I went straight to the prototype, it would limit my creative process.
+1 :))
Start by looking at ROI. Look at the time/cost vs. Gains/Risks involve. Make a choice. I would not storyboard for an e-presentation that takes 10-30 minutes to view(probably 15 hours of development), unless there was no other way to get the customer onboard. Trying to present abstract and complex ideas and information may warrant a storyboard to insure the designer and developer understand the customers request for an expensive project. Million dollar movies warrant the investment in time and money to create a clear storyboard everyone understands before filming(illustrating). Most of the time the SME’s will have some content they need to parlay using e-learning as a medium. The technology we have now allows quick and dirty proto-type to capture and demo the desired content(concepts). I’d say it becomes a preference driven by cost/efficiency. If you see it saving time and money later on(movie industry), use it! If the cost does not yield results, lose it!
These are some very good points. I agree that the decision to go for a storyboard or not depends on multiple factors such as duration of the course, complexity, target audience, and delivery medium. But doesn’t it give more clarity of thought when we move forward with a storyboard in place. There will be less waste of time in trial and error and change in course structure/design.
I have always had a hard time writing about what I was going to write. Even way back in the late 80s (eek!), when I was working on my B.A. in Enlgish Literature, I would write the paper first, then go back and create the required outline. So, now as I am working on eLearning tutorials, I am still faced with that hard time. I am constantly thinking as I create the storyboard or write the outline, “Let me just get started on this thing!” So, now I have a name for the way I like to work — I wish I was able to go to my professors and tell them that I would prefer working on a rapid prototype instead of an outline!
I hear what you are saying Mary. This approach can work well when you are the only person working on the project. But, if a team is working then some clarity on the flow is required. How do you determine this?
It is as though the functional prototype serves as a storyboard. Depending on the tool that you use; Articulate, Captivate, other; the slides in said tool are like the slides in an storyboard. In my experience, we did not storyboard at my last job, but used functional prototypes. However, I do see the benefit of storyboarding, for the non-SME designer. With many sessions of classroom instruction, I knew the direction the material needed to go, plus I had also developed paper manuals.
Interesting! But then how do you track the changes made to the prototype by client/SME?
The problem with prototypes in the digital world is that the client fails to see the difference between prototype and product. Too many times have I seen clients say ‘Great. Can I have it next week’ thinking that what they are seeing is the almost finished thing.
[…] To Storyboard or Not to Storyboard! Conversations on Captivate, Presenter and eLearning… Source: blogs.adobe.com […]
[…] Via Scoop.it – Innovatieve eLearning… So, here’s a question for all of us (including me): Should we continue creating storyboards for our courses or switch to rapid prototyping? Or is there some middle path? …Show original […]
[…] To Storyboard or Not to Storyboard! […]
[…] To Storyboard or Not to Storyboard! […]
+1 for the story board if for no other reason than to confirm that the client and I are on the same sheet of music regarding basic content/course flow. I usually end up doing a working prototype based on the storyboard so I think there are +/- of both. The ability to produce rapid prototypes helps me reduce the amount of time/detail required for the storyboarding process, but having a basic storyboard with broad stakeholder agreement ends up saving time in development.
So we have a middle path here! 🙂
In my experience SMEs tend to not be very comfortable reviewing story boards. While the directions for graphics placement and interactions may be helpful to developers, they seem to confuse SMEs. We have used the storyboard option in Captivate to give SMEs a hard copy for their comments, but show them the rough prototype as part of the review process so they get a feel for the flow of the module.
Thanks for sharing your thoughts Doctor. So we are moving towards rapid prototype but not discarding storyboards… 🙂
IMHO it depends on the job. In rapid projects, i use relatively complex fine-concepts, sometimes in combination with flowcharts.
If the client has no or less experience with E-learning development, it is a good idea to use storyboards because on client-side it produces a better understanding of what is planned and what is going on.
Thanks Marc. Can you share more details around the rapid projects workflow… Might be helpful for our community 🙂
Please remind me after October 20th. I must finish a substantial delivery until tomorrow followed by an business trip
In most work organizations, a content draft is very important to customers. I like get agreement that via a content draft, then put a portion of the content, with the graphic interface and navigation and interaction, etc., into Captivate and publish it as a Word doc for review. Once everyone has a sense of where the project is going, then I can produce one finished file–maybe 5-10 minutes–and get another round of feedback. Then I can build the whole project. Maybe that’s a piecemeal storyboard?
Interesting workflow! I would say that it covers the best of both the worlds! 🙂
Thanks for sharing…
I still like to storyboard. I like getting everything signed off with our, less experienced, customers.
I’d also really want to take issue with Allen’s assertion that the interactivity is more important than the content! Some learning ‘could’ take place if the content was purely textual. Absolutely no learning could happen if the work consists of zero content but perfect interactions.
Thanks for sharing your views Mark. Even I feel more comfortable working on the course once the content is freezed on and then go on to create and share the user interface/interactivity with the client for approval.
If storyboard is the skeleton of the project then prototype is the working model of the complete project.A storyboard discusses the flow of the project based on which a prototype can be developed.A prototype shows the UI level implementation of the storyboard.I would prefer to have a storyboard in place before creating a prototype.
Thanks for sharing your thoughts Priya. We definitely need to have the storyboard in place before we get into prototyping or asset creation. It streamlines the course creation process considerably…
Hi Mark – fancy seeing you here! I don’t think we can compare the two in isolation. It’s important to recognise where Allen interactions are coming from; essentially they have adapted, or applied, agile software development techniques to their whole design process – rapid prototyping is an essential part of that. I’m becoming increasingly interested in how we as elearning developers can use agile techniques to improve our workflows. I think there is huge potential there.
One of the key factors in making this work is that you have to design as a team throughout the process, many of us don’t have that luxury, many of us are one man or one woman bands. But I recently worked on a project that unwittingly used elements of agile and it was a revelation.
Re: interactions and content – surely we can use interactions to present content in a more engaging and memorable way?
You must be logged in to post a comment.
