Use the science of learning to design lessons, objectives, materials and assessments that actually change what people can do.

Instructional Design & How People Learn

Pick a topic and write the audience in one line (for example, 'new help-desk staff in their first week').

Write three vague goals the way people usually phrase them (for example, 'understand ticket priorities').

For each goal, ask 'how would I know they understand?' and write the observable behavior you would see.

Rewrite each as a full objective with performance, condition and criterion (Mager's three parts).

Label each objective with its Bloom's revised taxonomy level (Remember to Create).

Check that at least one objective is at Apply level or higher, and that the levels match what the job actually needs.

Remove any objective you could not assess in the time available, so you end with three to five.

Ask a colleague or friend: could two different trainers assess each objective the same way? Fix any that are ambiguous.

## Why it matters

"Understand Git" is not an objective. You cannot see understanding, so you cannot check it, and two trainers would teach and test it completely differently. A **measurable learning objective** says what learners will be able to *do* at the end, in a way you can observe. It drives every later decision: activities, materials and assessments.

## The parts of a good objective

Robert Mager's book *Preparing Instructional Objectives* (1962) set out three parts that are still the standard:

- **Performance**: an observable verb and what the learner does. "Create a branch and commit a change to it."
- **Condition**: the circumstances. "Given a practice repository and a terminal, without notes."
- **Criterion**: how well. "Within five minutes, with the commit appearing in `git log` on the new branch."

Many teams use the **ABCD** version: Audience, Behavior, Condition, Degree. In practice the audience is often stated once for the whole course.

> Given a practice repository with a merge conflict in one file, new developers will resolve the conflict and complete the merge so that the project's tests pass, within ten minutes.

## Bloom's taxonomy

Benjamin Bloom and colleagues published a taxonomy of educational objectives in 1956. Lorin Anderson and David Krathwohl revised it in 2001. The revised **cognitive process** levels are:

| Level | Meaning | Example verbs | Git example |
|---|---|---|---|
| Remember | Recall facts | list, name, define | Name the command that shows commit history |
| Understand | Explain meaning | explain, summarize, classify | Explain the difference between staging and committing |
| Apply | Use a procedure | use, run, carry out | Create a branch and commit to it |
| Analyze | Break down, find causes | compare, diagnose, debug | Diagnose why a push was rejected |
| Evaluate | Judge using criteria | choose, justify, critique | Choose merge or rebase for a given team policy and justify it |
| Create | Produce something new | design, plan, build | Design a branching workflow for a three-person team |

The revision also added a **knowledge dimension** (factual, conceptual, procedural, metacognitive), which is useful when you notice all your objectives are procedural.

Two cautions. First, the levels are not a strict ladder that every lesson must climb; a short how-to session can legitimately stop at Apply. Second, the verb alone does not make an objective measurable. "Analyze Git" is still vague. The task and the criterion do the real work.

## Verbs to avoid

*Understand, know, learn, appreciate, be aware of, be familiar with.* They describe internal states. Replace each one by asking "how would I know they understand?" The answer is the real objective.

- Weak: "Understand merge conflicts."
- Better: "Given a conflicted file, identify the conflict markers and explain which lines came from each branch."
- Better still (job-relevant): "Resolve a two-file merge conflict so that the tests pass."

## Write for the job, not the topic

In workplace training, start from what people will do on the job. Cathy Moore's **action mapping** approach asks "what do people need to *do* to reach the business goal?" before listing any content. If the team goal is "fewer broken builds on main", the key behaviors might be "run the tests before pushing" and "open a pull request rather than pushing to main", which may matter more than Git internals.

## How many objectives?

For a 90-minute session, three to five objectives is typical. More than that usually means you are covering, not teaching. Each objective should map to at least one practice activity and one assessment item; you will build that map in the next lesson.

## Common mistakes

- Writing what the *trainer* will do ("Introduce branching") instead of what learners will do.
- Using unmeasurable verbs.
- Objectives at Remember level when the job needs Apply or Analyze.
- Twelve objectives for one hour.
- Forgetting the condition, so learners practise with notes and are tested without them.

## Quick recap

- An objective states observable performance, conditions and a criterion.
- Bloom's revised taxonomy helps you choose the right level of thinking.
- Replace "understand" with what you would see learners do.
- Start from job tasks, and keep the list short.

## Try it

On the Do tab, rewrite vague goals as measurable objectives for a topic you know well.


Write measurable objectives with performance, condition and criterion, using Bloom's revised taxonomy.

Writing learning objectives

How to Write Learning Objectives with Blooms Taxonomy

How to Write Learning Objectives with Bloom's Taxonomy

Write your three to five objectives as rows of a table.

For each objective, write the evidence that would convince you a learner can do it. Prefer a realistic performance task for skills.

For each task, write how you will judge it (a pass condition, an answer key, or a rubric to write later).

Add one formative check you will use during the lesson for each objective (a poll, a 'show me', a quick question).

Only now, list the learning activities in order, and note which objective each one prepares for.

Build an alignment matrix: objectives as rows, columns for 'practised in' and 'assessed by'.

Mark any empty cell. Add an activity or assessment, or drop the objective.

Cross out any activity or content that maps to no objective, or move it to an optional handout.

## Why it matters

The usual way to build a course is to collect content, arrange it into slides, and write a quiz at the end. The result is often a course that covers a lot but does not prepare people for the job, and a quiz that tests whatever was easy to ask about. **Backward design** flips the order: decide what learners must be able to do, decide how you will know they can do it, and only then plan the teaching.

## Understanding by Design

Grant Wiggins and Jay McTighe described backward design in *Understanding by Design* (1998). It has three stages:

1. **Identify desired results.** What should learners understand and be able to do? (Your objectives from the last lesson.)
2. **Determine acceptable evidence.** What would convince you they have got there? Design the assessment now.
3. **Plan learning experiences and instruction.** What activities, examples and explanations will get them ready for that evidence?

John Biggs described a closely related idea in higher education: **constructive alignment** (1996). Objectives, teaching activities and assessment should all point at the same performance. If the objective says "resolve a conflict" but the test asks learners to define "conflict", the course is misaligned.

## Stage 2 comes before stage 3

This is the step people skip. Writing the assessment before the lessons forces you to make the objective concrete. For the Git workshop:

| Objective | Evidence (assessment) |
|---|---|
| Create a branch and commit a change to it | Practical task: in a fresh practice repo, create `feature-x`, change a file, commit; checked with `git log --oneline --all` |
| Resolve a merge conflict so tests pass | Practical task: a provided repo with a conflict; done when the merge completes and `npm test` passes |
| Recover from a commit to the wrong branch | Scenario question plus a short practical: move the commit to a new branch |
| Explain what a pull request is for | Two-sentence answer, compared with a model answer |

Notice that most evidence is **performance**: doing the thing in a realistic setting. Wiggins called these **authentic tasks**. Multiple-choice questions still have a place (quick checks, misconceptions), but they should not be the only evidence for a practical skill.

## Then plan the learning

Now each activity must earn its place by preparing learners for the evidence:

1. Pre-training: terms (commit, branch, HEAD), five minutes.
2. Worked example: branch and commit, with subgoal labels.
3. Faded practice: two branches in the practice repo.
4. Demo: creating and resolving a conflict, narrated.
5. Paired practice: resolve a conflict, swap roles.
6. Scenario: committed to the wrong branch; groups find the fix.
7. Assessment tasks from stage 2.

Content that does not serve any objective, such as the history of version control or a tour of Git's object database, goes into an optional handout or is cut.

## An alignment check

A simple alignment matrix catches problems early. List objectives as rows and mark which activities practise them and which items assess them. An objective with no practice is unfair to learners. An objective with no assessment is unverified. An activity that maps to no objective is a candidate for cutting.

| Objective | Practised in | Assessed by |
|---|---|---|
| Branch and commit | Steps 2, 3 | Task 1 |
| Resolve conflict | Steps 4, 5 | Task 2 |
| Wrong-branch recovery | Step 6 | Task 3 |
| Explain pull requests | (none!) | Question 4 |

The empty cell shows a gap: either add a short pull request activity or drop the objective.

## Formative and summative evidence

Stage 2 is not only the final test. **Formative** assessment happens during learning to guide the next step: a poll after the demo, watching pairs work, a quick "show me your `git log`". **Summative** assessment checks the result at the end. Plan both. Formative checks are also retrieval practice, so they help learning as well as measure it.

## Common mistakes

- Writing the assessment last, from whatever was covered.
- Testing recall when the objective is a skill.
- Keeping favorite content that serves no objective.
- Practising with help and assessing without it, without a step in between.

## Quick recap

- Backward design: results, then evidence, then instruction.
- Align objectives, activities and assessments (constructive alignment).
- Prefer authentic performance tasks for practical skills.
- Use an alignment matrix to find gaps and padding.

## Try it

On the Do tab, take your objectives from the previous lesson and design the evidence before the activities.


Plan results first, then evidence, then activities, and check alignment with a simple matrix.

Backward design

What is Understanding by Design? Interview with Jay McTighe

What is backward design?

## Why it matters

Designing one workshop can be done on a notepad. Designing a ten-module onboarding program with subject-matter experts, reviewers, an e-learning developer and a launch date is a project. Instructional design models give that project a shared structure, so everyone knows what happens when and who signs off on what. The two you will meet most often are **ADDIE** and **SAM**.

## ADDIE

ADDIE stands for **Analysis, Design, Development, Implementation, Evaluation**. It grew out of systems approaches to training developed for the US military in the 1970s (Florida State University's Interservice Procedures for Instructional Systems Development, 1975), and the acronym became the standard label for the instructional systems design process.

| Phase | Key questions | Typical outputs |
|---|---|---|
| Analysis | What is the performance problem? Who are the learners? Is training the right solution? | Needs analysis, audience profile, constraints, goals |
| Design | What are the objectives, assessments and sequence? | Objectives, assessment plan, course outline, design document |
| Development | Build it | Slides, handouts, videos, e-learning, facilitator guide; pilot |
| Implementation | Deliver it | Scheduling, trainer preparation, enrollment, launch |
| Evaluation | Did it work? | Feedback, test results, on-the-job measures, revisions |

Evaluation is not only at the end. Good ADDIE projects run formative evaluation inside each phase (reviewing the design document, piloting materials) and summative evaluation after launch.

### ADDIE for the Git workshop, scaled up

Suppose engineering leadership asks for "Git training for all 40 new hires this year".

- **Analysis:** interview two team leads and look at incidents. You find that the real problem is broken builds on `main` and lost work after bad merges, and that about half of new hires already know basic Git.
- **Design:** objectives (from earlier lessons), a pre-assessment that routes experienced hires to an advanced track, assessments, a 90-minute workshop plus two spaced follow-ups.
- **Development:** practice repository, facilitator guide, slides, a five-minute video on recovering lost commits; pilot with four volunteers.
- **Implementation:** monthly sessions, booked through the learning management system.
- **Evaluation:** pre/post task results, a survey, and broken-build counts per new hire before and after.

### Criticisms of ADDIE

ADDIE is often run as a strict **waterfall**: each phase finishes and is signed off before the next begins. Critics point out that stakeholders then see the real course only at the end, when changes are expensive, and that analysis and design documents can become paperwork rather than thinking. Most practitioners now run ADDIE iteratively, but the critique led to alternatives.

## SAM

Michael Allen proposed the **Successive Approximation Model (SAM)** in *Leaving ADDIE for SAM* (Allen and Sites, 2012). It borrows from agile software development: build rough versions early, review them with real people, and improve in small cycles.

SAM has three phases:

1. **Preparation:** gather background quickly (learners, goals, constraints). Hold a **Savvy Start**, a working session with stakeholders, subject experts and ideally learners, where the team brainstorms and sketches rough prototypes together.
2. **Iterative design:** repeat design, prototype and review in short cycles (often three).
3. **Iterative development:** build an **alpha** (complete but unpolished), then a **beta** (corrected), then a **gold** release, with review between each.

For the Git workshop, the Savvy Start might produce a paper prototype of the conflict exercise in the first afternoon. Running it with two new hires that week reveals that the instructions are confusing long before anyone builds polished slides.

## Choosing between them

| Situation | Leans towards |
|---|---|
| Regulated or compliance training with formal sign-offs | ADDIE (clear documentation trail) |
| Stable content, experienced team, fixed scope | ADDIE |
| Unclear requirements, new audience, interactive e-learning | SAM |
| Stakeholders who need to see something to react to it | SAM |

In reality many teams blend them: ADDIE phases as the overall map, with rapid prototyping and pilots inside Design and Development. What matters is not the acronym but doing a real analysis, aligning objectives and assessments, testing with learners before launch, and evaluating afterwards.

## Common mistakes

- Skipping Analysis because "they asked for training", then building training for a problem that was really about tools or incentives.
- Treating the design document as the goal.
- Showing stakeholders only finished work.
- Never closing the loop with Evaluation.

## Quick recap

- ADDIE: Analysis, Design, Development, Implementation, Evaluation.
- SAM: Preparation (Savvy Start), iterative design, iterative development (alpha, beta, gold).
- ADDIE gives structure and documentation; SAM gives early feedback.
- Most teams blend them; the essentials are analysis, alignment, testing and evaluation.

## Try it

Answer the quiz on the Do tab. Then sketch which ADDIE phase each task in your current or next training project belongs to.


Plan a training project with ADDIE's five phases and know when SAM's rapid prototypes fit better.

ADDIE and SAM

The ADDIE Model of Instructional Design

SAM - The Successive Approximation Model of Instructional Design

Write measurable objectives, design the assessment before the activities, and run a design project with ADDIE or SAM.