What I think makes good eLearning

Seven years, a few hundred modules. Most of what I now believe about good eLearning, I learned by shipping the kind that didn't work.

Training is a behaviour-change project, not a content-delivery project

Most failed modules I've seen fail the same way: they're briefed as "we need a course on X" and built as comprehensive coverage of X. Comprehensive coverage is not training. Training is the structured rehearsal of a specific behaviour the learner is meant to do — or not do — at a specific moment in their work.

The single most useful question I ask at the start of any project: imagine the training worked. What is a person doing six months later that they wouldn't be doing otherwise?

If the answer is "they would know about X," the project is mis-scoped. Knowing is not behaviour. Knowledge can sit inside a course in service of behaviour, but knowledge for its own sake is a wiki page.

The learner's time is the budget

Every minute in a module is a minute the learner did not spend doing their job. The course has to earn each minute back.

Most modules I've seen run 30–60 minutes. Most modules I would build now, with a free hand, would run closer to 15–25. The shorter version is harder to make, not easier. It requires that every minute survive the question: "what behaviour does this minute train?" If you can't answer that for a minute, that minute comes out.

The course gets shorter not by compression but by subtraction.

Realistic scenarios beat invented ones; authentic voices beat generic ones

Two heuristics that, in my experience, predict whether a course will be remembered:

• The scenarios resemble the learner's actual work — not in a heavy-handed way, but in the texture of the situation. The boss is busy. The client is frustrated. The deadline is awkward. Real work feels like that.
• The voice of the course sounds like a real person — not corporate, not a Storyline default character. Someone who, if you met them at a conference, you'd believe was actually good at the thing they're teaching.

The first is a writing skill. The second is a casting skill. Both are underrated.

Assessments measure what you incentivise

If your only assessment is a multiple-choice quiz with a 70% pass threshold and unlimited retakes, you've measured whether the learner can click through to the right answer. You haven't measured whether they learned anything.

What works better, in my experience:

• A single scenario at the end, no hints. The learner makes a choice and lives with the consequence.
• A predict-what-happens-next prompt in the middle of a scenario, before the consequence is revealed.
• A short, written reflection, read by the ID rather than auto-graded. The patterns in the responses inform the next revision.

If the LMS won't support those formats, that's the bottleneck, not the assessment design.

Accessibility is the floor

WCAG 2.1 AA was the floor. WCAG 2.2 AA is now the practical target, and from 2025 the European Accessibility Act and the US ADA Title II rules made it the legal one for a lot of public-facing training too.

Every module I ship has:

• Keyboard nav for every interaction; visible focus styles; focus management on screen change
• Real captions on every video — not auto-generated
• Alt text on every meaningful image
• prefers-reduced-motion respected by every animation
• prefers-color-scheme respected by every theme
• No reliance on colour alone to convey information
• Baseline 4.5:1 contrast, tested with real tools

Building for the inclusive case improves the course for everyone. The constraints that come from accessibility design tend to push you toward clearer writing, clearer layout, and clearer interactions.

Build for the LMS you have, not the LMS you wish you had

I see designers ship beautiful courses that fail on the LMS the client actually runs. Storyline's preview shows them looking great. The published package on a specific Moodle version looks broken, and the designer can't tell why.

Test on the target LMS at the end of every sprint, not at the end of the project. Five minutes of upload-and-launch on the production LMS at the end of every working week catches more bugs than a week of pre-launch QA.

This applies doubly to legacy LMSs, where SCORM 1.2 conformance is best-effort and failure modes are LMS-specific. The same package that runs cleanly on one LMS can lose completion tracking on another. Finding those at week one is cheap. Finding them at week ten is expensive.

Localisation is design, not translation

The single highest-leverage habit: write the master course as if you already know it will become five other languages. Avoid idioms. Avoid puns. Avoid scenarios where the cultural backdrop is doing load-bearing work. Keep sentences short. Leave layout room for languages that are longer than yours.

Long version of this is its own essay (here).

On 2026

A few things have shifted since I started doing this:

• WCAG 2.2 is the new floor; building to 2.1 alone is short-term thinking.
• cmi5 is gaining ground for new builds, particularly where mobile and offline matter, but SCORM 1.2 still has the deployed-content majority.
• xAPI/LRS analytics are becoming a baseline expectation for senior IDs, not a specialty.
• AI in the production pipeline is no longer optional — narration, localisation, draft scenarios, image generation. The question is which parts of the pipeline AI improves and which it quietly degrades.

I'd rather work on the question of where to use AI well than the question of whether to use it at all. The latter is settled.

Closing

The work is invisible when it succeeds. A good module changes a behaviour the company can measure six months later — a higher speak-up rate, fewer escalations of a specific type, faster ramp on a new tool. The course will not get credit for that change. The credit will go to the manager, the operations team, the policy.

This is fine, as long as the work is paid before the credit is distributed. The cost of doing it well is the cost of writing this kind of document — telling yourself, and the people who hire you, what good means.