OK. So, the title is a bit long. But I found this interesting read by Cath Ellis called The 10 Commandments of eLearning. Her number 1, regarding putting the pedagogy first instead of the technology, is a ringing refrain that I have heard time and time again. Yet, there are still many examples of products and projects in which the tool is showcased instead of the learning.
Cath also notes that risks should be balanced with safety. Her premise there is that going online is a risky thing for some people and so the environment should be made safe with introductions, reflections and social activities. This is definitely true in a social networking sense and in an online classroom sense. This may not necessarily apply to the employee who is doing an online training because they have to. Additionally, let me present the flip side that some feel a little TOO safe online. Therefore they feel empowered to share information or communicate in a manner contrary to their normal behavior patterns. This can be positive and negative.
I also found great solace in Cath’s comments about not “reinventing the wheel”. I constantly have to remind myself of that in my efforts to sometimes find the next groundbreaking theory or method of presentation. Sometimes in consistency and simplicity, we can find the greatest learning ROI.
So while Cath’s list may pertain more to direct online education, I’m sure that there are other “ten commandments” of elearning that have been developed. Does anyone have any examples? Maybe I will look to create my own. I won’t write them in stone though
.








Interesting… Cath’s commandments are good for her environment (async facilitated academics). For corporate folk, military folk, other folk, and ultimately the academics (once academia can strike the balance between pragmatism and the academic focus) I think a little different tack is more appropriate.
My number one commandment would be:
1. It’s not about me.
Inevitably folks tend to focus on them first and not what the learner / performer actually needs or the elements that will service those needs.
Academics and ISDs will say that the pedagogical approach is most important.
Technology types will say ‘the way I can build the technology is what I do – that’s most important to me’
Graphics and interactive types are focused on how they can leverage their input (more often than not it’s ‘how can I make this thing look cool’)
When it boils down to it it’s about all of these things and none of these things. Which brings me to my number 2.
2. Exercise the principle of least assistance.
What’s the least your team can do to solve the problem correctly. Often a jam packed training product filled with 3% need to know, 47% nice to know, and 50% who cares is a total waste of 97% of the organization’s energy on that effort.
3. Start with good beginnings.
The worst end products start from the most horrid beginnings. If the objectives are bad (or immeasurable) the end product will either be just as bad or likely just as off target as the objectives. The foundations should focus the effort, not leave it open to expanding scope. The foundations include not only the objectives but a narrative explaining the approach, strategy, scope, and concept for the effort. It’s much easier to adjust a brief narrative than it is to spend a week working on a design plan just to find out that it’s wrong. The concept is critical.
4. Focus on activity not screens or pages.
There is an aweful lot of eLearning out there that’s information focused. Information isn’t evil, but it doesn’t belong in a sardine can. eLearning programs have a lot of potential to leverage the ‘strengths and natures’ of the multimedia program while also leveraging the ‘strengths and natures’ of human beings in general. A page focused outcome is a recipe for crap on a conveyer. Nothing wrong with leveraging the learner’s ability to read in a natural format (print, article style) or sending them out into the real world to test a theory, have a discussion, or look at the way things are.
If you must include information to reinforce concepts…
5. Know the difference between need to know and nice to know.
Educate your SME’s in this art. Iterate through the process and validate with ‘how / when / why’. When you’re done there is often a clearly defined line and the stuff on the need to know side of that line is comfortably defined and manageable.
6. Focus on meaning and relevance
This is closely related to 5… Separating need to know from nice to know (all in support of the concepts > skills / values > tasks > performance) is one step in the process to keep on the track of meaning and relevance. But simply focusing on need to know doesn’t guarantee meaning or relevance.
7. Test the strategy in increments
This is for learners, right? Get into the habit of pulling a couple of learners in to see how they react to your design increments. Often the only folks that get eyes on the design increments are the SME, project manager, and project team. Yikes…
Bah… gotta go to work. These are from the bum. Will see if I can think of three more. If not… 7 good commandments are better than 7 good commandments and 3 soggy commandments.
Aha – one more:
8. Get real about measurement.
What do you really want to measure? Short term recall of trivial information? Or do you really want to measure the real outcomes? Knowing what you want to measure and not trying to measure something that you don’t need to measure – simply because you need to measure something – is a good step in the right direction. Knowing the difference between a measure and a challenge is also important.
To round things out..
9. Everything is strategic.
If it’s not strategic, it’s probably fluff or BS. If it’s fluff or BS, consider tossing it out.
There’s one or more in there somewhere.
10. Authenticity and credibility are necessary if not critical
If you don’t hold onto the soul of the learner with credibility you’ve lost the battle. Be authentic, use authentic elements, don’t lie, don’t stretch the truth, use authentic tones, use authentic dialog (if dialog is used).
11. Respect the learner’s time and environment.
We use standard units of measure to scope our outputs. In the beginning we conceptualize training units in whole or half fractions of hourly units. Wow… why would we estimate a product output to the hour? And what affect does that have on the design? Do we shoehorn more content in there because it’s short of the time goal? If so, this is opposite of what we should be doing.
Why not consider other factors? How often do we take a look at the performer’s available resources and tune the solution around what’s available and what the learner is reasonably willing to commit?
Wow… I’d reorder these a bit, there’s some overlap and I think there might actually be more than 11 commandments:P