The Lazy Designer: Providing Useful Feedback

This is a section from Brent Knowles’s Lazy Designer design best practices book. Read the rest of the sections on the Lazy Designer homepage.

“How to Submit Feedback that Will Make it into the Game and not the Recycling Bin”

Feedback (re: bug reports, user analysis, critiques) is essential for many creative endeavors, from writing stories or making movies or designing games. Even the most talented game designer benefits from seeing her product through the eyes of a potential consumer. Knowing how to provide great feedback is essential for a designer, preparing them for when they must solicit feedback and respond to it.

Feedback in this section refers to subjective analysis of gameplay, interface, story, et cetera. More straight forward bug reporting will be described elsewhere.

Consider this example:

Your interface sucks more than an vacuum cleaner. It’s stupid and clunky. I hate it.

At best this feedback would become a data-point on a spreadsheet under the column of ‘did not like’. Most likely it would be simply deleted.

Why?

There’s little information beyond ‘did not like’. I don’t care how clever an analogy the tester has constructed, or how intensely the tester disliked a feature, if they are not providing constructive feedback they are wasting the designer’s time, and worse, company money.

An aside. My first edit of the above paragraph started with ‘Because it’s useless.’ Often I have the tendency when providing feedback to be sarcastic or snarky. I (almost) always edit my bug reports to remove such negative bits.

What is constructive feedback? A websearch will provide several definitions, but at it’s core, constructive feedback should be:

– Respectful. The moment the designer is put on the defensive they are going to stop listening. Being respectful keeps the door open between tester and designer. This includes being polite and avoiding ‘hate’ words, as well as explaining what did work — good testers do not assume that the designers know what is working well, occasionally a great feature is cut because no one mentioned they loved it, they just assume because it is so good everyone knows it!
– Detailed. List the elements under consideration, explaining what did not work with them and WHY.
– Comparative. Is there a similar feature in another game that works better? Explain. Provide screenshots of the other game and/or supporting documentation.
– Progressive. Suggest ways to improve the feature. Do not be offended if those suggestions are not taken, do follow up if no improvements are implemented.

So, an example of better feedback might be:

The main interface is a little cluttered. I love the variety of features available, but a cleaner presentation would have allowed me to enjoy the game more.
I’ve noticed that you are using a quick bar like GameXYZ. In that game they allow you to stretch the quick bar to any size. I’d suggest we adopt this approach, if possible. Start with a small quick bar and then allow the user to grow it as required, let them control the introduction of ‘complexity’ when they are ready. See attached screenshots for an example of their quick bar in action.

A tester, whether one in quality assurance or a designer providing feedback on another designer’s levels, should never be arrogant or condescending. Feedback is an opportunity to help improve the overall product. And it is essential.

“The Lazy Designer – Providing Useful Feedback” Copyright 2009 by Brent Knowles