Storyboard vs. Rapid Prototype

Wow, great question!  I think the one can't go without the other. I start with creating a small storyboard to get the creative juices flowing, then turn that into a prototype. Togehter with the customer I'll work on the prototype and after that I'll need the storyboard again to keep an overview of the project. The storyboard will work more as a documentation/ reference. So, yeah, somewhere in the middle.

regards,

Richard Fransen

http://www.fn-training.nl

I always need to sketch and storyboard my initial ideas. In my opinion, storyboarding is an essential part of the design process because it is at this stage when you try your ideas more freely, encounter key questions about User Experience and User Interface and explore different alternatives until you find the best solution to present the content. If you miss this stage, you are jumping too prematurely to a final solution without exploring different possibilities that could work better at the end. So, I personally take the time to let my ideas grow by drawing the overall picture first and then, I have the chance to refine and improve those ideas when I build a functional prototype that clients can use to test interactions, information flow and so on.

Regards!

Mayra 

I would go with Rapid prototyping it works better for me.  Most clients get it straightaway and it lets them get a sense of functionality early on.

I do some sketching but normally only as part of my prototyping

I tend to get to Rapid Prototyping very quickly as well.  I get a rough idea in my head of the general structure of the course, and then I get the framework of it built out quickly.  I find my creativity really blossoms while I'm playing around in the prototype.  When I just stick to the storyboard, my creativity hits a wall.  I don't know if that's common for others, but it's definitely true for me.

I recently started using a storyboard. It really help me plan out all the content, visuals and interactions. I was able to show the customer the storyboard to make sure the content was ok. For me this was important because all the interactions are based on what the content presents. I didn't want to spend a lot of time building complex interactions (building it in flash) if the content was wrong. I think keeping a set of standard interaction you commonly use, like questions, drag and drop, click and reveal could inserted or used as examples to demonstrate to the client what the storyboard is talking about. This way you don't have to create custom interactions (unless needed) for every storyboard.

Great topic Rita-

    In some ways, my storyboard is part of my rapid prototyping. Once I have an outline, I plug that in and work with the SMEs to build out the content. If they've already given me content in a ppt deck or other format, I'll still do it this way. I do NOT want to work from inside their deck. Instead I'll use it as a reference to pull out the relevant material. (This has other benefits as well). I'll collaborate with SMEs and take many passes thru the storyboard before ever touching the development tool. So we're basically rapid prototyping the content and flow at this stage.

    I do have a section to capture design ideas and elements along the way, but the most I do with interactions is identify where they will likely add the most value. Sometimes I have an idea already of what the interaction will be but for the most part I just mark it as a potential interaction and focus on talking to the SMEs about what goes in it - not what it will look like. If they do want to talk about it, I'm going to show them an example of something existing instead of creating something.

Once I have everything that will go IN the course, I start working in the rapid development tool. My first pass (iteration) in the dev tool  is largely when I lay down the overall look and feel. When I plug in the content, media and interactions are largely just placeholders. Once I am ready to develop them, the SMEs have already signed off on the content. Then - and this isn't really part of this conversation but it's become a huge part of the "rapid" in my prototyping - I look through my library of interactions already created by Articulate and community members. I'm looking at concept only- what action is happening. Sometimes it gives me ideas, more often than not, I find one that I can use as the base of my interaction. I convert it to my layout/design aesthetic, switch out images, customize as needed, but frequently the majority (if not ALL) of the interaction build has already been done.  

All that being said, I'd say I tweak my process every single project. I'm looking forward to reading more ideas from all of you!

Like Phil we go straight to the prototyping. We used to develop storyboards in PPT. Then we started converting those PPTs into Articulate so that we could upload them to our online review tool and send invites to the SMEs. Finally it occurred to us to skip the PPTs altogether.

Often the first cycle is just a rough outline with placeholders for images, animations, interactions, etc. Then as me make changes we can just upload new files to create new review cycles. 

