How to Create Effective eLearning Courses: 11-Step Process

Most eLearning courses get completed. Far fewer change what anyone does on the job. That gap — between a green completion dashboard and a team still making the same mistakes — is a design problem, not a motivation problem, and it starts long before anyone opens an authoring tool.

This guide covers how to create effective eLearning courses from the stakeholder request to the post-launch numbers. Each step names the artifact it should produce and what has to be true of it before you move on, and every decision in it follows the same eLearning development best practices we apply on live builds.

11 Steps to Create an Effective eLearning Course

Step 1: Confirm Training Is the Right Fix, Then Define the Architecture

The fastest way to build an ineffective course is to build the course you were asked for. Requests arrive already framed as solutions, and the framing usually skips over what actually went wrong. Before scoping anything, work out which of these you’re looking at.

Only the first row is yours. Training layered on top of the other three burns budget and, worse, teaches your organization that training doesn’t work. This is the diagnostic that sits underneath Cathy Moore’s action mapping, and it’s the reason action mapping starts with a business goal rather than a content outline.

Three questions that expose the real gap

1. “Can they do it right now if their job depended on it?”
If yes, it isn’t a knowledge gap. You have a motivation or environment problem, and a course won’t touch it.

2. “Who’s doing it correctly today, and what do they do differently?”
If nobody is, the correct behavior may not be defined yet — it has to be established first. If some are, you’ve found both your content source and evidence that the task is possible under current conditions.

3. “What would we see change if this worked?”
Push until you get something observable: an error rate, a ticket type, a step being completed. That answer becomes your measurement baseline in Step 11.

Where this sits against ADDIE and SAM

Steps 1–3 are the Analysis phase of ADDIE (Analysis, Design, Development, Implementation, Evaluation), Steps 4–5 are Design, Steps 6–8 are Development, Step 10 is Implementation, and Step 11 is Evaluation. If your organization runs SAM (the Successive Approximation Model) or an agile instructional design process instead, the same eleven decisions still have to be made — you just make them in iterative passes rather than in one sequence, with a rough prototype standing in for the storyboard on the first loop.

The model you name matters far less than whether the diagnosis in this step actually happened. ADDIE gets blamed for slow, ineffective courses when the real failure was skipping analysis and starting at Development with a stakeholder’s slide deck.

Then: define the learning architecture

Once the training program is confirmed, decide how the course will teach before you touch content. This is the step other guides skip entirely, and it’s the difference between an effective eLearning course and a slideshow.

When the stakeholder insists anyway

• Build it, but narrow it. Scope to the genuine knowledge component.
• Put the diagnosis in writing — one paragraph in the brief covering what training will and won’t address.
• Name the non-training actions and assign an owner.
• Agree the metric anyway.

Step 2: Write Learning Objectives You Can Actually Measure

Objectives are the load-bearing part of the whole build. Every later decision — what content survives the cut, what interactions ask learners to do, what the assessment tests — traces back to them. Get them wrong and you spend 40 hours building something that can’t be evaluated, because nobody agreed what success looked like.

The formula

This is Robert Mager’s three-part objective, and the ABCD variant (Audience, Behavior, Condition, Degree) is the same idea with the learner named explicitly. Not every objective needs all three parts spelled out formally. But if you can’t articulate all three when pressed, the objective isn’t finished.

Verbs that work, verbs that don’t

The test is simple: can you observe it? You cannot watch someone understand. The replacements below map to Bloom’s revised taxonomy — remember, understand, apply, analyze, evaluate, create — and choosing the right level matters as much as choosing an observable word, because the level you claim here is the level your assessment has to test in Step 7.

One objective, three drafts

The verb table gets you halfway. What it doesn’t show is how much rewriting a real objective takes. Here’s the same objective from a supplier-onboarding module, in the order it actually got written.

Draft 3 also settles three later decisions in one line. The verb determine means Step 6 needs a judgment interaction, Step 7 needs scenario-based questions rather than recall items, and “no false negatives” tells you the pass mark isn’t 80%.

Terminal vs. enabling objectives

Terminal objectives are what the learner can do at the end — one to four of them, and these are what you measure. Enabling objectives are the sub-skills required to get there, and they become your screens and modules.

Sequencing insight: write objectives second, show them fourth

Objectives are the second thing you write and roughly the fourth thing the learner sees. The instinct is to open with “By the end of this module, you will be able to…” on screen one. It’s tidy, and it’s a motivational dead end — a list of objectives is meaningless to someone who doesn’t yet feel the problem.

