"Storyboarding" in Storyline?

Apr 15, 2014

I've read people and posts talking about "storyboarding in Storyline," and I'm trying to get a better sense of exactly what that means.

We've developed a few courses in Storyline so far, but these were all storyboarded in Word and copy/pasted into Storyline.  Can someone describe what their Storyline storyboard consists of, or looks like, or even better share an example of even a page or two?

What with all the possible objects and trigger-based actions you can have on a single slide, I'm having a tough time envisioning something that represents a screen to a client reviewer without me having to pretty-much build/program it.

Any thoughts/wisdom/experience on this would be much appreciated.

24 Replies
Ashley Chiasson

I'm definitely interested in an example of this. 

I'm thinking those who storyboard in Storyline are essentially creating a visual storyboard. I prefer to storyboard in Word; however, I have used PowerPoint to create visual storyboards when the client requests I do so. I assume the Storyline storyboards would be familiar to those done in PowerPoint, but an example would be great!

Nicole Legault

Hey Bob!

That is a a good question and a really interesting topic... I feel like I could say so much!!! I'll try to keep it brief  I've created Storyboards in Powerpoint, Word and Storyline in the past. I think we can all agree there is no "one right way" to storyboard. Every project will have different requirements of the storyboard. If you're storyboarding and developing your own content (which has often been the case for me) the storyboard may not need to include extensive notes or explanations for developers; it might be more to approve and review content with stakeholders and SMEs. If you have narration, you'll need to include a script, etc. So your storyboard really depends on your project and the players involved.

I think Ashley is right saying Powerpoint and Storyline creates more of a "visual storyboard" than when you're working with something like Word. What I have found in my own experience, is that when I storyboard in Word (which was more of a table-based storyboard) when I come in to Storyline to actually develop on a slide-by-slide basis I find that what made sense when I was storyboarding in a table in Word, doesn't really work when it's laid out on slides, and what might have all been included in one slide (or one cell in my table) in my Word storyboard, ends up making more sense to be spread out across 2-3 slides, or a slide with multiple layers, etc. So I find my "visual storyboards" made with Storyline or even Powerpoint end up being closer to the final result that working in a Word document. 

I've used Storyline to storyboard multiple past projects. Again ... I think how you approach storyboarding really depends on the specific project but in these cases I was doing both the storyboarding and the developing, so for me, it just made sense to storyboard directly in Storyline. 

