We’re hard at work testing all the missions in Far Away: Corporate Espionage. Whether it’s our local fans testing with cards from my printer or our excellent community testing the demo PNP, we need all eyes on the game to make sure it lives up to the promises of the crowdfunding campaign. Recently, I’ve found myself conscripting people who haven’t playtested a board game before. While the raw experience is most important, I can’t help but to think of some guidance for these people to get and give the most during the tests. Here are a few tips for anyone playtesting a game that ensure everyone walks away feeling great.
As a giant caveat, all of this is secondary to the dedication to actually test the game. I’m extremely grateful to anyone who runs through a Far Away mission and tells me about a typo or challenge. Think of this as guidance for folks who regularly help with their friends’ games.
Be honest. Feedback is only helpful if it’s true. Depending on the person, they tend to make one of two adjustments to their own perception. The first is that they censor their feedback to avoid looking foolish. Of course, playtesting should be judgement-free. We’d rather hear that something is confusing from a tester than on a BGG thread. The other direction is when testers try to find confusion. They understand what the rule is but perceive that others may not. In practice, I find this to be the more prevalent tester behavior. They’re there to find bugs and so they will.
You may think the goal is to remove all traces of confusion. It’s a good instinct but masks a different problem. Often, these fixes are added as clarification statements or phrases. Maybe “take two resources” becomes “take two resources of any type (including two different single resources) from the resource reserve”. The second statement doesn’t leave room for error but does add cognitive load. It also changes the rest of the rules: if we don’t add that different parenthetical elsewhere, does that imply those actions have to give the same resource? The real question here is what did the tester assume the rule meant? If they can be honest with themselves, they can avoid introducing new problems to the game.
Be patient. Similarly to being honest, testers should give themselves a chance to digest and understand the game. When you’re learning a game off the shelf, you don’t read half a paragraph and start asking questions. For some reason, this tends to be the default behavior when testing (at least in sessions that are more directly observed). While it can be a little randomizing to answer “what about X” with “the next paragraph explains X”, I think the real problem is that stating an opinion locks you into that opinion. If you’ve publicly committed to being confused, it’s embarrassing to backtrack.
I’ll use an example from a different job so I’m not throwing shade at my testers. When I helped design position management software for the University of Minnesota, we ran a usability test on the UI. The participants had eye tracking devices so we could see where they were looking on the screen. They were instructed to “think out loud” so we could hear their thoughts as we observed them behind a one-way mirror. One person was confused by a term in the text and stated, “I wish there was a help button I could click”. He was literally staring at a button labelled “Help”. At the time, I assumed he was an idiot. Looking back, I believe he started talking, saw the button, and couldn’t bring himself to admit he missed the obvious help button. It was easier to claim design failure than admit a personal mistake.
Signal your intentions: Sometimes, it’s helpful to stress test a game. What happens when you try to break it? It’s definitely good to know if there’s a secret strategy or way to ruin the game. However, it’s helpful for the designer to know you’re trying something unexpected. Testing is not only about finding issues. It’s also about understanding strategies. If someone’s not using feature X, the designer could assume it’s because the benefits of X aren’t clear. If a tester actively chooses to avoid X to see what happens, that’s something that doesn’t necessitate a rule tweak. This is in the same vein as being honest: what you’re doing is just as important as why you’re doing it.
Have fun: Testing a game can be an unsatisfying experience. Things are often confusing, the art’s usually not done, the helpful player aids don’t exist, and you may not even finish the game. Testing is an opportunity to peek into the design process and see the mind of the designer at work. It’s also your chance to leave a mark on the game. Whether you help find an issue, suggest a new feature, or sign off on a great experience, you’re making the game better. That’s something in which you should take pride. And if the game goes off the rails, enjoy the ride. Sometimes, all you can do is laugh at how badly you’re broken a game or how badly broken the game is.