
Software training has a reputation it has earned. Someone records a walkthrough of the interface, the learner watches every feature in order, and at the end they can recognize the screens but cannot do their job with them. The training covered the tool. It never covered the work.
This case study covers how a worldwide non-profit organization trained its staff on new HR system functionality, and why the design put a story around the software rather than a tour through it.
A worldwide non-profit needed employees to get to grips with new features in an HR recruitment tool. The organization asked specifically for simulation-based learning, with three outcomes attached: better trained staff, in less time, at lower cost.
The other requirements were about the experience itself. The learning had to be engaging and relevant to the learners’ job responsibilities, and the client wanted the training developers to come back with something that would make the experience an immersive one rather than another recorded walkthrough.
The difficulty with system training is that features have no natural order from the learner’s point of view. The software has a menu structure, and the temptation is to teach in that order, which produces a course organized around the product rather than around the job. A learner who spends most of their time in two screens gets the same amount of attention on the eleven they will never open.
There is also the question of why. A recruitment system embodies decisions about how roles are structured and compared, and someone who does not understand that reasoning will use the tool mechanically and get it wrong at the edges. Teaching the buttons without the logic produces staff who can complete the form and cannot tell when the form is wrong.
Our team used a story-based approach, with characters inside a scenario drawn from the learners’ actual job responsibilities. Appropriate situations and a strong narrative gave learners a reason to stay with the module rather than click through it, and gave the features a context in which they made sense.
This is the part that solves the ordering problem. A story has its own sequence, driven by what the character needs to do next, and that sequence is much closer to the order a real employee meets these tasks than any menu structure would be.
The program set out the reasoning behind the system before asking anyone to operate it, showing how the grading structure connects to salary decisions, workforce planning, reward, career paths, and succession. Interactive diagrams let learners explore those relationships rather than read them, which is what turns a policy explanation into something a learner can actually hold.

Content was delivered through clickable information, info highlights, guided simulations, and practice exercises with hints. The distinction between a guided simulation and a demonstration video is the whole argument for this approach. In a simulation the learner performs the step, and a hint arrives when they hesitate rather than a narrator performing it for them.
Knowledge check questions were placed both before and after the simulations, testing understanding first and then application. Asking before practice does something useful that most courses skip. It shows the learner what they do not know, which is what makes the practice that follows feel necessary rather than remedial.

The program was delivered as personalized learning through the client’s LMS and LXP, so learners met the parts of the tool that mattered for their role rather than working through the full feature set regardless of what they do.
The third result is the one that matters for a non-profit, where training budgets compete directly with program spending. Efficiency in tool usage after training is the closest thing here to a return, and it is the outcome that justifies having built something more considered than a screen recording.
Simulation is the obvious answer for system training, and it is only half of one. A simulation teaches the steps. What it does not supply on its own is the reason the steps exist, which is why this design spent time on the structure behind the system before putting anyone inside it.
The story is doing something similarly unglamorous. It is not there to make the subject entertaining, and a narrative laid over a feature tour would not have helped. It is there because a story imposes the order a learner needs, which a product menu never does.
If you are rolling out a new system and want staff who can use it rather than recognize it, Liberate can help you build training organized around the job instead of the interface.