Screen 3 does the real work. The learner makes a prediction, usually gets it wrong, and experiences the knowledge gap directly. By the time the objectives appear on screen 4, they aren’t administrative boilerplate — they’re the answer to a question the learner is now actively holding.

This is supported by three converging frameworks: Merrill’s First Principles (begin with a real-world problem), Keller’s ARCS model (attention and relevance precede motivation), and Gagné’s Nine Events (attention before objectives). It also aligns with Knowles’ andragogy, which holds that adult learners need to know why something matters before they’ll invest in learning it. Note that Gagné’s own sequence puts objectives at Event 2 and prior-knowledge activation at Event 3 — deliberately inverting those two is defensible when the prediction moment is what makes the objectives land.

Step 3: Analyze Your Audience and Constraints

You’ve confirmed the gap and written the objectives. Now find out who’s actually taking this and what conditions they’ll take it under — because both quietly override design decisions you thought were already settled.

Most audience analysis in eLearning stops at a demographic sketch that changes nothing. Learner personas are useful only if they produce specific design constraints you can point to later when someone asks why the course looks the way it does.

What you actually need to know

1. Prior knowledge — and how uneven it is. Not “beginner/intermediate/advanced,” but what specifically they can already do. The spread matters more than the average: a group where half are experts and half are new needs a different design from a uniformly novice group, even though the mean is identical.

2. Motivation — chosen or mandated. Someone who signed up will tolerate a slow start. Someone assigned it during a busy week will skim, skip, and hunt for the quiz. Mandated audiences need relevance established in the first 60 seconds or you’ve lost them.

3. Device and environment. A desk with headphones is a completely different design brief from a shop floor on a shared tablet with no audio. This single answer decides whether narration can carry meaning or must be redundant to on-screen text.

4. Time available. Not how long you’d like it to be — how long they’ll realistically get in one uninterrupted sitting. If it’s 10 minutes, a 30-minute module gets abandoned midway and the LMS records it as incomplete.

5. Language and accessibility needs. Second-language learners, screen reader users, translation plans — retrofitting for any of these is dramatically more expensive than designing for them. If more than one locale is even a possibility, scope eLearning localization services now, while the script is still a document rather than a recorded voiceover.

Constraints that quietly decide your design

The LMS row catches people most often. Designing a branching scenario with granular reporting, then discovering the LMS only records pass/fail, is a full rebuild. What you can capture varies enormously by platform: Moodle, TalentLMS, Docebo, Absorb, Cornerstone, SAP SuccessFactors, and Workday Learning all handle SCORM interaction data differently, and some pass only completion and score. Ask your LMS administrator for a sample report from an existing course before you design anything that depends on per-question data.

The one-page audience brief

Get it confirmed by someone who actually manages this audience — not the project sponsor. Sponsors describe the audience they wish they had.

Step 4: Map and Chunk the Course Structure

You have objectives and an audience profile. Now turn them into a screen-by-screen map — before anyone opens an authoring tool or designs a slide.

Content gets organized the way the source material was organized — the SME’s deck order, the policy document’s section order — rather than the order someone learns it in. The result is a course that’s complete and correctly sequenced for a reference document, and hopeless as instruction. It’s the default failure mode of any project that begins as a slide handover, and the fix is to start from the objective map and treat the deck as raw material, not as structure.

Mapping rule: objectives first, content second

1. List your objectives. Each terminal objective is a module. Each enabling objective is a section within it.
2. Sort every piece of source content into three buckets: need to know, nice to know, don’t need.
3. Anything that maps to no objective gets cut — or demoted to a downloadable job aid.
4. Anything an objective needs but you don’t have is a content gap. Go back to the SME now, not in week three.

Duration: what the numbers support

• 5–7 minutes per segment before attention degrades measurably
• 20–30 minutes total for a self-paced module in a work context
• Longer is justifiable when the task is genuinely complex and the learner has protected time — a certification path, an onboarding week. It is not justifiable because there was a lot of content.

If your map exceeds 30 minutes, the answer is another module, not faster narration. And where the content splits cleanly into discrete tasks people will need at the point of work, microlearning is usually the better format than one long module.

Sequencing: problem before concept

Not: concept → concept → concept → quiz. The second order is faster to build and reliably produces courses people complete without changing anything. Two parts get skipped most often:

The opening problem and prediction. Budget roughly 15–20% of module time before you teach anything. It looks wasteful on a spreadsheet and it’s what makes the remaining time land.

Guided practice before assessment. A supported application attempt, with coaching feedback, between the concept and the knowledge check. Without it, the assessment becomes the learner’s first attempt at applying anything — which is testing, not teaching, and is the usual reason knowledge-check scores disappoint.

