eLearning Design Documents

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.)