Learning Design

The Outcome-First Learning Design Playbook

Seven tools for designing behaviour-change learning programmes in complex organisations. Built from practice. Usable from the first tool.
Customer Success Transformation
Commercial Evolution
Leadership Development
Culture and Values
Tool 01 / Programme Overview
The context everyone needs
before work begins
Give everyone involved enough context to make good decisions without a separate briefing conversation. Complete this first. Everything else flows from it.
Programme Identity
Business Case
The specific business condition or performance gap that created the need. Two to four sentences.
The single most important line in this document. Describe the shift from current behaviour to required behaviour in one or two sentences.
Audience
Prior knowledge, experience, or exposure to this subject. What can a facilitator or designer reasonably assume about the room?
Scope and Constraints
Platform constraints, mandatory content, approval requirements, or anything else the design must work within.
What Success Looks Like
30 days after delivery
60 days after delivery
90 days after delivery
Notes for the Design Team
Organisational history with this topic, a previous programme that did not land and why, a political dynamic, a sponsor constraint. If it would come up in a briefing conversation, it belongs here.
Tool 02 / Behaviour Change Brief
From what, to what,
and why the shift is difficult
Name the gap between current and required behaviour with enough precision that the design has a clear direction. If you cannot describe the change in one sentence, work through this tool before moving forward.
◆
Principle: If you cannot describe the behaviour change in one sentence, the programme has no clear direction. Complete this tool before any content is built.
The Business Problem
The specific business outcome, not the programme goal.
What are people currently doing that is working against the business result?
The role or function living with the consequences.
The role or function this programme is targeting.
The Behaviour Change
Current behaviour (From)
→
Required behaviour (To)
This is the test. If this sentence does not feel specific enough to build a programme from, go back to the from-to fields above and sharpen them.
Three to five things a manager could observe without a survey or a self-assessment form.
Tool 03 / Stakeholder Map
Who is in the picture, why they
behave as they do, and where it will be hard
Identify the roles, relationships, and tensions that will shape whether the behaviour change takes hold. The key column is the third one: the logic behind current behaviour. Until you can document that, the scenario design will not be grounded in reality.
◆
Principle: Every role that resists change must be given a credible reason for that resistance. If participants cannot argue that person's case, the scenario will not feel real and the learning will not hold.
Role and Behaviour Map
Role Current behaviour Why this behaviour makes sense to them Where resistance will show up Influence level
Wider Tensions
Name the specific metric, policy, or norm that reinforces the current behaviour.
The people whose visible support or scepticism will shape how others respond to the programme.
In practice
Across both programmes, the stakeholder map took the form of a simple grid: role, current behaviour, the logic behind that behaviour, and the tension that would surface during the programme. The most important column was the third one. In the Customer Success programme, the person resisting the shift to proactive partnership was not resistant because they lacked skill. They were resistant because their performance metrics still rewarded reactive resolution speed. Documenting that logic changed the scenario design entirely. The case stopped being about capability and became about competing incentives. That is the level of detail the map needs to reach before design can begin.
Tool 04 / Case Scenario Builder
One decision point, real stakes,
no resolved ending
Build each learning scenario around a moment of genuine choice. Complete one copy of this tool per case. The scenario ends at the point of decision, not after the outcome is known.
◆
Principle: Cases end at the moment of decision, not after the consequence. The participant asks what do I do now, not what went wrong.
Scenario Basics
The business context, the relationships involved, and what is at stake. Enough detail to make the decision feel real.
The Decision
Name the specific trigger: a conversation, a meeting, a request, a piece of information that arrives and demands a response.
If the right answer is obvious, the case has no value. Name what makes the right choice genuinely difficult.
Confidence, conviction, comfort with discomfort. Name the personal shift required, not just the information needed.
The last line. The participant is left holding the decision. The outcome is not revealed.
Tensions and Supporting Detail
Name the conflict and how it shows up in this specific scenario.
Numbers, timelines, quotes, or facts that force the participant to interpret the situation rather than guess.
Tool 05 / Measurement Framework
How you will know the behaviour
has changed before you build anything
Define what success looks like in the workplace before the learning design is finalised. Every indicator must be something a manager can observe directly. If a survey is required to detect it, the indicator is not specific enough.
◆
Principle: If a manager needs a survey to detect the change, it is not a real indicator. Define what they would see or hear in the course of normal work.
Success Indicators by Learning Objective
Learning objective What success looks like in the workplace Visible by What a manager would see or hear
The Most Important Indicator
Name tangible outputs. Vague answers like better conversations do not count as indicators.
Tool 06 / Design Brief
Enough for the design team to build from
A brief gives the design team what they need to make good decisions without turning them into instruction-followers. Too much detail produces compliance. Too little produces guesswork.
◆
Principle: A brief that over-specifies produces compliance. A brief that under-specifies produces guesswork. The goal is to give the design team enough to work from without making the decisions that belong to them.
The Behaviour Change

Carries from Tool 02. Use the button to pull it across, then refine the language if needed.

From (current behaviour)
→
To (required behaviour)
Who Will Be in the Room

Write with enough detail that a facilitator who has never met this group can make sensible decisions about tone, complexity, and how to run the room.

Role Experience and background Their relationship with this topic What matters to them at work What the design team must know
What the Programme Needs to Achieve

Carries from Tool 05. Use the button to pull it across, then refine if needed. Each entry must be tied to something a manager can observe directly.

What participants will do differently How a manager will know it has happened
Case Requirements

Tell the design team what each case must accomplish. Do not write the case for them. Session timing, facilitation approach, and the structure of the teaching notes are their decisions.

