As a game designer, dealing with feedback is an everyday part of the job. This post aims to help you...
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:
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:
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:
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!