Given my project specifications, how should I build my framework?


My current project is a little tricky given that there are several ways I can build my framework. I need to decide on one, but I'm not sure what my pros and cons would be. Here are the specifications:

  • 8 different types of employees are taking this course, each one will have a different experience
  • The course consists of 3 modules:
  • Module 1 is a linear progression through slides
  • Module 2 begins with a choice from the user. The user selects their job at the company. Then the user is taken on a custom path throughout module 2. I have a collection of slides created, most of them being instructional FLVs. When the user's path is defined, the overall slide bank is tailored for that user and the user progresses through certain slides from the bank. Some slides are seen by every user, other slides are seen by just a few users. Once the user completes their path, they are taken to a summary slide that is shared by all paths.
  • Module 3 is a list of the entire slide bank. The user has the option to learn additional information if they so choose. This is easily achieved through branching
  • We are using an LMS (undetermined) to track users progression and quiz completion.

So here are my questions. Should I have one large project with duplicate slides for the Module 2 branching or should I create 8 different linear courses? Would duplicating the FLVs increase the file size of the project significantly? If it were one large course, is there a way to create a custom script for the user's path?

Preferably, I would like to keep it as one large project, but I'm not sure if Articulate OR the LMS would handle that well. With one large course, the user can select their path inside the course. With seperate courses, we can have the LMS know which course the user needs to take.

Depending on an answer, I would probably have more questions. Thank you in advance to anyone that can assist me in this decision.

4 Replies
Bob S

Hi Joseph,

IMHO, you may want to consider separate courses. As sexy and slick as 8 customized paths of content within a single course sounds, living with such a decision can be a different story...

  • What happens when you have to update just one of the paths? Do you republish the entire course?
  • What happens when job descriptions/roles change in the company? Do you scrap the whole course and start over?

One thing we did, is create the common front-end module as an "intro" or "fundamentals" module that everyone took. Then created distinct modules by role for the specialized training. Your LMS should be able to handle this kind of set up through a learning plan/job role sort of functionality.

That way you can easily change/update courseware as needed and provide each learner with exactly what they need... and nothing else they don't.

Hope this helps,


Joseph Replin

Bob, thanks for your input!

Updating content on the course(s) would require republishing each time, and that is a problem we know will come as the subject matter will be changing slightly every 6 months or so. It wouldn't matter much if it were one course or separate courses, as they all share similar content so we would be making changes to more than one slide either way.

As far as roles and responsibilities changing go, we haven't thought about that ahead of time but the roles pertaining to this project are pretty concrete and have been like that for decades. Not to say it wouldn't change, but I'm not to worried about it. 

I can see what you mean, but I'm still weighing which would be better. One large project would be a headache to initially create, but in 8 separate courses with similar content, I would later need to republish 8 different courses for revisions. Wouldn't maintaining 8 different courses be a bigger headache? Given how you did your course, did your "distinct modules" share any common slides with each other? How similar is it to what I am trying to achieve? 

You are helping greatly,


Bob S

We culled out the info that was truly baseline and common for all roles.

Next we identified the info that was a bit more advanced but still common to most/all roles.

Finally we confirmed that the remaining info was truly unique to a single/few roles.

This process above is the key. Once you've done that, then you can look at your options.

For example, if you find that the majority of what you have is common to all all roles, and only a fraction is role-specific, you may choose to go one way. Conversely, if there is only a small amount that's common but it was all basic info (our case), you may choose to house that in an "intro" or "fundamentals" module. You get the idea.

Our final solution was a bit blended....

  • "Basics" module with all common info
  • 5+ "Core" modules that were role specific and contained a repeatable format with some common info and some role-specific
  • 12+ "Advanced" modules that were completely role specific and scenario driven with role-specific scenarios the learners would work through based on the previous two modules and additional role-specific info.

Finally, also remember that if you identify a topic that is really arcane and uncommon for a unique role, consider NOT including it in the course at all. Instead include it as supplemental info/material so that it's there if needed for the rare situation, but not clogging up your learning for "just in case" inclusion.

And yes, with separate modules, we did indeed have to maintain them separately. But in our case, we found that the majority of the volatile info was role-specific. The "basics" were pretty evergreen. So the decision to structure as we did made sense.

Hope this helps,