Does storyboarding save or add time to the process?

I can relate with Alyssa Gomez as my firm don't use storyboard either. And since I have never worked on them, I don't feel the need to. Although I totally agree with you Nicole. Can't build a house without a blueprint and I am sure it saves lot of time. Sometimes I start with a rough patch on SL itself and iterate as I proceed.

hello!

Great thread btw.

I agree about the importance of creating a storyboard before jumping to the developing part, my great difficulty about the storyboarding is the visual part, i need the try out different things (graphics, interactions) in storyline and having to jump between the storyboard and storyline sometimes is a nightmare to me.

So in the meantime my practice is to do both on storyline.

One thing that's so true: is the fact that if you do not use a storyboard, there are many information that can get lost.

I tend not to use storyboards, I much prefer to start building with the content.  That doesn't mean my courses lack a structure or underpinnings.  

I would first import the content and lay it out in a structured fashion on the slides, generally the slide design has already been decided at this stage as I build a 5-6 slide template to show the client how the course could look.

Once the structure is in place I go back to the slides and build the containers for the content.

I find this method quicker and easier, it is much easier for the client to see how their content will look and function and saves time and money at the clients end.

On the times I have used storyboards i have found that content will not fit on the slide when you start to build,

One nightmare story i had when a company provided me with storyboards developed by instructional  designers.  I followed these storyboards closely and delivered what I thought was a product close to the storyboard, only to be told that although signed off by the client they expect the finished product to be different from the storyboard.

yeah i agree with you Phil, the stakeholders and the client can have the real experience if we show them the content displayed on the slides.

I prefer to work without a Storyboard but I often have to create them or use ones provided by others depending on client requirements. I find them time consuming to create and even though the client reviews them and signs off they still require changes once they see the constructed output.

Yes. Storyboarding and Prototyping do take up more time, but it's really a question of 'how much time do you want to spend making revisions?' - I've worked on many different projects of varying budgets, and I can honestly say that sure; rapid development is great, but you will spend more time in the long run making revisions. 

Storyboarding allows you to create the blueprint, as Nicole pointed out. Storyboards streamline your development process because you know what's going to happen on each screen, and what all of the elements are.

Prototyping is great for most projects, but I prefer to do it particularly with larger projects, because I want client sign-off before I spend months slogging away at all of the content. This also saves your but because once signed-off on, you can bill for any changes they decide to make months later that impact overall look and feel. 

So to answer your question, yes storyboard adds upfront time to the process, but the return on investment is that it often saves you time in the revision process.

