How to prioritize playtest feedback: what to fix now, what to park, what to ignore

The playtest went well. Ten people played, the form came back full, and now you are staring at forty comments that contradict each other. One tester found the combat too easy; another nearly quit over it. Someone loved the thing you were about to cut. Someone else hated the thing you love.

This is the moment playtesting actually earns its cost — and where most studios improvise. This guide is a system for turning that pile of opinions into a short list of decisions: what to fix now, what to investigate, and what to deliberately leave alone.

The first rule: feedback is data, not instructions

A tester is an expert on what happened to them. They are not an expert on what you should do about it. "The jump feels floaty" is a fact about their experience; "add a double jump" is a guess about your design. Keep the fact, evaluate the suggestion separately, and never feel guilty about taking one without the other.

This also means you owe no tester a change. You owe them attention and honesty — and the game owes you the right decision, not the popular one.

Sort by signal, not by volume

Before deciding anything, read everything once and tag each comment with what kind of signal it carries.

Repeated observations are the strongest signal. If six of ten testers stumbled at the same door, the door is the problem — no matter how much you like the door.

Contradictions are information too. "Too easy" and "too hard" from the same section usually means the difficulty is uneven, not that it averages out fine. Look at who said what: if the veterans said easy and the newcomers said hard, you have learned exactly where the skill floor sits.

One loud opinion is the weakest signal. A single tester who hated the art style may be right — or may simply not be your audience. Check it against your target player before acting.

Silent gaps matter. If nobody mentioned the crafting system you spent three months on, that is a result: it was invisible, or it was fine. Your form should tell you which.

The three buckets

Once tagged, every piece of feedback lands in one of three buckets. Be strict — a bucket is a decision, not a mood.

Fix now. Problems that block the core experience, that several testers hit, or that break trust: crashes, soft-locks, a tutorial that loses people, a control that fights the player. These get fixed before the next test, because the next test is wasted if they stay.

Investigate. Signals that are real but ambiguous: the contradiction about difficulty, the boss that "felt unfair" to two people, the feature nobody used. Do not fix these yet — design a question for the next playtest that isolates them. A vague complaint becomes a specific test.

Leave alone. Feedback that contradicts your design intent, comes from outside your audience, or asks for a different game. Write it down, because patterns change over time — but changing the game to please it now is how a focused design dissolves into a committee product.

Weight the source, not the volume

Not all testers are equal for every question. The player with five hundred hours in your genre notices balance problems a newcomer cannot see; the newcomer notices clarity problems the veteran is blind to. When two groups disagree, the question decides who is right: for "is the tutorial clear", believe the newcomers; for "is the endgame deep enough", believe the veterans.

This is why knowing your testers matters as much as knowing your numbers. A response rate and an average are useful; knowing who said what is what makes them meaningful.

The trap: fixing the loudest thing first

The comment written in all caps feels urgent. It is not necessarily important. Loudness correlates with personality, not with how many players will hit the problem. Before scheduling any fix, ask two questions: how many players will experience this, and how much does it damage the experience for those who do? A minor annoyance everyone feels can outrank a rage-quit moment one tester in twenty will find — or the reverse. The point is that you decide with the map, not the megaphone.

Close the loop with your testers

Prioritisation is not finished when your list is done. Tell the testers what you heard and what changed. It takes one message, it proves their hour mattered, and it is the single best investment in your next playtest: testers who saw their feedback land come back, and they come back sharper.

A working session, step by step

1. Read everything once, without deciding anything. 2. Tag each comment: repeated, contradicted, isolated, or silent gap. 3. Drop each into fix now, investigate, or leave alone. 4. For every investigate item, write the question that would settle it — that question goes into your next playtest form. 5. Send the testers a short summary of what you heard and what you changed.

Two hours, done the same week, while the session is still fresh in everyone's memory.

How Playtest Hub helps

Playtest Hub keeps the raw material for this process in one place, per playtest. The Results page shows, for that playtest only, how many people participated and the response rate, so you know how much weight the data carries. Rating questions show the average, the median and the full distribution — which is how you spot the "too easy / too hard" contradiction instead of reading a misleading average. Choice questions show counts and percentages, and text questions show every written answer, so the repeated observations and the silent gaps are both visible. Because each playtest has its own isolated Results, you can compare rounds: did the fix from last month actually move the number?

Feedback is not a verdict. It is a pile of evidence, and the studio's job is to weigh it — by repetition, by source, and by what the game is trying to be. Sort it into the three buckets, design the next question for what you could not settle, and tell your testers what they changed. Do that every round, and each playtest buys you more than the last.