Introduction
Key Highlights
- A realistic simulation is not automatically good training. The four instructional design choices that make system simulations build real capability.
- Watching is not learning. Learners who practise recalling a task retain far more than those who watch it done, and the gap grows with time: a week on, tested learners hold on to substantially more than those who only reviewed the material (Roediger and Karpicke, 2006).
- People do not get stuck on the happy path. They get stuck on the exception, so a simulation that only teaches the clean route leaves the first real problem uncovered.
- Most assessments test whether a user can follow a highlighted arrow, which is recognition, not capability. A real assessment removes the arrows and asks whether the task can be completed with nothing highlighted.
A flawless simulation that teaches nothing
A simulation can look perfect. It clones the system down to the last field, behaves exactly like production, and demos beautifully to a steering committee. None of that tells you whether it teaches anyone to do the job. Realism is the medium, not the lesson, and the two are easy to confuse when the clone is convincing enough.
The most common failure in systems training is not a weak tool. It is a design one: a click-through demo of the happy path, every button helpfully highlighted, that trains people to follow arrows rather than to work. It feels productive to build and reassuring to watch, which is exactly the problem. Passive review creates an illusion of mastery, and the research has known why for decades. In the classic study, students who were tested on material retained substantially more of it a week later than those who merely restudied it, even though the restudy group felt more confident in the moment (Roediger and Karpicke, 2006). A demo is the review. It is not the practice.
Good instructional design is what turns a realistic clone into training that builds capability. It comes down to four decisions.
Design for doing, not watching
The first decision is how much the learner does. A simulation that plays the task while the user watches, or that walks them click by click with the next step always lit up, keeps them in the passive mode the evidence warns against. It looks like learning and does not stick. A comprehensive review of study techniques rated practice testing, the act of retrieving and performing rather than reviewing, one of only two strategies with high utility for durable learning (Dunlosky et al., 2013). ASML saw this first-hand: it replaced training built from hundred-slide decks, which pushed information at people without letting them touch the tool, with interactive simulations of its live systems, because people do not learn software by reading slides. SFR, the French mobile operator, built its customer-service training on the same principle: rather than watch a lesson, reps had to explore the CRM clone and find the options themselves, at their own pace, which gave them a firmer grasp of the system before they took a single live call.
Designing for doing means the learner performs the task, from memory, with support that fades as they go. Early attempts can prompt generously. Later ones should make them recall the step themselves and only catch them if they stall. The moment a simulation stops showing and starts asking is the moment it begins to teach.
The exceptions are the lesson
The second decision is what you cover. It is tempting to build the clean, standard run of a process, because it is the easiest to record and the tidiest to demo. But no one calls the service desk about the standard run. They call about the exception: the invoice that fails a validation, the field that is greyed out today, the record that does not match, the approval that routes somewhere unexpected. If the training only ever showed the happy path, the first exception in production is where confidence collapses and the workaround is born.
Designing the exceptions in is what makes a simulation prepare people for real work rather than a rehearsal of the ideal. This is far easier when the underlying content is built from editable objects rather than a fixed recording, because an author can branch the flow, alter a field, or load a different data set to stage the awkward cases deliberately. The exceptions are the point, not an afterthought.
Set a test with nothing highlighted
The third decision is how you check that learning happened, and it is the one most often got wrong. Many evaluations simply replay the demo and confirm the learner pressed the highlighted button in the right order. That tests recognition, whether someone can spot the next step when it is pointed out, which is a much lower bar than recall, whether they can produce it themselves. It is the difference between passing a test with the answers on the page and passing it without.
The measurement gap here is well documented. More than 90 per cent of training includes assessments, yet only 58 per cent of learning professionals believe they measure learning effectively, because completion and quiz scores stand in for competence (ATD, 2024). A real assessment withholds the guidance and sets the whole task: create the record, handle the exception, take it to completion, with nothing highlighted. If a learner can do that, they are ready. If they cannot, no completion certificate changes the fact.
Designing a simulation programme that has to build real competence, not just completions?
Use the three modes deliberately
The fourth decision is sequencing, and it follows from the first three. Effective systems training uses three distinct modes, and most programmes lean on one where they need all three. A demo mode shows the task, useful for a first exposure and no more. A guided-practice mode has the learner perform it with support that fades, which is where the actual learning happens. An assessment mode removes the support and verifies capability. Show, practise, verify, in that order.
Assima Train is built to produce all three from the same captured process: demos, guided practice, sandboxes for free exploration, and evaluations. The design work is deciding which mode a given task needs and when to move a learner from one to the next, rather than defaulting to a demo because it is quickest to make. A task a clinician or a finance clerk performs daily may need little demo and a lot of assessed practice. A rare, high-risk task may need all three, drilled until the sequence is automatic.
Let the data improve the design
Good design is not finished at publish. As learners work through a simulation, the analytics show where they stall and where errors cluster, and those points are a design signal, not just a learner one. When almost everyone fails the same step, the step is usually badly designed, ambiguously worded, or missing the context a real user would have. Treating those hotspots as feedback, and reworking the lesson rather than blaming the learner, is how a simulation gets sharper over time instead of ageing in place.
Conclusion
The tool matters, but it is not where systems training is won or lost. A perfectly cloned system wrapped around a passive, happy-path demo with a recognition quiz at the end will look impressive and teach little. The craft is in four choices: make the learner do the task rather than watch it, build in the exceptions where people get stuck, assess whether they can work without prompts rather than follow arrows, and sequence show, practise, and verify on purpose. Realism buys you a believable stage. What people learn on it is decided by how the lesson is designed.
Ready to close the last mile gap?
Frequently Asked Questions
Let’s Answer Some of Your Questions.
No. Realism is necessary but not sufficient. A faithful clone of the system is the medium; whether people learn depends on the design inside it. A realistic but passive click-through demo teaches recognition of steps, not the ability to perform the task, which is a much weaker outcome.
Because watching is passive, and passive review creates an illusion of mastery without durable memory. Research consistently finds that retrieving and performing a task retains far more than reviewing it, an advantage that grows a week and more after learning (Roediger and Karpicke, 2006). A demo has its place as a first exposure, but it is not practice.
Because the standard process is not where people get stuck. Exceptions are: failed validations, missing fields, unexpected routing. If training only ever showed the clean path, the first exception in production becomes a support ticket or a workaround. Designing the awkward cases in is what prepares people for real work.
By testing capability, not clicks. Remove the on-screen prompts and set the full task, so the learner has to complete it without prompts, exceptions included. Completion certificates and multiple-choice scores measure attendance and recognition; the real question is whether someone can do the task with nothing highlighted.
By testing capability, not clicks. Remove the on-screen prompts and set the full task, so the learner has to complete it without prompts, exceptions included. Completion certificates and multiple-choice scores measure attendance and recognition; the real question is whether someone can do the task with nothing highlighted.
What are the three modes of simulation training? Show, practise, and verify. A demo introduces the task, guided practice builds capability with support that fades, and an assessment removes support to confirm readiness. Assima Train can produce all three from one captured process, so the design decision is which mode each task needs, not which the tool can make.
