The ADDIE Model, Explained by a Working Course Designer

The ADDIE model is the most widely taught process in instructional design. Its five letters name the work any course needs: Analysis (who are the learners, and what must they be able to do?), Design (how will they get there, and how will we know?), Development (building the materials), Implementation (delivering the course) and Evaluation (did it work, and what should change?).

That’s the textbook answer. The more useful answer is that ADDIE is a checklist of decisions, and each phase should end with something concrete you can hold up and check. This guide walks through what each phase should produce, using a small self-paced online course as the example, and deals with the most common complaint about the model: that it’s rigid and out of date.

Where ADDIE came from, and why it matters

ADDIE is often presented as if someone designed it. Nobody did, at least not under that name.

The process behind it comes from the instructional systems design (ISD) movement of the 1960s and 70s. Its best-known ancestor is the Interservice Procedures for Instructional Systems Development, written in 1975 at Florida State University’s Center for Educational Technology for the US armed services’ joint training programme (Branson et al., 1975). As the educational technologist Michael Molenda records, its top-level phases were “analyze, design, develop, implement, and control”: close to ADDIE, but not the same.

When Molenda went looking for the original ADDIE model, he searched the field’s textbooks and histories and asked experienced practitioners. He didn’t find one.

That history matters for two reasons. First, there is no official version to follow, so the diagrams you’ll find online, circles, waterfalls and loops, are each someone’s interpretation. Second, Molenda notes that the processes are generally understood as “sequential but also iterative” (Molenda, 2015). The strictly linear ADDIE that critics like to attack is a reading of the model, not the model itself.

The five phases at a glance

Phase	The question it answers	What it should produce
Analysis	Who are the learners, and what must they be able to do afterwards?	A one-page learner and performance brief
Design	How will they get there, and how will we know they can do it?	Objectives, assessments and a course map
Development	What will they read, watch and practise?	A built, reviewed pilot module, then the full course
Implementation	How does the course reach learners, and who supports them?	A live course, a pilot group and a support plan
Evaluation	Did they learn it, and what should change?	Findings and a revision list, fed back into the other phases

To make each phase concrete, we’ll follow one example throughout: a bookkeeper building a short, self-paced online course that teaches small-business owners to reconcile their accounts every month. It’s an invented example, but it’s typical of the courses independent creators build.

Analysis: define the gap before the content

Analysis answers three questions: who the learners are, what they need to be able to do after the course, and what’s stopping them now. The last question is the one most course creators skip, and it’s the one that tells you whether a course is even the right fix.

For our bookkeeper, analysis might reveal that most business owners already understand what reconciliation is. What they lack is a routine: they put it off for months, then face hundreds of unmatched transactions. That changes the course. Less explanation, more guided practice, and a monthly checklist they’ll actually use.

What it should produce: a one-page brief covering the learners (who they are, what they already know, how much time they have), the performance goal, the gap, and the constraints (budget, platform, deadline).

Design: plan the assessment before the lessons

Design turns the brief into a plan. The most useful habit here is to design the assessment first: decide how learners will show they can do the task, then plan the lessons that get them there. This is often called backward design, and it stops a course drifting into everything the expert knows rather than what the learner needs.

For the bookkeeper, the final assessment might be a sample month of bank transactions that learners reconcile themselves. Working backwards, the course needs lessons on matching transactions, handling the awkward ones (split payments, refunds, bank fees), and building the monthly habit, each with practice before the next.

What it should produce: measurable objectives, the assessments that test them, and a course map: modules, lessons, the practice in each, and the order they come in.

Development: build one module, then stop

Development is where most of the time goes: writing, recording, building quizzes and setting up the course platform. It’s also where the most time is wasted, because problems in the design only become visible once something is built.

The fix is simple. Build one complete module first, including its practice and quiz, and put it in front of a few real learners before building the rest. For the bookkeeper, that might be the module on matching transactions. If testers stall on the practice exercise, it’s far cheaper to find out now than after recording eight more modules in the same style.

What it should produce: a finished pilot module that has been reviewed by someone who knows the subject and tried by someone who doesn’t, then the remaining modules built to the same pattern.

Implementation: launch small and support learners

Implementation is more than pressing publish. It covers setting up enrolment and access, testing the course on the devices learners will use, writing the welcome and reminder messages, and deciding who answers questions and how fast.

For a new course, a pilot cohort is worth the delay: five to ten learners who get the course free or discounted in return for honest feedback. Our bookkeeper might run the course with a handful of existing clients before opening it to the public.

What it should produce: a live course, a pilot group, a support plan, and a way to collect feedback that’s built into the course rather than bolted on.

Evaluation: measure whether they can do it

Evaluation runs throughout, not just at the end. Formative evaluation happens while you build: reviews, tests with real learners, the pilot. Summative evaluation happens after launch and asks whether the course achieved its goal.

For a self-paced course, three kinds of evidence are usually within reach:

• Can learners do the task? Results on the final assessment are the most direct evidence. For the bookkeeper, how many learners reconcile the sample month correctly?
• Where do learners struggle or stop? Quiz questions most people get wrong and lessons where people drop out point to specific fixes. Check what your course platform reports on both.
• What do learners say? A short survey at the end, and a follow-up a month later asking whether they’re still using what they learned.

What it should produce: a short findings report and a revision list, with each item tied back to the phase where the fix belongs. A confusing quiz question is a development fix; learners who didn’t need the course at all is an analysis problem.

Is ADDIE outdated?

The most common criticism of ADDIE is that it’s a waterfall: long phases completed in order, with learners seeing nothing until the end. That criticism is fair of the way ADDIE is sometimes run, and it’s the reason Michael Allen and Richard Sites proposed the Successive Approximation Model (SAM), which replaces long phases with rapid cycles of design, prototype and review (Allen & Sites, 2012).

But as we saw, the strictly linear version was never the only reading. In practice, the choice is less ADDIE versus SAM than how often you loop. For a small online course, a sensible rhythm is:

1. A short analysis and design pass for the whole course.
2. Build and test one module.
3. Revise the design based on what you learned.
4. Build the rest, testing as you go.
5. Launch to a pilot group, evaluate, and revise again.

That’s ADDIE run in loops, and it’s close to what SAM recommends. What matters is that each kind of work happens, and that evaluation feeds back into the earlier phases.

Four common mistakes

1. Skipping analysis because you’re the expert. Expertise tells you what’s true, not what learners are missing. Talk to five of them before you plan anything.
2. Writing objectives you can’t observe. If an objective starts with “understand” or “know”, rewrite it until you could test it.
3. Building everything before testing anything. Pilot one module. It’s the single biggest saving in the whole process.
4. Treating evaluation as a satisfaction survey. Learners can enjoy a course and still be unable to do the task. Measure the task.

In practice

On a short course or a microcredential, the phases rarely get equal time. Analysis and the assessment design inside the design phase deserve the most attention, because they decide what the course is for and how anyone will know it worked; development is where most of the hours go. If time is tight, protect the first two phases and the pilot, and keep the production values modest. A plain module that teaches the right thing beats a polished one that teaches the wrong thing.

What to do next

Write the one-page analysis brief for your next course before you plan a single lesson: the learners, the performance goal in one observable sentence, the gap, and the constraints. Everything else in ADDIE builds on it.