Chunking is also the practical application of Sweller’s cognitive load theory and Mayer’s segmenting principle: working memory holds a limited number of new elements at once, so material delivered in learner-paced segments is retained better than the same material delivered continuously.

Build the map as a table

Three columns do the real work. Purpose forces you to justify the screen in one line; if you can’t, it’s filler. Objective exposes coverage gaps and orphan content in a single glance. Est. time keeps the total honest — estimate generously, because learners pause on decision screens.

Screens serving motivation or consolidation (welcome, objectives reveal, summary) legitimately map to no objective. Mark them as such deliberately rather than leaving the column blank.

Decide what to cut — and at what resolution

The real chunking decision is rarely whether to include something. It’s whether a legitimate concern earns a screen, a sentence, or a footnote. When a stakeholder objects to a cut, work down this ladder rather than reversing the decision:

Step 5: Storyboard and Script

The storyboard is where the map becomes a course. It’s the last point at which changing your mind is cheap: a rewritten storyboard frame costs 10 minutes; the same change after the audio is recorded and the animation is built costs a day. It’s also the single deliverable that tells you whether the instructional design behind a course is real design or just content formatting.

Medium doesn’t matter much. A Word table, a Google Slides deck with the script in the notes field, or a shared spreadsheet all work. For branching scenarios specifically, mapping the tree in Twine or a Miro board before writing frames will save you from a structure that can’t be built.

What a storyboard frame contains

Writing narration people don’t tune out

Complement the screen, don’t read it. If narration duplicates on-screen text word for word, you’ve created redundancy that increases cognitive load rather than reducing it. This is Mayer’s redundancy principle, and it’s one of the most consistently ignored findings in corporate eLearning. Learners read faster than you speak, finish first, and then have to wait. The screen shows the structure; the narration supplies the reasoning, emphasis, and connective tissue between ideas.

Write for the ear. Short sentences. One idea each. Read every line aloud before it’s approved — anything that makes you run out of breath or stumble gets cut. Subordinate clauses that read fine on a page fall apart when spoken.

Second person. “You’ll need to check” beats “the learner should check.”

Front-load meaning. The point goes in the first half of the sentence. Learners who drift return mid-sentence, and they should land on something useful.

No idioms if translation or non-native speakers are in scope. They don’t survive either.

Visual design: what the screen is doing instructionally

The “Visual” field is where most storyboards go vague — “relevant image here” is a decision deferred, not made. Three rules keep visuals working for the objective rather than decorating around it.

Every image earns its place or it goes. Mayer’s coherence principle is blunt about this: images, music, and animation that don’t support the instructional point measurably reduce learning. A stock photo of a smiling team in a meeting room is not neutral filler — it’s competing for the attention your diagram needs.

Put labels next to what they label. Mayer’s contiguity principle. A diagram with a numbered key underneath forces the learner to hold arbitrary numbers in working memory while their eyes travel. Labels on the diagram, in place, cost nothing and work better.

Set a small type and colour system once. Two type sizes for body and headings, one accent colour for interactive elements, and a rule that the accent colour is never used decoratively. Learners work out within two screens that “orange means click,” and that consistency does more for usability than any individual screen design.

On sourcing: stock libraries are fine for context and terrible for anything specific to your systems. Screenshots of your actual software, redacted where needed, beat any illustration of a generic interface. If you’re commissioning custom illustration or animation, lock the storyboard first — illustration is the most expensive thing in the build to revise after the fact.

Voiceover: human, synthetic, or none

Whichever you choose, build a pronunciation list for domain terms, product names, and acronyms before recording, and record room tone so edits can be patched later without an audible seam. If translation is planned, the decision above is really a decision about re-recording cost in every target language.

The facilitator map

If your architecture includes a facilitator — a guide, presenter, or character — decide screen by screen when they appear. A facilitator on every screen becomes wallpaper. One who appears with purpose stays meaningful.

Present when introducing the module, asking a question, delivering feedback, connecting sections, or summarizing — moments of address, where someone is speaking to the learner. Absent when a scenario, animation, or comparison should carry attention on its own. A character standing beside a diagram they aren’t explaining is competing with it.

Feedback is scripted here, not later

Every interaction needs its responses written at storyboard stage — including the wrong ones. For each response option, script what the learner chose, why it’s right or wrong (the reasoning, not the verdict), and what the correct thinking looks like.

Write the wrong-answer feedback first. It’s harder, it’s more valuable, and if you can’t articulate why a distractor is tempting, the distractor probably isn’t good enough.

Review the storyboard before you build

