How to Playtest Your Board Game Before You Launch on Kickstarter
Long before a game makes it to Kickstarter, playtesting is how you find out if it's ready.
Congrats! Your Kickstarter has been funded. Backers celebrate. You spend months on manufacturing and fulfillment, and then the reviews start coming in…
"The balance is completely broken."
"The rulebook makes no sense."
"This feels like an unfinished prototype."
"I want my money back."
Launching an underdeveloped game is arguably worse than not launching at all. Backers want to trust you with their money, and once you've shipped something that wasn't ready, that reputation follows you. Backers talk, and BGG threads are forever.
Playtesting is how you earn that trust before you ask for it. Done well, it also helps you build an audience, collect emails from potential backers, and discover the best version of your game. Here's how to run that process from first prototype to Kickstarter-ready.
Kickstarter
Start with yourself
Your very first playtester is you, and you can do a lot of playtesting on your own, especially early on. There's a lot of low-hanging fruit you can catch, and the goal here is two-fold: iterate quickly, and respect your playtester's time.
The earliest versions of your game will break in ways you can't predict. Scoring collapses. A weird card interaction shuts the whole thing down on turn two. Self-playtesting is how you find and fix most of that before involving anyone else. Better still, self-playtest lets you iterate as quickly as you can handle. You can try again immediately, or take a break and come back to it in an hour.
My benchmark: when I can self-playtest a game to completion by myself, it's ready for other people. By that point, I've picked the low-hanging fruit. The most obvious issues have been identified, and the game is functioning well enough to show other players to get their thoughts.
Get good at teaching it
Before you sit down with a playtester, teach your game to an inanimate object.
Software developers call this 'rubber ducking', and yes, I have a little rubber duck sitting on my game design table. You explain your game (or code) out loud to a rubber duck, and the act of saying it aloud helps to surface the problem. The exact same thing happens with rules.
Pull out your rulebook and your phone. Use your preferred voice-to-text transcription tool and walk through the whole game out loud, start to finish. You'll hear yourself stumble. You'll realize you skipped a step, or that a rule you assumed was perfectly clear makes no sense when you actually say it.
Use that transcript to write the first draft of a script. Even if you never use it word-for-word, writing it out forces you to sequence every rule in a logical order. When you do teach from it, you'll notice which parts lose people, and those are the parts you can fix.
Most of the time, my teacher follows a specific pattern:
- Who are you?
- Where and when are you?
- What are you trying to accomplish, and why?
- How do you accomplish that?
Here's an example from my recent game Around the World in 15 Minutes:
Enjoy the perfect vacation as you and your fellow sightseers journey across the globe! Around the World in 15 Minutes is played simultaneously, with each player traveling around their own personal map at the same time. You'll take turns as the Navigator and choose which of the 3 actions everyone will have to take that turn - Travel, Explore, or Collect. Have the best vacation out of your travel companions to win the game!
To be sure, a description like this rarely stands on its own. You'll see it alongside the picture or components. 'Where and when' also doesn't have to be defined if it's easy enough to figure out from the context. Still, it's easy enough to mention a year and place if they're relevant to the theme.
Who to test with
Friends and family will tell you the game is great, and they mean well. Their feedback usually won't improve your design, since they're not typically trying to identify issues with the game.
The playtesters you want are other designers and folks who play games like yours. Other designers catch structural problems – runaway leaders, mechanics that are doing twice the work they should. Regular players tell you how the experience actually feels to someone without a design vocabulary. You need both.
If you can get to a Protospiel, an Unpub event, or some convention, they're great – rooms full of people there specifically to play and critique prototypes. You'll get more actionable feedback in one afternoon than from months of kitchen-table testing with the same group.
What to watch for
As you teach the game, ask for questions frequently. I'll usually stop multiple times during the teach, then ask for questions again after the first round ends. This prevents questions from piling up and avoids knock-on frustrations if players feel that a misunderstanding prevents them from playing well.
Playtesting means watching and listening carefully. If possible, let others play so you can observe and assist. Players will tell you what they think went wrong, but their body language tells you where they actually got lost. Are they leaning in or checking their phones between turns? Are they staring at a card without saying anything?
If you're playing, recognize that you have an unfair advantage. I might play my first turn with an open hand of cards or talk through my strategy based on the game state. My goal here is to help players gain mechanical competency (the ability to play correctly) so they can get to the strategic side of the game.
Take 2 kinds of notes as you go: objective notes (what happened, what broke, what moment caused the problem) and subjective notes (what did the players say, what did their body language say). Both matter for different reasons.
When someone says they were confused, drill down. Which part confused them? Was it a card or an action? Which card? What about it specifically? 'I was confused' doesn't give you anything actionable to fix. Ask open-ended questions to get to the core problem or issue. 'I couldn't tell if this card resolves before or after I draw' is something you can actually fix.
Make at least one change between sessions – otherwise, you're just confirming what you already know.
Building your list while you test
Once your game is stable enough that it's not falling apart mid-session, start collecting emails.
Make a QR code. Link it to your Kickstarter preview page, a Mailchimp signup, or your website. Put it on the table at the end of every session.
A lot of designers wait until the campaign launches to think about their audience. By then, they've left months of potential sign-ups behind. Every person who plays your game at a Protospiel or a game night and enjoys it is a potential backer – they just need a way to find you when the campaign goes live.
A QR code on a business card-sized slip of paper is enough. Capture interest while it's fresh.
What is unguided playtesting?
Also called 'blind playtesting', unguided playtesting rules their presentation, not the game itself. Near the end of development, your goal is to hand over the box, say nothing (or as little as possible), and sit back and observe. Don't clarify, don't hint, and try not to answer questions. Avoid stepping in unless the session goes completely off the rails.
Unguided playtesting is where you find out what the rulebook actually communicates versus what you think it communicates. You don't come in the box, after all, and if players can't figure something out from the written rules alone, the written rules need to change.
Bring potential backers into these sessions if you can. People who haven't played before come to the rules fresh, and their confusion will be more honest than that of a regular playtester who already knows what you meant to write.
A rulebook editor is worth involving at this stage, too. A second professional set of eyes before these sessions catches the problems you've gone blind to after a hundred plays.
One more resource...
If you want to go deeper on all of this, I literally wrote the book on playtesting. Playtesting Best Practices, Real World and Online, published by Routledge, covers everything from self-testing to remote playtesting to gathering feedback that actually improves a design rather than just validating it.
Finally, my Micro Game May campaign for Dragon vs. Kingdom is live. It's a print-and-play game where you'll play as a kingdom builder working to build your kingdom and a dragon trying to burn it all down. Check it out here.
