addie

name

addie

description

Design and deliver training programs using Pastore's ADDIE framework: Analysis, Design, Development, Implementation, Evaluation. Use when the user mentions "ADDIE", "instructional design", "design a training", "build a course", "eLearning design", "needs analysis", "front-end analysis", "task analysis", "learning objectives", "ABCD objectives", "instructional congruency", "storyboard a course", "Kirkpatrick evaluation", "train the trainer", "rapid ID", or "is training the right solution". Also trigger when diagnosing failed training, writing objectives, designing aligned assessments, choosing instructional strategies, applying Mayer's multimedia principles, or evaluating training ROI.

ADDIE — Pastore's Instructional Design Framework

Core principle

"ADDIE is the basic building block, the framework for all of these. Regardless of the model being used, it's using ADDIE as its framework. Thus, you cannot replace ADDIE and if you hear someone talking about replacing ADDIE with X model, be wary of the snake oil they are selling." — Pastore 2020, p. 24

ADDIE is a framework, not a model (Pastore 2020, p. 22). It tells you the five phases — Analysis, Design, Development, Implementation, Evaluation — but not how to perform each. The "how" varies per project; that's what the dozens of ID models (Dick & Carey, Smith & Ragan, Gagné, etc.) prescribe. ADDIE is modified for every project (p. 11), and "there is NO best model that works for everything. The best model is the one that solves your current problem" (p. 23).

ADDIE was developed in the 1970s at Florida State for the US military as a strictly linear model (Branson et al., 1975); it was modified after a few years because the linear version "didn't work so well in practice" (p. 22). In the real world the phases overlap — implementation runs throughout, not just at the end (p. 99).

When this framework applies

Situation	Use ADDIE?
Client asks for "a training" or "an eLearning course"	Yes — but verify training is actually the answer first
Performance gap (employees doing X wrong)	Run front-end analysis first; training may not be the fix
New software/system rollout, new policy, new role	Yes — ADDIE end-to-end
Learners already know the content	No — pretest and skip
Tight deadline, experienced team, prior analysis exists	Use Rapid ID (§6) — modify ADDIE, don't skip it
Problem is communication, motivation, or system glitch	No — solve via other means (p. 15)

1. Analysis — Find the real problem

Core concept. Two distinct activities: Front-End Analysis (FEA) decides whether training is the right intervention; needs/task analysis decides what training should look like. Skipping or rushing this phase is the #1 cause of project failure ("70% of projects fail and poor analysis and management are usually the cause" — p. 106).

Why it works. Clients consistently misdiagnose their own problems and underestimate scope. The ID is the expert; if you don't catch the misdiagnosis, "it's your fault and you look bad" (p. 29). FEA catches the misdiagnosis; task analysis catches the scope underestimate.

Key insights.

• "Training is not always the answer" — could be communication, system glitch, motivation, or multiple problems (p. 15).
• Use the "Why" exercise (Olivier 2017) to drive past symptoms to root cause (p. 18).
• A gap analysis has three columns: Current State / Desired State / Recommended Solution (p. 20). Clients often have a "dream desired state" that's unrealistic; present multiple solutions with ROI/budget/timeline.
• Needs Analysis = learner analysis + context analysis + gap analysis (p. 28).
• "There is no learning style. We might examine if the learners prefer video, online, classroom, etc." — preference ≠ learning style (p. 30).
• A content walkthrough with the SME early prevents budget blow-up — clients always underestimate content volume (pp. 33–34).
• Goal vs Objective: goal is general ("train users to fly a plane"); objective is specific and measurable (p. 35).
• Get SME/client sign-off on the task analysis before writing objectives (p. 36).

Deliverables. Training charter (p. 26), gap analysis table, learner + context analysis, prioritized task list (1–10 importance/difficulty/length/cost — p. 38), full task analysis as list or tree (pp. 41–42), goal statement, proposal with ROI, analysis document.

Copy patterns.

• "You always need to go in knowing that you need to find the problem and cause then worry about the solution." (p. 16)
• "Good analysis helps ensure quality; bad analysis ensures poor quality." (p. 28)