• SME — for accuracy only. Give them a specific brief: check the facts, not the wording. SMEs asked for general feedback will add content, and every addition costs time you already budgeted.
• A representative learner — for comprehension. One person from the actual audience, reading it cold. This costs 20 minutes and catches things no amount of internal review will.
• The project sponsor — for scope. Confirming the storyboard is the course prevents the late-stage additions that blow deadlines.

Step 6: Build Interactivity That Teaches

If the answer is no, you’ve built a delivery mechanism, not a learning activity. Click-to-reveal that hides four bullets behind four icons is a slower way to read four bullets. The learner isn’t thinking — they’re operating.

Decorative vs. instructional

The pattern on the right: the learner has to decide something, and the decision can go wrong in an instructive way. Drag-and-drop and click-to-reveal aren’t inherently decorative — they become instructional when the sorting requires judgment rather than recall.

What “engagement” actually means here

Almost every guide to effective eLearning tells you to make the course engaging, and almost none define it — which is how “engaging” came to mean animation, colour, and things that move when you click them. That definition is why so many well-produced courses change nothing.

A more useful definition: a learner is engaged when they are doing cognitive work that could fail. Retrieving something from memory, committing to a judgment, resolving a case where two rules conflict. That’s the state where learning happens, and it’s uncomfortable — which is precisely why polished, frictionless modules feel good and teach little. Novelty and visual appeal buy attention for the first minute; only difficulty that the learner can succeed at holds it after that.

This is also the honest answer on gamification. Points, badges, and leaderboards reliably increase completion rates and reliably do nothing for transfer when they’re layered over passive content. Where gamified elements do work is when the game mechanic is the practice — a scored simulation where the score reflects real decision quality, not a badge for finishing screen 12.

Prediction before instruction

The highest-value interaction in most modules costs almost nothing to build: ask the learner to commit to an answer before you teach the concept. It manufactures a knowledge gap the learner feels directly, and the explanation that follows lands as an answer rather than as information. The research literature calls the underlying effect productive failure or the pretesting effect.

• No penalty for being wrong. If it’s scored, learners stop guessing honestly and start hunting for the safe answer.
• The answer must be genuinely non-obvious. If most people get it right cold, no gap opened and you’ve wasted a screen.
• Feedback explains, never just corrects. The learner who guessed right also needs to know why — otherwise they’ve learned nothing except that they’re lucky.

Branching scenarios

The strongest interaction available in self-paced eLearning, and the most frequently overbuilt — which is why mature scenario based eLearning services fix the size of the tree at storyboard stage, before anyone opens an authoring tool.

Structure: a realistic situation, a decision with 3–4 plausible options, a consequence that follows logically, then either a continuation or a return with new understanding.

How many branches is enough? Two or three decision points, each with 3–4 options. Beyond that, authoring cost rises steeply while learning gain flattens. A twelve-node branching tree usually indicates someone enjoying the tool.

Wrong answers must be genuinely tempting. Build distractors from what people actually do wrong on the job — the shortcut that usually works, the assumption that’s right 80% of the time, the reading of the rule that’s defensible but incorrect. If your wrong answers are strawmen, learners pattern-match to “the responsible-sounding one” and never engage.

Consequences beat verdicts. Showing what happens next is more instructive than announcing “incorrect.” The consequence is the teaching.

Feedback is the interaction

Level 3 is the only one worth building interactions for. Coaching feedback should also address near-misses: a learner who chose a defensible-but-wrong option needs different feedback from one who chose a clearly wrong option.

How much interactivity is enough?

There’s no ratio worth chasing. Interactions per screen is a vanity metric that produces exactly the click-to-reveal padding this step is warning against. A more useful framing: every objective should have at least one moment where the learner does the thing. If an objective says apply, decide, or determine, there must be a screen where they apply, decide, or determine.

Step 7: Design Assessments Aligned to Your Objectives

An assessment has one job: tell you whether the objectives were met. Get this wrong and you’ll report a 92% pass rate on a course that changed nothing, and nobody will know until the original problem resurfaces.

Constructive alignment

Every question traces to an objective. Every objective has at least one question. Build the trace table before writing anything.

Two failure modes this exposes immediately. Orphan questions serve no objective — usually leftovers testing something interesting from the content. Cut them. Uncovered objectives mean you claimed a capability and never checked it.

The third column catches the subtler failure. If your objective says determine which party bears responsibility and your question asks which of the following is the definition of…, the question tests recall where the objective claimed judgment — a Bloom-level mismatch. This is the single most common assessment error in corporate eLearning, and it’s why courses pass everyone and change nobody.

Writing multiple-choice questions that aren’t giveaways

