

Tuesday, August 28, 2007

How Long Should an eLearning Course Be?

Interesting question posed in eLearn Magazine article: How Long Should an E-learning Course Be?

Interestingly the author chooses to sidestep the question he poses and instead gives a direct answer to a different question (focusing on modules that are parts of a course):
What is a good length for a module? Through countless hours of instructional design, field testing, and client feedback, I have found that 30 minutes is about the maximum, and less than 15 is too short. The exact number of minutes between 15 and 30 should be dictated by the depth and number of objectives in the learning module. In a one-hour course, it's absolutely fine to have two 18-minute modules and one 24-minute module. Do what feels right. Test it with members of your target audience, and then fine-tune each module until it's just where you want it.
I have found a sweet spot for learning chunks around the 10-15 minute range. Of course, it's highly dependent.

However, I have a possibly different answer to the core question about how long should the course itself be ... my answer ...
As short as you can make it. Zero is optimal.
There's a natural tendency to try to teach too much. As teachers, we are passionate about our knowledge/information and its value. So we want to share. But instead we need to question every objective, every piece of content. If it's not absolutely essential, then it should be provided in some other way, i.e., reference.

When you take this approach, you often find yourself coming to a different kind of solution. For example, when we asked to design an eLearning Course that went along with the release of a new procurement software (e.g., order office supplies, business cards, etc.) for a large company, we originally were asked to do what amounted to an hour long introductory course.

However, since the software would be used sporadically (maybe once a month) and since it was fairly intuitive to use for most activities, all we really needed to tell people were a few basic pieces of information and to make sure they knew how to get more. So instead of teaching them a bunch of stuff up-front, we provided those few pieces of information inside a hybrid reference solution.
How long was the "course"? It was one page (a really good page).
Of course, you could drill down for lots more including guide tours of features and for a couple of really advanced, and possibly scary functions, some simulations.

Most people were very satisfied with just the most basic information and the ability to get more as needed. Some learners (many of the admins who would be using it more frequently) would go through most of the learning pieces based on the links in the Quick Start Guide.

The end result was considerably better (and lower cost) than the original solution that was requested.


Wendy said...

Absolutely dead-on. As trainers, there seems to be a tug between sharing everything so we don't hear "But I wasn't TRAINED to do that" and allowing folks the opportunity to discover solutions for themselves.

There is also the continuing issue of culture and expectation. They may claim to want you to "train" in as little time possible, but when you show a workable solution - they balk and ask "but what about the classroom time?" Maybe that's just my environment...

Glad to see you back Dr. Karrer and hope you had an awesome summer vacation.

Tony Karrer said...

Wendy, great points (as always).

There definitely is that balance of "I wasn't trained to do that" ... which backs us into telling everything we might ever possibly need to tell someone. However, I'm finding that many corporate cultures are moving away from that. And, there's greater acceptance of telling someone a little something and then telling them more over time after they have their feet wet with the basics.

Brent Schlenker said...

Right on the money! I used to plead with software developers to PUT ME OUT OF A JOB!
Heck, most of the software training out there is simply "training to the shortcomings of the software". I've even had meetings with developers who say, "well, can't we just train to it"?
Its like saying its not a bug, its a feature.