Community Series – The Developer Shaming Myth

253e3a9dc089290d8f3749d8a3057695Kristen and I have written a lot about feedback, specifically how we break it down into usable chunks and also process and compile it into useful information for developers. In both of these posts, we refer to the idea of shaming developers not really being an effective method for eliciting change, so we thought it would be a good idea to expound on the topic a bit and show people why, even though it seems like it works, it really doesn’t.

You’ve probably all seen a developer shaming post before. They’re the ones that attempt to “call out” developers, posted under the most benign circumstances as an awareness announcement, and in the most malicious as a way to showcase developer mistakes and create mass dissatisfaction. You might see them on fan forums when official channels get denied to the poster, or submitted to press sites as a way to shine harsh, Internet light down on a perceived issue.

Let’s look at a couple examples, shall we? The most common forms they take are:

When a corrective action like a ban or suspension has been given to a player and they disagree:

I am making this post to bring some real data to this situation. I want to share the insane double standards being used by the support team, and send a potential warning to players who craft and salvage any items in the game.

When a player is frustrated with design decisions or direction and decides to find evidence of the developers being contrary to previous statements:

Now the game has been released, it hardly feels ready. And as eager as I was to start playing at the stroke of midnight on the head-start weekend, after a few weeks of play time, I now feel like I’ve been lied to.

On top of all that they just released posted in a forum stating that they “weren’t going to release a perfect game…”.

I am nay saying the god complex that is running amuck. I know you guys think you have a perfect game and that your manifesto was on par with Marx but you have seriously reached the height of arrogance when you don’t set any deadlines for yourself, yet expect your paying customers to wait on you to fix a game that was released in a state of disrepair. I really really appreciate the talent, but I believe it’s gone to your heads. One only has to read their haughty forum posts to see that.

There are more instances, but these are the two most common we see come up.

Occasionally, threads and posts like these actually elicit a response from the developers, and in some of those cases, you might see action taken that matches what the player is posting they want done. This unfortunately leads to a mentality where “if we complain about it enough and draw attention to ourselves, we’ll get our way” – that for some reason the developer will want to save face by bowing to the demands of the player out of shame or fear of being seen negatively. This thinking couldn’t be more wrong, and here are some reasons why this is a myth.

Every action the developer takes is supported by a combination of sentiment and hard data.

It stands to reason that when a developer puts in an agreed-upon fix, builds a new feature most people like, or updates the game in general that they’re using supporting evidence to do so – metrics from internal and external testing, feedback from players and surveys, and so forth. Why, then is it that the argument made for when something isn’t done correctly in a player’s eyes that a developer is somehow “out of touch” with their game, or somehow “doesn’t play their own game”? Why is it that when a developer rolls back a change players dislike or they reverse a ban, that it is simply “the will of the players” or “they listened to the players”? No, the same data, metrics, evidence and internal processes used to implement a change are the same methods used to ensure a rollback or a removal are the wisest courses of action.

When someone purports to “shame” the developers by presenting an angry counterargument or personally insulting feedback to the developers in a TMZ-like tell-all format, that evidence is usually taken back by Community to the developers to see if that Fizzlebit Destruction Kittystorm ability really isn’t performing the way it’s expected to perform. If the data, and the (more constructively presented) sentiment/criticism from players supports action, then action will be taken. If a mistake was made (because they do happen sometimes no matter how much QA you put on a patch) and the evidence internally supports what players present, then it’s corrected.

This doesn’t always mean that how players feel doesn’t matter – it does, trust me, which is why Community teams look at trending sentiment and perception from players as justified metrics to at least investigate an issue. But very rarely is the rollback, change, or fix that the players want a direct and sole result of angry players looking to shame the developers into action by flooding forums and sites with rage-filled posts. In fact, if the data doesn’t support what the players think or are presenting as evidence, a developer will sometimes come right out and say it doesn’t (with the right massaging from us Community people, of course).

In short, if you want to correct an action a developer has taken with their game, you’re better off with intelligently gathered data coupled with constructive criticism – because we’ll be looking at those as the real feedback to take back to the developers instead of the pitchfork-wielding, call-to-angry-mob disdain that some players wield as weapons in an attempt to force a developer’s hand.

It isn’t the quantity, but the quality of the feedback that elicits change.

A typical shaming technique I’ve seen leveraged from players towards developers is the idea that if they post enough complaints, or overload the forum or fansites with enough dissatisfaction, that this will somehow move the developer towards corrective action that they agree with. And sometimes, when the developer does respond to this out of necessity or does something to calm the masses, it seems that it’s justified. But given the fact that we’ve explained that Community teams gather feedback in very specific ways and filter it, it’s really not the way to go. Primarily, it just causes the forum moderators on the Community team a headache as they seek to consolidate threads, remove duplicates, and take action against troublemakers.

When we take a look at an issue that is generating this much traffic, the fact that there is a lot of it out there is at most peripheral. Our primary objective is to gather the quality of feedback needed to illustrate to the developers to investigate a perceived player issue. The assimilation and gathering process you’ve seen us write about is performed multiple times, within minutes, on many posts, threads, and tweets, and more often than not, it’s not the original post of shame that gets referred to but the more rational, yet critical posts that either respond to it or are put up elsewhere.  Sure, you might think that shame posts are thus justified because they’d actually generate attention where it’s needed, but honestly, we’d rather you start out with a post that was constructively critical with no shaming or insults attached to it, because providing feedback is supposed to be the prime motivator, not making the developer look bad – and it’s very obvious which ones are the former rather than the latter.

Saving face and good service/relationships are important, but aren’t the only reason to take action.

Community teams are tasked with managing service and the x-factors of human interaction when it comes to players and developers. In this respect, it is important to maintain good relationships with players. It is important that when we need to do so, we save face by publicly acknowledging mistakes when they are made, or explaining as much as possible the circumstances behind actions taken in response to player feedback. But it is by no means the only thing that is taken into account. This is why when multiple shame threads on a subject are removed or consolidated, it isn’t because a developer wants to hide the issue – another myth that is a bit silly considering the internet usually knows what happens regardless of whether something gets hidden or not.

When action is taken, it’s not just to make a show of good faith to ensure that we are listening, or that we’re embarrassed by what happened. There’s also the idea of being consistent with actions being taken, of understanding that design sometimes doesn’t pan out as intended in the live game, that players should be acknowledged as having a viewpoint that the developers may sometimes not have considered. That’s why when something happens in response to massive feedback, it isn’t because the developers are ashamed of being called out on their mistakes, but because it’s important that the experience as a whole is satisfactory and fair – and a lot more goes into that than just player feedback and the relationship players feel towards developers.

Hopefully this helps bust the myth of trying to shame developers into change. Trust us – there’s more at stake at fixing something than player dissatisfaction, which is why it’s important to communicate more than just that when you’re giving developers feedback.

Leave a Reply

Your email address will not be published. Required fields are marked *