How to Give Playtest Feedback Developers Actually Use

Learning how to give playtest feedback well is the skill that separates players developers invite back from players they forget. The good news is that it isn't about being a critic or knowing game design. It comes down to three things: say what you felt, say when you felt it, and say what you were trying to do at that moment. This guide goes past the basics with a before, during and after routine, worked examples for different genres, and how to make video and livestream reviews that developers actually watch to the end.

If you're brand new to playtesting, start with how to become a playtester, which covers where to find playtests, building a tester profile and staying safe. This guide is the next step: making each review count.

The one rule: symptoms before suggestions

Dan Felder, a designer on Legends of Runeterra, wrote one of the best pieces of advice on this. Describe your experience the way you'd describe how you feel to a doctor. A patient who walks in demanding a specific scan and a specific medication makes the doctor guess at the symptoms behind the request. Players who open with "shorten the distance between these zones" do the same thing to a developer.

His real world example is worth knowing. In an MMO beta, players kept saying the walk between two zones was too long. Cutting the map would have taken weeks. The designers dug in and saw the actual symptom: quest focused players were bored on the walk because nothing on the route was part of a quest. They added a few quests to the area in a few days, the complaints vanished, and some players then asked for the area to be bigger.

So lead with the symptom:

I got bored walking from the camp to the mine. It took about three minutes and there was nothing I needed to do on the way. I'd already cleared the wolves on my first trip.

Then, if you want, add your idea: "Maybe a shortcut after the first trip?" The developer can use your symptom even if they solve it a completely different way. Filip Hráček, a developer who wrote a guide for his own playtesters, explains why that happens: a game is like push pins on a board tied together with string, and moving one pin often means moving ten others. Your fix might not be possible. Your symptom is always useful.

Before you play: three minutes that change everything

1. Read the developer's questions first. Most playtests come with a few things the developer wants to learn. Your review should answer every one of them. Everything else is a bonus.
2. Note your expectations. Hráček asks testers to tell the developer when the game wasn't what they expected from the store page. Write one line before you start: "From the page I expected a fast action roguelike." If it turns out to be a slow tactics game, that mismatch is valuable feedback on its own.
3. Know your own taste. Felder suggests including what kinds of content you usually enjoy, because it helps the developer read your reaction. "I mostly play cozy sims" changes how a developer reads "the combat felt stressful".
4. Set up your notes. A text file and a clock, or recording software if you're doing a video. Note the build version from the title screen.

While you play: keep playing, keep notes

Hráček's advice is not to stop mid game to critique the UI. Stopping to give a long opinion isn't a realistic playtest. Save the critique for after, and keep notes short while you play.

A good note has a rough time, what happened and how you felt:

• "6 min: didn't realise the blue doors needed a key. Tried for 2 min. Annoyed."
• "14 min: first boss. Died 3 times, loved it, wanted one more go each time."
• "22 min: opened the map to find the shop, gave up, kept exploring."
• "31 min: starting to feel samey. Same three enemies since minute 10."

Notice that two of those four are positive or neutral. You're noting moments, not only problems.

Also try to see past what isn't finished. Early builds often have no music, placeholder art and no tutorial. Hráček points out that missing audio can make a game feel strangely flat without the player knowing why. If something is clearly unfinished, mention it once and judge the thing the developer is testing.

If you find something broken, Jamey Stegmaier of Stonemaier Games gives advice for board game testers that works for video games too: point it out, then stop using it. Exploiting a broken combo for the rest of the session ruins the rest of your data.

After you play: a review structure that goes further

Write your review within a few hours, while you remember the moments. Here's a structure that works for almost any playtest:

1. Setup: build version, platform, input (controller, keyboard), how long you played, how far you got.
2. Expectation vs reality: one or two sentences.
3. Answers to the developer's questions, each one under its own heading or bullet, with a specific moment as evidence.
4. Best moment: the single moment you enjoyed most, and why.
5. Where it dipped: the moment you were most bored, confused or frustrated, and what you were trying to do.
6. When you'd stop at home: honestly, the point where you would have closed it if this weren't a playtest.
7. Bugs: what happened, steps before it, how often (always, 2 out of 3 times, once).
8. Would you play the next build? Yes or no, and why.

Don't skip the best moment. Felder calls positive feedback even more useful than negative, because it lets the team "clone the bright spots": find what already works and do more of it. Stegmaier says he has stopped working with testers who only said nice things, so the balance matters too. Both kinds of feedback, specific and honest.

Separate opinions from facts. Stegmaier's example: rather than "this action is bad", say why you never felt drawn to it. The Playtest Games guide on useful feedback makes a similar point about severity: a typo can be very annoying and still be low impact, while a silent save rollback is serious even if it looks fine. Say how it affected you and how much it got in the way, and let the developer set priorities.

Examples by genre

Every genre has its own kinds of moments worth reporting. Here's what good notes look like in a few common ones.

Platformers and action games

Developers want to know about feel and fairness. Report deaths you felt were your fault versus deaths that felt cheap.

