Once Is Not Enough: How to Playtest Custom Learning Games

I believe playtesting is a crucial, and often overlooked, part of learning game design. It takes multiple iterations to determine the right combination of game mechanics and game elements for your target learners. Whether you are an experienced game designer or an instructional designer trying to design a game for the first time, your game will benefit from multiple rounds of playtesting.

Of course, if we are going to tell everyone else to playtest their games, we have to do so as well! The following is the step-by-step story of how we created and play-tested a recent learning game for a client.

Example: Serious Game for Healthcare Workers

We recently created a game called “Five Star Facility,” targeted towards environmental technicians who work in healthcare settings. These technicians clean the patients’ rooms and other areas of a hospital or long-term care facility. It took us four iterations to get the game we wanted and players could most learn from.

We reached a great game in the end, but it took good playtesting and iteration to get us there. Our stellar design team of Amanda Gentry, Matt Kroeger, Kristen Hewett, and Erika Bartlett did a terrific job!

Version One – Let’s create something “sort of like Clue”

This version has similarity to a commercial game called Clue. The design team felt the target learners would be pretty familiar with Clue’s  rules and core dynamics (exploration, collection), and they wanted a game that learners could quickly learn to play. Gameplay was competitive. The game goal was to be the first person to collect all the room tokens, which represented all the categories of information players needed to learn and remember. Players rolled a die to determine how many spaces they moved on the board. Each space corresponded to a different category of environmental protection/cleaning. Players had to answer questions related to whatever category they landed on. Similar to Clue, they had to go into each room on the board. Answering a question in the room earned them a token for that room. The first player to earn all the tokens won the game.

It wasn’t a terrible game design… but it was just okay.

Problems With the First Design:

1. The game could get sort of long if people were rolling lots of low numbers.
2. The designers made the game competitive. In the real-world, environmental technicians should behave cooperatively with each other and with the healthcare team as a whole.
3. This first rendition ignored the “why” of the environmental tech’s job and didn’t help them see the connection between what they do and how the healthcare facility gets dollars to stay in business. Survey ratings determine the reimbursements healthcare facilities receive from Medicare. If your facility’s aggregate survey ratings are only three stars, you do not receive the same dollars as a facility who received five star ratings.

Version Two – Scrap the Clue idea. Let’s race to the finish.

The icons are gone, the die is gone, and we have a path we’re traveling and monetary targets to reach. This version stunk. It was boring and tedious to play. Players simply took turns drawing cards to try to reach the target dollar amount. They worked together to answer the questions, but when the designers switched from competition to cooperation, they failed to include game mechanics that created any conflict or tension within the players. There was no “Lose” state or no really bad things that could happen. This version was quickly ditched.

Version Three – Bring back the game icons. Add in a progress tracker.

Version three was much better! The team latched on to the realization that five star ratings led to better reimbursements. Now players had to secure at least $70K in reimbursements to win… and mistakes would push their survey ratings downward. This was better, but there was still a serious flaw. Players’ dollars didn’t go down when they made mistakes; only their survey ratings did. In the real world, these are tied together. We also discovered as we played that we needed to better write our questions to eliminate ambiguity of responses. On the plus side, the discussion team members did before deciding on a correct response was phenomenal. Lots of learning happened in these discussions.

 Version Four – We have a winner!

The final version of the game was the winner. Look at how we tied together survey ratings and reimbursement dollars. Players start with a 1.5 star rating and $30K in reimbursement dollars. To move to the right and earn more dollars, they have to enter a room and respond correctly to that category’s question. They still roll a die to move a team token around the board. If they land on a space outside of a room, they have to answer a question that corresponds to the icon they land on. A correct response allows play to progress to the next player with no adverse event. An incorrect response forces players to move to a lower survey rating. If they hit the zero starts spot on the game board, the game is over and the team loses. If they earn $10K from every “room” on the game board and achieve at least $70K in reimbursement, they win.

Lessons for learning game designers:

1. Make sure your choice of a competitive game or a cooperative game mirrors the real-world environment. Do not have people competing in a learning game if their real-world context requires cooperation or collaboration to be successful.
2. Be aware that competitive games do not tend to be as influential of learning experiences as cooperative ones do. In competitive games, only one person or team wins. The “losers” can disengage from the experience entirely if it is not managed well.
3. Make sure the game mechanics (rules) and game goal complement – or at least do not detract – from your real-world situation.
4. Make sure your game includes enough “tension” in it to keep things interesting. Interesting translates into “fun.” If there are not realistically significant odds of losing the game, it becomes boring to play.
5. Don’t be content with the first version of your game; it will not be the best version.
6. Don’t playtest once; identify changes to make, and then fail to playtest to verify those changes improve the game play and learning experience. You have to test every time you make a change.