In all creative industries there is a feedback loop. Unfortunately the art of giving feedback is not normally taught in schools. Giving bad feedback can be counterproductive and demotivating to your teammates. Multiple iterations are the key to successful development projects. Simply saying that someone’s work “sucks” is not very constructive to how they can make it better, they might simply go back to their desk and rethink their career choice. Constructive criticism is criticism that avoids hurting feelings, and tries to achieve a greater end product by informing the dev what they should do to make their creation better. These critiquing rules can be applied to other things besides the game industry, but here I’m focusing on making games as a primary example.
Giving It
Plan Better
Make sure everyone is aware that your artist/composer/programmer is going to HAVE TO do multiple iterations on this, even if they think that its perfect the first time. Everyone needs to plan actual time to compensate for this, otherwise we all get behind because Jimmy didn’t realize that his spaceship looked like genitalia.
Be Specific
Saying something is good or bad in general isn’t very good feedback. If we’re reviewing a 3d model of a spaceship and someone says that it sucks, that doesn’t tell us what about it is bad. Generalizing like that only halts the conversation. A better approach would be to say “The main body looks like a pizza cutter made out of duct tape.” might help the artist to narrow down what to iterate on, instead of starting from scratch. Often times if an artist isn’t told what is wrong they may end up changing something that was great about the piece.
Mention the tip of your tongue
If there’s something off about someones work, inform them that there’s something that bugs you about it, but you are not sure what. Someone else in the room might notice that same thing and have the proper background knowledge to decipher it (negative shapes, minor asymmetry, color barf, principles of animation, etc). If you find that nobody can figure out what’s on the tip of your tongue, then seek extra eyes and ears on the work.
Compliment
Mentioning only the things that are bad will lead to demotivation. If you made me food and I just said that it was salty how would you feel? What if instead I said, “It’s amazing, lot’s of flavour. There might be a bit too much salt.” It’s important to give as much positive feedback as you give negative.
A common practice (which is obvious if you use it too much) is the “Sandwich” method. A sandwich is where you say something positive, then your criticism, then something else positive in that exact order. Making a nice sandwich where the meat is the useful tidbits for the listener.
Do it more often
Creative people thrive on constructive criticism. You might realize that you don’t give enough feedback. If your game’s final boss’s roar sounds like a cow and nobody informs the sound designer that this game is more serious than that then it might just ship that way. Don’t assume someone else has already given that feedback. Don’t give too much, every hour probably isn’t very helpful to devs. It also doesn’t hurt to ask if they want more or less of your feedback, you will likely find out that they want all the feedback from whoever is willing to give it.
Train your team
Remember that not everybody is good at giving good feedback, that includes your team members. Tell them how when they are a bit off target (in a nice way). Send them an email link to an article just like this one (or this one, hint hint hint). As a team player, you should always be looking for ways to improve your team.
Taking It
There are a few rules for taking advice/feedback that are pretty easy to follow.
- Assume that NOBODY knows how to give good feedback.
- An angry forum post might have 40 insults, but that one criticism might be totally correct.
- Someone may only say bad things about your work, and not realize they are only saying bad things about your work.
- Don’t get angry. They might not be aware that they are hurting your feelings.
- Have a close non-work friend of yours give you really bad feedback for practice.
- Ask them to be specific.
- “Could you tell me what about it sucks?”
- “If the character’s cape was purple would that be better or worse?”
- Write down everything someone says. Good and bad.
- Ask for more feedback more often
- Organize all the feedback you receive, you will most likely find you don’t have the time to handle it all (see “Using it” section below)
- Thank them for their feedback.
- Even if their feedback didn’t help. They still took the time to help you.
- Be happy that they are giving you feedback. You rule, you’re making something awesome, and all the feedback only makes it more awesome!
Using It
Now that you have your feedback, you will find that you can’t do it all due to time constraints. Following this workflow should hopefully save you some time.
- Analyze and estimate
- Go through each piece of feedback and figure out if it will benefit the game.
- Remove any that won’t at all (Jimmy wanted to add guns to our ancient Egyptian era RPG)
- Estimate how long it will take to finish that feedback
- Example: “Turning the character’s flame-sword to a purple one will take 5 minutes, having it constantly change colors will take 35 minutes”
- The estimate doesn’t need to be super accurate (and it might not be accurate, so don’t worry too much).
- Estimate the amount of Player Impact this issue will have using a number value
- Example: “There is one crooked tree in the background farthest from the player. He/She likely will never notice it. Player Impact = 1”
- Example: “The player’s arms look really greasy, they are the size of the screen so the player will definitely see them. Player Impact = 10”
- Example: “The mice in this level squeek as if they were a duck whistle, there are dozens of them in this level. Player Impact = 10”
- Go through each piece of feedback and figure out if it will benefit the game.
- Use your best judgement of which ones to tackle.
- The “Low hanging fruit” are ones that will not take you very long.
- These are smart to approach first so that they return to the feedback loop.
- Ex: “I quickly added some vertices to the player’s armpit, check it out when you get a chance.”
- These are smart to approach first so that they return to the feedback loop.
- The “Best bang for the buck” are the ones that are low “Fix Estimates” that have high “Player Impacts”
- The “Low hanging fruit” are ones that will not take you very long.
- Apply your changes and get your work through the feedback loop again AS FAST AS POSSIBLE.
- Be sure to write down any changes that required large estimates.
- These should be included in your team’s next “Post Mortem”.
- If your team doesn’t do post-mortems then, OH MY GOODNESS FOR THE SAKE OF YOUR TEAM YOU SHOULD START DOING POST-MORTEMS!
- These indicate weak points in your workflow, tools, engine, team, etc, etc.
- These should be included in your team’s next “Post Mortem”.
- Be sure to keep somewhere written which changes you didn’t get to doing.
- If someone a month or two later asks you to polish that piece of art/design/code/work, you will already have a small list of things you can do to it.
- Be prepared to iterate again.
- But don’t just sit there and wait, there’s always something else to be done.