Simulator Usability and Functionality
How my business simulator (software) design ensures efficient and fool proof use!
Home > Business simulation usability
When the participants or tutor are using the simulation software (simulator) they are wasting time doing this rather than learning.
With a manufacturing background I like to design lean software that minimises this waste and so do not design in features that do not add to purpose and do not build in sprinkles or cherries because they are cool or blingy. Do you use software that has many, many features that you do not need, never use, do not know about and waste time?
Having said that, I have built in the necessary features based on using business simulations in the classroom over more than 40 years, thousands of times with tens of thousands of business people. I know what can go wrong and have built in features that ensure that this does not happen to you. Here I explore the whys and whats of this.
Business simulations are unlike application platforms like word processors or spread sheets where the software is used in an unstructured, extemporary way. As illustrated below, for business simulations there is a clear process where the data is loaded, decisions are entered, a period is simulated, data is saved and results displayed and/or printed.
Usual Business Simulation Processing Cycle
Quick to Learn
Neither the tutor or the learners wish to waste time learning how to use the software or make mistakes because the simulator is over complicated or confusing. (consider what happened when you moved from Windows 7 to Windows 8.)
The tutor wants to spend his or her time ensuring that learning takes place and the learners want spend their time learning about business rather than learning how to use the software.
Easy to Use
I like to ensure ease of use by taking users (participants or the tutor) through the cycle shown above. Although, there are additional administrative functions (like reprinting results, re-running a period, configuring the simulation) but as these are used rarely they are not at the heart of the normal process.
The objective is prevent the user wasting time searching what to do next.
Business simulations require both software use and learning support and these can be supplied by an on-line, context sensitive help system.
Support with Software Use
As described above, the simulation should be easy to use there are still a need for on-line help with the software, with the current task and data explanations. Software help tells the user which keys to press; task advice suggest to users what they should consider when performing a task and data explanations provide definitions of business terms (such as Cost of Sales).
Standard Help Buttons
When a button is clicked then a help window (as illustrated below) opens. The window's content should depend on the current software context (in the example when decisions are being entered).
Help with use of software
Ideally, these help pages should be brief and, if necessary, with a hyperlink to further information. In the Decision Entry example of software help the red, underlined word is a hypertext link to another help page.
Learning can be supported in several ways - through cognition prompts (pre-planned textual statements positioned in the decision-making cycle) and reflection triggers (textual comments that are produced reactively by the simulation to stimulate thought and discussion).
The software must minimise the time taken to enter decisions and produce results and minimise the risk of entering a decision wrongly. The chart below shows the decision template for my Training Challenge simulation and the result of error checking.
Decision Entry Template and Error Check
Spending time entering decisions is a waste. If the decisions are entered by the participants it takes time from their learning and if the decisions are entered by the tutor he is not spending time challenging and coaching and the learners are wasting time waiting for the decisions to be entered. So, how do I speed decision entry.
After entering decisions and before simulation, the decisions should be checked to see if they are legal or unusual. Illegal decisions are rejected and unusual decisions questioned. If either are detected then the user is informed and can return to the decision template to make changes. Without these checks, illegal decisions are likely to crash the simulator. If an unusual decisions is due to a misunderstanding, inappropriate results will be produced. Even if the unusual decision is deliberate then participants are warned of possible problems. The example above shows that "Group 4 clients feel that the Consultancy Fee seems high" - a comment that is designed to suggest that the decision is unusually high and might cause problems.
Without an error check time will be wasted as the period will need to be re-run.
Besides error checking it is helpful to parse data as it is entered. Parsing involves rejecting inappropriate key presses and is basic data processing practice. How does this work? Consider what happens when you enter a telephone number or credit card number on a website. The software is expecting numbers rather than letters to be entered and so if you press the letter O rather than the number 0 this is wrong. If the input is parsed, nothing happens when the letter O is pressed. An alternative is to wait until you've completed entry and then tell you to re-enter the WHOLE number. (For this example, trained software designers will also allow you to enter spaces to separate groups of numbers and then discard the spaces - amateurs will produce software that screams at you after entry - telling you only to use numbers - duh).
If entries are not parsed then an inappropriate decision is passed to the simulation model, in the best case, this will produce a wrong result and in the worst case crash the software (cause a run time exception).
Following simulations results are produced for participants to analyse, discuss and use to prepare their next decisions. Here time can be wasted during the analysis and administratively.
A very simple simulation may involve two or three reports but for realistically challenging simulations the number increases to a score or more. This means that there is disconnect between the number of reports and the size of the computer screen. This will lead to participants having to switch between screens. Not only does this take time, but short term memory constraints will force screens to be revisited. I feel that the best format for results is for them to be printed on paper. Not only can more information be provided on a sheet of paper but it is a permanent records and participants can make notes on the paper and participants have a record of their progress (including the notes).
A second consideration is font size. Where the simulator is used by the participants they cluster around the screen and are some distance from the screen. Where the simulator is used by the tutor, he or she tends to be mature without perfect eyesight. Consequentially, I use a reasonably large font.
Automated Production of Results
I feel that it is best for results to be printed on paper. This eliminates the need to switch between screens, allows participants to make notes on the results and keep an full set of results. Also with many simulations it means that only a single computer and printer is needed. But, printers are bottlenecks and I minimise printing time by automatically printing results directly after simulation and producing the results in stages. For example for my Total Enterprise simulations where several teams compete against each other, a series of reports are automatically printed in turn. Initially, a few preliminary results are printed that can be worked on while the full results are printed, then business research information is printed and following this information for the tutor.
What happens if something goes wrong? The software needs to minimise the time taken to recover from entry errors and from hardware problems. Central to protecting against problems is journalisation where copies of each period's data and for complex or interactive simulations copies of decisions are save to disc. The Usual Business Simulation Processing Cycle (displayed earlier) illustrates this. The data loaded is from the previous period and after simulation a new file is created to save the new data. Then if there is a problem the simulation can be made to revert to the earlier period and it is not necessary to resimulate from the beginning.
Journalisation is fundamental to software design.
As described in Error Check section before simulation errors should be checked to ensure that they are legal and not outlandish. But no matter how carefully you check decisions before you simulate, mistakes will sneak past and so being able to go back to an earlier stage or period to correct and rerun is vital. Also this must be done quickly and easily. This means that instead of re-entering all the decisions (for all teams) all that is necessary is to re-enter the (single) wrong decision.
In the early days this was an issue but today, the main problems are associated with the printer (jamming or running out of toner or ink). A second problem that a client had with a competitor's simulation was that the computer could not be switched off or the simulator stopped - if it was all data was lost back to the start (requiring all decisions to be re-entered and all periods re-simulated)! Both these are overcome by journalisation. Additionally, printer problems can be overcome by saving data before starting to print so that data can be recovered and results to be reprinted (after unjamming or replacing the toner or ink).
Most recent update: 20/07/15
Hall Marketing, Studio 11, Colman's Wharf, 45 Morris Road, London E14 6PA, ENGLAND
Phone +44 (0)20 7537 2982 E-mail firstname.lastname@example.org