Giving Good Feedback

by Kwasi Mensah

March 3rd, 2013

Giving Good Feedback

Myself and judge Chris Allen of Brass Monkey at the Mass Digi Challenge

Myself and judge Chris Allen of Brass Monkey at the Mass Digi Challenge

This weekend we competed at the Mass Digi Game Challenge. While we didn’t get very far in the competition we got to show our game to the movers and shakers of the Boston Independent game scene.

Part of the event is getting mentorship from several leaders in the Boston Indie Game scene. We had amazing mentorship sessions with Elicia Basoli, Alex Schwartz of Owlchemy Labs, Courtney Stanton, Robert Ferrari of Bare Tree Media, and a bonus session from the awesome Michelle Yaiser. One of the things all the mentors had in common is that they knew how to give good feedback.

 

Structure of  Good Feedback

Originally from http://www.straightdope.com/columns/read/1275/how-do-you-diagram-the-sentence-see-spot-run

I’ve learned over the years that knowing how to give productive feedback is actually a learned skill. Our first instinct when we see something we think needs to be improved is to say:

“It’d be really awesome if you did things this other way.”

That sounds fine and dandy and you may have a great idea but you’re only communicating the least important part of what’s needed to solve the problem. Plus you’ve just made it sound like you know more about what’s best for the game than the person who’s been staring it in the face for months, which can be very off-putting. The much, much better way of trying to help someone improve a feature is to say:

“I think feature X is a problem because of reason Y. Here’s my solution on how to fix it.”

By giving your  proposed solution in the proper context, the person that needs to fix it can now actually tell if they’ve solved the problem (as supposed to just implementing your solution). Plus now that the problem’s been named, the person can come up with other solutions to fix it. As awesome as  your suggestion might be, you’re not going to be around when the solution needs to be tweaked or flat out doesn’t work. But by giving the context of the problem, the person getting feedback will still know what to work towards. And now you’ve also engaged the person into discussing why they originally thought to do feature X a certain way. This let’s you find out what constraints they’re working under and hone you’re feedback to take them into account.

And if you’re getting feedback and realize it’s not coming in this form, do your best to understand what the real heart of the problem is. If someone is taking the chance to play your game and give you suggestions for how to make it better, chances are they really want you execute on what you’re working on.

Post a Comment

You must be logged in to post a comment.