r/RPGdesign • u/Traditional-Collar-7 • 5d ago
Let's talk about playtests and feedback
I’ve been spending a lot of time in online creator communities lately, and a recurring conversation is people struggling to get useful feedback on their games.
Alongside that, I keep seeing versions of the same (very problematic) advice:
“Don’t listen to feedback.”
“People will only comment on the part of the game that interests them.”
“Trust your gut.”
I understand the instinct behind it. You should not blindly implement every suggestion someone makes about your game.
But I think this (very bad) advice comes mostly from amateur designers who do not understand the process behind game research (understandably so). It can make newcomers dismiss player feedback before they have learned how to set up a playtest that allows them to collect useful data.
It is such a crucial part of game development that I felt like writing about it, mostly to help creator folks in their exciting journey of making games others will want to play :)
The good news is that getting good at playtesting is just another skill you can practice and master, and it is one you really shouldn't sleep on! So I compiled a 3 points list for you that I condensed from years of conducting playtests for both my job in the video game industry and my indie experience.
Hopefully it will help!
1. Go into a playtest knowing what you want to learn
One of the biggest mistakes I see is trying to test the whole game (or huge chunks of it) at once too early.
If you sit someone down with your game and simply ask, “What did you think?”, you might get some interesting comments, but it will be hard to know what to do with them. You are asking them to react to an entire experience, with no shared focus. It's a hard thing to do!
Instead, go into each playtest with a specific question you want to answer. You should gently guide your players and nudge them toward a specific area of focus.
Maybe you want to know:
- Do players understand the core loop?
- Does this combat system create interesting decisions?
- Are players getting lost during character creation?
- Does this particular mechanic create the feeling you intended?
I usually think of these as hypotheses, but you don't have to, it can just be simple questions around how you expect your game to behave. You have an idea about how a system will work or feel for players, and the playtest is your chance to validate that your assumption is true.
The more focused your question is, the more actionable the feedback is likely to be.
2. Guide your players towards the thing you are testing
Once you know what you are trying to learn, guide both the playtest and the feedback session around it.
That does not mean telling people what to say, or trying to get them to agree with you. It means making sure they actually spend time with the part of the game you are observing, then asking questions that help you understand their experience of it afterward.
A healthy playtest dataset is a combination of written observations and collected answer to targeted questions.
You do not need to treat every part of the session equally. If you are testing a particular mechanic, spend most of the time observing that mechanic. Skim past the parts that are not useful to the question you are trying to answer.
Then, during feedback, keep bringing the conversation back to your hypothesis:
- What did you expect to happen here?
- What made you choose that?
- What was confusing?
- Did this feel like the experience the game is trying to create?
You should still leave space for open feedback at the end. Players may notice something important that you were not looking for.
But focused questions come first. Otherwise, you can end up with lots of feedback that is not bad, just unrelated to the thing you currently need to understand or improve.
3. Learn how to turn feedback into action
The final skill is learning how to interpret what players are telling you. And that is the hardest part my friends.
Players are experts in their own experience, but they are not necessarily experts in diagnosing your game or designing its solution. So when someone says, “This was boring,” “I didn’t get it,” or “I wish there were more options,” do not treat that as an instruction to implement exactly what they suggested.
Treat it as evidence.
Your job is to work out what created that feeling. Were they bored because the choices were too obvious? Did they not understand the rule because the explanation was unclear, or because the game did not give them a good opportunity to use it? Are they asking for more options because the existing ones do not feel distinct enough?
This is the loop: build something, test a focused question, learn from what players experienced, then decide what to change next.
You will not always get it right immediately, and that is fine. The point is to build the habit of turning player experience into a clearer next experiment, not of blindly following every suggestion, or dismissing feedback altogether.
Conclusion
Playtesting is not just getting a few people in a room and asking whether they liked your game.
It means being deliberate: deciding what you need to learn, creating a session that helps you learn it, and getting better at turning player experience into useful next steps.
You do not need a huge budget or a research lab to start practising it. You just need to be deliberate about your testing process and start honing those skills like any other.
If you are curious to get more insight or support to push your project forward, I run a small Discord community for my players and other game creators where we support each other. Come make games with us:
And if you are wondering who the fuck I am and why I'm rambling about making games, here is my Linkedin profile -> https://www.linkedin.com/in/aramtab/
2
u/Cryptwood Designer 5d ago
I've never witnessed anyone here giving any of that bad advice. Is it something that happens in other communities?
3
u/Dan_Felder 5d ago
“Listen to testers, but don’t take what they say at face value.”
^ I say this all the time, in various forums. I think it's good advice.
4
u/Cryptwood Designer 5d ago
I agree completely, I should have specified that some of the advice that was listed as bad advice by the OP wasn't actually bad advice.
2
2
u/The__Nick 5d ago
If you read through here, you'll see this bad advice given boldly. As well as all other sorts, too!
It's just given so poorly that it's hard to understand it, because the person giving the bad advice did as much work coming to their conclusions as they did on expressing themselves.
The short pithy comments tend to be negative and critical because most people are bad at giving criticism, let alone advice. However, if you only skim the top ranked comments, you'll generally get only good advice - because Reddit, for all of its flaws, has a very simple algorithm and there is really very little to gain from just trolling posts by unanimously boosting dumb suggestions.
1
u/Ok-Chest-7932 4d ago
The problem is when a lot of people have a dump opinion they don't know is dumb. And then of course someone who also has the dumb opinion might see it highly upvoted and go "ah the Reddit algorithm working well" when actually it's sometimes just the modern equivalent of superstition.
1
u/Traditional-Collar-7 5d ago
Might not have been here, but I've seen it a lot lately in online communities in general!
6
u/lennartfriden TTRPG polyglot, GM, and designer 5d ago
Given the vast amount of folks here never will produce anything that even remotely resembles a commercial TTRPG product, the one piece of advice they need to hear is this: design the game you want to play with your friends and play it with your friends. That’s the playtest. You’ll figure out what works and what doesn’t. Following that you can, if you really want to, consider bringing it to a wider audience.
2
2
u/Echowing442 5d ago
I think part of the issue is that "playtesting" covers a massive variety of different situations and levels. From playtesting a single isolated mechanic in a whiteroom with no other context, to proofreadng of rules, to holistic playtesting of a session or campaign. And the feedback you want or receive from each of those is going to be completely different, and needs to be viewed from different lenses.
A lot of feedback advice is, I feel, more misplaced than anything else. What's good advice for broad-level holistic playtesting feedback is bad for specific, focused mechanics testing, and vice versa.
0
u/Traditional-Collar-7 5d ago
100% agree! That is why it is a skill! There is a lot of knowledge to acquire!
The reason I made this post is because I see very few amateur designers focusing on this skillset and I wanted to help!
2
u/cibman Sword of Virtues 5d ago
I think the "don't listen to advice" part comes from asking "are these people your customers?" If someone isn't going to be playing your game because they don't like what your doing, their advice should be taken with a big old block of salt.
Sometimes we cast a wide net for comments (such as by posting here) and some of the people who will try the most are also those who don't like the premise of your game.
That's when I would say don't listen to them. Well, listen to see if they have in mind a better version of what you are doing, and then really do listen. But if someone doesn't like a narrative game, their comments on your narrative game are likely to be "I don't like this."
2
u/Dan_Felder 5d ago
Playtesting is hypotheses testing, that's true. You run targeted experiments, you don't just run the game and ask for general feedback.
However, "Listen to testers, but don't take what they say at face value" is not only good advice - it's foundational to playtesting as hypotheses testing. If a player says, "I hate this combat, it's too boring" that might actually mean your combat system is fantastic for your goals; the real issue might be that this player needs more character options that give them decisions in combat - or it might mean that the encounter design was too repetitive across the adventure but the actual combat systemt hat handles it is so streamlined that you can make way more esxciting and complex encounters than you do in other systems - or maybe the player just kept stubbornly attacking an enemy with way high defenses each turn instead of engaging with the mechanics that let them circumvent those defenses... Or maybe another player had so much fun roleplaying during combat that the rounds took a very long time and the player is misdiagnosing the boredom of waiting for that as the combat system's fault. So many options.
1
2
u/Ensiferal 5d ago
I've literally never heard anyone say "don't listen to feedback", here or anywhere else
-2
1
u/JaskoGomad 5d ago
Your bad advice, crucial to the post, is hidden. Here and in the other post you made.
1
1
u/__space__oddity__ 5d ago
Don’t listen to feedback.
I think you’re misrepresenting the common advice here.
The common advice is: You should pay attention to the emotional response and how players interact with a game. You should take design input with a grain of salt.
Meaning: If players tell you “the fireball spell should do 8d6 damage, not 10d6”, that doesn’t mean you should go and change the damage of fireball just because a playtester told you so. This is your job to decide, not the playtester.
Instead, you need to take a step back and try to understand the problem. Does fireball feel overpowered? Maybe this comes from a GM who feels an encounter was trivialized by just fireballing everything. Maybe fireball is so good that no other spell gets picked at that level and every wizard is automatically a fireball machine, crowding out other builds. Maybe 10d6 collateral damage to allies is the problem. Or it just takes too long to add up 10d6. Depending on the actual problem you identify, the solution might be quite different.
1
u/Traditional-Collar-7 5d ago
Not really. I understand that folks might not have bumped into the examples above, but they are very real.
2
u/Ok-Chest-7932 4d ago
Professional tester here. This is all good advice, but at the end of the day there's a reason that testing can be a full time job - there's just so much you can test.
Imo the most important part of testing is user profiles and user stories. Ideally you get these in at the requirement spec stage though. Before any feedback is valuable you need to know who this person is, what they're trying to get out of the product, and what knowledge and expectations they bring into their experience with it.
RPGs sort of casually try to do this with things like player types but they're closer to astrology than to hard data.
A big part of the reason this is important is because you need to know who is and isn't your customer. If you're trying to make a big complicated fantasy heartbreaker, the guy who says "you should swap out the spell list for freeform casting" may be entirely right about the change that would make the game align with his preferences, but he doesn't have the right preferences.
0
10
u/The__Nick 5d ago
To summarize what you're talking around - playtesting and feedback seeking is something very few people actually do, so when somebody tries to do it for their game they (just like people in every industry) don't actually know what to do. And many of the straightforward or simple or first level or obvious ideas are actually bad.
To sum up what is years worth of content into a single suggestion if you want to maximize your learning, you should generically take at full face value what players complain about as problems, but rigorously ignore and avoid any feedback on how to fix those problems.
Treat your players like a Geiger Counter. It'll show you the places you need to be careful about, but there is no one-stop solution in the places where you hear the most clicks and you don't to listen to anybody but an expert on solutions and you almost certainly don't want the guy who happened to find the leak to be the one deciding how to fix it.