Knowing a subject well is not the same as being able to teach it. This intermediate course gives technical trainers and computer science teachers the evidence-based core of instructional design. You will learn what cognitive science says about memory (retrieval practice, spacing, cognitive load, worked examples) and what it does not say (learning styles); write measurable objectives with Bloom's taxonomy, plan with backward design, and run projects with ADDIE or SAM; build slides, short videos and e-learning that follow Mayer's multimedia principles; and write quiz questions, rubrics and feedback that show what learners really understand, with Universal Design for Learning built in from the start. One running example, a 90-minute Git workshop for new developers, ties the lessons together. Most activities are practical design tasks you can do with a document, free slide software and a screen recorder.

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

Instructional Design & How People Learn

## Why it matters

Most people teach the way they were taught: explain the topic clearly, show some slides, then move on. Learners nod along, the feedback forms say "great session", and a week later most of it is gone. Cognitive psychology has studied why this happens for more than a century, and it has found a few techniques that reliably make learning last. They are cheap, they work for beginners and experts, and almost every training course underuses them.

Throughout this course we follow one example: **a 90-minute workshop that teaches new junior developers to use Git** (commit, branch, merge and recover from mistakes).

## Learning is changing long-term memory

A useful working definition: learning is a lasting change in long-term memory that lets someone do something they could not do before. Two consequences follow.

- **Performance during the session is a poor guide.** Learners who just watched you run `git merge` can copy it immediately. That does not mean they can do it next Tuesday on their own. Robert and Elizabeth Bjork call this the difference between *performance* and *learning*.
- **Feeling fluent is not the same as knowing.** Re-reading notes or watching a demo again feels easy, so learners (and trainers) think it is working. Psychologists call this an *illusion of fluency*.

## Retrieval practice: make people pull information out

The **testing effect** is one of the best-replicated findings in learning science. In a well-known study, Henry Roediger and Jeffrey Karpicke (2006) had students read a passage and then either re-read it or take a recall test with no feedback. After five minutes the re-readers did slightly better. After one week the tested group remembered far more. Pulling an answer out of memory strengthens the memory itself; it is not just a measurement.

In practice, retrieval practice means low-stakes questions that make learners *produce* an answer:

- Start the session with three questions on last week's topic.
- After a demo, ask "write the command that creates a branch called `fix-login`" before showing it again.
- End with a one-minute "brain dump": write everything you remember about merging.

It works best when the questions are effortful but answerable, and when learners get the correct answer afterwards.

## Spacing: spread practice out

Hermann Ebbinghaus measured his own forgetting in the 1880s and found that memories fade quickly at first and then more slowly: the *forgetting curve*. He also found that repetitions spread over days beat the same number crammed together. A large meta-analysis by Nicholas Cepeda and colleagues (2006) confirmed this **spacing effect** across hundreds of studies.

For the Git workshop, that means not teaching everything in one block and never mentioning it again. Instead:

| When | What |
|---|---|
| Day 1 | Workshop: commit, branch, merge |
| Day 3 | Five-minute quiz in the team chat |
| Day 10 | Short task: fix a merge conflict in a practice repo |
| Day 30 | Review question in the onboarding check-in |

Each return trip is a retrieval opportunity, so spacing and retrieval combine.

## Interleaving and desirable difficulties

**Interleaving** means mixing different kinds of problems instead of practising one kind in a block. Doug Rohrer and Kelli Taylor (2007) found that students who practised mixed maths problems did worse during practice but much better on a later test, because they had to work out *which* method fits each problem. For Git, mix "undo the last commit", "switch branch" and "resolve a conflict" tasks rather than doing ten of each in a row.

Robert Bjork groups these techniques under **desirable difficulties**: conditions that slow learning down in the moment but improve long-term retention. The word *desirable* matters. A task so hard that learners cannot succeed at all is just frustrating.

## What the evidence ranks highly

John Dunlosky and colleagues (2013) reviewed ten common study techniques. They rated **practice testing** and **distributed (spaced) practice** as high utility, and highlighting, re-reading and summarizing as low utility. This is a good shortlist to remember when you design anything.

## Common mistakes

- **Treating quizzes only as grading.** Ungraded, frequent quizzes are a teaching tool.
- **Ending with a recap you deliver.** Ask learners to produce the recap instead.
- **Judging success by the mood in the room.** Smiling, nodding learners are not proof of learning. Check what they can do later.
- **Massing everything into one day** because the calendar is easier. Add at least one spaced follow-up.

## Quick recap

- Learning is a lasting change in long-term memory, not good performance in the session.
- Retrieval practice: make learners recall, then give the answer.
- Spacing: return to material over days and weeks.
- Interleaving and other desirable difficulties feel harder but last longer.

## Try it

Take a lesson you have taught or attended. On the Do tab, answer the quiz, then write down one retrieval question you could add at the start and one spaced follow-up you could schedule.


Use retrieval practice, spacing and interleaving so learning lasts beyond the session.

Learning science essentials

Study Strategies: Retrieval Practice

Study Strategies: Spaced Practice

## Why it matters

New learners often get lost not because the topic is too hard, but because the lesson asks them to juggle too much at once: a new tool, new vocabulary, a busy slide and a fast talker. Cognitive load theory explains why, and it gives you concrete ways to simplify a lesson without dumbing it down.

## Working memory is small

Information you are actively thinking about sits in **working memory**, which can hold only a handful of new items at a time. George Miller (1956) famously suggested "seven, plus or minus two"; later work by Nelson Cowan (2001) suggests about four chunks for new material. **Long-term memory**, by contrast, is huge. Experts are not people with bigger working memories; they have organized knowledge in long-term memory (schemas) that lets them treat many details as one chunk.

