Hooking learners with a simple story

August 16, 2008

Instead of just starting an e-learning course with a dry-as-sand list of objectives, I like to start with a “teaser” scenario. A teaser is designed to hook the user and give them a bit of motivation for taking the course.

Recently I have been working on a WBT about the A3 problem solving process and report writing (made famous by the process gurus at Toyota). The approach is very effective, yet amazingly simple: You follow a certain problem-solving process and, regardless of the complexity of the project, you write the report on a single A3 sized (11″ x 17″ piece of paper). The purpose of the WBT is to introduce people to the approach, which is becoming the company-wide standard at the client company.

Check out my A3 report writing teaser below. Click the Slideshare navigation arrows to go through the screens.

In this case, I wanted to give a sense of fun and simplicity to the subject matter. Hopefully people taking the course can relate to or hope to avoid the pain experienced by the charachter Joe and therefore want to take the lessons. So, the implicit objective is that in taking this course, you will avoid writing crappy, ineffective reports and, instead, create reports that your audience (e.g., your boss!) will understand and use.

Another thing I like about teaser scenarios like this one, is that it sets the groundwork for fun interactions later on. For example, the story can be continued with multiple choice questions and examples.

Following the teaser in my A3 course, users can select from several lessons. Joe appears throughout the course, sharing his lessons learned with the viewer. The viewer is able to help Joe make decisions via short vignettes and branching scenarios. When the learner makes a mistake, Athena (the Problem-Solving super hero) appears, sharing best practices for good report writing. Athena also shows up on summary screens between steps.

So what do you think? The audience is probably a bit like you. Most are smart folks and most have not heard of this approach to problem solving. Does an introductory story/scenario like this make you more likely to be interested? Or is it too goofy? I would also love to hear about any other low budget ideas for hooking learners up front.

Advertisements

My 48 Hour Rapid e-Learning Challenge

June 19, 2008

One person. One course. 48 hours.

Time to put rapid e-learning to the test. I recently got an assignment to create an e-learning course and it needs to be done fairly quickly. I need to get it done in a few weeks and I don’t want to spend more than 6 hours a day on it. On the downside, the course goals are a little fuzzy, there isn’t much existing content, and I am writing the content and developing the course on my own. On the positive side, I have a lot of autonomy to design what I want.

Here’s the plan:

I will use the Articulate suite to build the course (a tool I have used for one previous course). Because of the tight timeline, I will rely mostly on relatively simple approaches but (hopefully) engaging instructional strategies that a single, non-programmer/action scripter can do alone. To that end, I’m drawing a lot of inspiration lately from blogs like Cathy Moore (e.g. how to add emotional impact ; dump the drone), Tom Kuhmlan’s Rapid E-Learning Blog, and Jane Bozart (especially her Better Than PPT book).

Goal: A fully functioning course in 21 days (and no more than 48 hours). By “fully functioning” I mean ready for beta testing, not necessarily final release.

  • Days 1-5: content outline, design/strategy, storyboard in PPT, document my processes.
  • Days 6-10: finalize storyboard, write screen content and script, identify graphic/media
  • Days 11 – 15: Build all course screens and interactions
  • Days 16 – 20: Record audio, test, release beta for review
  • Day 21: Kaizen (improvement) – Review process for what worked, what didn’t. Look for areas of waste and inefficiencies, Improve and document process for next project.

Along the way:

In addition to developing the course, there are a few other things I will do:

  • Document lessons learned and best practices.
  • Track metrics and track data to help with future improvement projects.
  • Develop project management and process documents that can be replicated.
  • Update this blog minimum three days per week: include discoveries, general experience, review of software, etc.
  • Search out other blogs, product support site for help, and post questions as needed.

That’s it….ready, set…..

Do you have any ideas for getting set up and started on a WBT rapidly? War stories, best practices or things to avoid….any comments are appreciated. Comment here or e-mail me.