Most corporate MCQs can be passed without taking the course. The tells are structural, and learners spot them fast. The rules below are the practical core of Haladyna’s item-writing guidelines, which is the standard reference if you want the full set.

1. Make distractors plausible. Every wrong option should attract someone holding a real misconception. If a distractor is obviously absurd, your four-option question is really a two-option question.
2. Keep options parallel in length and structure. The longest, most qualified option is correct often enough that experienced test-takers just pick it.
3. Avoid “all of the above” and “none of the above.” Recognizing two correct options is enough to select “all of the above” without knowing the third.
4. Cut absolutes. Options containing “always” and “never” are almost always wrong, and learners know it.
5. Put the question in the stem. The stem should pose a complete question answerable without seeing the options.
6. Avoid negatives. “Which of the following is NOT…” tests careful reading more than understanding. If you must, bold the negative.
7. One defensible answer. Have your SME answer the assessment cold — any hesitation marks a question to rewrite.

Knowledge checks vs. assessments

Scoring a knowledge check kills its value — learners stop engaging honestly and start protecting their score. Spacing knowledge checks across the module rather than clustering them at the end also gives you retrieval practice, which is one of the few reliably evidence-backed ways to slow the forgetting curve Ebbinghaus described.

Pass marks and retries

Pass mark: 80% is the common default and it’s arbitrary. Ask instead: how many of these questions could someone get wrong and still perform the task safely? In compliance topics where any error carries real consequence, that number may be zero, and the assessment should be short enough to make 100% reasonable — a threshold that belongs in your compliance training plan alongside audit and refresher cycles, not in the authoring tool’s default settings. For broad foundational knowledge, 70–80% is defensible.

Retries: allow them, but not immediately and not with the same question order. A learner who fails should be routed back to the relevant content, not straight into a re-sit where they brute-force by elimination.

Track the right data

• Score per objective, not just overall. An 80% average hides the fact that everyone failed objective 3.
• Which distractors were chosen. A distractor selected by 40% of learners is a live misconception and tells you exactly which screen to fix.
• First-attempt scores separately from post-retry. Post-retry data flatters everything.
• Time on assessment. Suspiciously fast completions suggest guessing or answer-sharing.

Step 8: Choose Your Tools — and Decide Where AI Helps

Notice this is Step 8. Seven steps of design happen before the tool question, and that ordering is deliberate: the tool doesn’t determine the course, the design does. Pick the tool that fits the design you’ve already specified — not the other way around.

What actually drives the decision

1. What does your design require? Branching scenarios, complex assessment logic, and software simulation will rule out simpler tools immediately.

2. What does your LMS accept? SCORM 1.2, SCORM 2004, xAPI, cmi5, legacy AICC, or nothing at all. Check this before evaluating anything — and if nobody on the team has published to your LMS before, work through how to create SCORM content first, because packaging assumptions are cheaper to fix now than at launch.

3. Who’s building and maintaining it? A dedicated designer may justify a steeper learning curve; a subject-matter expert building content in the gaps between other work does not. Where there’s no one to own the tool long-term, outsourcing the build is usually cheaper than buying a license nobody has time to learn.

4. How often will it change? Content that updates quarterly needs a tool where updates are cheap. Video-heavy formats are expensive to revise; text-and-template formats aren’t.

The categories — and what’s in them

Licensing sits broadly in three bands: free and open-source; per-seat desktop licences in the low hundreds to roughly one to two thousand dollars a year; and enterprise cloud platforms quoted per organization, usually four figures and up. Pricing changes constantly, so treat this as a shape rather than a quote and check current rates directly.

Short version. If your design has real branching or simulation, you need a timeline tool. If it doesn’t, and the content changes often, a cloud collaborative tool will cost you less over three years. If you’re a one-person team producing a handful of modules a year, start with whichever tool your LMS vendor already integrates with, and only move when a design requirement forces it.

Where AI genuinely helps

AI is useful in this process, and specifically useful in ways that map to the drafting work rather than the design work. That split — draft vs. decide — is the whole practical boundary of AI for instructional design. General-purpose assistants (ChatGPT, Claude, Gemini) cover the writing tasks below; the AI features now built into most authoring tools, and dedicated generators like Synthesia or Colossyan, cover media production.

• First-draft narration from your storyboard’s on-screen text — you’ll rewrite it, but rewriting beats starting blank
• Distractor generation — ask for common misconceptions, then filter for the ones your audience actually holds
• Summarizing SME interviews and transcripts into structured content
• Alt text for images at volume
• Translation first passes, with human review
• Rewriting for reading level and stripping idioms for non-native audiences
• Generating scenario variations once you’ve written one good one
• Checking objectives for observable verbs — a mechanical check it does reliably

