Introduction
I’ve written in the past about why you need an instructional design document. It’s like a blueprint for a house. It helps everyone involved understand what the built solution will look like before development begins.
With the faster pace of things in today’s work environment, it’s becoming more common for people to want to skip ahead to building without a blueprint. Some call it “agile.” I call it misguided.
Many of us are creating a lot of microlearning courses these days. Companies want “learning in the flow of work.” From my experience, this is often a nicer-sounding way to say, “We don’t want to pay employees to sit in a class.”
(Yes, there can be learning benefits to shorter solutions, but that’s a topic for another post.)
When we’re putting together a five-minute course using a rapid authoring tool or even AI, taking time to put together a design document might seem like an unnecessary step. I’ll admit, I’ve sometimes made a simple content outline instead of a full design guide.
But I’ve come to realize even that’s risky. Here are six reasons why.
1. An instructional design document explains the why behind your choices.
Stakeholders can’t approve a design they don’t understand.
While prototypes can show the vision for a course, they don’t provide the whole picture. They can’t explain the rationale behind your design choices—because a good design document isn’t just a description of what you’re building. It’s an argument for how you’re building it.
For example, “use branching scenarios” just lists what you plan to do. But “learners need to practice making judgment calls in situations where there may not be one obviously correct response” explains why.
A client might look at a script, storyboard, or prototype and think:
- Why aren’t you including every piece of SME-provided content?
- Why are we assessing this objective with a scenario instead of a knowledge check?
- Why is this a 20-minute course instead of a 45-minute course?
- Why are we giving learners a job aid instead of teaching them to memorize this?
The design document gives you a place to answer those questions before someone sees the developed product and asks you to change it.
2. It aligns your learning objectives, content, and assessments
Recently, a client asked me to develop an assessment for a course they had already developed. Naturally, I asked for the learning objectives.
Reader, there weren’t any.
Now, how can we possibly measure whether a learner can accomplish what we want them to be able to do if we don’t know what we want them to do?
It’s like the Cheshire Cat telling Alice that it doesn’t much matter which way she goes if she doesn’t care where she’s going.
As learning and development professionals, we have to care where learners are going—and document that path.
The instructional design document outlines what learners need to do, how they will learn to do it, and how you will determine whether they can do it.
Spelling out this path in a document allows stakeholders to see the alignment at a glance—while problems are still cheap to fix.
For example, if your objective asks learners to demonstrate a skill, but your assessment only asks them to recall facts about it, you can spot that mismatch before you’ve built the course.
3. It helps ensure you’re solving the right problems.
Your instructional design document can capture the answers to questions you ask during your analysis:
- What is the performance problem?
- What are people doing now?
- What do they need to do instead?
- Why aren’t they already doing what they should be doing?
- What can training realistically address?
- What requires a non-training solution?
For example, if employees already know how to complete a process but can’t find the current procedure because it’s buried on SharePoint, another course isn’t going to fix that.
Or if managers aren’t doing something because the organization rewards the opposite behavior, you can build the world’s greatest eLearning course and accomplish precisely nothing.
You don’t necessarily need to spend six weeks conducting a learning needs analysis. But at a minimum, someone needs to answer, “What problem are we trying to solve?” before anybody opens Storyline.
4. It helps ensure continuity in future updates.
Few things are more frustrating for a learning experience designer—particularly those who do contract work—than handing over a carefully crafted learning solution only to see someone else break the design when they update it.
This happened to me with a course about planning for the needs of children in disasters that I lovingly designed many years ago. When I say lovingly, that’s no exaggeration. I put my whole heart into that project. I wrote bookend scenarios to begin and end each lesson and ground the content with emotional context that made it matter. (I wrote about the design approach here.)
To get those real stories, I interviewed families affected by disasters, including 9/11 survivors. Some of what I heard was heartbreaking. The work was harrowing, but incredibly rewarding.
This introvert made cold calls, y’all. I was invested.
Then, years later, I looked up the (publicly available) course after another contractor updated it. They kept most of the original stories but removed or replaced some videos with explainer-type content that didn’t have the same effect.
(Btw, the client told me he wanted me to update it, but the decision was out of his hands. Government.)
One thing that might have prevented another contractor from updating the course with mismatched parts—Frankensteined together like a mad scientist’s crowning achievement—is a clear, robust design plan.
Now don’t get me wrong—we had an instructional design document. But it focused on outlining the content, including learning objectives and assessment items. It didn’t explain the rationale behind design choices and why those choices were important for learning.
That’s why a content outline isn’t enough.
The question isn’t just, “Could someone else build this from my design document?” It’s also, “Could someone else make good decisions about this course five years from now?”
5. It shows that you followed a sound design process.
Many of my clients, especially in the military and healthcare fields, have a saying: If it isn’t documented, it isn’t done.
It’s not enough to follow a sound instructional design process. You need to be able to show that you followed one.
Accrediting bodies like IACET (The International Accreditors for Continuing Education and Training) will look for evidence that learning solutions follow sound instructional design principles. Most of the documentation they ask for can be built into the design document.
The design document creates a paper trail showing that decisions about the learning solution weren’t arbitrary. It can document things such as:
- Learning/performance needs
- Target audience
- Measurable learning outcomes
- Instructional methods
- Assessment methods and alignment to the outcomes
- Completion requirements
- Evaluation strategy
Even if your organization never plans to pursue accreditation, designing as though someone might someday ask you to show your work is a good habit to practice.
6. It prevents rework.
Learning experience design involves dozens, maybe even hundreds, of seemingly minor decisions that can become expensive when they’re made too late.
- One course or multiple modules?
- Restricted navigation or free?
- Custom navigation or built-in?
- True video or animation?
- Photo-realistic or illustrations?
- Voiceover or just text?
- Fully responsive or… whatever Storyline is?
- Which accessibility standard?
- What counts as completion?
When we fail to consider these questions (and more) before we start building, it can mean costly rework later.
Being truly “agile” means making decisions and responding to change efficiently—not postponing decisions until they become expensive.
Summary
The smaller the project, the smaller the instructional design document can be—but we still need to document the design.
For a five-minute microlearning, perhaps the design document is only two pages. It might contain the performance problem, audience, objective, key content, instructional approach, assessment, technical requirements, and a couple of sentences explaining the rationale.
That’s still a design document—and it has value throughout your project, and long after the development is complete. And sometimes, the design document is actually more than one document. There might be a content outline that lays out the learning objectives, instructional strategies, and assessments, while a separate style guide provides the rationale for design decisions.
Regardless of what form it takes, good design documentation records what you’re building, why you’re building it that way, how all the pieces fit together, and what someone needs to know to update it before they start knocking down walls.
It doesn’t have to be long. It doesn’t have to be fancy. It just needs to exist, so design decisions don’t only live inside your head.
