By Linux Foundation
Playtesting your game is thrilling. You’ve finally gotten your baby game in front of other players, you’re seeing what works and doesn’t work.
And then the session comes to a close. You say, “Okay, do you have any feedback?” and stare at your playtesters, waiting for them to fall over each other to give you a wealth of suggestions.
More often than not, instead, they just look at each other, look back at you, and say, “Not really.” They may point out one thing that went wrong so clearly people in the next room could see it, but that’s all the feedback you get.
And you end up feeling frustrated. How can you get useful feedback?
To understand that, you have to understand why people don’t easily give in-depth feedback in playtesting sessions. I think there are two main reasons: social pressure and asking the right questions.
Your playtesters are human, and they see that you’ve built a game you believe in. They don’t want you to believe your game is bad. They fear that you’ll take negative feedback personally. They also don’t want to be seen as the one person with criticisms if everyone else enjoyed the game. So, nobody goes first.
Also, “Do you have feedback?” is a vague question. It’s like a parent asking “How was school today?” or a boss asking “How’s the project going?” It’s easier to just answer “Fine.”
So. You can solve this with a couple of specific questions.
First, ask this: “What should definitely remain in the game?”
This starts the feedback with a question that’s both positive and probably unexpected, and subtly introduces some danger. The players realize that this game might change drastically, and it’s up to them to save some parts of the game.
It also shows you what parts of the game work, and what parts of the game the players enjoyed. Of course, these parts may not be perfect, but at least you know not to chuck them out immediately.
Then, ask this: “What would you like to see changed?”
Now that players realize that the game might change, you want to focus them on the problems.
Feel free to give the players some time to think about this. If the table’s initially silent, let that silence stretch for a while. Give people time to think. Don’t rush.
Then, ask this: “Did anything confuse you, even briefly?”
This is incredibly important. Some rules and aspects of games aren’t necessarily bad, they were just badly understood in the playtest. Many times, a rule makes sense to you but is unclear to other people, either because they have less experience than you, or more experience than you (“Oh, that term always means this to people who play these other sorts of games”). You need to know those pain points so you can rewrite the appropriate rules to be more clear.
Now, how should you be acting in the midst of all this feedback? Four things:
Write down everything the players suggest. You won’t be able to get it down word-for-word, naturally, but get the gist of it on paper. Even if you think it’s dumb. Even if you never plan to implement it.
Why? That tells the player that you care about her or his feedback, which further tells the other players that you’ll care about their feedback, too.
Also, you may look at that feedback later and realize that it’s not so crazy after all.
Ask “Why?” if a playtester doesn’t explain his or her suggestion. Meaning, if a player says “You should drop the encumbrance system,” full stop, ask them why.
You need to understand the reasoning behind their feedback, because their specific piece of advice might not be perfect, but the reason for the advice will tell you what’s going wrong.
Don’t disagree with a playtester. Your job here is not to tell the playtesters if they’re right or wrong; it’s to gather feedback. So just smile, nod, and accept whatever feedback you get.
Again, remember, you don’t have to implement any of the feedback you receive. So it’s much better to take all of it graciously and positively, so that you’ll get all the feedback you can possibly get.
Don’t explain your design decisions unless specifically asked to. This is a very common mistake, and very easy for us designers. A player will suggest that you change a rule, and you’ll launch into an explanation of why you included that rule.
You might think you’re engaging the player with that rule, to better understand the best way to change it. But more often than not, it comes across like you’re defending the game. It will make other players less likely to share feedback, because they don’t want to get into a debate.
Again, your job is to collect feedback. Collect it.
What should you do with all that feedback? I’ll write about that in the next post.