Most HSE procedures are written to be complete, not to be learned. They cover every case, cite every regulation and assume the reader has time. Put that document into slides with a quiz at the end and people will pass the quiz. Then, on a wet night with a delayed crew and a permit that is almost right, they will do what they always do.

Scenario-based eLearning closes that gap by making people practice the decision, not the reading. Here is the method we use to turn a written procedure into a scenario, step by step.

Step 1: Find the decisions, not the content

Sit down with a subject matter expert and ask one question: where do people get this wrong? Not what the procedure says, but where it breaks down in practice. You are looking for three to five decision points, for example:

• Starting work when the gas test was done more than the permitted time ago.
• Accepting a verbal handover instead of checking the isolation.
• Continuing a task when the standby person has to leave for a few minutes.

Everything in the procedure that does not relate to those decisions can stay in the reference document, linked from the module.

Step 2: Collect real situations

Good scenarios come from real events. Ask for anonymized near-miss reports, incident summaries and the stories supervisors tell new starters. The details make the scenario believable: the time of day, the pressure from the client, the colleague who says "we always do it this way". Change names and locations, keep the pressure.

Step 3: Map a small branch

Draw the scenario on paper before anyone opens an authoring tool. Keep it small: three or four decision points, two or three options each. Let wrong choices play out for a step or two, then bring the paths back together so the tree does not grow out of control.

A scenario with four well-chosen decisions teaches more than one with twenty trivial ones.

Step 4: Write consequences, not "Incorrect"

When someone makes the wrong call, show what happens next: the alarm, the stopped job, the investigation, the colleague who is exposed. Then explain the rule and why it exists. A consequence people can picture stays with them long after a red cross on a screen.

Step 5: Make the wrong answers tempting

The options that teach the most are the shortcuts people really take, written the way people really say them: "The reading was fine an hour ago, let's get going." If the wrong answers are obviously wrong, the scenario tests reading skills, not judgment.

Step 6: Review with the people who do the job

Have the draft checked twice: once by the subject matter expert for technical accuracy, and once by someone from the crew for realism. The expert will catch errors in the rule. The crew member will tell you that nobody calls it that on site, or that the radio would never be in that pocket. Both kinds of feedback matter.

Step 7: Assess the decision and record it

Decide what counts as a pass: every critical decision correct, or a minimum score across the scenario. Then record each decision, not just the final result. With xAPI tracking, you can see that 40 people passed and also that most of them hesitated at the same step, which tells you where the next toolbox talk should focus.

A worked example: confined space entry

Here is how the first decision of a confined space entry scenario might look after the steps above:

1. Situation: You are the entrant. The permit is signed, the gas test was done at the start of the shift, and the job was delayed by two hours.
2. Options: Enter now because the permit is valid. Ask for a new gas test before entry. Enter and carry your personal monitor as a backup.
3. Consequences: The first and third options lead to a scene where the monitor alarms inside the space and the rescue plan is triggered. The second leads to a new reading that shows the atmosphere has changed.
4. Explanation: Why the test must be repeated after a delay, with a link to the exact clause in your procedure.

Three more decisions like this one, each built on a real near miss, make a module of around ten to fifteen minutes that people remember.

Common mistakes

• Turning every paragraph of the procedure into a question.
• Branches so large that the review never ends.
• Characters who explain the rules to each other in full sentences.
• Feedback that only says right or wrong.
• Launching without testing the scenario with a real crew member.

A maintenance technician finishes a night shift at 6 a.m. A line supervisor has twelve minutes between the safety briefing and the first job. A drilling crew rotates every two weeks and spends the first day catching up on changes. None of these people will sit through a 45-minute module, and nobody should expect them to.

This is where microlearning earns its place. Done well, it fits into the gaps of a working day and keeps procedures fresh. Done badly, it is a long course cut into slices, and people notice. Here is how we design it for shift-based teams in aviation, oil & gas and manufacturing.

What counts as microlearning

Microlearning is a short, self-contained lesson that helps someone do one specific thing better. The length is a consequence, not the goal. A five-minute lesson that covers three unrelated topics is not microlearning; it is a short course that nobody will remember.

A useful test: can you write the purpose of the module as one sentence that starts with a verb? "Complete a pre-entry gas test in the right order." "Choose the correct extinguisher for an electrical fire." If you need two sentences, you probably need two modules.

Seven design rules for shift-based teams

1. One task, one outcome

Pick a single task and the decision that matters most within it. Everything that does not help with that decision goes into the reference document, not the module.

2. Open with the situation, not the policy

Start where the learner will be when they need this: "You arrive at the tank. The permit is signed but the standby person has not arrived." People pay attention to a situation they recognize. They skim a paragraph that starts with "The purpose of this procedure is".

3. Aim for three to seven minutes

That is long enough for a short scenario and a check, and short enough to finish during a break. If a topic needs more, split it into a sequence and let people take the parts on different days.

4. Design for the real environment

• Large tap targets that work with gloves or on a small screen.
• Captions on every video, because many workplaces are too loud for audio.
• Light files that load on a weak connection, and offline access where the site has no signal.
• The language the crew actually works in, not only the language of head office.

5. End with a decision, not a summary

Replace the closing recap with one or two questions that make the learner apply the rule to a new situation. A decision shows whether the module worked. A recap only shows that the learner reached the last screen.

6. Space it out