I think that storyboards are a good idea... in theory. They should be a time saver, because like Nicole pointed out, it is easier to make edits during the storyboard phase. However, in my experience stakeholders (especially if they haven't had a lot of experience working on e-learning projects) are often unable to visualize what the final product will look like, so even if they sign off on things in the storyboard phase, they end up wanting to make edits later on anyway.

Because of this, I tend to prefer a hybrid storyboard-prototype model, so that stakeholders can see the content and the functionality all at once. While sometimes it can be frustrating to have to make a lot of edits, I don't necessarily think it ends up taking me longer in the end since I get the feedback I'm looking for earlier in the process.

Wow. Great discussion thread! I find both storyboarding and prototyping to be more about value, rather than simply time spent or saved. I think it's important to stay flexible in your design approach based on the needs of the audience and the stakeholder's timeline and budget. Is the subject matter high visibility and/or high risk to the organization? Is it something new or highly customized? If so that's probably a good time to press for a more formalized storyboarding/prototyping approach. However if you're creating something that's a little lower profile or that's using a standard UI, going straight from a content outline into a prototyping mode seems more efficient. In both cases the value comes from the design thinking that underpins the process. 

Simple answer....

• If someone besides you needs to approve the course - YES
• If you have final say over both content and format - NO

More complex answer....

Consider splitting the different and don't do a traditional "story board" at all. Instead use a simple content-based  table format that allows you (and stakeholders) to quickly re-work content and sequencing by cutting and pasting. Be sure to include a column that gives a broad hint on how that particular content might be presented (ie drag and drop, read, video, etc).  Uber fast, easy to change, easy to get approvals/buy in, easy to see sequencing and saves actual development time too.

"Do you feel that storyboarding adds time, or saves time, overall?"

That's a loaded question! It really depends on so many factors. In general, the storyboard feels restrictive to me and while I recognize the ideal of having everything defined before development, in practice it never seems to work out that way. Creativity is not a linear process for me, but iterative.

For me, most of the time a storyboard doesn't save time, but don't think it adds time either. However, the value of it is questionable. My clients get more value out of understanding the types of interactivity, Until we get to that stage, the storyboard is conceptual or theoretical. I'd rather spend the hours developing a prototype.

If you are looking for efficiencies in your process, you may want do some post-mortem analysis with your team:

• Where did you spend most of your time on past projects?
• What would have helped to speed things up?
• Where did things break down - was it with SME? Client? (they are different people) your own team?

You may discover that you can educate your organization about process and roles and see some improvement. 

Hope that helps!

Holly

I can see the pros and cons of each and it comes down to what works best with the environment you work in, and the needs of the people involve.

If you have multiple people working on a course or series of courses I find working to a storyboard invaluable as you can quickly make edits and divide the work up between people.

If you are the sole person creating the course then I find using an agile methodology works best. Mock up a prototype run it by stakeholders build some more run it through revision etc. Personally I find this works wonders as the SMEs and stakeholders always seem to offer ideas that build on what is being created and things that may have been missed and the courses come together in a very organic way.

A rose by any other name - The truth is that you actually are storyboarding/prototyping, although not in the traditional sense. i.e. not in a separate document. The purpose of a storyboard or prototype is to organize thoughts and content. To allow the stakeholders to review and make changes before final production. It doesn't have to be a separate process or in a separate application.  It sounds like that's exactly what you are doing, you're just doing it in your development tool. Now, if you were just barfing out content with no reviews etc and calling it done, then yes, you certainly would be skipping an invaluable part of the SB or prototype process.

We DO create storyboards. We use powerpoint when ID's or Clients don't have access to Storyline, we design the final look and feel prior to starting, we get the script written (in the notes field), layout objects on screen, add development instructions etc. But our process involves quite a few people, so we are looking to get the storyboard as complete as possible before development starts. 

Depends on the complexity of the course.

Very old school here, but the real must have are objectives (what the participant is supposed to be able to do at the end of the course) and content outline (two- to three-level outline of the content). There's where you need to get stakeholder approval.

Adds time to the development process with additional reviews and revisions.

We have to have a full legal review of our proposed courses conducted before we move into development (don't ask....), therefore, we typically storyboard in PPT and write our scripts in Word (I generally do both at the same time, and use linked and embedded slides in my script to make reviewing and editing easier.

Once the script is approved, it's very easy to import the edited PPT deck into Storyboard.

Not the most elegant, but I find I can create some pretty sophisticated PPT decks that act very much like the finished Storyline course will (once I start adding all the fun stuff).

I agree. Especially if you're storyboarding in PPT, it's a lot easier to move your content around before you bring it in to Storyline (we still work with Storyline 1, so I don't know if Storyline 2 addressed any of the issues that led us to keep our storyboarding in PPT).

I prefer not to create a traditional storyboard. I prepare a script in Word that gets approved by the SMEs, and I've started putting together 4-5 concept slides in PowerPoint of some of the content/activity ideas. I send both docs to the SMEs at the same time to review so they have an idea of what the course could look like, and provide input. That has seemed to help the SMEs visualize and realize the type of capabilities Storyline has to offer. This way, if they totally hate my ideas as far as the activities and look, I haven't burned that much time.

In my experience, it doesn't matter how many times it's been "signed off" on, there are always changes at the end. I've done storyboards in the past, and it just seems easier for me personally NOT to do them. Maybe that "cute gorilla eating a banana" picture I wanted when I developed the storyboard seemed like an awesome idea at the time, but I just couldn't find the one I was looking for when I went to develop and now my slide is just going to have to have a banana instead. :( lol

I receive a Word document that is as "story-boarded" as it can get. There are graphics embedded in a horizontally-oriented table in the second column and the narration (with direction) in the first column.

I get the feeling that not everyone uses the same kind of storyboarding technique.

What is your storyboarding tool if you storyboard?

As far as it being a waste of time, I would say it can be if there are more than one author or more than one final authority. I made sure to avoid situations where an author gives me directions knowing that the final authority (editor/manager) may not agree. I have them work it out and send me one set of changes.

Some great discussion here, I recently was asked as a trainer in our organisation if I could put together a quick online program that would induct staff onto our work site. I created a prototype in Storyline and demonstrated it to them. However each time I demonstrate the prototype they ask for something more, either content that they want added or capability as they saw what Storyline could create.

So two approaches are evident here. Had I created a storyboard all the additional content would have been scoped and included once the build commenced, however this would have lengthened the process, but ensured it was covering all areas.

By developing a prototype I was able to demonstrate capability which also changed their understanding of what or how the induction could be delivered. For example including java script to extract and print information.  

So I think both have there place, storyboards allow the content to be reviewed and decided on before a build. If time permits should always be used. Prototypes demonstrate functionality so that end user can see what it is capable of. 

Peter: you're talking about what I, as an outside consultant, used to love, but as an internal resource despise: scope creep.

In either role, I like to create a design document that lays out exactly what will be covered: what the objectives are, how they'll be addressed in what I'm developing, and just how long everything will take.

I fit design documents into my process after I conduct any research about the topic but before any storyboarding or scripting. I don't proceed until the client signs off on the design document.

As an outside consultant, this is great because scope creep almost always entails submitting a change of scope document (in other words, "Sure, we'd love to make these changes for you. We estimate it'll take this much time and will cost this much to include what you want."). That provides my customers with an opportunity to decide if they really wanted to add all that new stuff. If they do, I'm getting paid for it. If they don't, the project can move on as originally planned.

As an internal resource, I don't have nearly as much leverage I find other than telling my customers that it will push out their deliverable date. I find I can't wield that tool nearly as effectively as I could if I were to tell my customers how much it will cost.

I like working with storyboards and outlines, but they seem to only serve me.  Nobody else appreciates the time-savings that come wih pre-planning.

Such valuable discussion! I like Bob's response. I don't use storyboards just to use them, however I do use them to have my SMEs approve my audio script and basic content approach. Because my screen content is driven by the audio narration, I ask them to concentrate their focus on and approve the scripting. I have had the painful experience of buidling a course without one and then having to rework it because there was a disconnect between the SME and me. In that way, I find them a time-saving tool, and my SMEs are part of the development process, which IMHO increases productivity and satisfaction overall.

:-)

Definitely-good insight! Yes, I too get the script finalized first-especially when narration is involved.

Well this is a question that keeps me up at night.  For me it depends on the shape and format of content provided by client.  If they already have all content in a word doc table, I will review it, make suggestions, add assessment questions, and scenarios / feedback.  Then get it signed off.  Then develop prototype of say topic 1.  Sign off.  Then build to completion.  If they want something out of scope I am likely to just throw it in as a good will gesture because the time I spend estimating and reworking the scope document, I might as well spread the love and just make the changes.