Where AI fails

Writing objectives from a vague brief. AI produces clean, plausible, measurable-looking objectives from a two-line request. They’ll be generic, because it can’t do the Step 1 diagnostic — it doesn’t know what’s failing on your job, and it will confidently fill that gap with something reasonable-sounding.

Factual accuracy on internal or specialized content. Anything about your policies, systems, or regulatory context. It produces fluent errors, and fluent errors are harder to catch than obvious ones.

Scenario nuance. AI-generated scenarios trend toward the obvious — the wrong answers are wrong for clear reasons. The distractors that teach are the ones that are nearly right, drawn from what competent people actually do.

Accessibility judgment. It can generate alt text; it can’t decide whether an interaction is usable by keyboard or whether color is carrying meaning.

The whole course. Tools that generate a finished module from a prompt or an uploaded document produce a structured summary of your source material — which is exactly the failure mode Step 4 exists to prevent. They’re genuinely useful as a first draft of content you’ll then restructure against objectives. They are not a course.

Step 9: Check Accessibility and Mobile

The standard for most organizations is WCAG 2.1 Level AA, which is the technical benchmark referenced by Section 508 and ADA-related requirements in the US, EN 301 549 in the EU, and AODA in Ontario. In many jurisdictions it’s a legal requirement for public-sector and public-facing content. We’ve written a full practical guide on accessible eLearning — here are the essentials.

1. Captions on everything with audio. Accurate, synchronized, with speaker identification where more than one voice appears. Auto-generated captions are a starting point, not a deliverable — they mangle exactly the domain terminology your course exists to teach. Provide transcripts as well.
2. Color contrast of at least 4.5:1 for normal text, 3:1 for large text and meaningful graphical elements. Test with a contrast checker rather than judging by eye.
3. Never let color carry meaning alone. Red for wrong and green for right is invisible to a substantial portion of your audience. Pair color with an icon, a label, or text.
4. Full keyboard operability. Every interaction reachable and operable by Tab, Enter, and arrow keys, with a visible focus indicator.
5. Logical reading order for screen readers. The order elements are announced should match the order they’re meant to be understood in — not the order they were placed on the canvas. Test with an actual screen reader.
6. Meaningful alt text on informative images. Describe what the image communicates, not what it depicts. Mark decorative images as decorative.
7. Learner-controlled timing. No auto-advance, no forced pacing, no time-limited responses unless the time limit is itself the thing being assessed.
8. No autoplay audio, and always provide a visible pause control.
9. Avoid flashing content — nothing flashing more than three times per second.
10. Text that resizes. Content should remain usable at 200% zoom without horizontal scrolling or overlapping elements.

Mobile

• Hover doesn’t exist. Any interaction depending on hover is unusable on touch.
• Drag-and-drop is unreliable on small screens. Provide an alternative selection method.
• Tap targets of at least 44×44 pixels with adequate spacing.
• Test in portrait. Most people won’t rotate.
• Confirm the LMS mobile experience. Some LMSs render fine and fail to record completion on mobile.

Step 10: Pilot, QA, and Revise

Pilot and QA typically take 10–15% of total project time, and it’s the first thing cut when a deadline slips — usually at the cost of a post-launch fix that takes longer than the pilot would have.

Run QA before the pilot

Don’t waste pilot participants’ attention on typos and broken links. Fix the mechanical problems first, then put it in front of people.

Content: spelling and grammar including text inside images · terminology consistent throughout · narration matches on-screen text as scripted · facts verified against the SME-approved storyboard · no placeholder text surviving anywhere.

Function: every navigation button and link works · every interaction responds correctly to every option · feedback displays as scripted including for wrong answers · assessment scores calculate correctly (test a deliberate fail, a borderline pass, and a perfect score) · retry paths behave as designed · resume works.

Media: audio levels consistent across screens · no clipping or background noise · animations complete before narration moves on · images render at correct resolution · captions synchronized and accurate.

Technical: completion reports to the LMS correctly · score passes through including per-question data · works in every supported browser · works on mobile in portrait · actual seat time matches the stated duration.

The pilot

Who: five to eight people from the actual target audience. Not stakeholders, not the project team, not people who already know the content. Stakeholders review whether the course matches what they asked for; pilot participants reveal whether it works, and those are different questions.

Ask afterwards: where did you get stuck? What felt like a waste of your time? What would you do differently at work tomorrow? Avoid “did you like it?” — reaction data invites polite approval that tells you nothing.

Deciding what to act on