• Weak: "The controls are floaty."
• Strong: "On the long gap in level 2, I overshot the platform four times. My jump felt like it kept going after I let go of the button. On short hops it felt fine."

Roguelikes and deckbuilders

Report your decisions, not just results. Say which choices felt obvious, which felt like traps and which you never took.

• Weak: "The fire cards are overpowered."
• Strong: "I took fire cards in all three runs because burn stacked so fast that nothing else came close. By floor 3 I was skipping every card that wasn't fire. I never tried the shield cards because they looked weaker on paper."

Puzzle games

Developers want to know where you got stuck and what you thought the rule was.

• Weak: "Level 7 is too hard."
• Strong: "On level 7 I spent about 10 minutes because I thought mirrors could only rotate 90 degrees. I solved it by accident when I clicked twice. Once I knew, it was satisfying."

Cozy, farming and life sims

Report pacing, the daily loop and what pulled you to the next day.

• Weak: "It's relaxing but slow."
• Strong: "Days 1 to 3 felt great because every day unlocked something. Days 4 and 5 were the same chores with nothing new, and that's when I started checking my phone."

Story and narrative games

Report what you understood, what you cared about and when you lost the thread.

• Weak: "The story is confusing."
• Strong: "I didn't realise the woman in the lighthouse was the narrator's sister until the third scene, so the reveal didn't land. I liked the letters. I read every one."

Multiplayer and competitive games

Report the lobby, the match flow and the moments of tension or frustration, plus connection details.

• Weak: "Matches are unbalanced."
• Strong: "In 4 of my 6 matches the team that took the middle point first won without a fight after that. Matches lasted about 3 minutes past that point with nothing to do. Wired connection, EU."

You can find playtests by genre and platform, for example cozy games, RPGs, pixel art games or Windows games.

Video reviews: how to make one developers watch

A recording shows things you'd never think to write down: where you looked, what you missed, the exact moment you got bored. Recording is the first piece of advice Hráček gives his own testers, because the developer knows the game inside out and will spot things you didn't, and bugs are easier to fix when they can see what came before. Here's how to do it well.

• Test your mic for one minute first, and play it back. A silent video loses half its value.
• Think out loud. Say what you're looking at, what you're trying to do and what you expect to happen. "I think that glowing thing is a door. Let's see. No, it's a shop." The first few minutes feel odd, then it becomes natural.
• Don't perform. You're not making content for an audience. React naturally, don't exaggerate.
• Say the time and build out loud at the start, then just play.
• Don't cut out the boring bits. The parts where you wander or get stuck are exactly what the developer needs.
• Add a short spoken or written summary at the end. Two minutes covering the developer's questions, your best moment, your low point and whether you'd play again. A developer with ten videos to watch will read your summary first.
• Include timestamps in your text notes for key moments ("12:40 first boss, 31:00 started getting bored"). It saves the developer time.

Livestream reviews

A livestream is a video review with an audience, and that changes things a little.

• Tell the developer before you go live, and follow whatever the playtest says about sharing. If a build is private or under NDA, don't stream it.
• Keep chat from steering you. Viewers will tell you where to go and what to try. Note when that happens, because the developer needs to know which choices were yours.
• Read the developer's questions on stream at the start so they're on the recording.
• Save the VOD and send the link with timestamps and a short written summary.
• Chat reactions are a bonus. If viewers got excited or confused at a moment, mention it, but keep your own experience front and centre.

Getting your reviews approved on Get Playtests

On Get Playtests, developers post their games with the questions they want answered and a minimum play time, and you choose which games to play. When you claim one, you have a delivery deadline. You can review in writing, on video or by livestream. The developer approves or rejects every review, and if a review is rejected, it goes to a moderator.

What developers look for is exactly what this guide covers:

• You played at least the minimum time.
• You answered every one of the developer's questions with real moments.
• You described symptoms before suggestions.
• You included both what worked and what didn't.
• You delivered before the deadline.

You earn tokens when a developer approves your review. Be clear on what they are: tokens have no cash value and they're not a payment. People review because they like playing games early and helping developers make them better. Reviewing is free, with no credit card and no identity verification.

Mistakes that get feedback ignored

• Only a verdict. "10/10, loved it" or "not for me" gives nothing to act on.
• A list of features you want. Wishes without the experience behind them are hard to use.
• Reviewing a different game. Judging a slow tactics game for not being a shooter. Say the mismatch, then review what it is.
• Exaggerating. Calling a minor typo "game breaking" makes the developer trust the rest of your review less.
• Waiting a week. Details fade fast. Write it the same day.
• Ignoring the questions. If the developer asked about the tutorial, a review all about the soundtrack misses the point.

A copy and paste review template

• Build, platform, time played:
• What I expected vs what it was:
• Developer's questions: one answer each, with a moment
• Best moment and why:
• Lowest moment and what I was trying to do:
• When I'd have stopped at home:
• Bugs: steps and how often
• Would I play the next build, and why:

Use it for your next playtest and you'll notice the difference in how developers respond. If you haven't found your first game yet, start reviewing here, and for more on getting started read how to become a playtester. Browse every guide at /guides.