When you type `git commit -m "Fix login"`, you see one action. A beginner sees a program name, a sub-command, a flag, quotation marks and a message, each of which needs attention.

## Three kinds of load

John Sweller developed **cognitive load theory** in the late 1980s. It separates:

- **Intrinsic load**: the difficulty that comes from the material itself, such as how many elements interact. Merging branches has more interacting parts than making a commit.
- **Extraneous load**: effort spent on things that do not help learning, such as decoding a cluttered slide, hunting for the right window, or reading text while also listening to different words.
- **Germane load** (in older versions of the theory): effort spent building schemas. Recent versions fold this into intrinsic load, but the idea remains: you want learners' effort going into the material, not into the packaging.

The design rule is simple: **cut extraneous load, and manage intrinsic load by sequencing**.

## The worked example effect

For novices, studying a fully worked example usually beats solving the same problem unaided. Sweller and Graham Cooper (1985) showed this with algebra, and it has been replicated many times. A beginner solving a problem from scratch spends working memory searching for a method; a worked example shows the method, so the effort goes into understanding it.

A worked example for Git might look like this:

```bash
# Goal: start new work without touching main
git switch main          # 1. start from the up-to-date main branch
git pull                 # 2. get the latest changes
git switch -c fix-login  # 3. create and switch to a new branch
# ...edit files...
git add login.js         # 4. stage the change
git commit -m "Fix login redirect"  # 5. record it
```

Each step has a comment saying *why*, not just what. Richard Catrambone's work on **subgoal labels** found that naming the purpose of each group of steps helps learners transfer the method to new problems.

### Fading

Do not stop at examples. Alexander Renkl and colleagues found that **faded worked examples**, where later examples leave out more steps for the learner to fill in, ease the move to independent problem solving. Example 1 is complete; example 2 leaves out step 3; example 3 leaves out steps 3 to 5; then learners solve a full problem.

## The expertise reversal effect

What helps novices can hurt experts. Slava Kalyuga and colleagues (2003) found that detailed guidance which benefits beginners becomes redundant for more experienced learners and can even make their learning worse. Experienced developers in your Git workshop will be bored and slowed by step-by-step examples of `git commit`; give them problems sooner. This is one reason a quick pre-assessment is worth the time.

## Simplifying a lesson: a before and after

**Before:** one slide with eight bullet points about branching, a screenshot of a terminal in small font, a live demo in a different window while the trainer explains merge strategies, and then "now try it on your own project".

**After:**

1. One idea per slide: "A branch is a movable label on a commit", with a single simple diagram.
2. Demo in a large font, in the same window learners will use, narrating only what is on screen.
3. A worked example handout with subgoal labels.
4. Two faded examples in a practice repository with no other files to distract.
5. Only then: try it on your own project.

Same content, far less load.

## Other load reducers

- **Split attention:** put labels on the diagram instead of in a legend learners must match up.
- **Redundancy:** do not read out the exact text on a slide while learners read it; say it *or* show it.
- **Pre-training:** teach key terms (commit, branch, HEAD) before the process that uses them.
- **Segmenting:** break a long demo into short chunks with a pause and a question between each.

## Common mistakes

- Making slides "engaging" with decorative images, animations and background music that add extraneous load.
- Giving novices open-ended discovery tasks before they have any schema to work with.
- Keeping detailed scaffolding for learners who no longer need it.

## Quick recap

- Working memory is tiny for new information; long-term memory is not.
- Cut extraneous load; sequence intrinsic load.
- Novices learn well from worked examples, then faded examples, then problems.
- Guidance should shrink as expertise grows (expertise reversal).

## Try it

Answer the quiz on the Do tab, then pick one slide or handout you have made and list two things you could remove or move to reduce extraneous load.


Use cognitive load theory and worked examples to simplify a lesson without dumbing it down.

Cognitive load

Teaching Strategies: Cognitive Load Theory

Teaching Strategies: Worked Examples

## Why it matters

Technical trainers mostly teach adults: new hires, customers, career changers and experienced engineers learning a new tool. Computer science teachers face a different mix of teenagers and adult learners. Both groups share the same basic memory system, but they bring different prior knowledge, motivation and constraints. Adapting a lesson to the people in the room matters more than any single technique.

## Andragogy: Knowles's assumptions

Malcolm Knowles popularized the term **andragogy** in the 1970s to describe how adults learn, in contrast with pedagogy for children. His assumptions are that adults:

1. **Need to know why** they are learning something before they invest effort.
2. **Have a self-concept** as responsible for their own decisions and dislike being treated like children.
3. **Bring experience**, which is both a resource and a source of habits that can get in the way.
4. **Are ready to learn** what helps them with real tasks and roles.
5. **Are problem-centered** rather than subject-centered.
6. **Are motivated more by internal factors** (competence, satisfaction) than external ones.

These are useful design prompts. A fair caution, though: andragogy is a set of assumptions rather than a tested theory, and research has not shown that adults learn in a fundamentally different way from children. Much of it is simply good teaching for anyone. Treat it as a checklist, not a law.

## Motivation: autonomy, competence, relatedness

**Self-determination theory**, developed by Edward Deci and Richard Ryan, has stronger research support. It says people are more motivated when three needs are met:

- **Autonomy**: some choice and control (which practice task, which project).
- **Competence**: early, visible success at an appropriate challenge.
- **Relatedness**: feeling connected to the trainer and to other learners.

