Instructional Design Document Template: Guide and Example
By Devlin Peck · Updated
Part of the Instructional Design Fundamentals guide
An instructional design document (IDD) is the blueprint for a learning experience. It captures the business problem, target audience, learning objectives, instructional strategy, and assessment plan in one place so stakeholders can sign off on the design before development starts. It sits at the center of the instructional design process, and it's one of the most misunderstood deliverables in the field: templates are everywhere, but almost nobody shows you a completed one.
This guide fixes that. You'll get the full section list, a six-step process for writing the document, a detailed walkthrough of the strategy section (the part reviewers actually read), a filled-in example, and a free template. You'll also get a straight answer on when you don't need a full design document at all, because many projects don't.
If you'd rather watch than read, I cover the fundamentals in this video:
What is an instructional design document?
An instructional design document is a pre-development deliverable that describes what a learning experience will accomplish, who it serves, how it will teach, and how success will be measured. You'll also hear it called a detailed design document, a design doc, a course design document, or an eLearning design document. Same artifact, different labels.
The IDD is the primary deliverable of the design phase. If your team follows ADDIE, it's what you produce during the Design phase of ADDIE and circulate for approval before anyone opens an authoring tool. Getting sign-off here is easy, whereas getting it after you've built forty slides is not.
People often confuse the design document with the storyboard. The design document explains why the solution exists and what it must accomplish. The storyboard specifies exactly what goes on each screen. Here's how the common design-phase artifacts compare:
| Design document | Storyboard | Style guide | |
|---|---|---|---|
| Purpose | Justify the solution: goal, objectives, strategy, assessment | Specify every screen: text, media, interactions | Standardize the look, tone, and conventions |
| Primary audience | Stakeholders and approvers | Developers (or future you) | Anyone producing assets |
| Level of detail | Strategy-level decisions and rationale | Screen-level scripts and programming notes | Fonts, colors, voice, naming rules |
What should an instructional design document include?
A complete instructional design document includes eight core sections: an executive summary, a project overview, an instructional blueprint, a motivation design plan, an evaluation plan, a learning transfer plan, a review and iteration cycle, and a rollout plan. This is the structure of the free template on this page, and each section answers a question a stakeholder will eventually ask you anyway.
| Section | The question it answers | Common mistake |
|---|---|---|
| Executive summary | What's wrong, why, and what are we doing about it? | Writing a page when two paragraphs would do |
| Project overview | What's the business problem, goal, audience, and proposed solution? | Stating a learning goal ("agents will understand empathy") instead of a business goal |
| Instructional blueprint | For each performance objective: how is it taught, practiced, and assessed? | Objectives that nothing in the course actually assesses |
| Motivation design | How will we keep learners engaged and confident? | Skipping it entirely, then wondering why completion rates sag |
| Evaluation and impact plan | How will we know the training worked? | Stopping at smile sheets and quiz scores |
| Learning transfer plan | What supports behavior change back on the job? | Assuming the course alone changes behavior |
| Review and iteration cycle | Who reviews what, and when? | Leaving reviewers unnamed, so feedback arrives late and from everyone |
| Implementation and rollout plan | How does this reach learners, and what's the backup plan? | No contingency for LMS issues or scheduling conflicts |
This structure meets and extends the conventional baseline. ATD's E-Learning Design Document Template is the field-standard starting point, and eLearning Industry's outline recommends nine sections running from project context through sign-off. Both are solid skeletons. Where this template goes further is the instructional blueprint: instead of a loose "instructional strategy" section, it forces you to map every performance objective to its enabling objectives, activities, assessments, and practice plan, and to justify the theory behind those choices. It also treats objectives as measurable commitments, so if yours are fuzzy, start with how to write measurable learning objectives before you draft anything.
How do you create an instructional design document?
Creating an instructional design document takes six steps: pull in your analysis outputs, write the goal and objectives, map the instructional strategy, outline the structure, define the assessment plan, and circulate the document for sign-off.
Pull in your analysis outputs
The design document is only as good as the analysis behind it. Bring in the performance gap, the root causes, the audience profile, and the project constraints (timeline, budget, tools, delivery environment). If you're inventing these while writing the document, you're not designing yet. You're still analyzing.
Write the learning goal and objectives
State one business-aligned goal (for example, a measurable change in CSAT, error rates, or time-to-proficiency), then write the performance objectives that get you there. Each performance objective describes an observable behavior with conditions and criteria, supported by the enabling objectives learners need along the way.
Map the instructional strategy
For each objective, decide how it will be taught, practiced, and assessed, and name the theory behind each decision. This is the heart of the document, so it gets its own section below.
Outline the course structure and sequencing
Show the shape of the experience: modules or lessons, their order, rough seat time, and delivery method for each piece (eLearning, vILT, job aid, coaching). Reviewers should be able to picture the learner's path from start to finish.
Define the assessment strategy and check alignment
Specify how each objective is assessed, what the passing criteria are, and what happens when a learner doesn't pass. Then run the alignment check: every objective has an activity and an assessment, and nothing in the course exists without an objective behind it.
Circulate for sign-off and keep it alive
Name your reviewers, give them a deadline, and record approval (an email confirmation is enough). Then treat the document as living: when scope changes mid-project, update it so it stays the source of truth instead of a fossil.
One more thing before you send it: write for skimmers. Stakeholders will not read a wall of academic prose, so use plain language, short paragraphs, and tables wherever a table beats a paragraph. These writing tips for instructional designers apply to design documents as much as they apply to course content.
How do you map your instructional strategy in the design document?
The instructional strategy section names your overall approach, the theory or model behind it, and shows how every activity ties back to an objective and an assessment. It's the section that makes the document worth writing. Everything else describes reality, but this section defends your decisions.
Select and justify the theory you're applying
Pick a small number of frameworks and write a one-paragraph justification for each major design decision. You don't need to cite twelve theorists. In my own design documents, the three I reach for most are Gagné's nine events of instruction for sequencing, Mayer's principles of multimedia learning for media decisions, and cognitive load theory for deciding when novices need worked examples instead of open-ended problem solving. If you want a wider menu, here's a rundown of instructional design theories and when to use them.
The justification matters more than the name-drop. "We use worked examples before independent practice because our audience is novice agents, and cognitive load research shows novices learn more from studying strong examples than from unguided problem solving" is a defensible design decision. "The course follows adult learning principles" is filler.
I've said for years that if you describe your work as just producing deliverables, you sound like an order taker. The way I'd rather come across, and the way I actually pitch my work, is that I partner with stakeholders to identify the business problem and the gaps in performance behind it. The strategy rationale is where your design document proves you're doing the latter.
Sharing your rationale is the difference between a designer who takes orders and a designer whose decisions survive a room full of stakeholders.
Build the alignment map
The alignment map is a simple table proving that every objective has a matching activity and assessment. Sharp reviewers check this first, because misalignment is the most common failure in eLearning: a course teaches one thing, has learners practice another, and assesses a third. Build one row per performance objective:
| Performance objective | Learning activity (including practice) | Assessment |
|---|---|---|
| Example: When an employee misses a deadline, deliver corrective feedback using the SBI model | Worked example video, then a branching roleplay as the manager | Live roleplay scored against a feedback checklist |
| Your objective #2 | ||
| Your objective #3 |
If a row has an empty cell, you've found a design problem before it became a development problem. That's the whole point of the document.
Specify practice, not just presentation
If your objectives involve conversations, judgment calls, or anything performed live, the design document should spec the practice layer with the same rigor as the content: what scenario learners face, what format the practice takes (branching scenario, peer roleplay, simulation), and what criteria decide whether they passed. "Learners will practice de-escalation" is not a spec. "Learners complete a simulated call with a frustrated customer and must apply all three protocol steps, scored against the call standards checklist" is.
Disclosure: this is the problem my company devlin.ai works on. You describe a scenario in plain English and get a working text or voice simulation that embeds in Storyline, Rise, or any LMS, with an AI evaluator scoring against your rubric and reporting the scores back to the course. If your design document commits to roleplay practice, this is one way to deliver it without scheduling humans for every rep. Want to see what an AI practice layer feels like before you spec one? Describe a scenario below and try the simulation it builds.
What does a completed instructional design document look like?
A completed design document reads like a business case attached to a teaching plan. Below is a condensed version of the exemplar we use at Peck Academy, my licensed career school, where students build exactly this kind of documentation to solve a performance problem for a simulated client. The scenario is fictional (Chic Avenue is a made-up retailer, not a client), but the document structure is the real thing.
The setup
Chic Avenue's customer support center has a CSAT score of 52%, which is 33 percentage points below the 85% industry benchmark. Analysis points to early-tenure agents struggling to de-escalate emotional calls, show empathy, and decide when to escalate. The executive summary states this in two paragraphs, then proposes the solution: a blended program called Live Call Onboarding that pairs self-paced eLearning with a virtual instructor-led practice session where senior agents run realistic roleplays.
The project overview then locks in the frame:
- Business problem: agents fail to de-escalate, empathize, and escalate appropriately, dragging CSAT below industry average.
- Business goal: raise CSAT by 33 percentage points in two years as agents provide better service.
- Target audience: remote US-based agents with 0 to 24 months of tenure, mostly hired for personality rather than call center experience, working daily in the Nexicall CRM.
Notice the goal is a business number, not "agents will understand de-escalation." This single choice shapes everything downstream.
One performance objective, fully mapped
The instructional blueprint takes each performance objective through the same gauntlet. Here's the first one:
Performance objective: Within the first 60 seconds of a customer call, demonstrate empathetic communication by using at least one validating phrase.
Its enabling objectives break the skill into teachable pieces: define empathetic communication, identify the customer's emotional state from word choice, tone, and pace, match validating phrases to emotional states, and distinguish validating from non-validating phrases. The assessment plan covers both deliveries: scenario-based quiz questions in the eLearning (80% to pass before attending the live session), then a live roleplay scored with a Call Standards Checklist, with supervisor remediation for anyone who doesn't pass.
The strategy rationale
This is the paragraph most templates never show you. Here's how the exemplar justifies the strategy for that objective:
This sequence draws on cognitivist principles to help learners build schemas for recognizing emotional cues and selecting appropriate responses. Worked examples model effective responses while structured practice strengthens these mental models. Knowledge checks provide retrieval practice to reinforce key concepts. The strategy also incorporates behaviorist elements such as immediate feedback during practice. The overall flow aligns with Gagné's nine events of instruction, progressing from attention and recall to guided instruction, practice, and application in the vILT roleplay.
Four sentences, three frameworks, and every claim is tied to a design decision that appears in the activity list. This is the level of justification to aim for.
The alignment excerpt
The blueprint's three objectives condense into this alignment map:
| Performance objective | Key practice activities | Assessment |
|---|---|---|
| Use a validating phrase within the first 60 seconds of a call | Emotion-identification drills, phrase-matching scenarios, vILT roleplay | Scenario quiz (80% to pass) + checklist-scored live roleplay |
| Apply the de-escalation protocol when callers show frustration or anger | Classify emotional cues in call snippets, analyze a worked example, roleplay high-pressure calls | Scenario quiz + roleplay versus a "frustrated customer" evaluator |
| Escalate out-of-scope calls with reassurance, a summary, and a warm handoff | Scope-sorting activity, summary-writing practice, start-to-finish escalation roleplay | Sequencing questions + checklist-scored escalation roleplay |
Beyond the blueprint
The remaining sections keep the project accountable after launch. The motivation design uses the ARCS model (the eLearning opens with an emotionally intense call to hook attention; learners earn a "call-ready" designation for satisfaction). The evaluation plan runs all four Kirkpatrick levels, with Level 4 defined as a 10-point CSAT increase within three months, reviewed monthly. The transfer plan specs CRM-integrated job aids, weekly supervisor call reviews, and learner self-checks. The review cycle names each reviewer and what they approve, and the rollout plan maps ten weeks from design sign-off to launch, with contingencies for LMS outages and trainer availability.
Career changers, take note: a document like this is a portfolio artifact in its own right, because it shows employers you can think, not just build.
Do you always need a full design document?
No. Many projects don't call for a full IDD. The quick test is counting the people who must approve your design before development can start, then scaling the document to match.
In my experience, the full document is most common in government work, and it earns its keep in one specific situation: when the design needs many stakeholders to sign off before the project can move to later phases. If five people with veto power need to agree on your approach, a document that captures every decision and its rationale is the cheapest way to get there. It's also excellent practice for people learning the field, because it forces you to justify your design decisions instead of defaulting to "content, then quiz."
For fast-moving corporate projects with one or two decision-makers, a streamlined design document usually serves you better: the business goal, a short audience profile, the performance objectives, the alignment map, and the assessment plan, on one to two pages. It gets straight to the point and still proves the design holds together.
And sometimes you should skip the standalone document entirely. If requirements are unstable or the stakeholder can't evaluate an abstract plan, collapse the design thinking into the storyboard and iterate on prototypes instead, the way an agile alternative like SAM prescribes. Showing a rough working version often builds more consensus than any document.
Not sure which of the three fits your project? Answer five questions and get a verdict, plus which template sections to keep or cut:
Answer five questions about your project. I will tell you how deep your design document needs to go, and which template sections to keep or cut.
How has AI changed design documents?
AI now drafts the boilerplate in minutes, which means the human parts, the strategy rationale and the alignment decisions, are now most of the document's value. This section reflects the tools as of August 2026.
The workflow shift is big: feed an AI assistant your analysis notes and it will produce a serviceable executive summary, audience profile, and rollout plan far faster than you can type them. Use that. Where teams get into trouble is letting AI invent the parts that require judgment: which theory applies to this audience, why this practice format fits this objective, or what trade-off the timeline forces. AI will happily generate plausible-sounding rationale for a design it has never analyzed, and reviewers can tell.
AI has also changed the media strategy your document specifies. My mockup stage looks different now: Claude Design is the best tool for instructional designers to build wireframes and mockups if your organization has access to it. I personally use Claude Code for everything, but it's more advanced, with a steeper learning curve and more setup time. If your design document promises visual prototypes alongside the written design, then these tools compress that stage from days to hours.
Frequently asked questions
What's the difference between an IDD and a course design document?
Nothing substantive. "Course design document" is the label you'll hear more in higher education and academic settings, while "instructional design document," "IDD," and "detailed design document" are more common in corporate and government work. The structure and purpose are the same: document the goal, audience, objectives, strategy, and assessment plan, and get sign-off before development.
Is a learning experience design document different from an instructional design document?
No. The template on this page is called a learning experience design document, and it's the same artifact. I've met people who insist instructional design and learning experience design are fundamentally different, but in my experience they usually aren't familiar with the history of instructional design or what good instructional design looks like. Good ID has always designed the full experience: motivation, practice, transfer, and all. Use whichever label your organization prefers.
Who writes and approves the instructional design document?
The instructional designer writes it, with subject matter experts supplying and verifying content accuracy. Approval belongs to the project owner or sponsor, usually alongside SME review. Name your reviewers and what each one approves directly in the document's review section. This turns the IDD into the source of truth when feedback stalls or scope creeps.
How long should an instructional design document be?
As long as the decisions require and no longer. A full design document for a multi-part program typically runs 8 to 15 pages; a streamlined version for a smaller project fits on one to two pages. Length should scale with risk and the number of stakeholders who need to sign off, not with how much you can write.