What Is the ADDIE Model?

ADDIE is a five-phase framework that instructional designers and corporate learning and development teams use to build training programs. The name stands for Analysis, Design, Development, Implementation, and Evaluation, and each phase produces something the next phase depends on. Florida State University’s Center for Educational Technology built the original version of the model in the 1970s for military training, and it has stayed the default starting point for instructional design work since. If you work in L&D, sales enablement, or any function that builds training for other employees, you have probably used some version of ADDIE without calling it that.

Teams reach for a structured model like ADDIE because building training without one tends to produce the same failure pattern: someone builds a course based on what they assume reps need, ships it, and finds out months later that it never addressed the actual performance gap. ADDIE forces a team to define the problem and the success measure before anyone opens a slide deck or a script editor, then checks the work at each stage instead of only at the end.

To make the five phases concrete, picture a 400-person software company whose new sales reps take five months to reach full quota, compared with three months for reps hired two years earlier. The VP of sales enablement gets asked to fix ramp time. Here is how ADDIE would carry that project from a vague complaint to a shipped training program.

Analysis

The Analysis phase asks what problem the training is supposed to solve, and whether training is actually the right fix for it. This is where a team gathers evidence instead of guessing at content. In the ramp-time example, the enablement team interviews five sales managers, pulls win-loss data from the CRM, and listens to a sample of discovery calls from newer reps.

The interviews turn up a specific gap. Reps understand the product well by month two, but they freeze when a procurement lead pushes back on price or a legal reviewer raises a contract objection in real time. That distinction matters, because it points the rest of the project toward practice and away from another round of product training videos.

A good Analysis phase ends with a written problem statement and a target metric, the two things the rest of the project gets checked against. In this example, the statement is short: reps lose deals at the procurement stage because they have not practiced handling live pushback, and the target is closing that gap within one quarter. Everything built in the next three phases gets checked against that statement.

Design

Design turns the problem statement from Analysis into a blueprint. This phase sets learning objectives, decides how content will be sequenced, and defines how success will be measured before anyone builds a single asset. Skipping it is how teams end up with training that covers the wrong material in the wrong order.

For the ramp-time project, the enablement team decides reps need repeated practice against three objection types before their first live call with a procurement stakeholder: price pushback, contract stalling, and competitor comparisons. They storyboard what each practice scenario should cover and agree that success means a rep can handle all three objection types without a manager stepping in.

The output of Design is usually a planning document: objectives written in observable terms, a rough outline of each module or scenario, and an assessment plan describing how a manager or the system itself will judge whether a rep has actually learned the skill. A subject matter expert, often a top-performing rep or a sales director, usually reviews this outline before Development starts, which catches gaps while they still cost a paragraph to fix instead of a finished module.

Development

Development is where the blueprint becomes real material: scripts, slides, videos, job aids, or practice scenarios. This is usually the slowest phase in a traditional ADDIE project, because writing realistic dialogue, recording video, or building a full e-learning module can take weeks of work per hour of finished training. It is also the phase where most review cycles pile up, since a subject matter expert has to check each draft against how a real conversation actually goes.

This is also the phase where AI roleplay changes the math. Instead of scripting every branch of an objection-handling conversation by hand and waiting for a full course to be built before anyone can try it, a team can build a rough draft of a scenario from real call transcripts and sales scripts, test it the same week, and refine it against actual objections instead of guessing at dialogue up front. Yoodli has a walkthrough of how to train AI roleplay on your own sales content that covers what that build process looks like in practice.

Yoodli has also moved content creation into the roleplay builder itself. With auto-generated learning content, which launched in June 2026, an admin uploads existing decks, product briefs, or playbooks and gets structured learning content back in minutes. The admin can then edit it, regenerate sections, and export it as a PDF or PowerPoint. That work used to take weeks.

Implementation

Implementation is when the training goes live in front of the learners it was built for. A rollout plan usually covers who gets trained first, how instructors or managers are briefed, and what support exists if something in the material does not land.

For the objection-handling program, enablement pilots the three scenarios with one five-person pod before rolling them out to the full 40-person team. Because the scenarios are AI roleplays rather than a finished instructor-led module, the team can pilot in week two instead of week eight, and adjust a confusing scenario branch based on manager feedback without re-shooting video or rewriting a slide deck. Managers get a short briefing on how to review a rep’s scored practice sessions before the pilot pod starts, so coaching conversations reference the same data the reps are practicing against. Teams weighing a similar pilot can talk to Yoodli’s team about what a first scenario build and pilot typically involves.

Evaluation

Evaluation measures whether the training worked. For the ramp-time project, that means comparing the pilot pod’s time to full quota against a control group of reps who did not get the new practice scenarios, tracking manager scores on live objection-handling calls, and checking win rate at the procurement stage after 90 days.

In a mature ADDIE process, evaluation happens at the end of each phase, not only once at the very end of the project. A team checks whether Analysis correctly identified the gap, whether Design’s objectives still make sense once real learners see the material, and whether Development produced something Implementation can actually use. Waiting until the end of a multi-month project to find out the objectives were wrong is an expensive way to learn that.

Many L&D teams pair ADDIE’s Evaluation phase with Kirkpatrick’s four levels: how learners reacted to the training, what they actually learned, whether their behavior on the job changed, and what business result followed. For the ramp-time project, reaction shows up in pilot feedback, learning shows up in scenario scores, behavior shows up in manager observation of live calls, and the business result is the ramp-time number itself, checked again after a full quarter rather than guessed at from the pilot alone.

Waterfall in Theory, Iterative in Practice

Many teams run ADDIE as a strict waterfall. Analysis finishes and gets signed off, then Design starts and finishes and gets signed off, and so on through five stages that never reopen once closed. That version of the model creates long project timelines and locks a team into decisions made during Analysis long before anyone sees a working scenario or module. A stakeholder who only sees the finished product in week ten of a ten-week project has no real chance to catch a wrong assumption from week one.

The instructional design work behind ADDIE was iterative by intent, with each phase feeding information back into the ones before it. A team building the objection-handling program can develop one rough scenario as soon as Design produces a first objective, test it with two reps, and use what they learn to adjust their Analysis assumptions before building the rest. AI roleplay fits naturally into that loop, since a single scenario can be piloted before a full curriculum exists, which shortens the distance between Design, Development, and Implementation instead of treating them as three sealed boxes.

The Five Phases in Practice

ADDIE gives L&D and sales enablement teams a shared vocabulary for talking about training projects, whether a given team runs it as five strict stages or as a loop that revisits Analysis after every pilot. Analysis, Design, Development, Implementation, and Evaluation describe the order most training work naturally moves through, even when the lines between the phases blur once a project is actually underway. A team that names which phase it is in, and what that phase is supposed to produce, tends to ship training that matches the problem it set out to solve.

Teams comparing tools for the Development and Implementation phases can use Yoodli’s buyer’s checklist for AI roleplay platforms.