• Fix now — anything preventing completion, anything factually wrong, anything multiple participants stumbled on, any accessibility failure.
• Fix if cheap — single-participant confusion on a minor point, wording improvements, pacing tweaks.
• Log for version 2 — structural changes, requests for additional content, anything requiring re-recording or rebuilding.
• Don’t fix — preferences that conflict with the design rationale. If someone wants the objectives on screen one, that’s a preference against a deliberate decision. Note it, keep the decision, and be able to explain why.

Then launch properly

• Confirm the correct version is deployed and the old one retired
• Check enrollment and assignment rules reach the right people
• Tell learners what the course is for and how long it takes
• Give them a route to report problems, and monitor it for the first fortnight
• Capture your baseline metric before launch — the observable measure agreed in Step 1. After launch is too late.

Who owns it after launch

Courses decay. Systems get new interfaces, policies get amended, the person in the scenario leaves the company. A module nobody owns quietly becomes wrong, and learners who spot one outdated screen discount the whole thing.

• Name an owner at launch — usually the SME’s team, not L&D. They’re the ones who’ll know when the policy changes.
• Set a review date, annually at minimum, and sooner for anything tied to regulation or software UI.
• Keep the source files and the storyboard together with a version number that matches the published package. Rebuilding a module because nobody could find the project file is a depressingly common expense.
• Log change requests centrally rather than fixing ad hoc, and batch them into a scheduled version 2. Continuous small edits to a live SCORM package create version mismatches in learner records.
• Retire deliberately. When a course is superseded, unassign it and archive it. Orphaned mandatory modules are why completion dashboards stop meaning anything.

Step 11: Measure Behavior Change, Not Completions

Every previous step was preparation for this one. If you can’t say whether the course changed anything, you built a completion record.

Completion rate is a vanity metric

None of these answer the only question that matters: is anyone doing the job differently?

The Kirkpatrick levels, in plain language

The Kirkpatrick Model is the standard evaluation framework in corporate L&D, and the Phillips ROI Methodology adds a fifth level converting Level 4 results into a financial return.

Level 1 — Reaction. Did they find it useful and relevant? Cheap to collect, weakest signal.

Level 2 — Learning. Can they demonstrate the capability immediately after? This is your assessment. Necessary, not sufficient.

Level 3 — Behavior. Are they doing it differently on the job, weeks later? This is where training either works or doesn’t.

Level 4 — Results. Did the organizational metric move — errors, costs, cycle time, incidents? This is the level where a course stops being a training statistic and starts being an eLearning ROI figure you can defend in a budget conversation.

Level 5 — ROI (Phillips). Results converted to money and set against the fully loaded cost of the program. Worth doing when the spend is large enough that someone will ask, and only when Level 4 data is solid enough to survive scrutiny.

Choose the metric before you build

Go back to the third diagnostic question in Step 1: “What would we see change if this worked?” That answer is your Level 3 metric, and you agreed it before development started. A usable Level 3 metric is:

• Observable — a countable event, not a state of mind
• Attributable — plausibly influenced by this course
• Already tracked, or cheap to track — if measuring costs more than the course, pick something else
• Baselined before launch — otherwise you have a number with nothing to compare it to

A realistic measurement plan

The worked example column uses illustrative numbers to show the shape of a usable plan — the point is that each row has a specific figure attached before launch, not after.

Why 30 and 90 days. Thirty days shows whether anything transferred at all. Ninety shows whether it stuck — and it’s the interval where training effects most often decay quietly back to baseline. A metric that improves at 30 days and reverts at 90 is telling you the environment doesn’t support the new behavior, which is a Step 1 finding arriving late.

Keep Level 1 to three questions: Was it relevant to your job? What will you do differently? What was missing? The second one is the useful one — vague answers signal the course didn’t produce a clear behavioral takeaway.

If the metric didn’t move, check in this order

1. Did they learn it? Assessment scores low → the teaching failed. Go back to Steps 5–6.
2. Did they learn it but not apply it? Scores high, behavior unchanged → a transfer problem, usually environmental. Which is the Step 1 diagnostic, confirmed the expensive way.
3. Was the metric wrong? Too distant from what the course taught, too noisy, or contaminated by something else.

Report it either way. L&D functions that only report wins get treated as marketing. Ones that report honestly get treated as a source of evidence.

Roles, Timeline, and What It Costs

Two questions come up on every project and almost never get answered in guides like this one: who needs to be involved, and how long does it take.

On small projects one person wears several of these hats. What can’t be collapsed is the SME and the sponsor — those are the two roles you can’t do on someone’s behalf.