Case reference Business situation Role the participant plays Decision point and tensions that must be present What the case must achieve
What Stays with the Design Team
These require professional judgement. A brief cannot make them and should not try.
In practice
The sequence that worked across both programmes was: behaviour change first, audience second, objectives third, case requirements last. Until the behaviour gap is named precisely, it is not clear which parts of the audience description are relevant. And until both are in place, objectives tend to describe content rather than behaviour. Starting with the from-to keeps every subsequent decision anchored to the actual change the programme is trying to produce.
Tool 07 / Stakeholder Sign-off
Alignment on record
before commissioning begins
Sign-off is rarely clean. The notes column is as important as the decision. Each stakeholder's position is recorded separately so differences in view remain visible and are not glossed over.
Programme Summary
Copy from Tool 02. This is what stakeholders are formally endorsing.
Sign-off Record
Name Role and function Decision Signature Date Conditions or notes
Programme-Level Notes
Conditions, dependencies, or decisions that apply to the programme as a whole rather than to one individual's position.
Reference / Definitions and Guidance
Working definitions built from practice,
not from textbooks
Refer to this section when a term in any tool needs unpacking. These definitions describe how the framework operates in practice.
Key Terms
Behaviour change
A behaviour is something observable. It is what a person does, not what they think, feel, or intend. Behaviour change means a person does something differently in their daily work, in a way a manager could observe without asking how the person feels about their training.
Test: could a manager watching this person for an hour identify whether the behaviour has changed, without asking about learning or development? If yes, it is a behaviour. If no, it is an attitude or a mindset, and those cannot be directly trained into existence.
The from-to
The behaviour change written as a before-and-after statement. It describes what the target group currently does and what they will do differently after the programme. Not a goal or an aspiration. A description of two observable states.
Too vague
From: customer conversations lack depth. To: customer conversations are more strategic.
Specific enough
From: account managers present product features in response to what customers ask for. To: account managers open conversations by reframing the customer's stated problem before presenting any solution.
Why the behaviour makes sense
Every person who exhibits the current behaviour has a reason for it that makes sense to them. This is the argument they would make if asked to justify what they do. It is almost always rational given their incentives, their experience, or their understanding of what gets rewarded.

Common sources: performance metrics that reward the wrong behaviour; a past experience where doing the right thing produced a bad outcome; unclear expectations; a belief that the new way will create more work for the same reward.

If you cannot articulate why the current behaviour makes sense, you do not yet understand why it exists. A programme built on an incomplete diagnosis will teach people what to do without addressing why they are not already doing it.
The decision point
The moment in a case scenario where the participant must choose. A specific, concrete trigger: a question, a request, information that arrives and demands a response. The case ends here. The participant does not know what happens next.

Two things must be true. First, the right choice must be genuinely hard — if the answer is obvious, the case has no value. Second, it must require more than knowledge: judgement, conviction, or a shift in how the participant sees the situation.

Cases end at the moment of decision, not after the consequence. The participant asks what do I do now, not what went wrong.
A measurable indicator
Something a manager can see or hear in day-to-day work that confirms the behaviour has changed. It does not require a survey, a self-assessment, or a development conversation to detect.
Not measurable
The participant demonstrates improved customer focus.
Measurable
Within 60 days, the participant opens at least two customer meetings by sharing a business insight, rather than a product update or an agenda.
If a manager needs a survey to detect it, it is not a real indicator. Rewrite it until it describes something visible in normal working conditions.
The design brief
A brief gives the design team what they need to build from. It does not make the decisions that belong to them. The brief covers what the programme must achieve, who it is for, and what it must contain. It does not specify how those things are accomplished.

What belongs in the brief: the behaviour change, audience descriptions, learning objectives with indicators, case requirements.

What stays with the design team: facilitation approach, session timing, teaching note structure, the specific detail inside each case, sequencing of activities.

Too much detail produces compliance. Too little produces guesswork. The goal is to give the design team enough to make good decisions, not to make those decisions for them.
The Disciplines Behind the Framework
Change management
Anchors the design to observable behaviour gaps rather than programme completion, and provides the from-to logic that every other tool builds from.
Case method
Governs scenario construction: endings that do not resolve, characters whose resistance has a credible basis, concrete detail that forces interpretation, and clear separation between the participant case and the facilitator guide. Based on Harvard and MIT case standards.
Design thinking
Ensures the people in the system are understood before any solutions are designed. Understanding why current behaviour exists, mapping the tensions between roles, and refining the brief based on what designers need all draw from this discipline.
Outcome-based measurement
Requires that success indicators are defined before content is built. Indicators are tied to what a manager observes in daily work, not to what participants report on a feedback form.
The Five Questions: How to Use This Playbook for Any New Programme

Work through these five questions in order. Answer them with enough precision and the brief writes itself.

1
What behaviour needs to change and what is making it hard right now?
This is Tool 02. If you cannot answer it in one sentence, the programme is not ready to be designed.
2
Who are the people involved and why does the current behaviour make sense to them?
This is Tool 03. The reason column is the one that changes the design.
3
What is the moment of decision the learning should be built around?
This is Tool 04. One case, one decision point. The scenario ends there.
4
What would a manager observe in the next 60 to 90 days that confirms the change has happened?
This is Tool 05. If it requires a survey to detect, rewrite it.
5
What does the design team need to know, and what decisions should remain with them?
This is Tool 06. Four elements: the behaviour change, audience descriptions, objectives with indicators, case requirements. Everything else stays with the design team.
The Outcome-First Learning Design Playbook
Olufemi Olurinola  ·  Strategy · Change · Growth