Don't Listen...

I wanted to share some great advice I got early on in my time on the PS2 team, from Thomas Schenck (@tomslick42), who is now on the H1Z1 team as the technical director, IIRC. It is applicable to players, devs, and really anyone who uses or develops any product.

In the crunch days before launch of PS2 and the many weeks that followed, we all spent long days and nights at the office making PS2 as great as it could be. During some of these late nights I would often chat with Tom about all sorts of design ideas - he had a lot of them, and also some game history to share. On top topic of feedback from the players, Tom had a great statement that stuck with me throughout my time as a designer. It still sticks with me, because I believe it applies to all forms of software and product development in general.

Don't listen to what they say;  

listen to what they're telling you.

When you work on a game, or any product, you gain knowledge into how that product is made, and more importantly why things are the way they are. You have requirements, insights, and information that is not available to consumers of that product (in this case, the players). They can never know all of the things you know, even if you try to tell them. So the context of the developer is fundamentally different from the context of a player. What a player might see as a problem may be an important part of a design for the developer, which the player wouldn't understand or value. So when a player gives feedback like "This thing sucks, remove it" the developer can't rarely ever take that feedback literally. Instead the developer must interpret that feedback as "This part of the product doesn't feel right" and try to get a better understanding of why the thing isn't working the way they had intended.

I had a similar experience recently with a friend working on a board game he and his buddies were designing. I helped play test the board game, and gave feedback. As I was giving feedback and suggestions, he was translating it into the source of the problem. When I said "it feels like I have nothing to do during this time" his response was "so you want more player interaction?" He had received that feedback before, had thought about it, and immediately recognized the underlying problem from the symptom I had given him. I had thought of ways to alleviate that problem, but his understanding of his game was far better than mine, such as how all the parts moved together. He had a very different response to my feedback than I expected, but it was correct because it took into account all of the history and requirements and other feedback of which I had little knowledge.

Takeaways

Players:

• Try to be as detailed as possible when describing problems, that helps devs frame the problem in their context. 
• Emotion and feel are great things to use, as that usually cuts to the root of an issue.
• Feel free to make suggestions, but expect that they will likely do something different because you don't have all the requirements.
• Lack of response or changes completely different from what you expect doesn't mean your feedback wasn't received - it can often mean a dev combined it with other context unbeknownst to you and arrived at a fix (or lack thereof) they believe is appropriate to all requirements.
• Sometimes they will agree with you, but may not change something for other reasons that override your feedback, or are awaiting other solutions that may address it.

Devs:

• Player feedback may lack context, but it's still giving you an angle that you may not see - their perspective. Just as your context is different, so is theirs.
• Even seemingly toxic feedback can be great. Matt often looked at 4chan and went out of his way to get every piece of feedback - good and bad - that he could to understand what people really thought of the game and how to best improve it.
• Dont' listen to what they say; listen to what they're telling you. :)

And thank you, Tom! You probably had no idea how much I took that to heart!