You spend so much time preparing your prototype. You rethink stuff as you write cards, go back to correct stuff, remember early playtests and adapt your corrections. You write rules, sometimes a bullet point list, sometimes a full-on rulebook. You call friends and buy snacks. Yes! Ready for the playtest.

And then, on the second turn, someone plays a rule wrong. Maybe they forget to stop their movement when they pass over an event token, or they pay for a building card with magic tokens instead of bricks.

Most designers would correct the tester, but I don’t.

Let me clarify. Sometimes, you have to because it would nullify your playtest: if you’re testing how tight your economy is, you can’t let a player forget to pay for an action. However, most tester mistake don’t break much, and I let them slip.

Before I explain why, let’s remember why we playtest. We playtest to gain information, we use that information to iterate, and iteration is progress. A good playtest is one that gives a lot of quality information, and that means that the right behaviour in a playtest is the one that will yield more or better information.

In a recent playtest of With a Smile & a Gun 2: The Smilegunnening (working title), a player misunderstood a rule.  The game has a rondel, and players can skip one space for free, but moving farther costs one meeple per space. This playtester had apparently played too much Mac Gerdts recently, and assumed that they could skip up to 2 spaces: that’s how it works in games like Navegador or Antike.

Should I correct them? Which decision would bring the most and/or best information?

Correcting them would give me some information: first, the player misunderstanding the rule is an important data point. It could mean the teach was lacking, that I need a reminder somewhere, a clearer graphic design, that it’s counterintuitive, or any number of things: I will clarify that later, after the game ends.

Second… there’s no second data point. That’s the extent of what I’m learning by correcting them. I learn that they messed up, and I might learn why.

If I let them play it out though, here’s what I learn:

• I still learn that the player made the mistake, just like if I correct them;
• I can see if their opponent corrects them, which can help me nuance or reinforce the previous data point;
• I can see if the mistake breaks the game: like it or not, players make mistake even when playing a simple published game, and knowing how bad it will be if they do is important;
• Related, if the game works just as well (or even, gasp, better) without the missed rule, I know I can drop it without breaking anything;
• I can better see the pace and flow of the game when I don’t interrupt.

That’s a lot more data.

In addition to that, I find that interrupting a playtest from the outside often leads to the playtester clamming up. Most of the time, I want playtesters to forget it’s a playtest, and to just play the game. I want them to forget I’m next to them, watching, judging. Interrupting them reminds them I’m here, staring at them and taking notes about how they act. Judgingly. It’s kind of like a reality show, and I guess I’m Tyra Banks?

So I let that player play a la Mac Gerdts. The other player corrected them at some point: the wider span of options made it too difficult to “block” their opponent – while not broken, it affected the game negatively. Since then, I’ve added an icon to the board that specifies how far you can move before paying. Maybe I’ll add a special power that breaks the rule, to help people remember it.

In a different playtest of WSG 2 Smilectric Gunaloo (told you it’s a working title), a playtester dropped the meeple they paid on the space they jumped over. To be clear, I never said anything close to that, that was not a thing in the game, but hey, why not. Eventually, their opponent paid a meeple to the supply, and the player in the wrong “corrected” them. A few turns later, one of them landed on one of their meeples, and took it back in their hand, no questions asked – I love it, they’re unknowingly designing a cool concept for my game, with no input on my end. They did ask for my input when player A landed on player B’s meeple: what do they do then? And that’s when I served them one of my favourites: “What would you like to have happen?”

Sometimes, however, the cost for not interrupting is too high. In a third test of Smiley Smiley Gun Gun (I’m trying stuff out), I did decide to interrupt the game and correct the tester. Players amass resources, which they use to bribe politicians and score points. The tester somehow missed that each politician can only be bribed with resources of the same colour. The game loses most of its meaning if all resources are wild and all politicians are the same, and that outweighed the extra data from letting it play out. Still, before I corrected them, I allowed a bit of time to see if their opponent caught it, see if they would correct them themselves – that’s not an outside interruption, affects the tester’s headspace a lot less, and again, is a data point about the rules’ clarity.

So yeah, sometimes, it’s worth interrupting. However, in my experience, it happens much more often than it should. Letting those errors slide is a useful tool, one that makes you a better designer if you have it in your belt.

On a separate note, the game is now called 2 Smiles 2 Gunrious.