ADDIE vs SAM – Which Instructional Design Model Should You Use?

You have a new project, a deadline and a stakeholder who wants to see something soon. One colleague swears by ADDIE, while another says ADDIE is too slow and you should use SAM. Both have a point, and both can be wrong for a given project. So in the ADDIE vs SAM decision, which model should you actually use?

Use ADDIE when requirements are fairly stable, the stakes or regulations demand documented decisions and many stakeholders must agree before you build; use SAM (the Successive Approximation Model) when requirements are fuzzy, the course is highly interactive or new, and stakeholders need to see working prototypes to know what they want. ADDIE moves through five phases with sign-offs between them, while SAM runs short, repeated cycles of design, prototype and review. Neither is better in general. Many experienced teams blend them, keeping ADDIE's analysis and evaluation discipline while borrowing SAM's early prototyping.

What Is the Difference Between ADDIE and SAM?

The core difference is when you find out you are wrong. ADDIE tries to get decisions right on paper before building. SAM assumes your first ideas will be partly wrong and builds rough versions quickly so you discover the problems early.

ADDIE stands for Analysis, Design, Development, Implementation and Evaluation. It grew out of military instructional systems design in the 1970s and remains one of the most widely taught models in the field. Each phase produces outputs, such as a design document, that stakeholders approve before the next phase begins.

SAM was introduced by Michael Allen of Allen Interactions, most fully in the 2012 book Leaving ADDIE for SAM, written with Richard Sites. It borrows ideas from agile software development: small iterations, working prototypes and frequent feedback from the people who will use the product.

How Does the SAM Model Work?

SAM comes in two versions. The simpler one, often called SAM1, is a small loop of evaluate, design and develop, repeated about three times, which suits small projects with a small team.

The fuller version, SAM2, splits the work into three phases:

1. Preparation. The team gathers background information and holds a "Savvy Start," a working session where stakeholders, designers, SMEs and ideally a few learners brainstorm and sketch quick prototypes together.
2. Iterative design. The team refines prototypes and plans the project in short cycles, reviewing each version with stakeholders.
3. Iterative development. The course is built in stages, usually called a design proof, an alpha, a beta and a final "gold" release, with review and correction at each stage.

Allen Interactions describes the approach on its SAM process page if you want the model's own framing. The key idea is that stakeholders react to something they can click on, not a long document they have to imagine.

ADDIE vs SAM Side by Side

The comparison below covers the points that matter most when you are choosing.

When Is ADDIE the Better Choice?

ADDIE fits best when you need predictability and a paper trail. Choose it when:

• The training is safety-critical or regulated, and auditors may ask how decisions were made.
• Content is stable and well understood, such as a procedure that is already written and approved.
• Many stakeholders across departments must agree on scope before money is spent.
• The format is familiar, such as a standard compliance module, so prototypes add less new information.
• The contract or procurement process requires fixed deliverables at fixed milestones.

In these cases, ADDIE's formal design phase is not bureaucracy; it is the cheapest place to catch disagreement.

When Is SAM the Better Choice?

SAM shines when nobody can fully describe the right solution in advance. Choose it when:

• The course relies on interaction, such as branching scenarios or simulations, where "how it feels" matters.
• Stakeholders struggle to approve documents but react quickly to something they can try.
• The audience or problem is new to the team.
• Timelines are tight and you cannot afford a late discovery that the design misses the mark.
• You have reliable access to real learners for quick tests.

The last point is easy to overlook, because SAM depends on feedback. Without real people to try each version, you are just iterating on guesses.

Why Do Early Prototypes Make Such a Difference?

Prototypes work because people, including experts, are poor at predicting how something will be experienced from a description. Psychologists call one part of this the curse of knowledge: once you know a subject well, it is hard to imagine what it is like not to know it. An SME reading a storyboard fills in the gaps automatically, but a new learner trying a prototype does not, and that is exactly the information you need.

Prototypes also make disagreements visible. Two stakeholders can approve the same design document while picturing completely different courses. Put a rough version in front of them and the difference shows up in minutes.

This is why the most important lesson from SAM applies even to teams who never adopt it formally: show something real, early, to the people who will use it.

What Goes Wrong When Teams Switch from ADDIE to SAM?

Most problems come from adopting SAM's speed without its structure. Iteration is not the same as improvisation, and a few patterns show up again and again.

The first is endless iteration. Without a limit on review rounds, each version invites new ideas, and the project never converges. SAM itself plans for a set number of cycles, and teams should agree on that number at the start.

The second is polishing prototypes, even though a prototype is meant to be thrown away or heavily revised. When developers spend days making an early version look finished, reviewers comment on colors and fonts instead of the learning design, and the team becomes reluctant to change direction.

The third is leaving learners out, as some teams do when they run SAM cycles with stakeholders only. That speeds up agreement, but it misses the main benefit, which is finding out what real learners do with the design.

The fourth is skipping analysis entirely. The Savvy Start is a fast way to gather background, but it does not replace understanding the performance problem. If the root cause is a broken tool or a missing incentive, no number of prototypes will fix it.

Teams moving the other way, from SAM back toward a more formal ADDIE process, face the opposite risk: losing the habit of showing work early. A good safeguard is to require one learner test before any design document is approved.

Can You Combine ADDIE and SAM?

You can, and for most corporate projects it's the approach I'd recommend. A practical hybrid keeps ADDIE's front and back ends and runs SAM-style cycles in the middle. The interactive overview below shows where the key ADDIE decisions sit, which helps you see where iteration can slot in.

A common hybrid looks like this:

1. Run a focused analysis to confirm the performance gap and audience.
2. Write measurable objectives and an assessment plan. If you need a refresher, here is how to write learning objectives that describe observable behavior.
3. Hold a short Savvy Start style session to sketch the approach with stakeholders.
4. Build and test two or three rapid prototypes of the riskiest parts.
5. Develop the full course in alpha, beta and final stages with defined review rounds.
6. Implement with a pilot, then evaluate against the measures you set in step two.

The objectives step is the anchor. Iteration without clear objectives tends to drift, because every review round adds new ideas and nothing tells you which ones serve the goal.

What Questions Should You Ask Before Choosing?

Before you commit, run through these five questions with your sponsor:

1. How well do we understand the problem and the audience right now?
2. Will reviewers give better feedback on a document or on a prototype?
3. How much does the course depend on interaction and feel?
4. Do regulations or contracts require formal sign-offs?
5. Can we get real learners to test early versions?

Mostly "well understood, documents, low interaction, yes, no" points to ADDIE. Mostly the opposite points to SAM. A mix points to a hybrid, which is where most real projects land.

ADDIE vs SAM: Match the Process to the Uncertainty

The ADDIE vs SAM question has a practical answer. ADDIE is the better choice when the problem is well understood and decisions must be documented, while SAM is the better choice when the solution is uncertain and people need to see it to judge it. The deciding factor is how much you still need to learn about what will work.

Whichever you choose, two habits carry over: anchor the project in clear, measurable objectives, and put something real in front of learners as early as you can. Start your next kickoff by asking how much is still unknown, and let that answer pick the process.

← All articles