How to Playtest a Game: A Guide for Game Developers

First: When should you playtest?

TL;DR Ideally, earlier than you probably think… and more than once.

You don’t need a polished game (or even a playable build) to learn something from potential players. Early on, you might test a description of the concept art, a rough prototype, or an explanation of a proposed mechanic.

The advantage is simple: the earlier you discover a problem, the easier and cheaper it usually is to change.

I like specific examples, so let’s pretend I’m working on an awesome new game: Spooky Ghost Manor 👻 (fully fictional; any resemblance to real games is coincidental. Though my love for survival horror is not.)

The game follows a vulnerable protagonist trapped in a ghost-infested mansion. To escape, players have to explore the manor, uncover its mysteries, solve puzzles, and survive the ghosts inside.

Now imagine we’re still designing the navigation system. 🗺️ We put a rough prototype in front of a few players and notice that they’re constantly getting lost. They keep opening the map, backtracking through the same hallways, and missing the environmental cues that are supposed to help them figure out where to go next.

That’s useful to learn now. At this stage, we can still rethink the map, the environmental cues, the layout, or even the way navigation works altogether. If we discover the same problem much later (when levels, quests, UI, art, scripting, and other systems have already been built around that navigation system), fixing it can become much more expensive.

And because games change constantly during development, testing your game shouldn’t be a one-time event. Test something. Make changes. Then test again.

Below are some examples of the kinds of tests you can run to collect player feedback. Playtesting is, in my opinion, the most powerful way: actually putting your game (even if it’s a rough prototype) into people’s hands and having them play it and give feedback.

Tap the chart to view it full size

Next: What are we actually testing?

TL;DR Act on observed usability issues, take caution with opinions.

At a high level, it helps to think about two broad areas: usability and engagement.