That was pretty much my "personal development cycle" too.

From conversations, a lot of people seem to be very unwilling to do this on premises with client - and I can never figure out why. It is (usually) an enlightening experience for them, and a breathe of fresh air for both parties. OK - so you need to be able to "busk", and certainly need to be able to fly Storyline, but so long as you know the capabilities, you can insert a placeholder even if you do not know the exact/precise way to achieve something.

I'd urge more people to give this a go - it's a lot of fun.

Bruce

Wow! What a great thread.

We've been looking at this for quite a while. We use wireframes, prototyping and storyboards. The approach that we use does depend on the software that we are using - we use a range of tools in addition to the Articulate Family....but we move to fast prototyping as soon as we can.

We are moving more and more to rapid prototyping. We've lost/wasted/spent a lot of time changing and reviewing scripts/storyboards with clients that have changed again when we have gone 'interactive'. I find we get much better feedback when we are in the interactive stage and the process is much quicker.

We spend out time defining the spec and then as soon as we can build a prototype.

Minimum Viable Product

Lots of our team have worked in games and apps as well as elearning. We all like the MVP model for development. It is well worth a look

Rita:

I used to storyboard quite a bit, but am moving toward prototypes. Basically it hit me one day the clients generally dig my designs and so why not just show them what I'm planning to do. Prototypes also help them give a feel for the voiceover (I do most of my own VO).

Do clients generally like most of the stuff in your storyboards? If so, why not prototype the next few projects and see where it goes. If nothing else, it's something new.

Bruce, James, Phil and any others using this method- by going straight to prototyping, are you essentially using the dev tool (Storyline etc) for your storyboard and then building out from there? Is it just a matter of semantics? Begin prototyping the course while developing content in the dev tool to cut out the rework that can come with storyboarding?  Do you compile SME content separately and then input into the prototype? 

I've stripped my storyboarding process down to simple excel tables to help SMEs organize their thoughts into clear steps and as a quick way to capture content in a format that is easily accessible. I want to avoid getting trapped in a cycle of spending too much time storyboarding, which sounds like a concern others have as well. That's how I compile my content before prototyping. Is the difference just that I still call that storyboarding?

I'm not trying to play devils advocate of any kind. I'm genuinely interested in how you manage content dev when you go straight to prototyping. With ever-shrinking timelines, I'm looking forward to hearing more about your process!

I go to a site for the first content meeting, get out the PC, link to the projector and tell them we are not really going to "talk", but build.

I ask them to trust me, and we start.

They get an appreciation of what I can do, and how, and a respect for the fact that I can be an "expert professional" like they are. In my experience you absolutely need to be prepared to counter the "detail goblins".

This is where the business conversations come in, (my hobbyhorse as you know...), and you continually back it up with various ID ideas (based on ID theory and the capabilities of Storyline etc.)

It also gives me a better chance (IMHO) of stopping them go off on a tangent and into too much detail, as I can continually say "...Great - however that's a bit off track, let's focus on the objectives and not "bury the lead" here".

Not sure what it is called anymore, I just build stuff as often as I can, then have a "refine-design" stage before I send them a QA link and do the next cycle of the spiral.

Does that help?

Bruce

Hi everyone,

Thanks so much for all your input! It's really refreshing to hear your ideas and approaches

I have to say that I am quite a fan of rapid prototyping, because like Phil said "Most clients get it straightaway and it lets them get a sense of functionality early on.", but somewhere along the way I still need my storyboard...

This is where I can really relate to what Natalia said -  "In some ways, my storyboard is part of my rapid prototyping.". I tend to think more and more like that.

I usual try to avoid making a storyboard with all the ingredients - music plays after three seconds; image goes here; fade in-fade out; describing the interaction - that doesn't help me in the development process, it tends to waste more time that save it, and it can really be more confusing for the client.

