Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
As a game designer, dealing with feedback is an everyday part of the job. I share 5 tips that aim to help you improve how you deal with feedback during game development.
As a game designer, dealing with feedback is an everyday part of the job. This post aims to help you...
Encourage feedback from your peers.
Embrace feedback rather than fight against it.
Process the feedback you receive.
Some of the best feedback you will receive during development is from your colleagues. You are likely to miss out on lots of important feedback if you cultivate an environment that discourages criticizing the project. Consider employing the following tactics to help come across as more approachable to your team:
Actively mention to your team that you are always willing to hear their feedback - a simple one but maybe the most effective at getting feedback from people who might not otherwise provide it. A simple "Just grab me if you have any feedback on this." at the end of a discussion goes a long way.
Always keep things positive - as bad as an idea might be, your priority should be encouraging the act of sharing feedback. Try to find any positives you can from their input to help show that you are trying to understand their contribution.
Give credit where credit is due - try to actively credit the team member for their input. statements such as "____ had a great idea for..." and "Actually, it was ___'s feedback that led me to this approach." help validate the team member's decision to offer their input.
Help people understand why an idea is turned down - make sure they know it is not personal and try to give objective reasons if possible. If there are no objective reasons then try to help the team member see the issue from your perspective.
Every designer likes to be able to say "That was my idea" but you need to be comfortable saying "I think your idea is better".
Prioritize the project before your personal pride. Making games is (usually) a team effort. Just because you are the designer on a project, it doesn't mean you are the only one who can design. Don't see feedback as an attack on your ability as a designer, see feedback as an opportunity to show how well you can recognize the best design for the project at hand.
Make sure, however, you don't confuse this point with being a push-over. In the times where you believe you are in the right, make sure you stick to the project vision.
Don't let project scope or restrictions stop you from considering the validity of a person's feedback. Even if it is abundantly clear that a proposed idea is not viable, it is often worth taking some time to considers the main points and ponder a more viable solution.
Consider the following feedback statement:
"I think this boss fight is too hard"
This is a very normal statement from a player's perspective but as a developer the following statements might be more useful:
"I haven't been adequately prepared for this boss fight"
"The boss has too much health"
"I don't feel powerful enough to kill the boss"
"Random gameplay elements have led to a more difficult than usual fight"
"The boss doesn't telegraph it's attacks well enough for me to prepare my defense"
It is very easy to assume the intention of the statement, perhaps based on other previous feedback. However, asking questions is the best way to dig deeper into a statement's true meaning, if the situation permits.
This is harder than it sounds. Your biggest obstacle at this point is trying not to put words into the player's mouth. When asked "Do you think the boss has too much health", it is too easy for the player to give me the answer they think I want or be guided by my question into believing something is more of an issue than they actually feel it is.
Start out by asking open ended questions, even something as simple as "What do you mean by this". Some people will be able to expand on their answer. If the person struggles to relay their opinion, offer a relevant multiple choice question to help them think critically about the experience they have had. "Are you having more issues attacking the boss or defending yourself from the boss" might be a good way to investigate further in this example.
It is much easier to process feedback if you consider the context of it. Consider the following scenario:
A team member says "Level 12 is not fun".
This alone is not enough to start acting on the feedback. We would need to consider the context of this feedback. Some points to consider might include:
How much experience does this player have with Level 12? - Is this their first time playing the level or have they been testing the level non-stop for weeks?
How far along in development is the level and its systems? - Are there work-in-progress areas or systems in the level? Are their bugs affecting the gameplay experience? Are players getting the full experience that you hope the final product will achieve?
Why was the player playing the level? - Are they being forced to play it? Was it to debug an issue? Consider how this might affect a players emotions.
Does the player belong to the target audience? - Is your game aimed at being fun for young children? Maybe you are aiming to make a compelling racing simulation? Not everyone finds all genres of games fun - acknowledge that someones feedback is often personal and not necessarily representative of the wider audience.
Is the level even meant to be fun? - Maybe this particular level is meant to be unsettling? Maybe you plan for this level to relax the player before a big impact point in your narrative? Make sure you keep the project vision in mind.
Always remember, however, that no matter the context, there is usually something useful to take away from a piece of feedback. Maybe you think the issue will be solved once all of the bugs are fixed? - This might now lead you to consider re-prioritizing bugs in order to test this level sooner than you had first planned.
Thank you for reading!
Read more about:
Featured BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)