Ethical boundary. Don't recommend a model before hearing the problem. "Your client may need you to use a different one." (p. 23) Don't accept the client's stated problem at face value.

→ See references/analysis.md for full procedure, training charter template, gap analysis worked example, and task analysis decomposition.

2. Design — Decide what the training will be

Core concept. Translate tasks into learning objectives in ABCD format, design assessments that align with each objective, select instructional strategies (organizational + delivery) for retention. The non-negotiable rule: objectives = content = assessment (p. 51).

Why it works. Without instructional congruency, you can't tell whether a low score means the learner didn't learn or the assessment didn't measure the right thing. With it, every part of the system is testable.

Key insights.

• ABCD format for objectives: Audience, Behavior (clear action verb — never "understand" or "remember"), Condition (given X), Degree (% accuracy) (pp. 47–50). Example: "Given a map of the United States, the learner will be able to identify the state of North Carolina with 100% accuracy." In practice, A and D can be omitted when always implied; never omit B and C.
• One action verb per objective. One objective = one sentence (p. 49).
• Validity = is the test measuring the right thing. Reliability = would scores be consistent on retest. "Something can be reliable but not valid. Not the other way around." (p. 54)
• Pretest is mandatory. Without it you cannot prove the intervention worked (p. 55).
• Multiple choice is the Swiss Army knife — versatile but hard to write well. Performance assessments work for both low and high knowledge levels but require rubrics (pp. 58–60).
• Bad rubric red flags: subjective titles ("Great/OK/Poor"), equal weighting of unequal items, multiple criteria in one box (p. 61).
• Three strategy types (Smith & Ragan 2004): Organizational (skeleton — e.g., Gagné's 9 Events), Delivery (how content motivates and engages — e.g., Keller's ARCS, PBL, games), Development (handled in §3) (p. 64).

Deliverables. Objectives table (one per task), assessment items + rubrics, instructional congruency table (Task / Objective / Assessment), strategy plan.

Copy patterns.

• "Objectives = content = assessment" (p. 51)
• "You must assess every single learning objective or you can't be sure the learners actually learned it!" (p. 53)

Ethical boundary. Don't write objectives with vague verbs ("understand"). Don't bundle multiple objectives into one sentence. Don't treat learner satisfaction as evidence of learning.

→ See references/design.md for ABCD walkthrough, assessment-by-knowledge-level table, rubric examples, and the Gagné/Dick & Carey strategy mapping.

3. Development — Build the deliverables

Core concept. Build the actual artifacts: instructor/learner guides, presentations, computer-based training, video, narration, job aids. Storyboard before you build, style-guide before you scale, pilot-test before you ship. Apply Mayer's multimedia principles throughout.

Why it works. Storyboards catch design flaws when changes are cheap (paper). Style guides keep work consistent and let you reverse-engineer your own files months later. Multimedia principles reduce cognitive overload — working memory holds ~5 units (Pastore p. 90; Miller 1956 said 7).

Key insights.

• Storyboard inside your authoring software — saves time when you're also the developer (p. 80).
• Paper prototyping can produce client-ready options in 5 minutes (pp. 77–78).
• Storyboard = quality checkpoint — get client sign-off before building (p. 77).
• Always create a style guide. Even solo. Defines fonts, 3–5 color family, screen resolution, buttons, spacing, formatting, SCORM/metadata, code comments (pp. 81–83).
• Mayer's multimedia principles (Mayer 2014) — multimedia, split attention, modality, redundancy, coherence, spatial/temporal contiguity, signaling, interactivity (Table 13.0, p. 93). Take with a grain of salt — most research was K-12/university lab studies (p. 92).
• Pastore's own meta-analysis: ~12% improvement in recall + problem-solving with multimedia (Pastore, Briskin & Asino 2016, p. 92).
• Software stack: Articulate, Captivate, PowerPoint, Lectora for authoring. Camtasia/Premiere/Final Cut/OBS for video. Audacity (preferred) or Audition for audio. Pastore literally repeats "Articulate and Captivate" four times for emphasis (p. 85).
• Hire a pro for narration. Text-to-speech still sounds robotic (pp. 73–74).
• Alpha test = big problems, on client's actual hardware, before signing contract. Beta test = small glitches, with users in small groups, near completion (pp. 97–98).

