Rapid prototype vs storyboard?

No Problem

Traditionally elearning courses have been storyboarded so the instructional designer can plan the content and activities and get feedback before starting to build the course. Storyboarding allows you to check your design is on target with expectations before investing time in developing.

However, sometimes it makes even more sense to rapid prototype rather than storyboard. Rapid prototyping is where all or some parts of an elearning course or activity are roughly built i.e. it’s a working model that’s not in the finished polished state. Rapid prototyping shows what you intend to do – whereas storyboarding tells what you intend to do.

So when does it make more sense to rapid prototype rather than storyboard. Put simply – when it is more useful to show how it works rather than tell how it will work. Here are some situations when I choose to rapid prototype rather than storyboard:

Working with SMEs or clients new to elearning

If I’m working with clients that have little or no prior experience of elearning I will prototype parts of elearning interactions (or show them a similar elearning interaction) so they can see exactly what a drag and drop, system demo, contextual feedback, or a branching scenario looks like.

When look and feel is important

Look and feel is always important but sometimes you might need to show rather than tell look and feel. This could be an advantage when a client’s preferences are to see how it works. It could also be wise to prototype part of a course if you are investing a lot of time and energy into the look and feel of a theme, or if you’re a developing a series of modules that will all have the same look and feel. Better to have solid agreement at the beginning rather than developing 10 modules, only for the client to ask you to change the look and feel afterwards!

When rapid prototyping will save or not add any more time

Sometimes I’ve actually found it quicker to skip the storyboard stage altogether and go straight into rapid prototyping an elearning interaction. For example, I usually go straight to prototyping for software simulations. I do this as I find it more useful/quicker/easier to get feedback from a prototype (working model) than from a storyboard presented on paper. Even though it may take slightly longer to rapid prototype it saves me time as it’s part drafted in the tool already and it results in a clearer vision of what the final product will be.

For a complicated interaction

If the interaction is complicated it can be useful to roughly prototype and get feedback from stakeholders before investing the extra time in perfecting the interaction and graphics. It’s also useful when it’s difficult to explain a type of interaction. For example, I’m currently prototyping an interaction in Articulate Storyline where the learner will receive individualised feedback based on their previous choices. It’s hard to explain what I’m doing in text, but I’ll show you the rapid prototype once I’m done – push the follow button to subscribe and get notified of when this is ready for you to view.

What do you think about rapid prototyping? Are there times when you choose to rapid prototype rather than storyboard? I’d love to hear your thoughts – follow me to hear more of mine.

6 thoughts on “Rapid prototype vs storyboard?

  1. Pingback: Rapid prototype vs storyboard? — e-Learning Feeds

  2. I wrote about this same topic awhile back: http://ashleychiasson.com/blog/terminology-tuesday-storyboarding-and-rapid-prototyping/

    Rapid prototyping definitely has its benefits, namely when it comes to reducing cost/enhancing efficiency. However, I do find that it may backfire on you if the content hasn’t been adequately verified prior to development. It’s a lot easier to modify a word document than it is to modify a .story, republishing, uploading and so on.

    Like

  3. Hi Ashley thanks for reading and commenting, you have a great post on this.

    I agree it would be a shame to do a large prototype on content that wasn’t verified. I use both storyboards and prototypes (sometimes blending both approaches) to check (or source) content as well. I also get performance and learning objectives signed off in a scoping document before commencing content design – to check I have understood what the target is.

    I prefer to storyboard directly in the tool i.e. Captivate or Storyline and don’t find the extra push of a button publishing it to Word any more difficult than storyboarding directly in Word or PowerPoint. This often saves me development time later on… I think the storyboard tool is often down to the designer’s personal preference.

    Love your terminology tuesday posts – what a great idea!

    Like

  4. I have recently started to go straight to a rapid protyping (or wireframe as I call it) after getting approval on the key concepts in a Course Content Map document. I review the concepts and content with the SMEs first then review the prototype with my manager (as a sort of peer review) who is also a learning professional. This works pretty well so far and saves a ton of time.Plus I have really struggled with translating a paper storyboard to my Storyline project. It seems so tedious to write it all down in a Word doc when I can just build it out in Storyline.

    Liked by 1 person

  5. I do software simulations. I only have one shot to get buy in/approval from stakeholders, who are also my SMES. Can a prototype have content? I need to have the content verified and I only get one chance — when they review the prototype.

    Like

  6. Pingback: Reflecting 2015 and learning 2016 | Making a difference

What are your thoughts?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s