Storyboarding help required!

Hi All,

I've recently been asked by my manager to Storyboard every course i create in Powerpoint, for sign of by the SME/Customer before actual development takes place (dev takes place in Storyline 2).

My issues with this method of storyboarding (over the usual templates in word) are:

A) I don't actually know what is going to look best on screen until i start to develop it and see how it all fits together.

B) The Customer will start to see the story board as an exact replica of something i've not even started work on yet, which could cause issues at signoff.

C) The time it takes creating something (almost creating it twice) the storyboard or non interactive replica of the content seems like a waste to me.


Any thoughts for or against this method of Storyboarding?

Is it worth the effort?

Thoughts on your storyboarding processes and logic behind it would be much appreciated.



9 Replies
Kris Lafleur

Hi Kevin,

I agree completely and the risks are bang on (at least in my experience). I generally use a Word sb for content approval and then design. As I am strictly freelance, I get into the exact same situation with clients who would prefer to follow their own internal process. There are 2 solutions I have used in the past that seem to find a middle ground. 

1. Graphic "placeholders" with a suggested description of intended graphic in the PPT. (Basically a square with the text I would normally include in the sb under "Notes for programming".)

2. Added a graphic inventory review step once the sb is approved. This just means breaking process down a little further but limits the amount of re-work. Once the sb is approved via PPT, I start developing. Before I program, I take the images and pop them into the PPT for the client to review and provide feedback. In some cases, this has actually been a better process saving time and energy on image dev. It also adds to a very collaborative development process.

Hope this helps,


Bob S



I agree with you completely. In fact, this was discussed in some detail in a recent thread here about impossible deadlines and methods to be efficient.   I always try and use a Word-based storyboard I've taken to calling a "detailed draft" for stakeholders.   The name sets it apart from a storyboard which so many associate with visuals more than content.

My "detailed draft" is an easy to work with (and comment on) table format Word doc with three columns; Topic, Details, Delivery Method.
*** Topic states simply what will be talked about in that silide/section,
***Details is a simple outline  of the talking points that will be covered (only if needed, exact verbiage can be added sparingly here as well).
***Delivery Method lists the interaction type if any. (ie Drag and Drop, Reading, etc)

As for how to push back respectfully?  I suggest explaining the benefits for the client/stakeholder and avoid the impact to you. How about these....

  • Allows you to see all of the content rather than just select screens
  • Adds clarity to the structure/sequencing of content as focus on layout is removed (for now)
  • Encourages tweaks to content BEFORE layout visuals are created that may make such changes harder later on
  • Increases speed at which you will be able to review.... both in terms of quicker delivery of first draft and ability to redraft with subsequent tweaks

Finally... I have found that this method has another "hidden" benefit for the project. Stakeholders are often quite busy people, and allowing them to review content like this early on (absent visuals) offers them a sense of reassurance....... so  much so that many times they will opt out, or be less invested in, the visual requirements that were a hot button for them originally.

Good luck!

David Tait

This is something that we've encountered recently too.

I see the benefits of this as follows:

  1. If you create your storyboard and do the design in PowerPoint then the client has the opportunity to review fully before you spend time building in Storyline. If you then import the ppt directly in to SL then you're not actually doing the work twice.
  2. The projects we've built in this way have largely sailed through the final review as everything has been seen early on.
  3. As Kris mentions, it is a very collaborative way of working plus it can really help the client buy in to your ideas as they feel closer to the action.
Bob S

To over simplify a complicated topic, I think it comes down to a "form over function" debate.

  • Traditional storyboarding (ie visuals) emphasizes form. Whether we believe it does or not, it certainly does to the stakeholder.
  • Content-based drafts (ie content with an indication interaction type), emphasizes function.

If we use a content-based draft, will some stakeholders still want to see a storyboard?  Sometimes.  But my experience is that they are far less invested in needing a full storyboard if they are comfortable with the content first.  At that point if they still have visual concerns, they are typically satisfied with a quick  mock up a screen or two, perhaps some discussion on images, etc.

So lots of workstyles out there and as long as they work for you and the client, great! But I've personally found content-based drafts far more productive and efficient overall.

David Tait

I don't think it does Bruce. My own view is that if I view PowerPoint as a tool and use it as a DTP package as I would Quark or InDesign then I am only limited by my own creativity. Just because something is laid out in PowerPoint doesn't mean it needs to look PowerPointy.

Of course there are other ways to get stakeholders to buy in but as Kevin suggested he was being led down this particular path I think it's more helpful to look for the positives.

Every course that I or companies I've worked for in the past have developed has been storyboarded, be it in a graphic design package or something like PowerPoint. This method for us was born out of having multidisciplinary teams made up of designers and Flash developers, largely before rapid-build eLearning became the norm (I'm going back 15 years). Designers would take the Word-based script to create the course and the developers would take the approved designs and bring it to life. It was simply too risky to go straight from Text-based scripts to the programming stage in the event that the client made big changes on first sight of the programmed version. Having a storyboard at least minimised this. Nowadays rapid-build tools makes it less of a risk.

As Bob suggests, and I agree, it's an argument between form and function. I prefer both where possible.

Kevin Raspin

Thanks for your input guys, some very interesting points made.

Just to be clear on the background, i'm pretty new to the business that I am currently working in, as an in-house e-learning consultant/designer and e-learning itself is also new to the business.

Therefore I am putting together the processes for e-learning from initial request to final signoff, there are plenty of 'audits' of the course built in during the development phase and a full agreement at the outset of the course 'content' and 'aims and objectives', so there should be little for the customer to be surprised at late on.

I just don't want to set the process & myself up for a fall by trying to hard to give everyone everything and promising too much, storyboarding in PPT may be ideal in a large development team, perhaps it's my situation that makes it different.


Martina Osmak

Hi everyone, great discussion going on here! I don't want to spam this discussion because the subject is just similar, not the same. But, since it really is close enough, I'd like to draw your attention to this thread (discussion on SaaS tool for Storyboarding) - . Maybe you have some ideas what features should be developed- which would help storyboarding to be effective, fast and easier.