jump to navigation

eLearning Design Documents August 3, 2007

Posted by B.J. Schone in eLearning.
Tags: , , ,
trackback

I haven’t seen many resources that dive into the workflow of eLearning development, especially for folks like me who build courses mainly from scratch. I thought I’d write about some of the methods I’ve used, hoping that others may chime in or that I may come to new realizations through my own reflection. Here it goes…

The Design Document

eLearning development requires collaboration from multiple people with unique skillsets, including instructional designers, subject matter experts, software/web/eLearning developers, graphic designers, and more. I’ve found that a design document is one of the best tools to help you keep a project on track and keep everybody in-the-loop. (This may seem like common sense, but I’m surprised I haven’t seen more written about the advantages of using design documents.)

The design document serves as the central source of information for the project, which 99% of the time is an eLearning course (for me). The document contains metadata including the course’s name, description, timeline (including due dates), notes from the client, and a storyboard section that outlines each page or interaction in the course. The document should also note when/where sign-off must be received by the client (ex. after each major step or phase of development).

Getting into more detail, each page of the course is outlined in the design document. For each page, the document should have a placeholder for the page title, description, content (or where the content can be found), desired interactions / exercises, multimedia (ex. audio, video), notes, and a time estimate (in hours).

Workflow

Our workflow usually goes in the order below. Although it looks linear, it is an iterative process with several reviews along the way. Some reviews are formal, others are informal.

  1. A business need is identified.
  2. A decision is made to build an eLearning course. (This isn’t always the case; eLearning is not a magic solution for everything. But in this case, we’ll assume it is.)
  3. Business owners are interviewed. We ask them to define the business need and identify what they would consider to be a successful outcome. Everything from this point forward is added to the design document.
  4. Subject matter experts are interviewed. They explain what information needs to be taught in order to successfully cover the material. We add this information to the design document.
  5. An instructional designer takes all of the information gathered so far and does their magic. Their notes and decisions are tracked in the document (along with the content that is generated from their work).
  6. The eLearning Developer takes the document and interprets it, along with a graphic designer, and builds the course.

Critical information comes out of each of these steps, and it is important to track this information in the design document. This makes it easy to track why decisions were made – and who made them.

On a related note, it helps to have an internally created eLearning developers’ guide which outlines the dos and dont’s of eLearning for your organization. I highly recommend Mike Dickinson’s article, Evolution of an e-Learning Developers Guide, in The eLearning Guild’s Learning Solutions e-Magazine. (Membership is required to view the article.)

Comments»

1. Cammy - August 6, 2007

Hey B.J.,

It’s always interesting to hear how other people approach projects. Our process is essentially the same. I’ve approached the document thing a little differently than you, breaking things out a bit more into separate docs:

1) Project Plan — this defines the overall approach and includes a high-level schedule and key milestones.

2) Design Document — my design docs provide the general framework for how we’re going to build the program and approach the content.

3) Storyboard/Program scripts — this is obviously where I get into page specifics.

Your design doc gets much more into the page specifics than I’ve ever done. You mention “placeholders” for content — do you have a storyboard shell built right into the design doc?

2. B.J. Schone - August 6, 2007

Hi Cammy,

Yes, we have a storyboard shell (which is essentially just a series of tables) built-in to the design doc. Also, our design docs are formatted for legal-size paper and they are landscape-oriented.

I could see some benefits of keeping the storyboards separate from the design document, but I personally like having everything in one document. So far, it’s been fairly manageable.

3. Akiva - September 25, 2007

Hi, Cammy & BJ

We also follow Project Plan, Design Doc and Storyboard. We also have a checklist, which fall under design plan which is a checklist each content creation team member has to tick so we can monitor quality assurance and have accountability.

What i need is a simple workflow online tool that the content team can go into to see progress of development – where the course is up to in production line (i.e. SME due date for completing course, Flash designer finish(es)(ed), Interactive quizzes completed by…). Do you know of anything?

4. Dr. Salil Gupta - September 23, 2008

Hi Cammy,

Good, short and sweet. all said in a nutshell and in least number of words. Thanks


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: