What Is ADDIE and How Do You Use It?

If you have ever been told to "use ADDIE" on a training project — by a consultant, in a job posting, or in a graduate-school assignment — you have hit the most widely-taught framework in instructional design. ADDIE has been the field's working model since the 1970s, when it was developed for the U.S. Army to systematize how training programs were built.

The acronym is straightforward: Analysis, Design, Development, Implementation, Evaluation. The five phases describe a sequence that takes a training program from the moment someone says "we need training on this" to the moment you can answer "did it actually work?"

This guide walks through each phase in plain English, names the common mistake at each one, shows how to apply the framework without spending two weeks on it, and works a real example end to end.

What ADDIE stands for

Five letters, each a phase:

• A — Analysis. What problem are we actually solving, and who are we solving it for?
• D — Design. What will the program look like and what will learners be able to do after?
• D — Development. What materials need to exist to deliver the program?
• I — Implementation. How does the program get into learners' hands?
• E — Evaluation. Did it work?

The textbook version of ADDIE treats these as sequential — finish one before starting the next. In practice, that linear sequence rarely survives contact with a real project. We will come back to that.

A — Analysis

The phase nobody wants to do, and the one that determines whether everything that follows is worth the effort.

Analysis is when you answer five questions before writing a single slide:

1. What is the actual business problem? Not "we need training on customer service." That is a symptom. The problem is "complaint volume is up 30% quarter over quarter and the satisfaction score dropped 8 points." Now you have something to solve.
2. Who is the audience? Their role, their existing skill level, their motivation, their constraints. "Customer service" is meaningless without "frontline retail staff in their first 90 days" or "ten-year tenured agents who've stopped engaging in training."
3. What is the performance gap? What can they do now versus what they need to be able to do? The gap is what training closes; everything outside the gap is wasted air time.
4. Is training even the right answer? Sometimes the problem is a broken process, an under-resourced team, or a software issue — none of which a training program will fix. Save yourself the build by asking this question honestly.
5. What are the constraints? Budget, timeline, delivery format, language requirements, audience availability, LMS compatibility. Constraints shape every later decision.

The common mistake: Skipping analysis and jumping straight to "let me start writing the slides." Done this way, training programs reliably miss the actual problem. They cover the symptom, look professional, and change nothing about the underlying number.

What good analysis produces: A one-page brief that answers the five questions above. Not a 40-page report. A page.

D — Design

With the analysis done, design is when you decide what the program will be — before you build any of it.

Three things get decided in design:

1. Learning objectives. What learners will be able to do after the training that they cannot do now. The verb matters: "list," "describe," "demonstrate," "calculate," "evaluate" are testable. "Understand," "appreciate," "be familiar with" are not. Three to five objectives per hour of training is the practical range.
2. The structure. Modules, lessons, sequence, delivery format, total run time. This is where you decide whether the program is one 90-minute session or three 30-minute sessions, whether it is live or self-paced, whether activities go in the middle or the end.
3. The assessment strategy. How will you know they learned it? A knowledge check at the end, a role-play during the session, a 30-day behavioral follow-up. Design the assessment before the content, not after — otherwise the assessment becomes "whatever happened to fit the slides."

The common mistake: Writing learning objectives like "understand customer service principles." That is not an objective. It is a topic with a verb attached. A real objective is "given an upset customer scenario, demonstrate the three-step de-escalation sequence taught in this program."

What good design produces: A storyboard or outline — module names, time allocations, learning objectives, activity types — that fits on one to two pages. That is what gets reviewed before development starts.

D — Development

The longest phase. Development is when you build the actual materials — the Student Manual, the Facilitator Guide, the Slide Deck, the quiz, the certificate, the evaluation form.

This is the phase that has changed the most in the last few years. Until recently, development took 80–160 hours for a four-hour program. With AI tools that understand training-program structure, the same materials can be drafted in minutes and refined in hours. The depth and quality of the output is largely a function of how good your analysis and design phases were — garbage in, garbage out. Tools that draft a complete kit work when you give them a tight brief; they cannot rescue a vague one.

Development also includes:

• Subject-matter expert review. Whoever has the deepest knowledge of the content needs to read the draft and flag what is missing or wrong.
• First-pass pilot. Run the program with one to three people before rolling out broadly. You will catch the things you missed.

The common mistake: Starting development before design is done — building slides that then dictate the structure backwards. The slide deck should be the output of design, not the input. If you are starting from an existing deck, you are doing reverse-development, which is its own discipline.

What good development produces: Ready-to-deliver materials that match the storyboard from design. If they do not match, either the storyboard was wrong or the development drifted; figure out which before delivery.

I — Implementation

Delivery. The actual training in front of actual learners.

The framework treats implementation as one phase, but in practice it has three sub-steps:

1. Train the trainers (if multiple facilitators will deliver the program). Hand them the Facilitator Guide, walk them through the timing cues and discussion questions, run a dry-run if possible. Trainers cannot deliver well from materials they have not seen until the morning of the session.
2. Set up the environment. Room booked, materials printed, LMS loaded, audio tested. Boring, decisive — these are what derail otherwise-solid programs.
3. Deliver. Run the session. Pay attention to what works and what doesn't in real time.

The common mistake: Treating "ready to deliver" as if it means "will go smoothly when delivered." Most program failures during implementation are facilitator-readiness failures, not content failures.

What good implementation produces: A program that ran on time, with the planned content, with engaged learners. The data you collect during implementation feeds the next phase.

E — Evaluation

The phase that almost nobody does well.

Donald Kirkpatrick's four-level evaluation model is the standard scaffolding here:

1. Reaction — Did learners like it? (The "smile sheet" at the end of training.)
2. Learning — Did they learn it? (Pre/post knowledge tests.)
3. Behavior — Are they doing it differently 30–90 days later? (Manager observation, performance metrics.)
4. Results — Did the original business metric move? (Complaint volume, sales numbers, error rates.)

