Vague Playtest Feedback? Turn "It's Fun" Into Real Notes

Vague playtest feedback is the most common result of a first playtest. You send the build to five people and get back "it's fun," "pretty cool," "maybe make it faster?" and one thumbs up emoji. None of it is wrong, and none of it tells you what to change. This guide shows how to turn that kind of answer into notes you can act on: what vague feedback actually means, the follow up prompts that open it up, how to read behaviour instead of opinions, and how to set up your next round so the vague answers never show up in the first place.

Why playtesters give vague feedback

Vague feedback is not laziness. It usually comes from one of four places.

• They are protecting your feelings. Friends and family know you made the thing. "It's fun" is the polite way out. Dashpop's playtesting guide puts it plainly: friends are especially good at trying to protect your feelings.
• They do not have the words. Most players can feel that a jump is floaty or a menu is annoying but cannot say why. As one r/gamedev commenter put it in a thread on exactly this problem, it will always be vague, because most players do not know enough about game development to tell you why something feels wrong.
• You asked a vague question. "What did you think?" invites a summary. "Was it fun?" invites a yes. The question sets the size of the answer.
• They forgot. A form filled in an hour after playing captures the overall mood and loses the moment. The friction at minute four is gone by minute forty.

The fix for each is different, which is why the rest of this guide is split into what you do with feedback you already have, and what you change before the next round.

Treat every vague comment as a pointer, not a verdict

A useful mental shift: players are good witnesses and bad designers. Flockbay's post on playtest questions says it this way, and it matches what experienced developers say in every thread on the topic. A tester can tell you where they got lost and when they stopped caring. Asked how to fix it, they invent something.

So when you read "the combat feels off," do not file it as "combat bad" or ignore it. Read it as "something in combat did not match what this player expected, somewhere." Your job is to find the where and the what. The comment is a pointer to a region of the game.

Here is how common vague phrases usually translate, and what to look for:

• "It's fun." Polite, or genuinely positive but unspecific. Look for: did they keep playing after the minimum? Did they replay a level without being asked? Those are the real signals.
• "It's fine" or "it's OK." Often a soft negative. Look for: where their attention dropped. Long gaps without input, wandering, opening the pause menu.
• "It's confusing." Usually one specific moment, not the whole game. Look for: the first time they did something you did not expect.
• "It feels slow." Could be movement speed, pacing between events, animation length or text speed. Look for: where they were waiting rather than deciding.
• "Too hard." Could be a real difficulty spike, an unreadable attack, or an unclear failure condition. Look for: where they died repeatedly, and whether they changed strategy between attempts.
• "Needs more polish." Often means one rough edge they hit early, like placeholder audio or a janky first animation, that coloured everything after it.
• "Maybe add X." A suggestion is a symptom. Ask what moment made them want X.

Follow up prompts that open up a vague answer

If you can talk to the tester again, by chat, voice or a reply on their review, a short follow up usually gets you from "it's fun" to something you can use. Keep it to one or two questions so it does not feel like homework.

For "it's fun" or "it's cool"

• "What was the moment you enjoyed most? What were you doing right then?"
• "If you had five more minutes, what would you have done next?"
• "How would you describe it to a friend in one sentence?"

The friend question is surprisingly useful. If their sentence describes a different game from your store page pitch, either the page or the game needs work.

For "it's fine" or "it's OK"

• "Was there a point where you thought about stopping? What was happening?"
• "What did you expect the game to be before you started, and how was it different?"

For "it's confusing"

• "Where was the first moment you were not sure what to do?"
• "What did you think that button, item or character was for?"
• "How would you explain the main mechanic to someone who has not played?"

That last one comes from designer Max Brooke's playtest writing: instead of asking "Did you understand X?" ask "How would you explain X to me?" If their explanation does not match your rules, you have found your problem without them having to diagnose it.

For "it feels slow" or "the controls feel off"

• "Was there anything you tried to do with the controls that did not work?"
• "Where did you feel like you were waiting rather than playing?"
• "Was it the moving, the fighting, or the time between things?"

For "too hard" or "too easy"

• "Which part did you retry the most? What did you change between tries?"
• "Did you know why you failed each time?"

For "you should add..."

• "What moment made you want that? What were you trying to do?"

The universal follow up

When nothing else fits, use the one Flockbay recommends for anything surprising: "What made you think that?" Do not explain or defend. The moment you say "but there is a hint on the wall," the honest part of the conversation is over.

Watch what they did, not just what they said

The most reliable fix for vague feedback is to stop depending on words. In the r/gamedev thread on vague feedback, one developer said that if they had to choose between observing testers without any feedback or getting feedback without observing, they would choose observation every time. Another noted that early playtesting is all about what you see watching people play, not their comments: you know what feels off because they say "huh" and frown at a screen.

You can get behaviour three ways.

1. Sit with them, in person or on a call. Ask them to share their screen and think out loud. Jakob Nielsen's summary of the think aloud method is three steps: recruit representative users, give them representative tasks, then stay quiet and let them talk. Prompt only when they go silent, with neutral nudges like "What are you thinking right now?"
2. Ask for a recorded session. A video review with voice gives you the hesitations and the "wait, what?" moments that a written review smooths over. This is the single biggest upgrade from "it's fun." If you want to compare paid recording tools with free options, see our PlaytestCloud alternatives roundup.
3. Log it in the build. Deaths, quits, time per level, how often the pause menu opens. Even a simple text log with timestamps lets you check what a tester said against what they did.

