How do you write learning objectives that serve learners, stakeholders, and designers?

Every learning objective serves three audiences, and instructional design tradition puts them in a definite order. First is the learner: what will I get out of this? Second is the stakeholder: the operations group a training department supports, a funding organization, internal leadership, the client who commissioned the work, all asking what outcome they are funding. Third is the designer, whether the title reads instructional designer, educational designer, or content developer, who must build the program from the objective and will be measured against it. Get the order wrong, and instructional designers will tell you so: the objective is written for the learner first.

The first two audiences are more aligned than they look. A learning objective states a learning outcome, and an outcome is exactly what both the learner and the stakeholder want to read: the learner sees what they will be able to do, the stakeholder sees what they are funding, and it is the same outcome. The tension is with the designer, who cannot build from an outcome alone and needs the specific situations and behaviors beneath it. This guide is about the architecture that serves all three: an objective layer stating the learning outcome that learners and stakeholders both read, and a layer of gap statements beneath it written for the build.

Who are learning objectives actually for?

Consider a statement from a familiar genre of kickoff document: "Participants will understand the importance of timely feedback and develop the communication skills needed to address performance issues."

Read it first as the learner who will spend hours in the program. What will I be able to do afterward that I cannot do now? I cannot tell. "Understand the importance" describes a state of mind I am supposed to reach, not anything I will be able to do, and "communication skills" could mean almost anything. The statement gives the learner nothing to want.

Now read it as the sponsoring operations leader. What will be different in her department when the program is done? She cannot say either. "Understand the importance" promises a state of mind, not an outcome she can see, and the statement asks her to fund a feeling.

Now read it as the content developer who has to build the thing. Which situations does the program cover? Which behaviors change, from what to what? A designer starting from this sentence will fall back on the only concrete thing available, the content outline, and the program will become a tour of topics.

One sentence has failed all three of its readers, though not equally and not for the same reason. The failure for the learner and for the stakeholder is the same failure: the sentence states no outcome, so neither can see what they will get. Fix that, and both are served by the one repair, because they want the same outcome. The designer's need is different in kind: even a well-stated outcome will not say what to build. The learner wants an outcome, the stakeholder wants the same outcome, and the designer needs ground truth beneath it: specific situations and specific behaviors. The resolution is not a better sentence but a second layer.

What does the top layer state?

The learning objective proper lives at the top, and it states a learning outcome. Because it names an outcome rather than an activity, it reads cleanly to two audiences at once. The learner reads it and sees what they will be able to do that they cannot do now. The stakeholder reads it and sees what outcome they are funding. A good objective earns that double reading through four properties: active, built on a verb naming something people will do; measurable, at least in principle, so the program can be held to it; legible, phrased in terms both the learner and the sponsor already understand; and singular, one outcome per statement, so it stays checkable.

For the feedback program above: "Managers will address recurring performance issues in direct, timely conversations instead of deferring them to the annual review." A manager in the program reads that and knows what they will be able to do by the end. An operations leader reads the same sentence, knows what she is funding, and can ask months later whether it happened. One outcome, two readers, no conflict.

This division of labor has old roots. Arreola's classic guidance on writing learning objectives separates the goal, "a statement of the intended general outcome," from the specific subordinate performances that contribute to it, and notes that a single goal may sit above many of them (Arreola, 1998). It also puts the learner first, which is the tradition this architecture keeps.

Different stakeholders enforce the top layer differently. Continuing medical education is the strictest flavor: objectives there are often fixed verbatim in a grant application, and the funded program must deliver against those exact words. A training department answering to an operations VP, or an agency designer answering to a client, faces a looser version of the same reading. The stakes on the stakeholder side vary; the learner's reading does not, because every learner wants the same thing from an objective, a clear picture of what they will be able to do.

What the top layer cannot do, however well it is written, is tell anyone what to build. That is the job of the layer beneath.

What lives in the layer beneath?

Beneath each objective sits a small set of gap statements, and this layer belongs to the designer. The learner never sees it, and the stakeholder sees it only if they want the detail behind the outcome. Each gap names one specific situation and the behavior that must change in it: what people typically do there today, and what they should be doing instead. Finding those gaps is its own discipline, covered in finding the gaps; this guide picks up where the gaps are known and must be written well.

The craft rules that get misapplied to objectives do their best work here. Arreola's three-component formula asks every statement for an observable behavior, the conditions under which it happens, and the criterion for judging it (Arreola, 1998). Applied at the gap layer, the formula maps cleanly: the situation is the condition, the change is the behavior, and what the better behavior accomplishes is the criterion. His list of banned verbs applies here with full force: know, understand, grasp, and appreciate fail the observability requirement, because no one can watch any of them happen.

