Playtesting is an essential aspect of game development. From ideation up to delivery, there should be repeating cycle of design-build-test-reflect. Always be working toward making something playable, and when you have something playable, play it. The shorter you can make this cycle, the better. Can you have an idea on Monday and test it on Friday? Can you have an idea at noon and test it at 1:00pm?
In preproduction, many of your playtests will be with other team members and classmates. As you refine your work, you should be bringing in other testers. Remember that your concept document should reflect who is in your target audience, and that’s who you need for testing.
Playtesting is goal-directed. Every playtest should have a clear goal. Always know what it is you are testing, whether it’s a control scheme, a level design, a sound effect, a system interaction, or any other design decision.
Always take notes when you playtest, whether it is solo testing or with other people. The number one fallacy that we tell ourselves is, “I will remember this.” My personal favorite method for tracking design choices and playtesting results is to keep a design log.
When someone else is playing the game, watch them play. Notice what they say and do: such observations are your primary source of playtesting data. What someone says or recommends is worth writing down, but it should always be in the context of what they actually did.
Explain as little as possible—before, during, and after gameplay. Instead, ask them questions. The best question to ask is, “What did you do?” This helps you understand the player’s experience, including what verbs the game is eliciting.
After the testing, there are three questions to consider:
Triaging the playtesting results this way forces you to make hard decisions. Once you have done this, you begin another round of the design-build-test-reflect cycle. The more you practice the process, the better you become at it.
The Playtest Report is a formal document that is designed to hold the team accountable to the iterative development process. It serves both the team and the producer by providing information that can be used to improve the process and the product.
A good report will start with the big ideas and then work its way downward toward the details. This is often done by including an executive summary that anyone in the organization can read for an overview. The body of the report follows, and raw data can be included either within the report or as appendices.
A report states precisely what happened and what it means. A good report points explicitly toward immediate future action. It does not make arguments as in an essay, although it must provide context for how the reported phenomena are being interpreted.
Here are some reflection questions that you can use to guide you in composing your playtesting report:
All game design advice worth its salt will talk about the centrality of playtesting. Here are some resources that I like and that may be useful to you.
