Useful Tips Early in the Playtesting Process

 Useful Tips Early in the Playtesting Process

Seriously. Like, SO much game left.

Being early in the playtesting process presents all sorts of obstacles, but it also provides us with a lot of opportunities! The thing is that it can be easy to miss those opportunities if you're a neophyte designer (like myself!) and find yourself getting overwhelmed with new ideas, changes, iterations, blah blah blah. You sometimes end up reinventing the wheel or traveling in a bit of a circle and besides that being time wasted, it can also feel very frustrating. So based on my very limited experience, I wanted to share some tips in the early parts of the playtesting process that I think are extremely useful and can provide you with data you can leverage to make each successive iteration of your game that much better. None of it is airtight, of course, and we all have our different styles of working. Do what works for you! But anyway...

As a novice game designer, it's easy to get excited about either the very big picture or the extraordinarily small details. There's a lot of ground to cover in-between those two things, but it's not always fun or sexy or full of things that jump out at you. The first thing?

1) Practice Your Pitch

I know this isn't exciting. I know it is work. I know it may feel like putting the cart before the horse - "I'm teaching the game to some friends, not pitching it to a publisher. And they already know it's a prototype!" All of those things are true, but also, when we're talking to friends and family, it can be easy to lean on their understanding and their patience. We've been sitting with our game idea for awhile, but unless we regularly explain it to other people, we sometimes don't think about the order in which we share game rules or concepts. We might share the most exciting stuff (the hook) first. But play-testers are already sitting at your table, so you don't need to lead with your hook to interest them; they're already interested! In my little play-testing journal, Chad and I track start and end time for game set-up, rules explanation, and actual play time, and then we add all that time up so we have four different values. There have been plenty of times when I've decided I'm not in the mood for a game because just learning the rules will take longer than I want to invest.

Don't walk into this cold. I don't care how well you know the game; knowing a game is different from teaching a game. Practice how you're going to teach the game so you can get more accurate data regarding how intuitive the rules are and how quickly people can learn them.

2) Pick Your Questions Before Gametime

This is part of your prep before every playtest, in my opinion. Maybe when you're a more experienced designer or a veteran, you can walk in cold and improvise because you already know what you're looking for. But when you're a novice, any notion that you can do this will be quickly disabused when the play-test gets going. There is so much data to collect during a playtest. I'm taking notes on peoples' postures, their non-verbal body language, sounds they make (when something comes up, are they making a sort of delighted ah-ha! sound or are they letting out a resigned sigh?), and then I'm also often tracking the choices people make in-game as well as the questions they ask or suggestions they make. By the time we get to the end of a playtest (We want Familiars to run 60-90 minutes, but we're still in 90 minute territory for actual game-play, so we've got trimming to do and more thoughtful measures to implement), I'm tired! I've been writing for the past 90 minutes and paying pretty close, uninterrupted attention. I don't necessarily have questions in my head ready to go. OR I have different questions than when we started! The data elicited by the old questions might not be irrelevant, but the newer questions feel more pressing, so I may or may not remember to ask the old questions.

If I write down my questions before the play-test, that helps me do a couple of things. Firstly, I can decide whether or not to share those questions with my play-testers before they start in order to prep them. If I want them looking at a certain mechanic, then it might help if they know that so they can jot down notes or consider whether or not that mechanic is particularly useful or relevant to them. If I'm asking about small components of the game (a tertiary game mechanic, for instance), they may not even think to notice it and by the time I ask at the end of the game, all they can do is shrug. Alternately, I may not want to ask them until after the game to see how naturally the mechanic or element of the game came up and whether or not it naturally received any attention from players. Secondly, by writing my questions down, I don't have to worry about whether or not I remember them and waste everyone's time while I try to retrieve them from the recesses of my mind. They're right in front of me and I'm ready to go with my questions to collect feedback. Finally, knowing what data I'm trying to collect before the game starts colors my observations. I can notate general observations, but since I know what I'm looking for, I'm more likely to collect data relevant to those questions. Figure out the purpose of your play-test before you run it in these early stages and especially (again) as a neophyte game designer.

3) Don't Get Defensive; Just Listen

I've definitely used this GIF before, but I can't remember where, so that makes it okay to recycle it!

This is a thing I need to check regularly, because I've encountered it as a play-tester and I'm always at risk for it as a new designer. When people offer feedback, you don't need to justify or explain everything. This is especially true when you've asked for specific feedback and it's been offered to you. I recently play-tested a game for someone who wasn't even the original designer and was asked for "general feedback." I offered said feedback, and then the person coordinating the test explained the flaws in my reasoning and feedback. Mind you, the flaws weren't based on my misunderstanding of rules or gameplay or something. I had never played the game before, I was asked for my feedback, I offered it (in a way that I thought was thoughtful and not critical; mostly just observational), and it was kind of dissected. That felt crappy. But additionally, I gave you the thing you said you wanted and you couldn't just accept it; you decided that I was mistaken and needed to know why.

No thanks.

Look, I get the inclination to be defensive. I've done that before while receiving notes as an actor in rehearsal or as a playwright. But here's the thing: unless the feedback was unsolicited, you solicited the feedback. So what good does it do to defend your choices? Not everything needs to be turned into a conversation, especially when offered feedback is less about the product and more about what the person wanted it to be. Sometimes that matters ("You advertised the game as a pick up and deliver game, but the central mechanic features a die and if I'd known that, I wouldn't have chosen to play this game." - totally relevant!), but other times, it simply doesn't ("You know what would be cool? If you made this game more like Everdell because I really like that game!" - I love Everdell so hard, but Everdell is Everdell and this game isn't Everdell and it never will be, so this is pretty irrelevant feedback). When you solicit feedback from your play-testers, unless their feedback is based on an erroneous understanding of the rules or elaboration will net you more useful data, please don't turn all of it into conversations explaining why you did a thing and expect that explanation to invalidate someone's criticism or feedback. We're perfectly capable of notating any and all feedback, thanking our play-testers for generously spending their time and energy on our game, and then choosing not to implement said feedback. We gain SO much more from listening than talking. Especially in these early stages.

4) "If there was one thing you wish you could have done during this game, what would it be?"

It's easy for me to forget this question. I'm much more conditioned to ask, "What did you like and what did you dislike?" But setting specific parameters really focuses the data we're receiving in your feedback and it also helps me better grasp what players are prioritizing. They may not even realize they're prioritizing certain things, but this question really helps distill that to its essence.

I'm sure I'll think of other things as time goes on, but this feels like a good place to stop for now. I hope at least some of this was useful to y'all!