For the Git workshop: explain in the first two minutes how Git will be used on their team (why); let them choose between two practice scenarios (autonomy); make sure everyone completes a first commit within ten minutes (competence); and pair people up for the merge-conflict exercise (relatedness).

## Novices versus experienced learners

The biggest difference in any adult group is usually **prior knowledge**, not age. The expertise reversal effect from the last lesson applies directly:

| Learner | What they need |
|---|---|
| Career changer who has never used a terminal | Pre-training on terminal basics, worked examples, short steps, lots of reassurance |
| Developer who has used Git through an editor | Mapping from buttons they know to commands, then problem practice |
| Senior engineer from another version control system | A quick comparison, then advanced tasks (rebasing, recovering lost commits) |

A five-question pre-assessment before the session lets you group people or offer a "fast track" handout.

## Experience as a resource and an obstacle

Adults have **misconceptions** built from experience. Someone who used shared network folders may think of Git as "a place to save files" and be confused when a commit does not appear on the server. Ask learners to predict what will happen before you show it, and listen to the wrong predictions: they tell you which mental model to fix.

## A myth to drop: learning styles

Many trainers were taught to diagnose learners as "visual", "auditory" or "kinesthetic" and to match teaching to their style. In 2008 Harold Pashler, Mark McDaniel, Doug Rohrer and Robert Bjork reviewed the evidence and found no adequate support for this "meshing" idea: studies with the right design did not show that matching instruction to a preferred style improves learning. Later studies have found the same.

People do have preferences, and using several modes (a diagram *and* an explanation) helps everyone, but that is because of how the material is best represented, not because of learner types. Design for the content and for prior knowledge, not for learning-style labels.

## Practical constraints of adult learners

Adults in workplace training often:

- are interrupted by work messages, so short segments and clear "where we are" signposts help;
- have limited time, so practice should use realistic tasks they will face next week;
- fear looking incompetent in front of colleagues, so make early mistakes safe (practice repositories that can be thrown away, anonymous polls).

## Adapting a lesson: example

**Original:** a 90-minute lecture on Git internals, then commands, then a quiz.

**Adapted for adult new hires:** start with a two-minute story of a real merge conflict on the team and what it cost; quick pre-assessment; worked example in a throwaway repo; choice of two practice scenarios; pairs resolve a conflict; finish with a checklist they can pin next to their monitor and a spaced follow-up task on day 3.

## Common mistakes

- Skipping the "why" because it seems obvious to you.
- Teaching to an imagined average learner instead of checking prior knowledge.
- Labelling learners by learning style.
- Treating experienced learners' questions as interruptions instead of resources.

## Quick recap

- Knowles's assumptions are useful prompts, not a proven separate theory.
- Support autonomy, competence and relatedness.
- Prior knowledge matters more than age; adjust guidance to it.
- Learning styles matching is not supported by evidence.

## Try it

Answer the quiz on the Do tab. Then think of a group you might teach and write one sentence each on why they need the topic, what they already know, and one choice you can give them.


Adapt a lesson for adults by building on prior knowledge, motivation and real tasks, and drop the learning-styles myth.

Adult and novice learners

The 6 Principles of Andragogy (Explained in 3 Minutes)

The Biggest Myth In Education

What cognitive science says about memory and motivation, and how to use it: retrieval, spacing, cognitive load and adult learners.

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.

Designing Instruction

Pick a slide with five or more bullet points and duplicate the original so you can compare.

Write the single main point of the slide as a full-sentence title. If there are several points, plan one slide per point.

Replace bullets with one relevant visual per slide: a simple diagram, a cropped and zoomed screenshot, or a short code snippet in large monospace text.

Put labels directly on the visual (spatial contiguity) and remove decorative images, icons and animations (coherence).

Move the detail you cut into a handout written in full sentences, or into the speaker notes.

