Playtesting can be a fraught experience, even in the best of circumstances. This goes double if the designer of the game is involved in the playtest, or if you’re friends of the designer (which is pretty likely in the early stages). I’ve found over the past year that I actually really enjoy playtesting, so I wanted to share my top tips on how to run a really helpful playtest and how to be a great playtester.
Let’s start at the start: what is the goal of a playtest? What are we trying to accomplish when we do this? As a designer, I’m looking for three main categories of information:
- What did people enjoy vs not enjoy?
- What did people find confusing?
- What did or did not support the intent of the game? Or, shortly, what worked and what didn’t work?
The whole goal of a playtest is to refine the game, to help make it the best game it can be. The above questions are how I do that. The first two are pretty self-explanatory. If people are obviously not having fun or are just constantly looking at me in bewilderment, something isn’t working. The last one is the main point I want to expand on, and how it differs from the others.
One of the key things to understand when you’re coordinating a playtest – whether you’re the designer of the game or not – is the intent of the game. What is the designer (yes, you too!) trying to accomplish? What type of game are they trying to make? What are they trying to say? And yes, I have gone into playtests where the designer (me!) didn’t have answers to those questions, and as a result, the whole thing pretty much ended up being useless.
What I think a lot of people struggle with is finding where the game’s intent and their own expectations don’t match, and providing feedback accordingly. If the designer’s intent is to make a suspenseful horror game and you think it’s going to be a zany beat-em-up, giving the feedback “well, I thought all those suspense rules really got in the way of me kicking this monster’s ass” isn’t helpful. There’s a mismatch somewhere in that situation, and it’s always worth explaining the intent of the game before you start.
As the playtest coordinator, I find it helpful to watch what your players do and not just what they say. It’s not that they’ll be intentionally misleading you or anything sinister! It’s because sometimes they might not think to mention something or that you want to remember for later. To give an example, I have a game in playtesting where the character playbooks were two-sided and in the initial playtests people had to keep flipping back and forth between the two sides. Mechanically, there wasn’t anything wrong with the information on the sheets, but where it was placed made a big difference in terms of players interrupting themselves to check their character sheets.
To that end, my biggest piece of feedback for a playtest coordinator is to take copious notes during the game. So many notes. Take notes on everything, even if you never end up using all of them. It can be hard to take a lot of notes while staying engaged in what’s happening in the session, but everyone else should be understanding about the fact that this is the whole point of a playtest. I know some designers actually like to use audio recording during their playtest sessions and then go back and listen later (I personally don’t do this, but I definitely see the value in it!).
When it comes time to provide feedback, there’s a tried and true critique method called the compliment sandwich – say something you liked, something you didn’t like, and then another thing you liked. It goes a long way towards sparing feelings, but this should go without saying: you can tell someone what you didn’t like about their game without being a jerk. For myself, I tend to structure the feedback phase in three parts, in this order specifically:
- I ask them what (if anything) they liked
- I ask them what (if anything) they disliked
- I ask them what (if anything) confused them or they didn’t understand
A lot of designers ask their testers to point out problems but NOT to offer solutions, and I personally tend to agree with that methodology. I don’t mind one or two small points, but mostly – let me solve the problems. I’m the designer, that’s what I do, and you can trust me to find the right solution for what I’m going for. It’s absolutely not intended as a slight against the playtesters, but in my experience, it’s needed to keep things moving. Brainstorming solutions to problems takes time away from finding the problems. Everything in its time, you know?
As a sidenote, if you’re a fellow game designer testing someone else’s game, it can come across as terribly condescending and rude to say “well if this was MY game, this is what I would do.” It’s usually well-meant, but rarely well-received.
I do like to emphasize this to my playtesters: you can ask questions too. You SHOULD ask questions! A majority of the time, the coordinator/designer is going to be asking you questions, but don’t let that stop you. If something isn’t clear in the game, if something needs to be spelled out, if something is an assumption that never made it into the game text – they need to know that.
What do you think? Have you had particularly good or bad playtest experiences? What are your top tips for getting the most out of the playtest process?
The 3 questions about testing are very important to improve your work.
what (if anything) they liked
what (if anything) they disliked
what (if anything) confused them or they didn’t understand
Thanks for sharing
I was thinking that the questions should be:
1) Strengths
2) Problems/Weaknesses
3) Tweaks
It would work best if you hand out a3x5 card for each of those items rather than discussing them aloud. This way not only will it allow each person to feel free to express their opinion as they really feel, but also it gives you something to go back to for review later.