Then compare. Flockbay's example is a good one to remember: a tester who rates difficulty 2 out of 5 but died eleven times at the same spot is being polite or proud. A tester who says they would keep playing but stopped at minute nine has answered with their actions.

What to write down while you watch

Write observations before interpretations. Dashpop's guide recommends this exact habit, and it keeps you honest. "They did not understand the shop" is an interpretation. "Opened the shop three times, closed it without buying, then asked where to upgrade the sword" is an observation you can design against.

A simple note format that works:

• Timestamp: 04:12
• What happened: Walked past the glowing door twice, went back to the start area.
• Possible question: Does the door read as interactive?

Ten lines like that from one session are worth more than a page of opinions.

Rewrite your questions before the next round

Most vague feedback is created before the test starts, by the questions you sent with the build. If you only change one thing, change this.

Replace judgement questions with moment questions

Turn each question that asks the player to grade the game into one that asks about something that happened:

• "Was it fun?" becomes "What was the best moment? What happened right before it?"
• "Was the tutorial clear?" becomes "What did you think the game wanted from you in the first minute?"
• "Was it too hard?" becomes "Where did you fail most, and did you know why?"
• "Do you like the art?" becomes "What did you expect this place to be, based on how it looks?"
• "Any feedback?" becomes "When did you want to stop playing, and why?"

Our playtest survey questions guide has a full bank of these by goal, and the game feedback form template shows how to put them in a form players will actually finish.

Ask fewer, sharper questions

One research question per round. If this build is about onboarding, ask about the first ten minutes and nothing else. Five focused answers beat twenty scattered ones. Flockbay suggests keeping post session forms to two or three minutes, with the most important question first, because tired testers write less.

Ask while it is fresh

Send the questions with the build and ask testers to answer right after the session, not later that week. If you are running a live session, ask your questions at the end, not during play. Questions mid session change how people play.

Use a few ratings, but never alone

A 1 to 5 score for fun, difficulty and clarity lets you compare rounds, but a 3 means nothing without the open answer next to it. Keep the wording identical between rounds.

Pick testers who would play your game anyway

Feedback gets vaguer the further a tester is from your audience. A friend who only plays sports games will struggle to tell you why your roguelike's pacing is off. Players who chose your game because it looked like their kind of thing have the vocabulary and the motivation to be specific. Our guide on how to find playtesters covers where to find them.

How Get Playtests is set up to avoid "it's fun"

We built Get Playtests around this exact problem, so it is worth saying how it helps.

• You write the questions you want answered in the posting, so reviewers answer your moment questions instead of writing a summary.
• You set a minimum play time, so feedback comes from people who got past the first few minutes.
• Reviewers choose which games they play, so the people reviewing your game picked it from the list because it looked like their kind of game.
• Reviews can be written, a video, or a livestream, which means you can get the recorded, think aloud style session described above without scheduling a call.
• You approve or reject every review. A review that ignores your questions does not have to count, and rejected reviews go to a moderator so it stays fair for reviewers too.

Posting a playtest is free, with no credit card. Reviewers earn tokens for reviews you approve; tokens are not money. A brand new developer's first posting may wait until one of their reviews of someone else's game is approved, which is what keeps reviews coming for every game. Writing that first review is also a great way to feel how hard it is to give specific feedback, which makes you better at asking for it. Post your playtest free.

Turn the notes into decisions

Specific notes still need sorting. After each round:

1. Group by moment, not by tester. Put every note about the first boss together, every note about the shop together.
2. Count. One tester confused by the shop is a note. Three out of five is a problem.
3. Separate the problem from the suggested fix. Keep "three players could not find the upgrade" and drop "add a big arrow" until you have decided how to solve it yourself.
4. Pick the top one to three issues. Fix those, then test again with new players. Small rounds repeated often beat one big round. If you want numbers per round, see how many playtesters you need.
5. Write down what you expect the change to fix. Then check it in the next round. If the confusion moved somewhere else, that is still progress.

If the bigger question behind all this is whether the game works at all, our guide on how to know if your game is fun covers the play signals to watch across sessions and how to decide whether to keep, change or kill an idea.

A quick checklist for your next playtest

• One research question for this round, written down.
• Three to five moment questions, no "was it fun?"
• A minimum play time that reaches the part you are testing.
• At least one recorded or live session, with think aloud.
• Testers who would plausibly buy your kind of game.
• Questions answered right after playing.
• One follow up per vague answer: "What made you think that?"
• Notes grouped by moment and counted before you change anything.

If you want a full session plan to go with this, our guide on how to run a playtest has a minute by minute script, and remote playtesting covers recording sessions with testers you will never meet in person.

Common questions about vague playtest feedback

Should I ignore feedback like "it's fun"?

No, but do not count it as validation either. Treat it as a weak positive and look for behaviour that backs it up: did they play past the minimum, replay, or ask when the next build is coming?

How do I get testers to be more specific without leading them?

Ask about moments ("What were you doing when you got stuck?") instead of naming the thing you suspect ("Was the jump too floaty?"). Then use neutral follow ups like "What made you think that?"

Is video feedback better than written feedback?

For anything about controls, onboarding, readability or pacing, yes, because you can see the hesitation. Written reviews are faster to read and better for summaries and comparisons. A mix of both from the same round is ideal.

What if all my feedback is positive but vague?

That usually means your testers are too close to you or the questions are too broad. Change one of the two for the next round: new players who chose your game, and moment questions instead of judgement questions.