Cathy Moore's test from action mapping, her goal-first method for designing training around observable actions, is the sharpest one-line check for this layer. List "visible, specific behaviors, actions that a guy with a clipboard could observe and check off" (Moore, 2014). If an observer standing in the workplace could not confirm the behavior is happening, the gap is not written yet.

Some gaps are procedural: the better behavior is a sequence anyone could follow. But the gaps that justify a program are usually judgment-heavy: the better behavior is a choice made under pressure, among options that all look defensible. Write those gaps as decisions. Keeney defines decisions as "situations where the decision maker recognizes that a conscious choice can be made," and argues that decision making is a skill learned the way other skills are learned, by breaking it into elements that can be worked on separately (Keeney, 2004). A gap written as a decision decomposes the same way: the situation, the options people actually take, the option the best performers take, and the consequences that separate them, each of which is something a designer can build.

Here is the feedback objective decomposed into three gap statements:

Gap 1: the delay. When a team member misses a second deadline in the same month, managers typically fold the issue into the next scheduled one-on-one, weeks later. They need to name the pattern in a dedicated conversation within days of the second miss.

Gap 2: the retreat. When the employee responds defensively in that conversation, managers typically soften the message until it disappears, sliding from the specific behavior to reassuring generalities. They need to acknowledge the reaction and return to the observed behavior and its effect on the team.

Gap 3: the vague close. When the conversation ends, managers typically close with general encouragement and no commitments. They need to close with one agreed change in behavior and a date to review it.

Each statement passes the clipboard test, each carries Arreola's condition, behavior, and criterion, and each is a decision: a moment where the typical move and the better move are both available and something makes the typical move tempting. "Address issues directly" is the outcome; the defensiveness moment in Gap 2 is the build.

One gap statement, three uses

The reason to write the gap layer carefully is that each statement gets used three times.

It is the scenario spec. The situation in the gap becomes the scene: the second missed deadline, the defensive reply, the closing moment. Nothing needs inventing, because the gap already names where the action happens.

It is the decision-point spec. The typical behavior becomes the tempting choice, the better behavior becomes the optimal choice, and the distance between them is exactly what the decision measures. Designing decision points covers that craft in full, including why one gap should become exactly one decision.

And it is the analytics label. When results come back, "most managers chose to defer the conversation in Gap 1's situation" is a finding a sponsor can act on, because the gap statement names the situation and the behavior in the same words the report uses. What learning analytics should measure makes the full argument.

All three uses stay aligned because they share a source: when the scenario, the decision, and the report trace to the same written gap, the program measures what it built and reports what it measured.

Can one statement do both jobs?

Is the second layer always necessary? Sometimes a single statement really can carry both the outcome and the build. "Given a customer requesting a refund outside policy, service representatives will offer the approved alternatives before escalating." That sentence is a legible outcome and a buildable spec at once, because the program behind it covers one situation and one behavior. When scope is that narrow, the objective and the gap collapse into the same statement, and adding a layer would be ceremony.

The strain appears the moment the program covers more than one situation, which is almost every program worth funding. The feedback program has at least three situations and three behaviors. To hold them in one sentence, the writer has two options, both bad: enumerate everything, and the objective becomes a paragraph no learner or sponsor will read as an outcome; or abstract upward until one verb covers all three situations, and the verbs vague enough to do that are exactly the ones Arreola bans. The vague objective is less a craft failure than a side effect of compression, what happens when several situations are forced through one sentence.

So the working rule: let a single statement serve alone when the program genuinely contains one situation, and split the layers the moment it contains more. Learners and stakeholders read at the outcome resolution and the designer needs the ground-level one, and past a very small scope no single resolution serves all three.

Where does this lead?

Nothing in the two-layer model requires a particular tool; a workshop or an e-learning module benefits just as much when the outcome is stated for the sponsor and the gaps are written for the build. But the architecture has a natural continuation: gap statements written as situations and decisions are already the plan for a simulation. That is how Guided Scenarios are planned at AliveSim: a program usually carries several learning objectives, each stating one learning outcome, and together they frame it; each gap beneath an objective becomes a scenario situation with a decision at its center; and the experience, the coaching, and the analytics all inherit the same spec.

The boundaries of this guide, restated plainly. How to find the gaps in the first place belongs to finding the gaps. What happens once the gap layer exists, the choices, the grading, the coaching, belongs to designing decision points. This guide owns the writing: an objective above, stating a learning outcome that learners and stakeholders both read, and beneath it a set of gap statements the designer can build from directly.

References

• Arreola, R. A. (1998). Writing Learning Objectives: A Teaching Resource Document. The University of Tennessee, Memphis, Office of the Vice Chancellor for Planning and Academic Support.
• Keeney, R. L. (2004). Making better decision makers. Decision Analysis, 1(4), 193-204.
• Moore, C. (2014). Action mapping on one page. Handout, Online Learning Conference. blog.cathy-moore.com.

Published July 18, 2026 · 11 min read