You can investigate both throughout development, but they give you different kinds of evidence. If several appropriate players (more on this in Rule #2) can’t figure out how to leave the first area in Spooky Ghost Manor, you probably don’t need 30 more people to confirm that something has gone wrong. You’ve observed a usability problem.

But if three players tell you the manor isn’t scary, or that they hate the protagonist’s outfit, that’s different. Those are subjective reactions. A few opinions can be useful, but you’d want to see how common those are in your potential audience before you act on it.

So, as a simple rule: Repeated observed problems can be strong signals with a small number of players. Opinions usually need more context, and more players, before you make big decisions.

Bonus: here is how your focus on either usability or engagement dictates which type of playtest you may choose to run:

This article focuses on moderated playtesting where you observe the player live. Why? In my opinion, it gives the biggest bang for your buck. You watch player actions and reactions, which gives you a very detailed idea of the experience they’re having. You also have a chance to ask things directly, rather than assuming you understood what issue they experienced or how that impacted them. It provides the most in-depth insights explaining the “why” behind the rating they might give your game on a survey.

Example time! Imagine we have an early playable prototype of Spooky Ghost Manor. It’s a bit rough, some art is missing, and not every mechanic is finished. That’s OK: I’m not getting feedback on art or the full range of player abilities yet.

We put it in front of a handful of players and watch them play for 30 minutes (aka we run a moderated playtest). If several players miss the same environmental cue, repeatedly get lost, or don’t understand the inventory, we’ve found something worth investigating (a usability issue!).

If a couple of them say they don’t like the protagonist’s hat? Maybe the hat is killing the vibe… maybe it isn’t. I wouldn’t invest time & resources into redesigning the character just yet.

With that foundation in place, let’s get into the rules that will help you get more useful feedback from your playtests, and actually know what to do with it.

Rule #1: Know what you want to learn

TL;DR A few focused questions beat a mountain of scattered feedback.

This sounds obvious, but it can be the easiest thing to skip, assuming you’ll figure out priorities later.

A playtest can generate an overwhelming amount of feedback! Players may comment on combat, art, menus, controls, difficulty, characters, story, music, and that one ghost who pisses them off for no particular reason.

If you try to investigate everything, you can easily finish with mountains of data and no idea what to do with it. Instead, prioritize what matters most and what you can still change.

If you’re struggling to decide what that is, try one of two exercises.

Ask: What could sink this game?

This is a simple pre-mortem. Imagine your game shipped and players didn’t respond the way you hoped. Why?

Let’s return to Spooky Ghost Manor. Our team imagines the game has launched to disappointing reviews. We brainstorm everything about the game itself that could have caused that outcome. We come up with a list of 10 things, each of us prioritizes the list on their own, and then we get together and decide on the final prioritized list.

Eventually, we all agree that two risks rise to the top:

Navigation: Players constantly get lost in the manor, not because finding the path is intentionally challenging, but because they can’t understand the map or environmental cues.

Puzzles: Players find the puzzle logic so obtuse that they repeatedly need walkthroughs, undermining the satisfaction of solving mysteries themselves.

We now have decided what deserves our limited research time.

Or ask: What must be true?

You can run the same exercise from the opposite direction (perhaps a more positive experience for the team). This method is also called WWHTBT (“what would have to be true?”).

So, what must be true for your game to deliver the experience you’re designing? This list may connect directly to your game’s design pillars.

For Spooky Ghost Manor, it might look something like this:

• Navigation: Players must be able to navigate using the map and environmental cues without becoming lost for too long.
• Puzzles: Players must be able to understand the puzzle logic once they’ve solved it; exploration must yield the puzzle clues they need.
• And so on (we might write these out for combat, story, etc.)

Now we prioritize. Which are we least confident about? Which can we still change?

Finally, we turn broad goals into concrete questions. So, instead of:

Goal: Test navigation.

Try:

Goal: Test if players can successfully navigate the manor’s first section using (1) the map and (2) environmental cues provided.

Now we can watch for specific things: Can players find the map within a reasonable amount of time? Do they understand its symbols? Can they use it to plan a route? Do they notice the two environmental clues telling them where to go in this section?

That focus makes the results much easier to act on.

Rule #2: Test with the “right” players

TL;DR The closer your testers are to strangers who’ll find your game on Steam (or whatever platform your game is on), the better.

Researchers often say that “research is only as good as your participants”. We also kind of love to periodically shout “you are not your player!!”

Unfortunately, finding the right players can also be one of the hardest and most time-consuming parts of the process, which is exactly why small teams often compromise here. The goal is simple: test with people who reasonably represent the audience you’re building the game for.

So, who is Spooky Ghost Manor for?

Spooky Ghost Manor target player Our game is a survival horror experience built around vulnerability, exploration, puzzles, limited resources, and intentionally constrained combat.

That means our target players are probably people who enjoy survival horror and have experience with games that share those qualities.

Our team identifies 5 comparable Steam games: 3 that directly match our genre and mechanics, plus 2 adjacent titles (like dark mystery games with horror elements) that share the player motivations we’re targeting (e.g., atmospheric unease, puzzle-solving) with our core experience.

Think in terms of stronger and weaker signals

You won’t always be able to recruit your perfect player. That’s OK. A less-than-perfect participant can still reveal something useful; you just need to be careful about what conclusions you draw from them.

Think of recruitment as a spectrum:

The closer someone is to your intended audience (green), the more confidence you can have that their experience resembles the one you’re designing for.

Your own team sits at the other end (red) for a reason: you’re “cursed with knowledge”. You know where the hidden passage is. You know what the skull icon means. You know the painting in the hallway is supposed to be a clue. A new player does not.

That doesn’t mean your developer friend can’t tell you that the inventory menu is confusing. It just means you shouldn’t automatically treat their reactions as representative of your future audience (who could be even more confused by the menu, plus other things your dev friend didn’t struggle with at all).

Where do you find players?

Go where your players already are, and start early. Depending on your game, that might mean:

• Discord communities
• Reddit communities (around your genre or comparable games)
• Your existing community
• Social media
• Friends-of-friends

A note on your existing community, like a Discord server. Yes, they are players who like your genre and probably play similar games. They’re technically in the “green” (see illustration above), but they are not your ideal playtesters. This might be upsetting, but hear me out! Your Discord members and superfans are more invested in your game than the average player who discovers it on Steam, so they’re less representative of your actual audience (I’ve compared these two groups in my work multiple times and have seen how much their reactions diverge!). For example, their familiarity and investment can bias how they experience onboarding, first impressions, and general appeal. So, aim for at least some playtesters who play similar games but haven’t been following your dev journey. It is a tough goal; if you find even just a couple of these players and get the rest from your Discord community members, that’s already a win.

Build a playtester panel

Now, you can start recruiting playtesters ahead of time. What you want to do is create a simple interest form (a survey) before you need participants and gradually build your own playtester list (aka your own panel).

Spooky Ghost Manor interest form For our future masterpiece of a game, our team already identified 5 comparable games and found communities around those games (as well as the survival horror genre in general) on Reddit. Note that we didn’t just go to r/playtesters. It may seem like a great solution, but folks there aren’t your average player. Many of them are involved in game development, and many have playtested so many games they experience and notice things differently from your target player.

We then share a short Google Form (we’ll call it a Playtest Interest Survey) asking things like:

• What genres do they enjoy; which are their most favorite?
• Their experience with a list of games (including our 5 comp games) and how much they’ve played each (a scale with numbers of hours played)
• What they liked/disliked about some of those games (write-in questions)*
• Their background (mainly to see if they have game dev experience)
• Tech info (e.g., do they have appropriate hardware, like a controller)
• Best way to contact them (e-mail works well)

*Write-in questions can also serve as an “articulation check”: can this person explain their experience clearly enough during a playtest? This matters even more if you’re offering incentives. Your screener should help you identify people who can articulate, genuinely fit the target audience, and don’t work in games, without making the “right” answers obvious.

In addition to posting our Playtest Interest Survey on Reddit, we also start harassing (in a friendly way, of course) everyone we know: friends, family, co-workers, people in our building, our coffee barista, etc. If they know someone who plays games, we ask them to share the link to our Interest Survey. Maybe we even carry a QR code of the survey to hand out!

Now, instead of scrambling to find some players the week our build is ready, we already have a pool of people to contact as we have a Google Spreadsheet with all the answers.

If I have a little budget, I prefer to spend it on participants. Not everyone is willing to give up time for free, and the people who are extremely excited to test your game can gladly do it for free but may not represent everyone you want to hear from. So I’d use my budget on recruiting playtesters from that “green” band.

Rule #3: Stay neutral & focus on behaviors (not opinions)

TL;DR Your job is to avoid biasing the playtester as much as possible.

One of the most valuable things you can collect in a playtest isn’t opinions. It’s behavior (that usability stuff). Because what people say doesn’t always match what they do.

Suppose a Spooky Ghost Manor player enters the east wing. They open their map three times, walk past the correct hallway twice, enter the wrong room, backtrack, and finally say: “I have no idea where I’m going.”

That’s powerful evidence! Compare it with simply asking afterward:

“Did you find the map easy to use?”

The player’s answer may still be useful, but you already watched what actually happened and you saw exactly how they reacted and how they attempted to work around it. Observing allows you to actually diagnose the underlying problem that led to navigation issues (e.g., the player thought the symbols on the map meant something totally different than we intended).

You’d also be surprised how many players would say “yep it was easy!” even though they struggled with the map in the beginning.

The hardest moderation tip: stop helping

Watching someone struggle with something you designed can be agonizing. But resist the urge to rescue them. If our player can’t find the east-wing door, don’t ask:

“Did you notice the door over there?”

You’ve just told them there is a door they should notice. Instead, try:

“What are you thinking right now?”

“What are you trying to do?”

“What are you looking for?”

And if they ask you what they’re supposed to do, turn it around:

“If you were playing by yourself right now, what would you try?”

If you’re worried about accidentally biasing players (as in influencing their thoughts or behaviors during the test), there’s an even simpler option: Don’t say much at all. You can ask them to think aloud (see the Playtest Planner for an example) if they’re comfortable doing so. Watch, listen, and take notes. Save your questions for a debrief afterward.

There is one obvious exception: bugs. If you know a bug is preventing progress, don’t spend 15 minutes studying someone’s inability to defeat the Ghost of Broken Build 0.3.7 (hehehe). Help them bypass it and move on.

There’s a lot more that goes into moderating a playtest well, as you really need to be careful not to influence the playtester (harder to do if you’re the one working on the game! Easier for a researcher like myself who is not part of the creative process). If you’d like to see a separate deep-dive article on moderation, let us know.

Your minimum viable playtest

Alright: you have $0, a weekend, and the latest build of Spooky Ghost Manor. What do you actually do?

For an earlier build, my starting point is a simple 1:1 moderated playtest: the player plays while you watch. It provides the most depth of understanding as to why players experience issues, confusion, or joy from playing your game.

This approach also works especially well with earlier builds because you can observe things you never thought to ask about, and step in if the build actually breaks.

Here’s the minimum viable version:

1Pick one or two important things to learn

The more focused your plan, the more likely you are to actually act on it. For us, the key question is: can players use the map and environmental cues to successfully navigate the first section of the manor?

But we don’t stop here; we’ll also want to get as specific as we can and write out more detailed questions that ladder up to our main one:

• How long does it take players to find the map (we have a rough timeframe in mind for how long we expect it to take)?
• Can players understand the symbols on the map? Are they confused by or are misunderstanding something?
• Can players use the map to plan where to go? Do they rely on it (we assume they will) or do they find it so confusing that they just brute force navigation?
• Do players notice environmental clue #1, #2? Do they understand where it’s nudging them to go?
• Are players able to reach the destination within the amount of time we expect them to?
• Are players experiencing any other issues / frustrations during the playtest?

Focusing on our key question(s) will help us avoid getting distracted by every piece of feedback that comes up (we’ll still take notes on those other things, of course). And it will help us act and actually make changes based on the findings.

2Find a handful of people as close to your target audience as you realistically can

Some are surprised by how small the number of playtesters needed for a moderated playtest round is (read more on that here). For our question, 5–7 survival-horror players from my extended personal network or community would be a great start. Ideally, they’re all from the “green” band (where signal is strongest) that best represents our target players. But they don’t have to be perfect. To be honest, if I get 2–3 “green” participants and the rest are in the “yellow”, that’s fine by me. Just get as close to your intended audience as you reasonably can.

Pro tip: pilot your playtest! Grab a buddy or a family member and run through the playtest with them to make sure your plan works in real-life conditions. It’s a good opportunity to practice moderating and asking neutral questions live.

3Give them the game with as little explanation as possible

Don’t teach them how the map works. Don’t point out the important hallway. Don’t explain what the skull icon means. That’s what you’re testing.

Exception: if your build is missing a planned tutorial, show a screenshot of it or read it aloud at the start. That’s what players would see in the later build.

4Watch them play

Take notes on moments of:

• Confusion
• Frustration
• Surprise
• Excitement
• Experimentation
• Hesitation
• Giving up

For our game, we might have notes like these:

• 3 players misunderstood the locked-door symbol
• 2 repeatedly missed the same hallway
• 1 never realized the map showed their current location

I often organize notes in a spreadsheet where each participant is a column and each topic is a row. My preference is to have a notetaker, though, so I can focus on observing and moderating; typing notes furiously can get distracting for the playtester! I do always have a physical notepad where I jot down things that really stood out to me.

If possible, and with the player’s permission, record the session. That way you can focus more on observing and less on trying to capture every detail live. If your call platform also gives you a transcript (like Google Meet), even better. However, even with recording in place, take notes on the key things that you notice during the playtest.

5Ask neutral questions

Your goal is to understand the player’s experience without accidentally teaching them how the game works or influencing what they’re thinking.

If you’re worried you tend to overshare, say less or simply don’t talk. It’s completely fine to mostly observe and save your questions for the end (like a 10-minute interview right after they’ve finished playing).

I already wrote up some examples of asking neutral questions above, but check out this article for more.

6After each session, write down the important observations

It’s even better if you can regroup with your team after each session and discuss anything that stood out to you. If you have a second person watching the session (your notetaker), it can be great for you both to chat right away (while your memory is fresh) about what each of you thought was most important, most surprising, etc. Two heads are better than one!

And yes, you may have tons of notes and the recording, but it can be overwhelming to begin looking through those as a starting point.

7Look for patterns, not just comments

One player struggling with something might be an anomaly. Several appropriate players struggling with the same thing is a more reliable finding. And keep in mind: you get the strongest signal from participants in the “green” band!

Also, remember: players can help you discover problems, but you still own the design. They may suggest solutions, and those ideas can be interesting and worth jotting down, but don’t feel the urge to build what they ask for. Your job is to understand the underlying problem first, then find a creative and practical solution.

8Make changes

Prioritize the findings that most threaten the experience you’re trying to create and that you can realistically address. You’d want to get together with your team to go over the key findings from the playtest and decide next steps together.

How exactly do you prioritize what to act on? Below are some common high-priority issues to act on first:

• Any confusion or unintended friction during onboarding (e.g., tutorial stage).
• Any progression blockers or comprehension difficulties that prevent the player from continuing the game (e.g., they can’t figure out workarounds on their own and need help during the playtest)

Again, from a small sample of 5–7 players, usability issues are safer to act on. If several players can’t navigate the manor because they misunderstand the map, that’s probably worth fixing. If two players dislike the protagonist’s hat, maybe hold off on the wardrobe redesign.

For subjective questions like enjoyment, scariness, or overall appeal, you’ll usually want a larger sample before making big decisions (note that larger samples usually mean an unmoderated playtest since you can’t sit and watch each of the 20+ players!).

9Test again

Maybe we redesign the map. Great. Now we put the new version in front of fresh players and see whether it actually works better.

That cycle (test, change, test again) is where playtesting becomes truly useful.

The point of all this Ultimately, the goal of playtesting isn’t to prove that your game is good. It’s to discover where the game in your head and the game your players are experiencing are still different. Be excited if you find an issue during the playtest: you caught it before you shipped. 🙂

Spooky Ghost Manor’s next steps

Our team’s goal was to surface usability issues related to navigation, the main focus of our playtest. We’ll also note any other issues (e.g., puzzles, combat). After all, we might discover serious combat problems we didn’t know we had!

In reality, you might want to test multiple aspects. Those playtesters may have been really hard to find, so you want maximum value from your time with them. It’s OK to focus on multiple areas, but keep the scope tight and be detailed. For example, Spooky Ghost Manor could test navigation, puzzles, and combat in one round. But write down specifics for each (like we did for navigation). Otherwise you’ll be overwhelmed trying to act on the feedback.

Let’s say our team is resource-constrained and can’t run more moderated sessions. That’s fine: our playtests have already surfaced usability issues to fix. Our next step could be unmoderated playtests with a larger player pool and a feedback survey at the end instead of 1:1 conversations.

Important: These playtesters need to be fresh: people who haven’t already participated with us. We want untainted eyes on the game.

The survey would ask standard ratings (Likert scales on understanding, difficulty, enjoyment, interest in continuing) plus write-in questions about what players liked, disliked, or found confusing. Since we’re not watching 1:1, we can run more sessions and test engagement, not just usability (and we can finally see if it’s worth getting rid of the protagonist’s hat! E.g., if it turns out that 60% of our testers dislike it, away it goes).

Ideally, our unmoderated playtesters record themselves playing and narrating aloud. This lets you revisit playthroughs if needed, but it does require more coordination. You’ll need clear instructions, confirmation they can execute properly, and a submission process set up.

Thanks for reading! If you’ve made it this far, hopefully playtesting feels a little less intimidating, and you have a clearer idea of where to start.

Happy playtesting!

About the author

Mariya Vizireanu, PhD is a senior research consultant specializing in game and player research, with in-house research roles at Rec Room and Jam City. She teaches games user research at UXR Institute. Read more at her bio page.