Deliverables. Storyboards, style guide, instructor guide, learner guide, presentations, CBT files, video, narration, job aids, images, alpha + beta tested software.

Copy patterns.

• "I do my storyboard in the software I am developing in (this is a big tip)." (p. 80)
• "Articulate and Captivate. Articulate and Captivate." (p. 85)
• "Think of storyboard as a quality checkpoint." (p. 77)

Ethical boundary. Don't ship without alpha-testing on the client's actual stack. Don't use text-to-speech for full narration. Don't skip the style guide because you're "just one person."

→ See references/development.md for storyboard template, style guide checklist, Mayer's principles applied, usability guidelines, and the software stack matrix.

4. Implementation — Roll it out

Core concept. Train the trainer, install on the LMS, manage change, communicate with stakeholders, collect data for evaluation. Implementation is not a final phase — it runs throughout the project (p. 99).

Why it works. "A poor implementation can make the greatest training seem terrible" (p. 101). The best content fails if learners can't access it, the trainer doesn't know how to deliver it, or stakeholders don't know it's coming.

Key insights.

• Create a lessons-learned document during this phase (p. 99).
• Train the trainer (TTT) can mean: training trainers-of-trainers, training many trainers, training SMEs, or being the trainer yourself (p. 100).
• Pastore name-checks ADKAR as one example change-management model but says change models are out of scope for the book (p. 100).
• Look ahead to evaluation: collect baseline + during-implementation data you'll need at Kirkpatrick L3/L4 later (p. 100).
• "Many times this is where my job as an ID stops" (p. 99) — ownership often transfers here.

Deliverables. Deployed product, lessons-learned doc, TTT sessions, communication plan.

Copy patterns.

• "A poor implementation can make the greatest training seem terrible." (p. 101)

Ethical boundary. Don't treat implementation as a hand-off you wash your hands of. Don't skip baseline data collection — Level 2 and Level 4 evaluation depend on it.

→ See references/implementation.md for TTT planning, change management touchpoints, and the data-collection plan.

5. Evaluation — Did it work

Core concept. Determine effectiveness using Kirkpatrick's four levels (Kirkpatrick 1994). Pastore's prescription: "If you're going to learn one evaluation model in our field, this is the one" (p. 103) — used over 99% of the time.

Why it works. Each level answers a distinct question, and conflating them produces false positives. Satisfaction (L1) is not learning (L2). Learning is not transfer (L3). Transfer is not ROI (L4). "Learner satisfaction is not necessarily correlated with learning" (p. 104).

Key insights.

• L1 Satisfaction — did they enjoy it? (smile sheets, surveys)
• L2 Learning — did learning occur, by how much? Requires pretest + posttest (p. 104).
• L3 Transfer — are they doing it on the job? Observe, performance data, interviews, surveys — weeks/months later.
• L4 ROI — defined performance metric (assembly errors, money saved, productivity).
• Levels 3 and 4 are "more difficult to capture and not performed as often in most organizations" (p. 104) — but define the ROI metric upfront (pp. 104–105).
• Formative vs Summative: formative happens throughout (SME review, pilot test); summative is final (ROI, course success) (p. 102).
• Phillips's ROI model is not mentioned in this book.

Evaluation report structure (p. 105): Background/Client → Stakeholders → Key Questions → Model Selected → Data Collection and Findings → Recommendations.

Deliverables. Evaluation report, L1–L4 data, ROI calculation.

Copy patterns.

• "Learner satisfaction is not necessarily correlated with learning." (p. 104)

Ethical boundary. Don't claim a training "worked" with only L1 data. Don't skip the pretest then claim measured learning gain. Don't promise L4 ROI without an upfront, agreed-on metric.

