I spent years learning to become an instructional designer. I took courses, pored over hefty tomes, conducted research, performed tough internships, and worked with brilliant mentors. I got my Ph. D. in instructional design. Later, I spent several many years practicing and teaching Instructional Systems Design (ISD).
The ISD model is a systematic procedure for designing and developing all types of instruction, including training games. In this procedure, the first step is learner analysis, where you create a profile of the typical participant who will use your game. Then there is task analysis, where you specify the tasks that participants should be able to perform after playing the game. Then you specify objectives in measurable, behavioral terms to create an outline of the training activity. Next you actually design a game (finally!). Then you test a prototype of the game, evaluate the results, and make suitable revisions.
The ISD model prescribes how we should design training games. But that’s not the way I design training games. When I design training games, I cheat (my favorite hobby) and use several different approaches. Sometimes, if my client insists on the use of ISD model, I superimpose the steps of the ISD model, employing reconstructed logic.
Of several different game-design approaches, I prefer what I call concurrent co-design. Concurrent because I mix up the sequence of design steps. Co-design because I design games with groups of players. By designing while playing, everyone becomes a designer. The result is an organic co-creation. Nobody can figure out who contributed what to the final design. And nobody cares about the recognition of individual contributions.
Concurrent co-design is not a procedure that you implement one step at a time. Instead, it is a set of design principles that you implement in any sequence or combination.
Here are some of these principles:
Don't analyze in isolation. Conduct the learner analysis as you design and play the game. If your game does not match learners’ preferences, they will refuse to play or, better yet, come up with a superior set of rules.
Begin close to the end. Design the game by playing it, even if playing is a final step in the ISD model. Look at your training goal in a holistic fashion. Decide what type of learning is involved and select one or more designs or frames that have worked with similar goals in the past. Start playing the game, making up or altering the rules and play materials as you go.
Design and test together. Play the game with real people as early in your design process as possible. Any group will do. As my friends know, I sometimes start a game with people riding in a crowded elevator or lining up at a ticket counter. An effective game works with all types of players. Any necessary fine-tuning can be done quickly on the spot.
Manage paradoxes. The heart of game design is the art of managing paradoxes. Make sure your game is fun to play and produces a serious training impact. Make sure that your game supports individual needs and forces individuals to take into account the needs of the team. Make sure your game rewards skills and has an element of chance to provide hope to the player who is behind.
Ignore your objectives. This is a major paradox for you to manage. Park the training objectives in the back of your mind. You will be surprised by the actual attitude change, skill acquisition, and knowledge mastery that result from the game. Identify these outcomes and add them to your list of training objectives. And remember, your game does not have to teach everything. You can supplement it with debriefing discussions, reading assignments, and hands-on demonstrations.
Tinker. Play with the rules, not within the rules. Don’t begin with a complete set of rules. Instead, start with one or two basic rules and improvise the rest. Watch the rules emerge from the play--and from the players. Because every player has a different background, your game ends up with an eclectic flow.
Debrief players. Find out what they enjoyed and what they disliked. Ask players for suggestions for improving the game. Play it again immediately to test new procedures.
Let go. Game designs are never finished. Don't get proprietary and insist that there is only one correct way to play your game. Encourage facilitators and players to alter with your game. Minutes, days, or years later, when you least expect it, somebody will share a brilliant twist to your game.
Send me your tweaks
I invite you, as my readers and co-designers, to help me in this process. As you read and play the games in this issue, in the past issues, and in the future issues, come up with your own adjustments and modifications. Let me know how you have tweaked a game through email (firstname.lastname@example.org) or by using the Commentary section.