Check body text is at least 24 pt, color is not the only way meaning is shown, and contrast is high (run the tool's accessibility checker if it has one).

Present the new slides out loud to yourself or a friend, explaining rather than reading. Time it.

## Why it matters

Slides are the most common training material and the most commonly misused. A slide packed with text turns the trainer into a narrator and the learners into readers who are also trying to listen, which is the worst of both. Research on multimedia learning gives clear rules for slides and handouts that support learning instead.

## Mayer's cognitive theory of multimedia learning

Richard Mayer and colleagues have run hundreds of experiments on learning from words and pictures, summarized in *Multimedia Learning* and, with Ruth Clark, *e-Learning and the Science of Instruction*. The theory rests on three ideas:

- **Dual channels:** we process visual/pictorial and auditory/verbal information in partly separate channels.
- **Limited capacity:** each channel can handle only a little at a time (working memory again).
- **Active processing:** learning happens when people select, organize and integrate information with what they know.

From this come design principles. The most useful for slides:

| Principle | Rule | Slide example |
|---|---|---|
| Multimedia | Words and relevant pictures beat words alone | A branch diagram, not just bullet text |
| Coherence | Cut interesting but irrelevant material | Remove stock photos, decorative icons, background music |
| Signaling | Highlight the essential organization | Bold the one command that matters; use a consistent heading |
| Redundancy | Do not add on-screen text that repeats narration word for word | Short labels on screen, explanation spoken |
| Spatial contiguity | Put words next to the part of the picture they describe | Labels on the diagram, not in a legend |
| Temporal contiguity | Present words and matching pictures at the same time | Show the diagram while explaining it, not three slides later |
| Segmenting | Break complex lessons into learner-paced parts | One step per slide in a process |
| Pre-training | Teach key terms first | A vocabulary slide before the process |

Note the redundancy principle carefully: it is about narration plus identical on-screen text. Short key phrases with a spoken explanation are fine. And slides you send as a **self-study handout** have different needs from slides you **present**, which is why many trainers make two versions.

## Redesigning a text-heavy slide

**Before** (title: "Branching"):

- A branch is a pointer to a commit in the repository history
- When you create a branch, Git creates a new pointer at the current commit
- Commits made on the branch move the pointer forward
- HEAD indicates the currently checked-out branch
- Use `git switch -c <name>` to create a branch
- Merge the branch back when the feature is done
- Delete merged branches to keep the repo tidy

**After**, split into three slides:

1. Title as a sentence: **"A branch is a movable label on a commit."** A diagram of commits as circles, `main` and `fix-login` as labels, with the label `HEAD` attached to `fix-login`. Trainer explains verbally.
2. **"New commits move the current branch forward."** The same diagram with one new circle, `fix-login` moved onto it, `main` unchanged.
3. **"Create and switch in one command."** Just `git switch -c fix-login` in large monospace text.

The rest of the bullets go into the handout, written in full sentences for later reference. Writing slide titles as full-sentence claims (sometimes called the assertion-evidence approach, researched by Michael Alley and colleagues in engineering education) tells learners the point of each slide before they look at the picture.

## Handouts that teach

A good handout is not a printout of the slides. Useful formats:

- **Worked example sheet** with subgoal labels (from the cognitive load lesson).
- **Job aid or cheat sheet**: the five commands they will use daily, with when to use each.
- **Guided notes**: a skeleton with gaps learners fill in during the session, which adds a little retrieval.
- **Reference** with the detail you cut from slides.

## Practical rules

- Font large enough to read from the back (or on a laptop in a video call): 24 pt minimum for body text is a common rule.
- Code in monospace, high contrast, and only the lines that matter.
- One idea per slide; more slides is fine.
- Check color contrast (aim for at least 4.5:1, the WCAG level for normal text) and never use color alone to carry meaning.
- Use the slide software's built-in layouts and reading order so screen readers handle it.

## Common mistakes

- Using the slide as your speaker notes.
- Decorative images and animations that add extraneous load.
- Reading the slide aloud word for word.
- A tiny screenshot of a full IDE when one line matters; crop and zoom instead.

## Quick recap

- People learn better from words plus relevant pictures, with clutter removed.
- Do not duplicate narration as on-screen text; put labels next to what they describe.
- Split dense slides; use sentence titles and simple diagrams.
- Handouts are separate tools: worked examples, job aids, references.

## Try it

On the Do tab, redesign a text-heavy slide using these principles.


Apply Mayer's multimedia principles to redesign a text-heavy slide and write a useful handout.

Slides and handouts that teach

Mayer's Principles of Multimedia Learning

Transform text-heavy slides into clean designs

Choose one task that takes under three minutes to show (for example, resolve a merge conflict, filter a spreadsheet, reset a test account).

Write a script table with time, what is on screen and what you will say. Open with what the viewer will be able to do.

Prepare the screen: close other apps, turn on do-not-disturb, use practice data, and increase font size to 18–24 pt.

Record a 10-second audio test and listen back. Fix echo or noise before recording properly.

Record in short segments following the script, pausing between steps.

Trim long pauses and mistakes; keep the total around three minutes.

Generate captions and correct them, especially commands and technical terms.

Write the key commands or steps as text to go below the video.

Ask one person from your target audience to watch it and then do the task without help. Note where they got stuck.

## Why it matters

Short videos let learners revisit a demo when they actually need it: the first time they hit a merge conflict on their own, three weeks after the workshop. They are also easy to make badly: twenty-minute recordings of a trainer clicking around, with no plan and unreadable text. A few research findings and production habits make a big difference.

## What the research says about length and style

Philip Guo, Juho Kim and Rob Rubin (2014) analyzed about 6.9 million video-watching sessions on edX. Engagement dropped off sharply for longer videos; the median time people watched topped out around six minutes regardless of how long the video was. Their recommendations: keep videos short, plan them for online viewing rather than chopping up lecture recordings, and talk fairly quickly and with enthusiasm. Tablet-style drawing ("Khan-style") and a personal tone engaged viewers more than polished studio slides.

Mayer's principles apply too:

- **Segmenting:** one task per video. "Resolve a merge conflict" is one video; "everything about Git" is not.
- **Signaling:** zoom or highlight where the viewer should look.
- **Coherence:** no intro music, no long logo animation, no tangents.
- **Personalization:** a conversational "you" and "we" tone beats formal language.

## Planning a 3-minute screencast

Plan before you hit record. A simple script table works:

| Time | On screen | Narration |
|---|---|---|
| 0:00–0:15 | Terminal with conflict message | "You ran `git merge` and Git says there's a conflict. Here's how to fix it in under two minutes." |
| 0:15–1:00 | Open the file, conflict markers visible, zoomed | "The lines between `<<<<<<<` and `=======` are yours. The lines below, up to `>>>>>>>`, came from the other branch." |
| 1:00–1:45 | Edit to keep the right lines, delete markers | "Decide what the final code should be, then delete all three marker lines." |
| 1:45–2:30 | `git add`, `git commit`, tests pass | "Stage the file to tell Git it's resolved, then commit. Run the tests to be sure." |
| 2:30–3:00 | Recap card with three steps | "Find the markers, choose the code, add and commit." |

A plan like this keeps the video under three minutes and tells you exactly which windows to have ready.

## Recording setup

- **Clean the screen:** close other apps, turn on do-not-disturb, hide bookmarks and personal tabs, use a fresh practice repository with no real company code or secrets.
- **Make text readable:** increase terminal and editor font size (often 18–24 pt), use a high-contrast theme, and record at a resolution that will look sharp when scaled down (for example, a 1920×1080 area).
- **Audio matters more than video:** viewers forgive average video but not poor sound. Use any headset or USB microphone, record in a small soft room, and do a 10-second test first.
- **Free tools:** OBS Studio (free, open source, all platforms), the built-in recorders in Windows (Snipping Tool or Xbox Game Bar), macOS (Shift-Command-5) and many video-call apps. Paid tools such as Camtasia add easy editing.

## Recording and editing

- Record in short takes, one segment at a time; it is easier to redo 40 seconds than three minutes.
- Pause between steps so you have clean cut points.
- Do not over-edit. Removing long pauses and mistakes is enough; a natural voice is fine.
- If you make a real mistake that learners will also make, consider keeping it and showing the fix.

## Accessibility

- **Captions:** auto-generate them (YouTube, Microsoft Stream and many tools can) and then correct them, especially commands and technical terms.
- **Describe what you do**, not just "click here": say "open the Source Control panel on the left".
- Provide the commands as text below the video so learners can copy them.
- Avoid flashing content.

## Where videos fit

A video is a resource, not a lesson by itself. Pair it with a task: "Watch the 3-minute video, then resolve the conflict in practice repo 2." Link it from the place people need it, such as the team wiki page on merging.

## Common mistakes

- Recording a full live session and calling it a video course.
- Unreadable font sizes.
- A long introduction before the useful part.
- Showing real credentials, customer data or internal URLs on screen.
- No captions, or uncorrected auto-captions full of garbled commands.

## Quick recap

- Short, focused, conversational videos hold attention better.
- Script the video against the screen before recording.
- Readable text and clear audio matter most.
- Correct the captions and give commands as text.

## Try it

On the Do tab, plan and record a 3-minute screencast of one task you know well.


Plan, record and caption a short, focused screencast that learners can use when they need it.

Short instructional video

Tips: Before Recording Your Screencast

How to Make a Screencast: Tips and Tricks

Write one objective for the module and the evidence that would show it was met.

Sketch the module on paper first: a short explanation, one worked example, three practice scenarios and a final check.

For each scenario, write the situation, one correct choice and two plausible wrong choices based on real mistakes.

Write feedback for every choice that explains the consequence, not just 'correct' or 'incorrect'.

Build it in your chosen tool (in Google Forms, use 'go to section based on answer' to branch).

Add alt text to images and check that you can complete the whole module with only the keyboard.

Pilot it with one or two people from the target audience while they think aloud. Note every hesitation.

Fix the top three problems you saw and save the revised version.

## Why it matters

Self-paced e-learning lets a company train hundreds of people on its own schedule, and lets a teacher give students practice outside class. But "e-learning" often means clicking Next through slides with a quiz at the end, which teaches very little. Good e-learning uses interaction for retrieval, decision-making and feedback, not decoration.

## What makes e-learning interactive in a useful way

Interaction should make learners **think about the content**. Useful kinds:

- **Questions with feedback** that explains *why* each answer is right or wrong.
- **Scenarios and branching**: "Your push was rejected. What do you do?" Each choice leads to a consequence and feedback. Cathy Moore's scenario-based approach puts these decisions at the center.
- **Practice in a safe environment**: a simulated terminal or, better, a real practice repository with instructions.
- **Sorting and matching**: classify commands into "changes history" and "safe to run".

Less useful interaction: click-to-reveal tabs that hide text, drag-and-drop with no thinking, and Next buttons. They add clicks without adding learning, and hidden content can be an accessibility problem.

## The tool landscape

| Tool | What it is | Cost |
|---|---|---|
| H5P | Open-source library of interactive content types (question sets, branching scenarios, interactive video) | Free via the Lumi desktop app or plugins for Moodle and WordPress; hosted h5p.com is paid |
| Google Forms with sections | Branching quizzes with "go to section based on answer" | Free with a Google account |
| Articulate Rise 360 | Web-based, block-style responsive courses | Paid (free trial) |
| Articulate Storyline, Adobe Captivate | Slide-based authoring with triggers, variables and simulations | Paid |
| Twine | Free, open-source tool for branching stories; good for scenarios | Free |

You do not need a paid tool to learn the craft. The design skills transfer.

## Standards: SCORM, xAPI and cmi5

If your course will run in a learning management system (LMS), you will export it in a standard format so the LMS can launch it and record results:

- **SCORM** (1.2 and 2004) is the long-established standard for packaging courses and reporting completion and scores to an LMS.
- **xAPI** (Experience API) records richer statements ("Ana resolved a merge conflict") to a Learning Record Store, including activity outside the LMS.
- **cmi5** is a profile of xAPI that defines how an LMS launches and tracks content, combining xAPI's flexibility with SCORM-style structure.

You will set up a course in an LMS in the Training Delivery & Evaluation course; for now, know that authoring tools export these formats.

## Designing a short module

Use backward design even for a 10-minute module. Example: "Undo mistakes safely in Git".

1. **Objective:** given a description of a mistake, choose the safe Git command to undo it.
2. **Evidence:** five scenario questions at the end, each a different mistake.
3. **Learning:**
   - A short explanation with one diagram: "Some commands rewrite history; some add new history."
   - A worked example: undoing a pushed commit with `git revert`.
   - Three practice scenarios with feedback, for example:

> You committed a typo fix to `main` and already pushed it. Your team does not allow rewriting `main`. What do you do?
> - `git reset --hard HEAD~1` then force-push. *Feedback: this rewrites shared history, which your team forbids and which breaks others' copies.*
> - **`git revert HEAD` then push.** *Feedback: correct. Revert adds a new commit that undoes the change, so shared history is kept.*
> - Delete the repository and clone again. *Feedback: this does not remove the commit from the server.*

4. **Summary job aid** learners can download.

Notice that the feedback explains the consequence. That is where most of the learning happens.

## Accessibility in authoring tools

Choose content types that work with a keyboard and a screen reader, add alt text to images, caption videos, keep sufficient color contrast, and avoid timed interactions unless the timing is the skill. Test your module once using only the keyboard.

## Pilot it

Before releasing, watch two or three people from the target audience go through the module while thinking aloud. You will find confusing instructions, broken branches and questions with two right answers. This is SAM's "successive approximation" in miniature.

## Common mistakes

- Converting a slide deck into "e-learning" by adding Next buttons.
- Feedback that only says "Correct" or "Incorrect".
- Interactions that hide essential content behind clicks.
- Building in a paid tool before validating the design on paper.

## Quick recap

- Interaction should make learners decide and retrieve, with explanatory feedback.
- Free tools (H5P via Lumi, Google Forms, Twine) are enough to learn the craft.
- SCORM, xAPI and cmi5 let an LMS launch and track content.
- Design backward, check accessibility and pilot with real learners.

## Try it

On the Do tab, build a short interactive module with a free tool.


Build a short interactive module that uses scenarios and explanatory feedback, with free tools.

E-learning tools

H5P Tutorial - Create Interactives for Your LMS or Website

Get Started with Articulate Rise in 5 Minutes

Make slides, handouts, short videos and e-learning that follow multimedia learning research.

Building Materials

Pick one objective at Apply level or higher.

List three real mistakes or misconceptions learners have about it (from experience, forums, support tickets or your own early mistakes).

Write a scenario stem that can be answered without looking at the options.

Write the key and two distractors, each based on one of the misconceptions. Note beside each distractor which misconception it reveals.

Check the options: similar length and grammar, no 'all of the above', no overlap, only one defensible answer.

Write feedback for each option that explains why it is right or wrong.

Repeat for two more questions, placing the key in a different position each time.

Give the three questions to someone who knows the topic and someone who does not. If the novice can pass by elimination, rewrite the weak distractors.

## Why it matters

A quiz question has two jobs: to help learning (retrieval practice) and to tell you what learners actually understand. A badly written multiple-choice question fails at both. If the wrong answers are obviously silly, learners can pass by elimination. If the question is a trick, good learners get it wrong. Well-written questions, especially well-written **distractors**, let you diagnose specific misconceptions.

## Anatomy of a multiple-choice item

- **Stem:** the question or problem.
- **Key:** the correct answer.
- **Distractors:** the incorrect options.

Thomas Haladyna, Steven Downing and Michael Rodriguez (2002) reviewed item-writing advice and research and published a widely used set of guidelines. The core of it:

### Stem guidelines

- Put the main idea in the stem; a learner should be able to answer it without looking at the options.
- Ask about one important point, tied to an objective.
- Use a realistic scenario when the objective is Apply or above.
- Word it positively. If you must use NOT or EXCEPT, make it bold.

### Option guidelines

- Make every distractor **plausible** to someone who has not mastered the objective.
- Keep options similar in length and grammar (the longest, most detailed option is often the key, and learners notice).
- Avoid "all of the above" and "none of the above".
- Vary the position of the key.
- Do not overlap options or make two of them correct.

### How many options?

Rodriguez's 2005 meta-analysis found that **three options** (one key, two good distractors) is usually enough: adding a weak fourth option barely improves the item and takes longer to write and to read. Two strong distractors beat three weak ones.

## Distractors that diagnose

The best distractors come from **real mistakes**. Collect them from practice sessions, support tickets and open-ended answers. Each one should map to a specific misconception, so that a wrong answer tells you what to reteach.

Example from the Git workshop:

> You changed `app.js`, ran `git commit -m "Update"`, and Git said "nothing added to commit". Why?
> - A. You need to push before you can commit. *(misconception: confuses local commit with remote push)*
> - B. **You did not stage the file with `git add` first.** *(key)*
> - C. Your commit message was too short. *(misconception: thinks Git validates messages)*

If many learners pick A, they have not separated local and remote repositories, so you know which part to revisit. That is far more useful than knowing that 60% got it right.

Compare a weak version:

> What does `git add` do?
> - A. Stages changes for the next commit
> - B. Makes coffee
> - C. Deletes the repository
> - D. All of the above

It tests only recall, two distractors are absurd, and "all of the above" adds nothing.

## Writing for higher levels of Bloom's taxonomy

Multiple-choice items can test more than recall when the stem presents a situation:

- **Apply:** "Which command creates and switches to a branch called `docs`?"
- **Analyze:** show a `git log --oneline --graph` output and ask which branch a commit is on, or why a merge created a merge commit.
- **Evaluate:** "Your team forbids rewriting shared history. Which of these is the best way to undo a pushed commit?"

For skills, combine multiple-choice checks with practical tasks (see Backward design).

## Other question types

- **Short answer** reveals misconceptions you did not anticipate. Use it in pilots to harvest distractors.
- **Two-tier questions** ask for an answer and then the reason, separating lucky guesses from understanding.
- **Confidence ratings** ("How sure are you?") help learners calibrate.

## Feedback on quiz items

In practice quizzes, give feedback that explains why the key is right *and* why the chosen distractor is wrong. Feedback that addresses the specific misconception is more useful than "Incorrect, the answer is B".

## Review your items with data

After a run, look at two simple statistics:

- **Difficulty (p-value):** the proportion who answered correctly. Very high (above about 0.9) may be too easy; very low may be confusing or untaught.
- **Discrimination:** do high scorers on the whole quiz get this item right more often than low scorers? If not, the item may be flawed.
- **Distractor analysis:** a distractor nobody picks is doing no work; replace it.

## Common mistakes

- Testing trivia because it is easy to write.
- Implausible distractors.
- Clues in grammar or length.
- Trick questions and double negatives.
- No link to an objective.

## Quick recap

- Clear stem, one key, plausible distractors, no "all of the above".
- Three good options are usually enough.
- Base distractors on real misconceptions so wrong answers diagnose.
- Use scenarios for higher-level thinking; review items with data.

## Try it

On the Do tab, write diagnostic questions for a topic you teach.


Write multiple-choice items with clear stems and distractors drawn from real misconceptions.

Writing good quiz questions

How to write MCQ distractors that work: use your students' real mistakes

Writing distractors for multiple-choice questions

Describe the task in two sentences and list the objectives it assesses.

Turn the objectives into three to five criteria. Avoid vague criteria such as 'effort' or 'professionalism' unless you can describe them.

For each criterion, write the 'proficient' description first, in observable terms.

Write the lower levels by what is missing or wrong, and the top level by what goes further.

Read each row and replace any adjective-only differences ('good', 'very good') with observable ones.

Find or create two samples of work and score them with the rubric. If possible, have a colleague score them too and compare.

Rewrite any description you and your colleague scored differently.

For one sample, write feedback with at most three points that answers: where am I going, how am I going, and where to next.

## Why it matters

Practical tasks, projects and presentations cannot be marked by an answer key. Without clear criteria, two assessors give different scores, learners do not know what "good" looks like, and feedback becomes vague ("nice work, tidy up the code"). A **rubric** makes quality visible, and good **feedback** turns an assessment into the next step of learning.

## What a rubric is

A rubric lists the **criteria** you will judge, the **performance levels** for each, and a **description** of what each level looks like. Susan Brookhart's *How to Create and Use Rubrics for Formative Assessment and Grading* (2013) is a practical reference.

Two main types:

- **Analytic rubric:** scores each criterion separately. Better for feedback, because learners see which part needs work.
- **Holistic rubric:** one overall score from a description of the whole. Faster, useful for quick judgments, but less diagnostic.

## Example: analytic rubric for a Git team project

Task: in pairs, add a feature to a small app using a branch and a pull request.

| Criterion | 1 Beginning | 2 Developing | 3 Proficient | 4 Exemplary |
|---|---|---|---|---|
| Branching | Work committed directly to `main` | Feature branch used, but unrelated changes mixed in | One feature branch with only related changes | As 3, and branch name and scope follow the team convention |
| Commits | One large commit, unclear message | Several commits, messages vague ("fix") | Small commits, each message says what and why | As 3, and history tells a clear story a reviewer can follow |
| Pull request | No PR, or no description | PR with a title only | PR explains the change and how to test it | As 3, and responds to review comments with follow-up commits |
| Conflict handling | Conflict left unresolved or work lost | Resolved, but tests fail | Resolved, tests pass | As 3, and explains the resolution in the PR |

Notice what makes it work:

- **Criteria match the objectives**, not generic qualities like "effort".
- **Descriptions are observable**, so two assessors would agree.
- **Levels describe quality**, not just quantity ("several commits" vs "small commits, each with what and why").
- Four levels avoid a lazy middle choice; some teams prefer three.

## Writing a rubric step by step

1. List the objectives the task assesses.
2. Turn each into a criterion (three to six is plenty).
3. Describe **proficient** first: what meets the standard?
4. Describe the levels below by what is missing or wrong, and the level above by what goes further.
5. Test it: score two or three real samples with a colleague and compare. Rewrite any description you disagreed on.
6. Share the rubric with learners **before** the task, ideally with an example of proficient work.

## Feedback that moves learning forward

John Hattie and Helen Timperley (2007) framed effective feedback as answering three questions:

- **Where am I going?** (the goal, which the rubric shows)
- **How am I going?** (current performance against it)
- **Where to next?** (the specific next step)

Feedback can also do harm. Avraham Kluger and Angelo DeNisi's 1996 meta-analysis found that in roughly a third of cases, feedback interventions actually *lowered* performance, especially when feedback pointed attention at the person ("you're a natural") rather than the task.

Practical rules, drawing on Paul Black and Dylan Wiliam's work on formative assessment ("Inside the Black Box", 1998):

- **Be specific and about the task:** "Your commit messages say what changed but not why; add the reason in one clause" beats "improve your commits".
- **Make it actionable now:** give feedback while learners can still use it, before the final submission.
- **Limit it:** two or three points learners can act on, not twenty.
- **Make learners do something with it:** for example, ask them to revise one commit message and resubmit. Wiliam puts it this way: feedback should be more work for the recipient than the donor.
- **Comments and grades:** Ruth Butler (1988) found that students given comments only improved more than those given grades, or grades plus comments, which suggests a grade can draw attention away from the comment. When you can, give comments first and the grade later.

## Peer and self-assessment

A clear rubric lets learners assess their own and each other's work. Have pairs swap pull requests and score them with the rubric before submitting. They learn the standard by applying it, and you get fewer weak submissions.

## Common mistakes

- Criteria like "creativity" or "professionalism" with no description.
- Levels that differ only by adjectives ("good", "very good", "excellent").
- Rubrics shared only after marking.
- Long feedback lists with no clear next step.
- Praise aimed at the person rather than the work.

## Quick recap

- A rubric = criteria + levels + observable descriptions.
- Analytic rubrics give better feedback; holistic rubrics are faster.
- Write proficient first; test with real samples and a colleague.
- Feedback answers where am I going, how am I going, where to next, and asks learners to act on it.

## Try it

On the Do tab, write an analytic rubric for a project in your subject.


Write an analytic rubric for a project and give feedback that learners can act on.

Rubrics and feedback

How to Create Rubrics for Assignments

Providing feedback that moves learning forward

## Why it matters

In any group you teach, some people have disabilities (visible or not), some are working in a second language, some join on a phone in a noisy space, and some are tired or anxious. If accessibility is an afterthought, these learners hit barriers: an untagged PDF, an uncaptioned video, a color-only diagram, a timed quiz. Designing for this variety from the start is cheaper than retrofitting, often helps everyone, and in many workplaces and schools it is also a legal requirement.

## Universal Design for Learning

**Universal Design for Learning (UDL)** is a framework developed by CAST, a US nonprofit, beginning in the 1980s and 1990s (David Rose and Anne Meyer were among its founders). It takes its name from universal design in architecture, where curb cuts built for wheelchair users turned out to help people with strollers, carts and luggage too.

UDL asks designers to provide options along three principles (CAST released version 3.0 of the UDL Guidelines in 2024):

| Principle | The "why", "what" or "how" of learning | Examples in a Git workshop |
|---|---|---|
| Multiple means of **engagement** | Why: interest, effort, self-regulation | Choice of practice scenario; clear goals; a safe practice repo where mistakes cost nothing |
| Multiple means of **representation** | What: how information is presented | Diagram plus spoken explanation plus written handout; captions; commands available as copyable text; key terms defined |
| Multiple means of **action and expression** | How: how learners show what they know | Use the terminal or a graphical client; explain a resolution verbally or in writing; keyboard-accessible tools |

UDL is not about lowering standards. The objective stays "resolve a merge conflict so tests pass"; UDL removes barriers that are not part of that objective. If the objective is about Git, then reading a low-contrast screenshot is not a fair part of the test.

A note on evidence: UDL is a design framework with broad adoption and a growing research base, but reviews describe the evidence for its overall effect on learning outcomes as still developing. Its concrete accessibility practices (captions, alt text, structure) rest on firmer ground and on legal standards.

## Accessibility standards you will meet

- **WCAG** (Web Content Accessibility Guidelines) from the W3C, currently version 2.2, organized around content being **perceivable, operable, understandable and robust**. Most organizations aim for level AA.
- In the US, **Section 508** (federal agencies and their vendors) and the **ADA**; in the EU, the **European Accessibility Act**. Requirements and deadlines differ by country and change over time, so check with your organization's accessibility or legal team.

## A practical checklist for training materials

**Documents and slides**
- Use real headings, lists and built-in layouts so screen readers can navigate.
- Add meaningful alt text to informative images; mark decorative ones as decorative.
- Contrast at least 4.5:1 for normal text; never rely on color alone (add labels or patterns).
- Use the accessibility checker built into Word, PowerPoint or Google tools.

**Video and audio**
- Accurate captions (correct technical terms); transcripts for audio.
- Describe important visual actions in the narration.

**E-learning and quizzes**
- Everything works with a keyboard; focus is visible.
- Avoid time limits unless speed is the skill; if used, allow extensions.
- Clear instructions and error messages.

**Live and virtual sessions**
- Share materials in advance so people can preview or enlarge them.
- Turn on live captions in the meeting tool; speak one at a time.
- Offer several ways to participate: speak, chat, poll, or follow-up message.
- Ask, privately and early, whether anyone needs adjustments.

## Applying UDL to a lesson: example

Original plan: 40-minute lecture with dense slides, a live demo in small font, and a timed 10-question quiz.

UDL revision:

1. Share slides and the worked example sheet the day before (representation, engagement).
2. State the goal and show what success looks like (engagement).
3. Demo in large font with narration, captions on, commands pasted into chat (representation).
4. Practice in pairs or solo, terminal or graphical client (action and expression).
5. Untimed practical task instead of a timed quiz; learners can explain their resolution in writing or out loud (action and expression).
6. Recording with corrected captions posted afterwards.

## Common mistakes

- Treating accessibility as a final check instead of a design input.
- Equating UDL with "learning styles": UDL is about removing barriers and offering options, not diagnosing learner types.
- Fixing only what an automated checker flags; also test with a keyboard and a screen reader.
- Assuming no one in the group needs accommodations because no one said so.

## Quick recap

- UDL: multiple means of engagement, representation, and action and expression.
- Keep the objective fixed; remove barriers that are not part of it.
- WCAG 2.2 AA is the common target; legal requirements vary, so check locally.
- Captions, alt text, structure, contrast and keyboard access are the basics.

## Try it

Answer the quiz on the Do tab. Then pick one of your own materials and run your tool's accessibility checker on it.


Apply Universal Design for Learning and basic accessibility practice so materials work for every learner.

Accessible learning

UDL At A Glance

Introduction to UDL

Write questions that diagnose misconceptions, rubrics that make quality visible, and materials that work for every learner.

Instructional Design & How People Learn

About this course

Course content

How People Learn

Designing Instruction

Building Materials

Assessment

Where this course leads

Next course on the path

Careers that use it