Agree. Although I encountered an interesting who-are-the-users? issue when I was involved in using simulations to support training. The people buying the system

Agree. Although I encountered an interesting who-are-the-users? issue when I was involved in using simulations to support training. The people buying the systems did at least understand they they should consult the users when writing their (so-called) user requirements. But who were the users? Three categories were identified: The students themselves, the instructors and the 'customers' of the training system - the people who had to 'employ' the students when trained. After a lot of discussion, they picked the instructors as the main users, and wrote the requirements for the training system with them in mind. It worked, sort of. But what was overlooked was that the individuals who spent most actual screen time with the systems were the courseware developers. They had to build the training scenarios, which involved a lot of faffing around in the virtual world to create content that would support specific training objectives. The courseware devs, using the completed system, reckoned on an hour of dev time to build five minutes of useful training in the sim. One of the reasons it was so slow was that the courseware devs (think of them as level designers in a gaming context) had very few tools to help them build the scenario, e.g. to check map inter-visibility. The system devs had created some great tools for the instructors (e.g. after action review) but they had pretty much failed to consider how many different training scenarios were needed to keep the training relevant over time, and thus the relative importance of scenario dev tools.