I started by organization all my information in tables in Word, then moving the text content onto individual slides in my Storyline file which was my storyboard. I included the text that went on each slide (not final, I'll come back later and refine and review), as well as placeholder for the images that I want to include. I also included things like layers, where buttons would go, etc. I also figure out, and include notes (I might even go ahead and build out to test) parts of the navigation and figure out how everything will connect and link. I do this to make sure everything I'm including in my storyboard is possible and can indeed be done, so when it comes to development I don't find out all of a sudden that something I wanted to include just doesn't work.

When I had all my text content, and multimedia figured out, and figured out how the whole thing will link/how navigation will work, I presented this to the stakeholders. We ran through the whole thing. When it's approved, I duplicated my .story into a new file, and working right from that, I developed my course. I just styled my slides, replaced my placeholders images with final images, edited my text, built in all the rest of the animations and trigger functionality that was missing. It saved all the time of having to copy and paste things over from Word or from Powerpoint. 

That's my experience on how I used Storyline to create my storyboards. Hope this helps!! As you see, this works particularly well when you have the same person doing storyboarding and development.

Steve Flowers

I'd caution against *storyboarding* directly into Storyline. Have seen a few train wrecks result from jumping right into the tool without conceptualization and preparation that goes into identifying the problems to be solved. Storyline *can* be the wrong tool for those tasks if you're not careful. Like Nicole says above, you have a lot of artifacts you'll need to hand off that Storyline might not be well tuned to deliver. 

Documents do a great job at capturing things like scripts and offer flexible options for review. I've started using http://www.realtimeboard.com for goal and flow storming. It's working pretty well so far. I'm really comfortable in development environments but it just doesn't feel like the right tool (for me) to use to build design documentation or the grunt work of storyboarding in Storyline.

Some folks can be super successful prototyping directly in Storyline. But I suspect there are plenty of sketches, and requirements documents, and conversations that happen before cracking open the tool that support that kind of work. 

Now that the negative-nancy advice is out of the way, Storyline can be a good place to develop your ideas once you know exactly what problems you're solving and you have a general flow hammered out in your design docs. I have used it to quickly give folks a sense of sequence and gating but what I learn from these prototypes is applied back to the design documentation and Storyboard.

Whatever works best to solve the problems at hand is the right choice. 

Jerson  Campos

Steve and Nicole have a point. You might need to fully develop a storyboard before starting development in storyline, but you should have a clear understanding of what you want to develop. Some ideas might seem great at first, but could be extremely hard to execute once in storyline (like my fire extinguisher demo). It is best to write down your ideas or create some mockups before going into storyline. Especially when you start working on the look and feel of it. You don't want to start developing in storyline with several slides into and and then go "hmmm,  i really don't like this font". There is no easy way to change the fonts in all the slides other than going to each slide individually and changing them.

Its the same thing with website development. They create comps for the UI and look of the site and the navigation planned out  before a developer even starts on the code. Why shouldn't we take the same approach?

Jackie Van Nice

Interesting topic! It's rare I have to do a full storyboard. I invariably mock up a demo of my design ideas in Storyline - not too different from what Nicole described - get client approval on that and the written content, and go from there. 

Jerson, just as an aside, you mentioned the lack of a way to do global font replacement in Storyline. Have you seen this Screenr from Mike Taylor that shows a pretty ingenious way to make it happen? https://player.vimeo.com/video/204869894

Bruce Graham

The voice of dissent..... 

I almost exclusively "storyboard" directly into Storyline - although I have one current client who has a particular way he likes to do things, so he creates an MS-Word storyboard with text/script/image descriptions etc.

So - they are not really "storyboards" per se - they are prototype courses. Just imagine a .story file with some notes pages that say "BG - need to find an image for this page/create a ScreenCam illustrating this process..." or whatever.

As Steve says, before this "rapid prototyping", I will usually play with ideas in conversations with clients and then start to execute, often making many changes, (but not huge ones...) along the way. Saying that, it is usually only one or two conversations, and I seldom if ever exchange anything in the way of images. In many situations I have worked with a PC and a large screen in a meeting room starting with a blank SL project - and we just "go for it"...

With images, usually we are close, and they may require only minor, or no editing by my illustrator, (who can read my mind exactly anyway...). Usually they have an idea of fonts etc. and I am lucky in that a lot of what I do is repeat business for clients, so that we start from a known and agreed general perspective.

The only way that I can explain my success at this principle is that I can imaging quite well, and that I often get clients to do this too. I may start by asking them to close their eyes, and tell me what they see on the first screen, and we work from there..... Sometimes they find this VERY odd, but after a few minutes, they can get quite animated about this process, as it's refreshingly different to going through PowerPoint slides. Someone once told me the way to success in sales is to "...sell them a vision of success". I just decided there was no harm in doing this rather literally

I am happy working any way, however, everyone has their preferred method.

Bruce Graham

One other thing having re-read Steve's (excellent) post above.

As I may have mentioned before once or twice......for me, the start point is talking to the client about, and understanding their specific BUSINESS issue, rather than necessarily worrying about the TRAINING issues.

I find that doing this simplifies the thought processes, and what the solution/solutions might be if we come to Storyline, so that may assist me in some way doing what I do in the way that I do it.

Steve Flowers

I'd equate business issues with performance issues in some senses. Assuming the business aims are on target, products have value, etc... in the "people produce value" chain, there are success factors that the individual contributes and factors that the organization contributes. 

Here's my model for how the main factors (not all factors) relate. It's based on Dave Hartt's 8 buttons, Carl Binder's 6 boxes, and Tom Gilbert's BEM. Training an individual won't fix problems with selection & assignment, misincentives, dearths of information, poor resourcing (not having the right tools), not having the capacity (can't lift 500lbs), or not being motivated to do the job (knows how, chooses not to). Skills and knowledge can be moved with training efforts. But I think we often overestimate that gaps are S&K. It's the easy answer - but can be wrong. It's human to point to human deficiencies - blaming an individual for a system failure Unfortunately, answers are almost never that simple. 

In the diagram, notice how each individual factor has an organizational complement.

Bruce Graham

Jerson wrote:

    

Can you explain the difference in what you mean when you say Business issue and Training issues



OK...

Client - "I want some training on Health and Safety please!"

Bruce - "OK - why do you want that?"

Client - "...because we have to - it's the law?"

Bruce - "What is the law ACTUALLY requiring...?"

Client - "That we train everyone."

Bruce- "Yes, (well - maybe it actually says you have to OFER the training, but that is a separate issue...). Is it the law that you do it, or is Operations trying to get everyone to realise your insurance bills are crippling the company? It may also have something to do with the fact that the Board has set a target of 25% reduced on-site accidents per year for 3 years, so that the insurance band drops - thereby reducing the annual costs to finance, AND reducing the legal bills from people that sue you?"

Client - "How do you know that?"

Bruce - "It's in your company Annual Statement..."

Client - "Ah..."

(This example is for example purposes only, Terms and Conditions apply, may contain nuts)

That sort of conversation, (or similar) allows me, very often, to completely re-frame the requirement, cut out the unnecessary course sections, (or make them "optional supporting data - available if you need it from ........")

I usually try to start by talking about "businessey stuff", not immediately starting "training speak". What we do (eLearning, classroom training or some amalgam) is only a means to an end in the vast majority of cases.

I do not have a theoretical background like Steve's diagram, and of course business issues are the ONLY reason we train people, either to increase revenue, reduce losses, or reduce business/personal risk, (this example being #1 and #3).

However...because of my background I do understand the fundamentals of business and business operations, and am able to cut to the chase of WHY something is being proposed, which (in my mind anyhow...) simplifies what needs to be done in many cases.

Does that help?

Steve Flowers

I think you're getting at the issue, Bruce I have some disagreement with the goal always being a business driver. It boils down to accomplishments (what the organization does) and values (what the organization cares about). Different organizations are going to be motivated by different drivers. The health care industry is going to have a different set of accomplishments and values than the financial industry. A fire department may be concerned about financials and resources, but the accomplishments aren't in any way parallel to profit motive.

I dig the vignette you presented above. Pure profit motive is one way to look at it. I'd definitely consider the business value (ROI) in pitching a solution. But I'd add as perhaps a greater value... providing a safe environment for all employees is both good for business and good for the people that I care about in this company;P

The diagram above illustrates one way to think about sorting the root causes and mapping those to the solutions with a greater probability of solving the problem. If we fail to consider that we might be providing incentives for the wrong behaviors, not supplying the right tools, providing the wrong information, or hiring the wrong people -- we're wasting our time providing training. 

Bruce Graham

Steve,

I have worked in, and with many industries and sectors, and somewhere along the line, if you ask and ask, and dig deep enough - training is being done for profit, loss and risk reasons. Customer Loyalty is sometimes quoted as the 4th, but I pull that into profit, (as that is the one it affects - ultimately).

Fire Department - reduce personal risk, and customer (people saved) risk.

A safe environment IS important - but someone at the top will ultimately equate it to $/£.

Often a companies values exist for VERY strong and sensible commercial reasons.

All I am trying to say is these are usually more interesting (IMHO) to look at than just say "Oh yes! I am EXCELLENT at Storyline, and can build multi-layer interactions using JavaScript for you!"

Respectfully.

Nancy Woinoski

Steve Flowers said:

I'd caution against *storyboarding* directly into Storyline. Have seen a few train wrecks result from jumping right into the tool without conceptualization and preparation that goes into identifying the problems to be solved. Storyline *can* be the wrong tool for those tasks if you're not careful. Like Nicole says above, you have a lot of artifacts you'll need to hand off that Storyline might not be well tuned to deliver. 

Documents do a great job at capturing things like scripts and offer flexible options for review. I've started using http://www.realtimeboard.com for goal and flow storming. It's working pretty well so far. I'm really comfortable in development environments but it just doesn't feel like the right tool (for me) to use to build design documentation or the grunt work of storyboarding in Storyline.

Some folks can be super successful prototyping directly in Storyline. But I suspect there are plenty of sketches, and requirements documents, and conversations that happen before cracking open the tool that support that kind of work. 

Now that the negative-nancy advice is out of the way, Storyline can be a good place to develop your ideas once you know exactly what problems you're solving and you have a general flow hammered out in your design docs. I have used it to quickly give folks a sense of sequence and gating but what I learn from these prototypes is applied back to the design documentation and Storyboard.

Whatever works best to solve the problems at hand is the right choice. 

Um - what do you mean by negative-nancy? 
Nancy Woinoski

@ Steve - I tend to agree that training should support business issues. To me "business issues" are the problems that are creating the most negative impact on an organization's ability to succeed or the opportunities that will give it the best advantages to succeed.  The issues themselves may impact an organization's activities, goals and values or whatever. An organization's activities, goals and values, in turn, are put in place to ensure the organization continues to survive and thrive be it for pure profit or more altruistic reasons.

Ari Avivi

There are two great themes going here. 

1st storyboarding.

i have jumped straight to storyline to build for the client ( we are embedded in the company so I use that term in that context) and have discovered that at times doing it that way has led to a massive amount of content creep.  Currelny I build a content map in Mindjet manager, it has the great advantage of exporting to word complete with a Table of contents that is numbered ( 1.1.2 etc)

I'm clear with the clients that this is a summary of content and get that signed off before i start with the visual component.  Being embeddded I have the luxury of sometimes telling my client that they are not design specialists and they have to trust me when I tell them that as much as you like farmville, It doesn't make sense make our compliance policy trainnig work like that.

After content is signed off then a demo slide, or set of slides is set up in storyline to show how it will look and some of the functionality.

Once that is signed off then we develop the rest of the program.  If they come back an ask for changes we remind them that they are chaning their own content and that we are happy to do so, but they have to be aware of that fact.

As for topic 2 - determining needs.  We ask a lot of questions.  "what does it look like when they do it right", "do they need to know it from memory or can they follow an aid" ( this is a frequency of use type question).  "are you asking a new employee to perform the skill ast the same level of competency as your experienced employees?  is that a realistic expectation?"

just my thoughts.

Kimberly Read


I completely agree with Nicole in regards to there not being a "right way" to storyboard. I agree also with her rules of thumb for when to use Word, PowerPoint or Storyline to storyboard.

I use a more visual tool like Storyline or PowerPoint when:

  1. The images needed for the course are available to me and finalized
  2. I'm confident in the content
  3. The course content is not easily understood without visuals

I tend to use Word when:

  1. I need SMEs to closely study the content of the course and/or audio script
  2. The images needed are not available to me yet or finalized (an application still undergoing development and screens haven't been finalized, for example)
  3. I'm working with more than one person on a course and the development team needs to coordinate on a complex topic

Of course storyboarding should not even begin until:

  • It is established that training is the performance support needed (versus more resources or tools or something else from the organization)
  • All parties have agreed on the end desired result of the training (i.e. learning objectives and performance outcomes)

Just a point from personal reflection - I found it difficult to create a visual storyboard in PowerPoint when I was a new instructional designer getting started in the field (Storyline didn't exist back then). Over time I developed the ability to create rapid prototypes.

Karen Wegner

Great discussion!  After reading Ruth Clark's book on designing Scenario Based eLearning, I created a one page planning form that I've used to think through and map out the content that will be used in a scenario.  While it's not technically a storyboard, I found that it was very helpful to do the thinking before building the actual course in Storyline.  I was able to get initial feedback on the design concept before going further.  Once I had the scenario design approved, I also wrote the initial script in Word, and then moved to PPT mockups that could be easily reviewed/approved.

I included brief descriptions in each section of the document that explain what would be entered, but those could be removed.  And you'll need to read Ruth Clark's book for a full understanding!   

David Field

I have followed this thread and agree with what people are saying that there is no right or wrong way of storyboarding. I have been using storyline to build up my storyboards over the last 12 months. Using this approach has enabled me to work closely with my SME to show prototypes of the course with the content in place. This has reduced the amount of reworking that I have had to do. I then take a screen shot and put this into a story board that I produce in word.

In the word document I explain what the slide is and what the user will have to do to interact with it. I also put the text that is on the slide in a box for the SME to edit if required.

This works for me

Holly MacDonald

Bob,

I tend to list in a word table and describe the type of interaction/activity that will be on the slide. If client has not seen this type of interaction before, I either build those dummy interactions with placeholders so they can see or show them something from the showcase or downloads to visualize it. I agree it's hard to replicate in a flat word doc, but you do want to make sure that once you start building your prototype as a kind of living storyboard, you don't go too far down the path of building a custom item in SL. I'm basically building/sourcing a library of interaction types to illustrate for them and then just pop the links into the word doc for reference. 

I've also wondered if doing a quick screencast would provide the context. Does anyone do this?

Hope that helps

Holly

This discussion is closed. You can start a new discussion or contact Articulate Support.