The ADDIE model of instructional design

ADDIE grew out of instructional systems development work done for the United States military in the 1970s, much of it at Florida State University. The acronym itself has no clear author. When the instructional design researcher Michael Molenda went looking for its origin in the early 2000s, he found no founding paper and no original diagram: the label had spread through practice and textbooks until everyone assumed someone else had invented it. That is worth knowing, because it explains why every organisation's ADDIE looks slightly different and why none of them is the official one.

The five phases at a glance

Analysis: the phase everyone shortens

Most failed programmes were doomed in analysis, usually because it barely happened. Somebody senior asks for a course on communication and design starts that afternoon. Nobody asks what people are doing now that they should stop doing.

Analysis has one job: turn a request into a problem you can test. "Improve communication" is not testable. "Team leads avoid raising a missed deadline with a peer until the deadline has already passed" is.

Questions to answer before you design anything

• What behaviour would change if this worked? Write it as something an observer could watch happen.
• Is the gap skill, will, or system? Training only fixes the first. If the reward structure punishes the behaviour, no course survives contact with it.
• Who is in the room, and what can they already do? Design for the middle of the group, not the keenest person in it.
• What is genuinely fixed? Time, group size, seniority mix, whether people can be taken off the floor at all.
• How will success be judged, and by whom? Agree it with the sponsor in writing before design starts, or you will be judged on feedback scores by default.

Design: decide the ending first

Design is where you write the objectives and the assessment that proves them, in that order, before touching materials. Work backwards: start from the observable end state and reason back to the first activity.

Weak objectives use verbs you cannot see. Understand. Appreciate. Be aware of. Strong objectives use verbs you can watch: give, decline, escalate, summarise, challenge, hand over.

1. Write each outcome as a visible behaviour. "Give corrective feedback using a specific example and an agreed next step" beats "understand feedback models".
2. Decide how each outcome gets practised. If an objective has no moment where someone does it, cut the objective or build the moment.
3. Sequence for difficulty and for exposure. Low-stakes practice comes before anything that puts a person on show in front of their own manager.
4. Budget time honestly. Debriefs run longer than the activities that feed them, so halve the content while it is still cheap to halve.
5. Write the follow-up measure now, while the objectives are fresh, not after delivery when nobody has the appetite for it.

If you cannot say what a learner will be doing in minute forty of the session, you have written a topic list, not a design.

Development: build the cheapest version that can fail

Development is production: exercises, briefs, facilitator guides, slides, scoring sheets. The failure mode here is polish. Teams finish beautiful materials, then discover on the first run that the central exercise does not produce the conversation it was built for.

• Prototype the core activity on paper and run it with colleagues before anything is properly built.
• Write the facilitator guide as though someone else will deliver it, because eventually someone will. Include the debrief questions, not only the instructions.
• Build for the room you will get, not the one you booked: nineteen people instead of twelve, patchy connectivity, two late arrivals.
• Keep a version of every exercise that works with no technology at all.

Implementation: the pilot is not optional

Implementation covers the pilot, facilitator preparation, logistics and the first live cohorts. Most organisations treat it as delivery. It is really the last and best test of the design.

Run the pilot with a friendly group and a genuine observer, then change something. A pilot that changes nothing was not a pilot, it was a rehearsal.

• Brief line managers before the session, not after. What people do the following Monday depends more on their manager than on your materials.
• Prepare facilitators on the debrief rather than the slides. The debrief is where the learning is made, and it is the part that needs real facilitation skill.
• Set the conditions for honesty early. Practice only works where people can be visibly bad at something first, which is a question of psychological safety.

Evaluation: the phase that gets cut

Evaluation is the phase organisations say they value and rarely fund. The common language for it is Donald Kirkpatrick's four levels, set out in the late 1950s: reaction, learning, behaviour and results. Most programmes stop at the first, because a feedback form is cheap and evidence of behaviour change is not.

1. Reaction. Did they find it useful? Ask about usefulness and intention to apply, not enjoyment. Enjoyment predicts very little.
2. Learning. Can they do it now? Watch the final practice round rather than issuing a quiz.
3. Behaviour. Are they doing it at work? This needs a check four to eight weeks later, usually through the manager.
4. Results. Did the original problem move? Only credible if you agreed the measure back in analysis.

Putting evaluation last is the most misleading thing about the ADDIE diagram. Formative evaluation belongs in every phase: test the analysis on a sceptical manager, the design on a colleague who will argue with it, the materials on a pilot group. Only the summative judgement comes at the end.

Where the model breaks down

1. It reads as sequential and rarely is. The tidy five-box diagram implies each phase closes before the next opens. Real projects loop backwards: development exposes a vague objective, implementation exposes a lazy analysis.
2. Run as a waterfall, it is slow. Long analysis and design phases push first learner contact months out, by which point the business problem has often moved. That gap is what the Successive Approximation Model, associated with Michael Allen, was built to answer: short cycles, prototypes early.
3. It says nothing about how people learn. ADDIE is a project process, not a learning theory. It will happily help you build a well-documented lecture that changes nobody's behaviour. The decisions that matter come from elsewhere: practice, feedback, spacing, experiential learning.
4. It has no canonical version, and it invites over-documentation. With no founding source, ADDIE means whatever your template says, and in a small team the paperwork can cost more than the training. The phases are questions to answer, not documents to produce.

How ADDIE compares with the alternatives

Running ADDIE without freezing

1. Timebox analysis to about a week of real effort. Interview five people, watch the work if you can, write one page.
2. Design one session properly rather than sketching a whole curriculum. Curricula written before the first session runs are mostly guesswork.
3. Prototype the hardest exercise first. If it fails, everything downstream of it changes anyway.
4. Book the eight-week follow-up in the same email as the session. Evaluation scheduled later is evaluation that does not happen.

The phase ADDIE describes least well is the one that decides everything: what happens in the room. A design can pass every review and still fail because the exercise produces polite agreement instead of friction, or because the debrief ran out of time just as it got interesting. That is why experiential sessions get prototyped on real groups early and then keep changing. You learn what a design teaches by watching people do it under pressure. Analysis tells you what should change; practice and an honest debrief are what change it.

Tour De Force runs this as live, experiential training for teams worldwide — online and in person. Talk to us, or play Gamified learning appsThe Weekly Challenge to see the method in ten minutes.