eLearning Developer

ADDIE instructional design model

Following is a high-level quick list of items to consider when starting a new instructional design/course authoring project.

1. Target Audience: Language, average reading level, technical aptitude (computer skills)
2. Training Modality: Will this be an eLearning course, instructor-led, blended? Why?
3. Learning Environment: For eLearning – do computers have sound cards with speakers or headphones, what’s the average computer resolution, what kind of bandwidth is available.
4. Source Content: Are you converting existing content to eLearning or creating new courses from scratch? What reference/research/source materials will you use?
5. Learning Objectives: Why is the training needed? What specific skills or knowledge should learners possess upon completion? How will you measure weather objectives have been met?
6. Development Timeline: By what date is this training expected to be ready to deliver to learners? What happens if your project runs late?
7. Budget: What financial resources have been set aside for this project? What happens if you run over budget?
8. Subject Matter Experts: Who are the subject matter experts and what is their contact information? What is their knowledge of the instructional design process? Have they been granted time to dedicate to this project and are they on-board or resistant at all?
9. Seat time: How long should it take a learner to complete this course? What is the estimated course runtime and what is the estimated student seat time?
10. Technology: What software will likely be used? Simply upgrade PowerPoint with audio lecture and upload to LMS? Custom 3D animations and graphics based in Flash? Computer skills demos with Captivate?

To request a complete job aid / checklist for each phase of the ADDIE model, request one via the Ask The eLearning Experts form.

When developing eLearning – whether you are doing it yourself or evaluating eLearning companies – it is vitally important that you prototype (or proof-of-concept) each major phase along the way. Developing an eLearning prototype is an iterative process that generally requires at least two or three revision cycles to get it right. Some organizations are resistant to developing a prototype due to the front-loaded cost and time required to do so. If you need to justify or defend, or persuade others to the idea of building a prototype, here are some high-level benefits to bear in mind:

1. Establish a baseline: Your eLearning prototype, once created, serves as an unmistakable baseline of exactly what you expect. The best way to communicate the vision you have for your course is to point to a functioning prototype.
2. Confirm your team’s/vendor’s ability to get the job done: Have you ever hired someone based on strong recommendations and great interview skills? The candidate said all of the right things, nodded his head in agreement with everything you said you wanted, and it’s all systems go. A few frustrating weeks pass by and you’ve arrived at the decision that this person or vendor just does not have the chops. You should have required a small proof-of-concept to confirm the skills were there.
3. Minimize miscommunication: Imagine this – your storyboards are done, audio is produced, graphics picked out, and all you have to do is assemble the content into your final eLearning course (authoring). Now imagine this – the development team worked hard for several weeks and just gave you a sneak peak at what they’ve been up to. You are horrified, because the quality level is way below what you expected and not at all in line with your vision. If you had prototyped the project first, you could have avoided this.

The risks of paying way too much for development or projects running way over budget can be minimized greatly by simply developing a proof-of-concept. This goes for all major phases of the eLearning development process including storyboards, narration scripts, and media production. Any part of the process that will consume time and money if not done correctly the first time really should have it’s own proof-of-concept development cycle built in to the process.