How to Ignore Playtesting Feedback to Improve Your Game

One of the most difficult things do as a leader of the game’s vision is knowing when to disregard feedback.

While I obviously don’t think you should ignore *all* feedback from playtesters and stakeholders while you make a game, it’s important to know when to disregard feedback, keep it for later, or understand the underlying problem of the feedback to create solutions for the team.

If you’re making a game, you’re going to be inundated with feedback. If you’re working at larger companies making games like I have, it’s going to come from all angles — playtesters, stakeholders such as execs or cross-functional teammates, maybe people on external platform teams, and from the dev team itself. At one company, I organized the weekly org playtest of about 150 people, two dev team playtests of about 10 people, on top of doing game reviews with execs and receiving feedback from external playtesters. That’s a lot of incoming information to sift through and make actionable.

It can be overwhelming to figure out which feedback to prioritize, especially as you receive feedback from people who hold more power than you at your company.

Here are the best strategies I’ve learned to prioritize playtesting feedback, or table it when necessary to help the team move forward:

• Playtest with the target audience
• Structure playtesting sessions and surveys to answer questions about the mechanics or systems
• Define the underlying problems
• Identify how the feedback fits into your current priorities

Some early playtesting on a paper prototype.

Playtest with the target audience

The closer the players are to your target audience, the more valuable their feedback will be. It’s important to pre-screen playtesters for more official focus groups, or if it’s ad-hoc feedback you’re getting, understand what type of player the person is. Don’t ignore the feedback that you get from other types of players, but prioritize the feedback from your target audience.

One time I was playtesting a VR game that was very early. It had D&D vibes, and the art style leaned medieval. As a playtester and game dev, I made it apparent that I was not the target audience for that game, so to take my feedback with a grain of salt. I enjoy a different type of game, and while that game could have been a big hit (it ended up being so), I felt like my contribution to that session was less valuable than the other people, who did identify as the types of people who would play that game.

Another time I was leading design for a VR party game, and we scheduled quite a few playtesting sessions with diverse groups of people. In one of the early ones, we ended up with a group of people who thought our game wasn’t interesting. We got a lot of good UX feedback from the players, but the game systems and content didn’t resonate with them. They were more interested in playing first-person shooters when we asked them what games they typically play. We took that UX feedback, but it was the cue to find a more representative set of players who liked to play casual or party games, and to get their feedback on the systems and contents of the game.

Keep a list of games that are good comparisons or references in your backpocket, and ask your players if they’ve played them. You can use these to get a sense for what your players like in a game.

Structure playtesting sessions and surveys to answer questions about the mechanics or systems

It’s good practice to give someone your game and just watch them play. The right time for this is when you have few unanswered questions about your core game loop and you’re looking to find out if the game is compelling, understandable, and easy to use.

But when you’re in the earlier stages of development, or maybe some of the systems are in-progress but not in a holistic state, it’s more effective to structure your testing sessions and surveys around a specific set of questions you want answered. This way, you get exactly what you need answered at the stage of development, it fits in with your priorities at that time, and fends off some of the more random ideas players will have. For example:

• Do players understand the value of [x] resource?
• Can players describe what the long term goals are in the game?
• What are players thoughts on [x] feature or system?
• How does the timing of the progression feel?
• Can players describe a reason to return to the game?
• Do players knows how to use [x] feature or flow?

Define the underlying problems

Don’t worry about the solution that has been proposed by the player. Why are they proposing that?

Often people jump to their own solutions, but as a designer or leader of the vision, you have all the context for the game systems and priorities. It’s important to realize that, and understand what the problem is that those people are trying to solve.

Often times people will get wrapped up in hypothetical problems. It happens when people haven’t played the game and want to give feedback on it, or when people don’t have enough tangible problems to solve themselves. The best thing you can do is direct people toward tangible problems that have to do with unanswered questions in the build of your game. Get them playtesting!

Identify how the feedback fits into your current priorities

You can fit all that feedback into your roadmap, but the team will flounder if you don’t plan for it and set priorities. I typically map out the next [x] months game systems and questions to be answered, and when we get feedback I do one of the following:

• Enter the idea into an “ideas backlog” if it’s an entire new game system or mechanic.
• Iterate on a game system, mechanic, or UX if it’s a current system that just needs some tweaking.
• Identify if it’s a missing ingredient by looking at all the game systems and figuring out the gaps and problems. If any of the feedback solves those problems, it’s something to consider and brainstorm with the team.

I’ve seen people completely pivot based on feedback, or create an existential crisis on the team. This causes anxiety on the team and should be avoided. It’s better to iterate and improve systems before scrapping and pivoting them altogether. Nothing will be perfect or fun at first.

It’s important to make a game you want to play, but feedback is really important to the process. Often it’s how my teams iterate quickly and where I focus on creating good processes. But feedback isn’t the end-all-be-all, and it’s still important to create a game you want to play. Sometimes it’s important to do whatever you want. It’s your life, and your art. Have fun.