It’s safe to say that everyone in our field will find themselves as part of a team at some point in their life. And as part of that team, they will have to give and/or receive feedback.

Whether the feedback is the result of user testing, client review, or internal review, whether it is from by the CEO, a client, an intern, or your mom, and whether it is delivered in writing, verbally, on Post-Its, or via interpretive dance, the feedback should always be in service making the best product possible.

That means effective communication.

Most people I encounter are actually quite good communicators and well-schooled in the basics of critiquing. (Thanks, liberal arts education!) But we’re also not perfect, and there are things that push my buttons. So this post is not to comprehensively address the rules of feedback. It’s instead a politely worded rant of the things that drive me crazy.

In effect, it’s my feedback to the world of people giving and receiving feedback. (If you like my feedback, you can return the favor by following @NoCrusts on Twitter or liking us on Facebook.)

When You’re Giving Feedback…

1. Begin on a positive note.

In couples therapy, it’s called the “Softened Startup.” If you’re under a time constraint, even a simple statement can go a long way, such as “You’re doing really well, but I’m short on time so I need to jump right into our notes.”

It helps to end on a positive note, too. Especially if you’re feedback was particularly difficult. It helps to remember that even if you hated the work, someone put a lot of effort into the product you’re reviewing (or most likely did).

2. Be specific. “It’s not fun” does not count.

If you take away nothing else from this post, please remember this: “It’s not fun” or “Make it more fun” is useless feedback. It’s vague and, frankly, insulting. Development is a long process where “fun” is the end goal. Sometimes the “fun” comes together at the very last minute. When was the last time you had “fun” looking at a design document?

So if you find yourself writing the f-word, dig deeper and ask yourself what’s really bothering you. (Anne also has discussed the f-word before, too!)

• Is it that you’re concerned the writing isn’t engaging?
• Is the art not setting the mood?
• Is it not making you laugh?
• Are you missing a euphoric sense of fiero?
• Are you concerned that the target age group may not understand what’s going on?

By being specific, you’ll help the team understand your worries and best figure out how to address it. Or, at a minimum, acknowledge that you’re struggling to be more specific and begin a conversation about the concerns.

3. Don’t contradict previous feedback

And if you do, acknowledge that you’ve changed your mind and explain why. Nicely.

4. Prioritize feedback

What’s negotiable? What’s not? By prioritizing the feedback into must-haves and nice-to-haves, you appear rational and reasonable. The team can strategize how to discuss feedback and in what order to address it during the development process.

Early in development cycles, it’s not uncommon for the majority (or all) feedback to fall into a must-have category. But if you’ve established the existence of various priorities at the beginning of the development process, it’s psychologically easier on everyone. There’s the belief that down the road, perhaps at alpha or definitely by beta, the feedback will start to shift into categories.

5. Respect the scope (assuming there is one)

Pretty much every project has limits, be it budget, schedule, or otherwise. Feedback frequently pushes boundaries in the name of improving the project. But it’s rather criminal to request new features or change designs radically under the guise of feedback, especially if you’re then going to act surprised when the receiving party pushes back on the requests.

It’s OK to request new features — no one gets it right out of the gate, so it’s natural that you’ll find things to change or add. But acknowledge that your feedback may fall in a gray area so you can have a productive conversation about how to best achieve the goal.

Related to this, it’s also important to respect the milestone. If you’re at beta, requesting new features is a really bad idea unless you’re willing to significantly compromise budget and launch date.

Hint: Scope-creep statements often begin with “Wouldn’t it be great if…”

If You’re Receiving Feedback…

1. Ask for more information

Some feedback doesn’t make sense. Or you’re not sure why it’s a must-have. Asking for a little more information never hurts. It’s not uncommon, too, that during the process of explaining, alternative solutions pop up.

2. Get on the phone or meet in person (if you can)

Email is great. But if you find yourself with long email chains full of rainbow colored commentary, it’s time to have a real-time, synchronous conversation!

3. Put feedback in writing

When feedback is given verbally, send a follow-up note with a summary of the notes and agreed on changes. If possible, have everyone confirm that it is an accurate reflection of the feedback. Then keep it neatly organized, in a shared location even. You never know when you might need to go back and refer to previous notes.

4. Challenge contradictions and scope-creep delicately

It’s ridiculously frustrating when a request comes down the chain that clearly contradicts an early request. But bullishly pushing back doesn’t help the problem. You might feel better in the short term, but you’re still left with the problem of how to address the feedback.

Engage the necessary people in a conversation about why the change is necessary and cite the previous feedback. (If it’s in writing, it’s far easier to do this.) Once you understand the heart of the problem, you can suggest the best path (including whether it involves budget, personnel, or schedule changes) and make a plan for action.

5. Suggest compromises

When faced with a request that’s clearly unreasonable (for budget, schedule, or other reasons), it’s easy to simply say, “No.” It’s well within the reasonable boundaries to do so.

But if it’s at all possible, give the request a bit of consideration, even if it’s a clear case of scope-creep. If you can suggest a compromise (even if it’s to add the feature after launch), the feelings of goodwill can only help the entire team.

Now, go forth and collaborate in harmony! Or drop us an email at KidsGotGame@NoCrusts.com.

Photos © Luis Vidal, Philip Dean