However, when it comes to define content and script (and review it with SME's); and especially branching, I really need to storyboard. It helps me to keep track of the course's flow, and to think ahead before moving on to development. 

How do you handle this in rapid prototyping / storyboards?

Thanks once again :)

Rita.

Hi Natalia,

Thank you for putting it so clearly.

That is one of my main questions as well - how is content handled when going right into rapid prototyping?

I had a project when I got right into rapid prototyping, which worked well for the client to get a feeling of how learning experiences where going to be developed. But it's difficult for me to move on to development without storyboarding the content, because I'm taking the risk of having screens changed due to content flow.

I believe we can storyboard directly in the dev tool, where we can make a draft of the interactions instead of describing them in a ppt or word doc (maybe in this situation it is really more of a semantics issue!!).

However, this approach does not help me to get an overview of content flow, and branching. This is why I tend to mix both approaches - storyboarding to lay out and define content, and rapid prototyping to show learning experiences to the client.

Does it make sense?

Muy interesante Bruce. I'd love to see you in action. 

Interesting discussion.

I use rapid prototyping for how-to and step-by-step training.

In case of scenario development, I create storyboards.

What kind of documentation do you use when doing prototype development. I've also found that doing a prototype even if I just put placholdersin for potential spots for quizzes, interactions, movies, etc. but we are REQUIRED to submit a storyboard of the finished product (not the design idea) that "documents everything another developer would need to revise the product a year or two later and you're not around'.  I think mayb we're using the storyboard the wrong the way. Can you use a storyboard to capture the details of the prototype?

Seems that you are being asked to provide a "Developer's Manual" rather than a storyboard.

The thing is, so long as everything is labelled clearly and sensibly with Storyline, if a Developer were to pick up any piece of work, it is, (in most cases...), pretty obvious as to what is happening.

Bruce

Hi Rebecca,

Storyboard is more commonly used to plan the course, by I believe it can be a good tool to document the finished product as well.

There are hundreds of storyboard templates, so it basically depends on what information do you need. With a storyboard you can detail information for each screen on audio/sound effects, transitions, navigation, on-screen text, script, tone of voice, insert a link for the used media files, etc.

I believe it won't be a good help for detailing branches, but a good mapping of the course's screens will help.

Rita.

Just read through this whole thread, and I found it really interesting how the word "storyboard" seems to means different things to different people! 

Several people described a kind of hybrid approach, with a somewhat bare-bones "storyboard" for content and prototyping for functionality and design.  That's the way I end up doing most of my projects, although sometimes I don't even need a real prototype - if the design is already set (e.g., if the client has a template i have to use), I can show samples of other work to give a sense of functionality.  For Storyline projects, I do the storyboard in Storyline, so the storyboard, prototype and final course are really just iterations of the same thing.  For me, that initial storyboard (or first iteration) is really all about content; I want to make sure the content is correct, flows right, is focused correctly according to the desired behavior change, etc. before I start building it out.  When this process works well, I get very few edits on the fully-functional course, because we worked all that out with the storyboard.

I agree.  I think it also helps a lot to be consistent about the way you organize all your assets and media.  If the concern is, "How will another developer know where the audio file for slide 3 is if you're gone," I think you can alleviate that by having the whole team be consistent in how you name and file everything.

In another thread people were talking about creating a readme.txt for each course, maybe that would also help meet this need?

http://community.articulate.com/forums/t/21492.aspx

@Sheila - must try and understand this "...whole team..." concept

Bruce

PS - must also try and understand why/how my text went REALLY huge there!

It depends on the skills you have - if you can prototype rapidly then why storyboard !

I think it also depends on personal style and preferences. Whilst I have no problems with the "storyboard" principle, (which for me means pre-written text, explanations of graphics and interactions etc.), I thoroughly enjoy the challenge of at-site rapid-prototyping.

For me, it is a highly "theatrical" performance, not just "eLearning", but also employing visualisation, Q&A, and facilitation - which I find to be an exhilarating as well as very effective way to work.

Bruce