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 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.