How to validate a storyboard

Jan 06, 2021

Hello everybody,

I'm curious to see how you explain the validation process of your storyboard to your clients. 

Do you define the number of validation passes they have? What is included in each pass? (ie, flagged items on validation pass #2 shouldn't exceed the items flagged on validation # 1). 

Would you have tips on how to validate a storyboard?



7 Replies
Karl Muller

Hi Julie,

We don't have external clients, but this is what we do.

The storyboard is completed as a team effort by the development team and one or more SME's.

The completed first draft goes out to a peer group of SME's (about 5 on average) that review the draft and provide individual review comments in a Word doc. They may not edit the document, only add review comments.

We collate all the review comments and send out second draft to all respondents.

We then have a conference call and review all each and every comment as a group and reach agreement about the changes that will be implemented. The exact wording of all changes are agreed upon as a group.

After the meeting we make the changes and send out the final version for approval. At this point no additional changes can be made; the only option is to verify correct implementation of previously group agreed upon changes.

Julie Frappier

Hi Karl, 

Thanks for your input, it's greatly appreciated.

So, for the storyboard, you only 'allow' 2 cycles?  

How many for the actual Storyline?

Where I work, I give my client (internal client - Business unit) 3 cycles. After receiving final approval, we then proceed to integrate the STB into Storyline and once that's done, it's sent back to the client for another 3 cycles (5 business days each)..

So, the review process is tedious, to say the least.

The reason why I was asking, if that for this client, it's been difficult. Even after the 3 cycles, they come back with new changes on the Storyline, when it'd been approved during the STB phase. 



Karl Muller

Hi Julie,

Yes, the review process is indeed tedious. Development projects need to be very carefully managed or you will be faced with endless scope creep and a never-ending project.

As part of every new project, we create a project Terms of Reference document to inform stakeholders and manage expectations. 

It states the scope of the overall project, purpose and intended outcome, sponsors, team members, their roles and responsibilities, includes the project plan, milestones and deliverables, etc.

Something we state in great detail for each phase of the project, and specifically for review related tasks, what is considered in and out of scope. Clearly state the extent and nature of their activities: In Phase 2B, you will be getting draft 1 of the SB. You are required to ..... 

It is important to notify SME's and other stakeholders up front, at which point of the process no new content can be added to the course. We typically lock down content additions with the acceptance of the final SB.

A big challenge we face when working with stakeholders for the first time, is that while they may sign off on a SB, they do not have the experience to visualize what the online course will look like and how it will function. 

So when they see the first version of the course, they have a major "ahaha!" moment and suddenly they starting thinking of new things to add, because they didn't know what could be done with the technology.

How we manage this situation is to find an existing online resource that is quite similar and show it to them as an example at the start of the project, and inform them that the current project will be very similar to it.

Julie Frappier

Thank you, Karl, sorry for the late reply, but this validates that what we're doing, we're doing it right :) 

Have you ever come across business partners or clients that just don't get the difference between Integration of content and Curriculum design? Or challenge you that your process takes a long time to create an e-learning?




Karl Muller

Hi Julie,

Certainly sounds familiar.

Some clients simply want us to copy and paste existing documentation and call it training.

So they get really annoyed when we propose doing any kind of instructional design, as they do not see the added benefit up front. Usually they are pleased with the end result, but the added time required for the design stage is always a hard sell.