→ See references/evaluation.md for Kirkpatrick level-by-level instrumentation, formative checkpoints, and the report template.

6. Beyond ADDIE — Rapid ID

Core concept. Rapid ID is faster execution of ADDIE, not a replacement (pp. 106–109). It's for experienced IDs who can modify steps without breaking outcomes.

Pastore's checklist for when Rapid ID is appropriate (p. 106):

1. Analysis is already completed (don't skip — see the 70% failure stat).
2. Constant access to SMEs, developers, graphic artists, sign-off authority.
3. Project can roll out in sections.
4. Reusable learning objects exist (SCORM enables this).
5. Limited interactions/graphics/strategies are acceptable.
6. Easy authoring software (Articulate, Captivate, PowerPoint).

Easiest time saver: change the development tool (rapid authoring vs custom programming). This saves time without changing the process at all (p. 107).

Skeleton course = no graphics, no video, no interactions, no instructional strategies. Pastore's "least favorite option" but used when needed (p. 109).

Ethical boundary. "Be careful that we aren't cutting important corners that may impact the outcome" (p. 109). "Designed for those that are experienced IDers" — not for new IDs (p. 106).

→ See references/rapid-id.md for the modification checklist and the skeleton-course pattern.

End-to-end process

1. Receive request → start Training Charter day 1 (who/what/why/budget/schedule) — pp. 26–27.
2. Front-End Analysis — problem, root cause via "Why" exercise, gap analysis, recommended solution. Confirm training is the right intervention — pp. 15–20.
3. If training is the answer, Needs Analysis — learner + context + gap. Brief content walkthrough with SME — pp. 28–34.
4. Write goals (project + instructional). Present multiple solution options with ROI/budget — pp. 20, 34.
5. Proposal/SOW → client sign-off — p. 35.
6. Task Analysis — break goals into tasks, prioritize 1–10 (importance/difficulty/length/cost), decompose until prior knowledge takes over, get SME/client sign-off — pp. 36–43.
7. Produce analysis document — pp. 43–44.
8. Write ABCD learning objectives, one per task, level-aligned — pp. 45–50.
9. Design assessments for every objective (instructional congruency: objectives = content = assessment); pretest + posttest; rubrics for performance — pp. 51–63.
10. Choose organizational strategy (e.g., Gagné's 9 Events) and delivery strategies (Keller ARCS, PBL, games) — pp. 64–70.
11. Build deliverables (instructor/learner guides, presentations, CBT, video, narration, job aids) — pp. 71–75.
12. Storyboard each screen (paper first, then mockups in dev tool); client sign-off — pp. 76–80.
13. Create style guide — pp. 81–83.
14. Apply Mayer's multimedia principles + usability guidelines — pp. 89–96.
15. Alpha test (big problems, client hardware) → Beta test (small glitches, real users) — pp. 97–98.
16. Implement — lessons-learned doc, LMS install, train the trainer, change management, baseline data collection — pp. 99–101.
17. Evaluate with Kirkpatrick L1–L4; produce evaluation report (Background → Stakeholders → Questions → Model → Findings → Recommendations) — pp. 102–105.

Common mistakes

Mistake	Why it fails	Fix	Page
Trusting client's stated problem	Misdiagnosis cascades through the entire project	Run independent FEA; "Why" exercise to root cause	15, 108
Recommending a model before hearing the problem	The right model depends on the problem	Listen first, then prescribe	23
Skipping content walkthrough	Client says 30-min course; reality is 2 hours	30-min SME walkthrough before quoting	33–34
"Understand" or "remember" as action verb	Unmeasurable; objective fails	Use observable verbs: identify, calculate, demonstrate	48
Multi-verb / multi-objective in one sentence	Can't assess what wasn't isolated	One verb, one objective, one sentence	49
Misaligning objective level with task level	Quality drops; learners over- or under-shoot	Map task complexity → objective complexity	47
Bad rubric (subjective titles, equal weights)	Inter-rater unreliable; learners game it	Objective per-box descriptors; weight by importance	61
Skipping pretest	Can't prove intervention worked vs prior knowledge	Pretest + posttest; mandatory	55
Treating L1 satisfaction as L2 learning	Learners can love a course and learn nothing	Always run L2 with a real assessment	104
Skipping style guide because "I'm solo"	Can't reverse-engineer your own files in 6 months	Always — fonts, colors, formatting, SCORM	82–83
Skipping storyboard sign-off	Scope creep, full redevelopment	Treat as quality gate; client signs	77
Not stress-testing on client hardware	Course breaks on production LMS	Alpha test on client's actual stack	97
Believing in learning styles	Wastes design effort on a myth	Design for preferences, not "styles"	30
Cutting corners in Rapid ID without judgment	Quality drops where it matters	"Be careful that we aren't cutting important corners"	109
Replacing ADDIE wholesale with X model	"Be wary of the snake oil they are selling"	Modify ADDIE; don't replace it	24

Quick diagnostic

Symptom	Likely cause	Where to look
Training shipped, performance gap unchanged	Front-end analysis missed the real problem (motivation/system/comms)	§1, analysis.md
Learners pass the test but can't do the job	Misalignment of objective ↔ task complexity, or no L3 transfer measurement	§2 + §5
Smile sheets glow, behavior unchanged	Conflated L1 with L2/L3	§5
Course runs over budget every project	No content walkthrough; underestimated scope	§1 (p. 33–34)
Learners can't access the course	Implementation failure (LMS/tech)	§4
Can't tell whether learners knew it before	No pretest	§2 (p. 55)
Storyboard rebuilt three times	No client sign-off as quality gate	§3 (p. 77)
Rapid ID project quality cratered	Cut corners that mattered; no prior analysis to lean on	§6
"Our team uses this proprietary X model instead of ADDIE"	They don't — X is built on ADDIE	§0 (p. 24)

About the author

Ray Pastore, Ph.D. — author of The Instructional Design and Development Process: A 'How To' Guide for Practitioners (Kindle Direct Publishing, 2020, 1st Ed., ISBN 9798651489978). The book is based on Pastore's Instructional Design Video Series (transcribed and edited from the videos). The body of the book contains no separate biographical block — Pastore writes in first person throughout but does not include a formal bio in the chapters covered.

Further reading

Citations Pastore makes in this book:

• Branson et al., 1975 — original linear ADDIE at Florida State for the US military (p. 22).
• Dick, Carey, and Carey, 2014 — popular ID model; comparator throughout (pp. 11, 51, 66).
• Smith and Ragan, 2004 — three types of instructional strategies (organizational, delivery, development) (pp. 11, 64).
• Olivier, 2017 — "Why" root-cause exercise (p. 18).
• Mayer, 2014 — multimedia principles, definition of multimedia, knowledge levels (pp. 46, 89, 92, 93).
• Miller, 1956 — working memory ~7 units (p. 90).
• Bloom et al., 1956 — taxonomy domains: cognitive, affective, psychomotor (p. 65).
• Gagné, 1985 — Gagné's 9 Events of Instruction (pp. 64, 66).
• Keller, 2009 — ARCS motivation model (p. 65).
• Kirkpatrick, 1994 — four-level evaluation model (p. 103).
• Pastore, Briskin, and Asino, 2016 — meta-analysis showing ~12% multimedia improvement (p. 92).

Primary source: Pastore, R. (2020). The Instructional Design and Development Process: A 'How To' Guide for Practitioners. Kindle Direct Publishing. ISBN 9798651489978. http://raypastore.com/

Related skills

• bear-hunter-system — for designing your own learning of a topic at 80–95% retention (consumer side).
• feynman — for explaining-to-understand; complementary to learning objectives that demand "explain" or "demonstrate."
• tdd — same red-green-refactor discipline applied to code; ADDIE applied to training is the human-skills analog.
• drive-motivation — pair with §2 delivery strategies (Keller's ARCS) for intrinsic motivation design.