People lose a large part of what they learn within days unless they come back to it. This has been known since Hermann Ebbinghaus described the forgetting curve in 1885, and the spacing effect has been confirmed many times since. In practice, send a two-question follow-up a few days after the module and again a few weeks later. It costs very little and makes a visible difference.

7. Put it where the work happens

A QR code on a piece of equipment, a link in the job card, a module pinned in the shift handover app. The closer the lesson is to the task, the more likely it is to be used at the moment it matters.

When microlearning is the wrong tool

Microlearning is excellent for refreshers, procedure changes, pre-task reminders and reinforcement after a full course. It is the wrong choice for:

• Initial qualification, where people need the full picture and the regulator expects structured training hours.
• Complex systems, where understanding comes from seeing how the parts connect.
• Hands-on skills that need practice on the real equipment or a simulator. A short module can prepare people for that practice, but it cannot replace it.

How to tell whether it works

Completion rates are the easiest number to report and the least useful. Better signals are:

• Scores on the decision questions, and which wrong answers people choose.
• Results of follow-up questions a few weeks later.
• Findings in audits and inspections on the topics you covered.
• Questions supervisors stop getting on shift.

If modules are taken on phones or offline, standard SCORM tracking may not capture all of this. xAPI can, if your platform has a Learning Record Store. We explain the difference in our guide to SCORM, xAPI and cmi5.

Short is not the point. Useful at the moment of work is the point, and short is usually how you get there.

Every eLearning project we run gets to the same question at some point, usually a few weeks before launch: "Which format do you need the course in?" The honest answer depends less on the course than on what you need to prove afterwards. This guide explains what each standard records, where each one falls short, and how we choose between them for compliance training in aviation, oil & gas and other regulated sectors.

What SCORM records, and where it stops

SCORM is a set of rules published by the US Advanced Distributed Learning (ADL) initiative. Two versions are still in wide use: SCORM 1.2 from 2001 and SCORM 2004, whose 4th edition dates from 2009. Almost every LMS on the market can import a SCORM package, which is the main reason it is still the default.

A SCORM course talks to the LMS while the learner has it open in a browser. It can report:

• Completion status: not attempted, incomplete or completed.
• Success status: passed or failed (SCORM 2004 separates this from completion; 1.2 mixes the two).
• Score and session time.
• Bookmark data, so a learner can close the course and resume later. SCORM 1.2 limits this to 4,096 characters, which long courses with many interactions can run out of. SCORM 2004 raised the limit to 64,000.

What SCORM cannot do is record anything that happens outside that browser session. A drill on a rig, a session in a flight simulator, a lesson opened on a phone with no signal: none of it reaches the LMS through SCORM.

What xAPI adds

xAPI (Experience API, sometimes still called Tin Can) records learning as short statements in the form someone did something: "Amira completed the confined space entry scenario", "Karim scored 8 out of 10 on the engine fire checklist", "Supervisor confirmed Lina's gas test technique on site". Each statement is sent to a Learning Record Store (LRS), which can be built into the LMS or run as a separate system.

Because the statements can come from anywhere, xAPI can track:

• Simulations and VR sessions, decision by decision.
• Mobile lessons completed offline, sent when the device reconnects.
• Observed practical assessments, recorded by an assessor on a tablet.
• Detailed interaction data inside a course, such as which wrong answer people choose most often.

xAPI 2.0 was approved as an IEEE standard in 2023 (IEEE 9274.1.1-2023), which settles most of the long debate about whether it is a proper standard. The catch is that xAPI on its own does not define how an LMS should launch a course or what "complete" means. You decide which statements to send, and your reports are only as good as that design.

Where cmi5 fits

cmi5 is a set of rules on top of xAPI. It defines how an LMS launches a course, how the course identifies the learner and which statements mean "completed", "passed" or "failed". In practice it gives you the predictable behavior of SCORM with the flexibility of xAPI data, including courses hosted outside the LMS and mobile-friendly delivery.

It is also the least supported of the three. cmi5 is going through IEEE standardization of its own, and while more LMS platforms add it every year, many still do not. If your platform supports it, it is worth considering for new projects. If it does not, it is not a reason to change platform on its own.

SCORM, xAPI and cmi5 side by side

How to choose for compliance training

1. Start with the audit. Write down what an inspector or client will ask to see: who completed what, when, with what score, and whether the certificate is still valid. If all of it lives in the LMS, SCORM covers it.
2. Check what your LMS supports, precisely. Ask for the exact versions: "SCORM 1.2", "SCORM 2004 4th edition", "xAPI with a built-in LRS", "cmi5". "Supports xAPI" can mean anything from full support to accepting a package and ignoring the data.
3. Look at where the learning happens. If part of the training takes place on equipment, in a simulator or away from a desk, plan for xAPI for that part.
4. Keep a SCORM version as a fallback. Most authoring tools can publish the same course in several formats. Clients change LMS more often than you would expect.
5. Test in the real LMS early. Upload a short test package before the course is finished. Bookmarking, scoring and completion rules behave differently from one platform to another, and it is far cheaper to find out in week two than in the week of the launch.

What we usually recommend

For most aviation and oil & gas clients, we deliver the core course as SCORM 2004, because it works everywhere and gives auditors exactly what they expect. When the program includes simulations, practical assessments or mobile refreshers, we add xAPI tracking for those parts and send the data to the client's LRS. We suggest cmi5 when the client's LMS supports it well and the program is new, so there is no legacy content to migrate.

The format matters less than deciding, before the build starts, which questions the data needs to answer.