Most organizations measure Level 1, sometimes Level 2, rarely Level 3, and almost never Level 4. The further down the levels you go, the more expensive and politically difficult the measurement becomes — and the more useful the answer.

The common mistake: Conflating "the smile sheet was good" with "the training worked." High Level 1 scores are necessary but nowhere near sufficient. Plenty of programs participants enjoyed have moved zero needle on the metric the analysis identified.

What good evaluation produces: Evidence — at any of the four levels — that informs whether to keep, kill, or revise the program. Programs that aren't evaluated tend to stay in the catalog forever regardless of whether they work.

The honest critique of ADDIE

ADDIE has been around since the 1970s. It has been critiqued, replaced, supplemented, and brought back many times since.

The most common criticism is that the textbook sequence is waterfall — finish one phase before starting the next — in a world that rarely accommodates that pace. Programs get scoped on the fly. SMEs disappear during development and return during pilot with rewrites. Business priorities shift mid-build.

Newer frameworks like SAM (Successive Approximation Model) and Agile L&D propose iterative cycles instead — build a rough version fast, get it in front of learners, refine. These approaches are popular for good reason; they handle real-world chaos better than the textbook ADDIE waterfall does.

In practice, most working L&D teams blend the two. They use ADDIE as the mental checklist — did we analyze the problem, design the program, develop the materials, implement well, evaluate the results? — without enforcing the strict sequence. Skipping any one of the five letters is what gets you in trouble. The order in which you visit them, and how many times, is negotiable.

How to use ADDIE without spending two weeks on it

The version of ADDIE taught in graduate school assumes you have weeks per phase. Most trainers and SMEs building real programs do not.

Here is the lightweight version that retains the discipline without the bureaucracy:

• Analysis: 30–60 minutes. A conversation with the stakeholder plus a look at the metric you're trying to move. Write the five-question brief. One page, plain text.
• Design: 1–2 hours. Three to five learning objectives, a one-page storyboard, an assessment plan. Sketch it on a whiteboard or in a doc — anything that can be reviewed quickly.
• Development: hours to days. With AI-assisted tools, a complete first draft of all materials in minutes. With manual drafting, days. Either way, plan for a focused review pass before declaring it done.
• Implementation: as long as the program runs. Plus 30 minutes per facilitator for a walkthrough.
• Evaluation: ongoing. A Level 1 survey at the end, a Level 2 knowledge check during or after, a Level 3 manager check-in 30 days later. You do not need a formal study — just a structured look at whether the metric moved.

Done this way, a small training program can run through ADDIE in two to three days of focused work, not two months.

A worked example: a one-hour customer service refresher

A retail manager has a problem: customer complaints are up 30% this quarter, and exit surveys consistently mention "the cashier seemed annoyed." She has a 20-person team and one hour to train them.

Analysis (45 minutes): She talks to her two strongest cashiers, reads through 20 recent complaints, and identifies the pattern — the team is making transactional contact (process the order) instead of relational contact (greet, acknowledge, thank). The brief: complaint volume needs to drop by Q4; the audience is 20 cashiers at varying tenure; the gap is between transactional and relational engagement; constraints are one hour, one in-person session.

Design (90 minutes): Three learning objectives:

1. Greet every customer within five seconds of approach using one of three prescribed openers.
2. Acknowledge customer complaints using the three-step framework taught in this session.
3. Close every transaction with a sincere personalized thank-you.

The structure: 10-minute intro on why this matters (with two real complaint quotes); 30 minutes covering the three behaviors with demonstration and role-play; 15 minutes of practice in pairs; 5-minute commitment exercise. Assessment: role-play observation at the end plus a 30-day complaint-count comparison.

Development (4 hours, AI-assisted): A complete kit — Student Manual with the three frameworks, Facilitator Guide with timing and role-play prompts, Slide Deck with the demonstration sequence, a job aid with the three openers printed wallet-sized, a five-question knowledge check.

Implementation (1 hour): She delivers the session to all 20 cashiers in a single Tuesday morning meeting, with the assistant manager observing and noting which behaviors landed.

Evaluation (30 days): End-of-session reaction survey (Level 1) — 4.4 of 5. Knowledge check (Level 2) — 18 of 20 cashiers passed. Manager observation (Level 3) — within two weeks, the new greeting was happening with about 70% of customers. Complaint volume (Level 4) — down 18% by week 4.

Total time invested: 7 hours over three days. Total documents produced: 6. Evidence of impact: yes.

That is ADDIE compressed for a real-world constraint. The framework did not slow her down. It made sure she did the things she would have skipped under pressure.

Why ADDIE still matters in 2026

AI tools have collapsed the time required for the development phase. What used to take 80–160 hours of a designer's time now takes minutes for a first draft. That is real, and it has changed the field meaningfully — most of the cost of building a training program used to live in Development, and that line item is now a fraction of what it was.

What AI has not done is reduce the importance of the other four phases. Analysis still requires human judgment about what problem is worth solving. Design still requires deciding what good performance looks like and how to measure it. Implementation still happens in front of real humans who notice if the facilitator is unprepared. And evaluation still gets skipped in 80% of programs, regardless of how the materials were built.

The trainers who get the most value from AI tools are the ones who run a tight analysis and design before they prompt anything — and who measure honestly after. The framework has not changed. The tools that handle one phase of it have just gotten much better.

If you want to see what a coordinated, well-developed training kit looks like — the Student Manual, Facilitator Guide, Slide Deck, and knowledge check all built together — download a free sample. The output reflects an ADDIE-trained design philosophy applied at speed: skip analysis at your peril, design before you develop, evaluate or don't bother.