Software
simulations.
A simulation puts the learner inside a fake version of the software they're learning. They click the right menu, fill in the right field, hit the right button — and the simulation responds. It's the difference between watching a tutorial and doing the tutorial.
Active practice of software tasks.
Simulations work when the goal is for the learner to do the task, not just understand it. Software training, system rollouts, compliance procedures inside line-of-business tools — anywhere the learner will be doing this work tomorrow.
- New software rollouts where everyone must learn the same workflow.
- Compliance procedures inside accounting, HR, or operational systems.
- "Show me, then let me try" patterns where active practice matters.
- Refresher training before a hands-on session or assessment.
Conceptual or strategic content.
Simulations are expensive to build. Reserve them for content where the value is "did the learner actually do the task". For background, theory, or "why we do this" content, use other patterns — video, prose, or a scenario.
- Conceptual learning where doing isn't the point.
- Tasks that change frequently — the sim will be out of date in months.
- Single-step interactions — a screenshot with a callout is cheaper.
- Software that the learner won't actually use for months — they'll have forgotten.
Try the simulation.
A simplified spreadsheet interaction. Your task: calculate the total for the column. Click the right cell, then click Sum — the simulation guides you and tells you if you go wrong.
Calculate the total of column B (cells B2 through B5). Step 1: click the empty cell B6 to select it.
Real simulations look like the real software, not this simplified version. The principles are the same: lock everything except the next correct action, guide the learner through the steps, and let them recover from mistakes without restarting.
Get the structure right.
Match the real software visually
The simulation should look as close to the real software as legal/technical constraints allow. The same colours, the same layout, the same labels. Learners who train on a simulation that looks different from production will hesitate when they switch — undermining the whole point.
Limit the surface area
Don't try to simulate the whole application. Build just the part of the screen the task needs. Everything outside that scope should be visible (for realism) but disabled (to keep the path clear). Big simulations are exhausting to build and noisy to learn from.
Guide, don't punish
Show the next correct action visibly — a subtle highlight, a "next click here" arrow, a pulsing dot. Some simulations hide the cue entirely and let learners hunt; that's almost always frustrating. Reveal the cue immediately if the learner clicks the wrong place once.
Accessibility — keyboard and screen reader
Software simulations are some of the hardest interactions to make accessible. Every clickable cell needs to be a button or focusable element with a meaningful aria-label. The "next correct step" should be announced as instructions move. Without this, the simulation excludes screen reader users entirely.
Three modes: Show, Try, Test
Classic simulation pedagogy: first the learner watches the steps (Show), then they do it with prompts (Try), then they do it without prompts (Test). Some simulations skip the Show step; others skip the Test. Pick deliberately based on what the learner needs.
Recoverable mistakes
Letting a wrong click restart the entire simulation is a punishment. Better: show feedback ("That's the format menu — for this task, we want the Sum button"), let the learner try again, and continue. The simulation is meant to train, not test endurance.
How to build simulations that teach.
Decide whether a simulation is even the right call.
Simulations are expensive — usually Storyline-level work. Before you commit, ask: would a video walkthrough do the job? A screenshot with hotspots? A printed quick-reference card? Simulations beat all of these when the value is in active practice. If the learner just needs to recognise the screen, a simulation is overkill.
Lock everything but the right next step.
Most software has dozens of clickable elements at any moment. In the simulation, only the next correct action should be live. Everything else should be visible but disabled. This both keeps the learner on track and dramatically reduces the simulation's complexity.
Write task instructions in the learner's voice.
"Click cell B6 to select it." beats "The user navigates to cell B6." Speak directly to the learner, in their language, in present tense. Training videos with narrator voiceovers fall into corporate distance — simulations don't have to.
Handle wrong clicks with context.
If the learner clicks the wrong cell, don't just buzz. Explain what they clicked, why it's not the right next step, and what to try instead. "You clicked cell A6, which is the label. We want B6, the empty cell to its right." Recovery feedback is where simulations earn their value.
Decide whether errors count.
In a Try mode, mistakes are learning moments — log them, but don't grade them. In a Test mode, mistakes might count toward a score. Be explicit with the learner about which mode they're in. Mixing the two creates the "wait, was that for real?" moment that erodes trust.
Keep simulations short.
Five to fifteen steps maximum. A 40-step simulation is exhausting and a maintenance nightmare. If the workflow has more steps, break it into multiple simulations, each focused on one task. Learners can pause between them; one long simulation forces them to do it all in one go.
Plan for the software changing.
If the real software updates next quarter, the simulation might be out of date. Build with that in mind: separate the content (task instructions, feedback) from the visual (screenshots, layout) so updates don't require rebuilding from scratch. Some teams find video easier to update; some find simulation easier. Decide deliberately, not by default.
When you'd reach for a software simulation.
New ERP or HRIS rollout
The whole company is moving to a new system. Active practice of common workflows — submitting an expense, requesting leave, posting a journal — beats reading the documentation.
Compliance procedures in line-of-business tools
How to enter a high-risk transaction in the trading system. How to flag a safety incident in the reporting tool. Where the procedure matters and the workflow has to be exactly right.
Software training for new hires
Common workflows in the CRM, the support tool, the project management software. Onboarding modules where the simulation replaces a "shadow a colleague" session that's expensive to scale.
Refresher before a high-stakes task
Annual recertification for safety systems. Pre-flight checks for equipment operators. Where the learner does the task rarely but has to do it correctly when they do.
Need a working
software simulation?
We build software simulations in Storyline and Rise, depending on the depth. Three-week delivery, transparent pricing, zero drama.