Development effort. The most-cited benchmark is the Chapman Alliance survey, which put development at roughly 79 hours per finished hour of basic, largely linear eLearning; around 184 hours for interactive courses with scenarios and custom assessment; and around 490 hours for advanced simulation. Those figures date from 2010 and modern cloud tooling has compressed the lower tiers considerably, but the ratio between tiers still holds: an interactive course costs roughly two to three times a linear one, and a simulation several times that again. Use it to argue about scope, not to build a quote.

Calendar time. For a single 20–30 minute interactive module, five to seven weeks is a realistic end-to-end schedule with normal review cycles. The variable that blows schedules is almost never build time — it’s SME availability and the number of review rounds nobody agreed a limit on in advance.

10 Mistakes That Kill eLearning Courses

Quick Glossary

Frequently Asked Questions

How do you make a good eLearning course?

Confirm the problem is actually a knowledge gap, write objectives you can observe and measure, structure the course around those objectives rather than around the source material, make learners decide something before you teach them, and agree how you’ll know it worked before you start building. The production values matter far less than that sequence — a plain module built this way outperforms a beautifully animated one built from a slide deck.

What tools do you need to create an eLearning course?

At minimum, an authoring tool and an LMS. Slide-based tools like iSpring suit linear narrated modules; timeline tools like Articulate Storyline 360, Adobe Captivate, and Lectora handle branching and simulation; cloud tools like Rise 360, Elucidat, and Easygenerator suit teams and frequent updates; H5P and the Adapt Framework are the main open-source options. Delivery runs through an LMS such as Moodle, TalentLMS, Docebo, Absorb, or Cornerstone. Choose in that order — design first, then the tool that supports it, checked against what your LMS accepts.

What are the three P’s of e-learning?

The phrase gets used two ways. In corporate L&D it usually means Pedagogy, Platform, and People — the teaching approach, the technology delivering it, and the learners and stakeholders around it, with the argument being that all three have to be right for a program to work. In language teaching and some classroom contexts it refers to the Presentation, Practice, Production lesson sequence. Neither is a formal standard, so if someone uses the phrase, it’s worth asking which one they mean.

Can ChatGPT create an eLearning course?

It can produce a course-shaped document quickly, and that isn’t the same thing. What it does well is drafting: narration from your on-screen text, distractor candidates, transcript summaries, alt text, translation first passes. What it can’t do is the diagnosis in Step 1, judge which wrong answers are genuinely tempting for your audience, or verify anything specific to your policies and systems — it produces fluent errors that are harder to spot than obvious ones. Use it to draft what you’ve already decided, not to make the decisions.

How long should an eLearning course be?

20–30 minutes for a self-paced module in a work context, broken into segments of 5–7 minutes. If your map runs longer, split it into another module rather than compressing the pacing. Longer formats are defensible for certification paths or onboarding programs where learners have protected time — not because there was a lot of content.

How long does it take to build one, and what does it cost?

Five to seven weeks is realistic for a single interactive 20–30 minute module including review cycles. Effort scales sharply with interactivity: the widely cited Chapman Alliance benchmark put basic linear eLearning at around 79 development hours per finished hour and interactive courses at around 184, with simulation several times higher again. Modern cloud tools have compressed those numbers, but the ratio between tiers is still the useful part. The most common cause of overrun isn’t build time — it’s SME availability and unlimited review rounds.

ADDIE or SAM — which should I use?

Either, and the difference matters less than most discussions of it suggest. ADDIE suits projects with stable requirements and a defined sign-off process; SAM suits projects where the requirements will change once stakeholders see something concrete. Both require the same underlying decisions — diagnosis, objectives, structure, interaction design, assessment, evaluation. A team that skips the analysis will produce a weak course under either model.

How do you measure whether an eLearning course worked?

Not by completion rate. Use the Kirkpatrick levels: reaction and assessment scores at completion, then the behavioral metric you agreed in Step 1 read at 30 and 90 days against a baseline captured before launch. Thirty days shows whether anything transferred; ninety shows whether it stuck. If a clear organizational metric exists — error rates, cycle time, incidents — read that after 90 days as your Level 4.

What Your Next Course Owes Its Learners

Nobody’s 25 minutes are free, and an eLearning module that everyone completes and nobody applies costs an organization more than it saves. The real standard isn’t engagement, satisfaction, or a green dashboard — it’s whether someone can do the job better on Monday. That’s the test every one of these eleven steps exists to pass, and it’s why knowing how to create effective eLearning courses starts with a diagnosis and ends with a number, not with an authoring tool. It’s the same standard we hold our own custom eLearning development services to on every project.