A few days ago I posted an article that including notes for playtesters. While I’m at it, I’ll throw in a few suggestions for designers and developers sending out material for playtesting. If you don’t do these things, you can’t expect the good feedback described in the previous article.

1. Make it clear what you’re giving playtesters. If you’re giving them a rough draft, say so. If it’s been edited, say so. Playtesters are a part of the process, and they need to know where they fit in so they know what kind of comments to make.

2. Make your goals and intentions clear. Don’t just give them rules. Tell them what you’re trying to accomplish with those rules. Then, you don’t get a review, you get a feedback report. Reviewers write reviews, and say whether they like a thing or not, but playtesters do something different (and likely more valuable). They tell you whether or not the game works. But a playtester can’t tell if something works if they don’t know what it’s supposed to do. If it’s meant to be a rules-heavy, tactical game that scratches the wargame itch as well as the rpg itch, as a playtester I’m going to look for very different things than if you told me it’s a fast-moving, cinematic theater-of-the-mind kind of game. If you don’t tell your playtesters what you’re trying to accomplish, all they can do is tell you if they like it or not. And if you’re giving them the tactical game and they don’t like tactical games, their report will be skewed.

3. Provide specific instructions and questions. Don’t just dump rpg rules on someone and say, “here you go.” Tell them what to do: “make characters and report back on what choices you made, and why, how the process went, and how long it took.” That kind of thing will get you some real, quantifiable and usable feedback. If you have time in your process, continue to be very specific. “Run three combats with the NPCs provided and report back specifically on the initiative system and the defense numbers.” If you can’t do that, then at least ask them to focus on a specific part of the rules you really want tested as they play the game.

(The exception to this is when you are testing the readability and understandability of the rules late in the process. At that time, you might just hand a brand new group the rules and say, “here you go. Make characters and run an adventure and tell me how it goes.” In this case, you’re only testing whether they can figure things out, not if the rules actually work.)

4. Think of your playtest in phases and stages. Alpha phase is just you playing with your friends, trying stuff out. Beta phases is preparing a rules doc that others can use to run games. But Beta phase itself should be parsed out into separate stages. The first is just the initial contact with the rules. People read your game and try to figure it out. Maybe they make characters. Try out a single encounter. That sort of thing.

After that, though, are as many stages as you have time for. In each stage, you ask your testers to focus on a different part of the rules, and at the end of each stage you ask them about that subject. Perhaps at the beginning of each stage you give them new material–rules updates, new NPCs or creatures, new character options, or whatever. There is no right or wrong number of stages.

4. Don’t answer questions right away. I know it sounds crazy and rude, but lots of your playtesters will submit a bunch of clarification questions right away when you send them the rules. Make note of all of them, but then let them struggle through. You don’t want to develop a game that relies on people asking you questions. And you don’t want to develop a playtester mentality of “we’ll just ask the designer” because that’s not a very accurate way to test the rules, unless you plan on being on hand to answer every little question that comes up in everyone’s games everywhere, forevermore. (This is sometimes called “designer in a box” design–it’s a good game, if the designer’s directly involved, otherwise, it’s hard to play.)

After you get through the first stage, compile all the questions and develop a master FAQ document that you can send to everyone, so that they all playtest with the same assumptions.

5. Thank your playtesters profusely. Playtesting is vital.

1. 

   Brendan · November 1, 2012 at 5:38 pm · Reply

   Outstanding suggestions Monte.
2. 

   Imaria · November 1, 2012 at 5:45 pm · Reply

   Your methodology for playtesting just makes me hope even more that our group makes it into your playtest. Having tried to playtest for more… amateur game developers, this addresses a lot of the problems that arose. The “don’t answer questions” one is high on the list, actually; he was so helpful that the rules themselves never became clear enough without him being there. Sunk the game, in the end.
3. 

   David L. Dostaler · November 4, 2012 at 6:29 pm · Reply

   Great advice. I’ve probably been guilty of all but #5 over the years. My older playtest style was always: “Here it is, what do you think?” I’ve become much better about asking specific questions and telling people what the specific game is actually supposed to be like (and refraining from instantly answering all questions). However, it’s great to see it all listed out here. Not only a good reminder, but sound advice.

   –David