How to feed your trolls and influence people...
This post is an adapted version of the presentation I gave at the Montreal International Game Summit this year. So if you want to learn a little of what we talked about, grab a seat and let's get down to the subject of player feedback and how to intepret it.
Before we start it's important to not that this post is not exactly same as the session as some things just work differently when committing it to a page, as opposed to delivering it live. I am also one of those annoying people who insist on using animated presentations rather than simply being able to hand over the slides like you might with Powerpoint or Keynote, so this is an adaptation from the original presentation. It's a degree shorter when presented here, as with a forty minute presentation you end up with a few anecdotal asides that simply don't translate as well when it's written down. However it should still make for some interesting reading!
...so lets dive right in...
Online communities present an interesting challenge for developers in this day and age. It is often an unpredictable and complex environment. However there is always one piece of advice I would give to absolutely anyone who intends to have a public role on the internet. It may sound simple, but it will be the only thing that allows you to retain your sanity...
Never take it personally...
...people can be rude, mean and often downright abusive. Even if you could do everything perfectly, there will still be someone out there who gets a kick out of trolling you and generally questioning your genetic lineage. My forum handle has been 'Silirrion' for many years, and this is just an example of some of the fun and cheerful feedback you will provoke at some stage....
It's an unavoidable part of public engagement, and you simply have to let it slide off of you. If you aren;t able to disengage that part of your brain, you will eventually get driven down and worn out. It's a natural human weakness, and it takes some time and patience to learn that you can't take it personally.
So that established who are these trolls?
Any excuse to use Statler and Waldorf in a presentation slide is ok with me! These guys might have claim to being some of the original trolls in popular culture, but things have moved on since then!
There are now more channels for feedback than ever before. It should go without saying that if you are going to engage
Ok, so once you are prepared and up to date on all your social media jargon and have established the lines of communication you will be using, what exactly is it that is so dangerous when it comes to player feedback? At a fundamental level there are three age-old traps that we see developers fall into time and time again when it comes to player feedback. They are inherent dangers that prey on some of the basics of human psychology.
The first of these three dangers is, put quite simply, born out of arrogance, and that is the idea that the proverbial 'you' as a designer simply 'always know better' than your players. You can forgive people this one on occasion, as sometimes the internet makes it all to easy to make you feel like you are a higher life form, and I'll never turn down an excuse to use an XKCD cartoon as an example...
It is an easy trap to fall into. Feedback from players often tends to not be fully informed. After all, they don't have access to all of the information that you do as a designer. That often makes it easy to fall into the trap of ignoring their feedback on the grounds that it 'wasn't taking X into account' (even if X was something the players couldn't possibly know!). Now I'm not advocating you listen to every hair-brained idea that pops up on a forum thread or on a YouTube comment, but likewise you should never dismiss them out of hand, and use them as a way of testing your own convictions. Even asking yourself if the question is valid, is often worth the time in and of itself, because it gets you thinking about your own designs in critical terms.
Someone's honest opinion is always worth considering...but we will get back to that point later!
So if that's the first danger, what's the second one?
Moving on you have a problem that is deeply rooted in a fundamental desire we all have - we all want to be liked! Alas, that can have a nasty side-effect...the Knee Jerk reaction...this is one of my own personal bugbears.
While it is easy to understand why a developer might fall into the trap with this one, it can also indicate a fairly fundamental lack of understanding of what a designer is needed for in the process of making games.
This angry mob of players wanted you to have more of the color red in your game. You have to keep them happy right? One of them wrote a lengthy, very articulate and impassioned plea on your forum for the inclusion of more red. Your CEO even read that one and want's to know what the harm is in adding more red...
..yeah...this isn't going to work...
...really? Crap...what the hell do we do now?
You can't win with that type of an approach!
Quite simply you can't please everyone all of the time. What's more, is that as a designer you shouldn't be trying to do so either! This is why this particular problem tends to irk me as a producer. When someone comes running to me with an issue simply because they read a forum thread about an issue, and wants to implement the players solution immediately it usually tells me two things
Firstly they didn't see and consider this issue themselves, and it took the players to point it out to them. Now not every issue is predictable, so this one can be forgiven on occasion. However then secondly you have the fact that they often haven't thought of the players feedback critically and objectively. They aren't actually approaching it as a design issue. They are reacting emotionally, and treating it more like it were a PR crisis.
They often want the players to like them, not be hating on them, and want to 'fix' that as quickly and as easily as possible, rather than actually considering the issue at hand, and all the implications of a solution.
Now saying this is a bad approach doesn't in the slightest mean it might not be an issue you have to take seriously. It often is something that has to be addressed. What is important here is that designers remember that they are the actual designers, and should be the ones that have the bigger picture, and be capable of assessing all the feedback, and coming up with an actual design solution. A solution which they have come to having carefully considered both the validity of the feedback and the impact of the possible solutions.
That is why we have designers in the first place.
Having that instant emotional knee jerk reaction to someone not liking what you have done is rarely a good situation to place yourself in.
That leads us neatly onto the third danger...
In many ways this is the danger that will present you with the greatest risk to your project. It isn't as much of a flaw in the designer as the previous danger, but it is far more dangerous when it comes to how you spend your resources. In many ways it is an extension of the knee jerk reaction but takes on a much more cunningly dangerous form...and that is the attempt to actually plan to try and make everyone happy and end up with a weird design by committee approach.
In most design projects focus is important. You need to have a clear design goal, a visions for your product. You should have a clear demographic in mind, a budget, some great unique selling points that you are going to anchor your design around. You should be aiming to take an idea, a specific something, and execute on that with a lazer focus.
The extension of the 'knee-jerk' reaction is actually planning to try and please all of that feedback, and to try and be more things to more people than your budget, resources or ambitions allow. This can lead to some very messy, unfocused development practices. Not every project needs to have every cool idea you can possibly imagine crammed into it.
This is a trap that producers often find themselves slap bang in the middle of. Everyone has ideas...players, managers, marketing departments, CEOs, designers, artists, and coders alike. It is often the greatest challenge a producer faces. How to keep their team focused on the agreed goals, and not running off on tangents because a feedback channel suggested they might not like something.
Those of us of a certain age will remember what happened when someone let Homer Simpson load his 'perfect car' with every cool thing he could think of!
What's more is that this isn't even the start and end of a developers problems with community feedback!
If this all sounds very negative it isn't actually meant that way. A designers job is a difficult one because ideas are easy, freely available and, in effect, cheap. Designs on the other hand are complex beasts, that must pay homage to ideas, and often require the proverbial sacrifice in blood, sweat and tears. Feedback, and knowing how to deal with it, are essential to improving designs and refining them...but we aren't even finished with the complications just yet...there is one more very important one...
...unfortunately an element of collecting feedback is that not all of it is truthful....
On this subject a few pictures can spare a few hundred words at least - pictures from the good folk at Penny Arcade. Everyone knows that the internet has that fundamental weakness to it. The psychologists can have a field day theorizing as to reasons why we do it, but we can all agree that people often warp the truth into some evil unrecognizable form of the original information or opinion prior to it being posted.
So if we have established that we can't even trust the feedback to be honest and accurate how exactly can we view it?
Personally I always advise designers and those tasked with looking at feedback to treat them like some kind of smoke signals from your users. They are an indication of the areas that you need to investigate. There might be a raging fire beneath the smoke, or there might just be a small flame being manipulated by a man with a rug intent on sending a message that may or may not be true.
The true skill in using feedback effectively is trusting in your own ability to actually use feedback analytically...
...which leads us nicely into one of the more recent industry hot button topics
Metrics...some will tell you that they are the be all and end all of design analysis. Some will claim you can build entirely profitable enterprises purely from analysis of these metrics. Indeed some have already built very profitable empires out of a largely stats and metrics driven approach to design.
Personally I have always thought that metrics are a tool. A very important tool, but they are not the only tool available to a designer, and I would argue that a designer who only considers metrics is potentially just as short sighted as one who insists on only going with their 'gut feeling'
It is an interesting conflict that has been growing in the industry over the last few years. The creative instincts of the designers versus the cold hard metrics of user behavior. I love metrics, but I also find myself making decisions based on intuition, experience or belief in a design. The two do not have to be mutually exclusive of each other.
Metrics serve a valuable purpose in allowing you to understand more about how people approach your designs, and how they interact with them. They often turn up things you wouldn't expect, and when approached as a tool to learning in that way, will usually mean that you are better informed and will make better designs in the future when armed with that information.
Likewise, this is a creative industry, and our natural instincts and creative sensibilities are important parts of the design process. If you distill your design down to a purely metrics driven formula then you may risk missing out on those all important creative inputs that can truly make the difference between a bad game and a good one, or a good game and a great one.
...and that leads on to the important part of assessing feedback, and that is how to read it. Before we get into this section I would invite you to watch this session from the TED lectures first.
This lecture is from a gentleman named Simon Sinek who wrote a very interesting book about the behavior of people and how business can use it that addressed a fundamental aspect of what motivates and inspires people.
...read on when you are finished...
Now while Sinek goes a lot further into what this kind of understanding can mean for a business. I was also struck by how fitting it is understanding players feedback. Just as in the examples he gives about why people are motivated and inspired by certain types of communication, you can benefit greatly from understanding why a user feels the way they do about a piece of feedback.
So in our content the key is in understanding why the user has felt compelled to give you a piece of feedback. You can take the 'Golden Circle' that Sinek talks about so eloquently and apply it to the feedback that you recieve from a design point of view. It will help you get to a deeper understanding of what is motivating the players feedback.
So taking the What, How and Why, I always like to challenge each piece of feedback with a question from each, and doing so soon reveals how much more important the WHY is, rather than the What and How.
- What is the problem the player has?
- How has the players perceived that issue?
- Why do they feel that way?
Sounds easy right? Maybe so, but you would be amazed how many times I have worked with, spoken to, or heard about designers who all too often fail to get to that all important third questions of WHY.
This also is a pretty robust approach for almost any piece of feedback. Sometimes it will be answered by the first question, or maybe the second, but going all the way to the third question will often enlighten you far more in terms of understanding how users understand and interact with your designs.
Importantly to often allows you to realize that the problem isn't actually what the user describes, but may lie elsewhere in your design.
Take an example. You have made a boss fight in your game. You are proud of the boss fight, feel it is pretty well balanced, and hope it is fun for the players. The players however find it way too hard and complain that several of the bosses attacks hit too hard and they die to much.
Now some designers see an easy answer and would say: "let's just reduce the damage on those attacks."
However, maybe the issue isn't actually with the bosses attacks. In fact, you designed a special shield the players could activate to mitigate some of that damage, and upon closer inspection, the problem isn't the bosses attacks, but lies in the fact that your users aren't using their shield.
The question you have to ask is: Why did that happen?
Did you forget to introduce the mechanic?
Did you only make it useful so infrequently that it didn't occur to the player to use it?
Did you make the shield too difficult to execute?
Did you fail to properly visually communicate when to use the shield?
These are all possible questions that you may have missed because you did not ask 'WHY?" and simply reacted to the feedback at the general level. It might be that actually solving one of those possible causes above would actually make that boss fight way more fun and a better experience when the players get to it....if you didn't ask yourself the why, then you might have been selling your encounter short...
So lets fit that into those three questions we asked at the start...
- What is the problem the player has?
- The boss is killing them too many times and making it frustrating
- How has the players perceived that issue?
- They see those powerful attacks that kill them, and don't know how to deal with them.
- Why do they feel that way?
- Because you have failed as a designer to make the use of the shield intuitive enough (and that could be for any of the reasons above)
Many people might end up just asking the first two questions and conclude that reducing the damage inflicted by the bosses attacks is their best solution. It's quick, and it does indeed solve the problem that the player complained about...however in not asking the 'WHY?', you then miss the opportunity to make that boss fight much more fun and engaging for the user.
Yes, that is a simplified example, but I think the point is clear enough.
...is really the most important question to keep asking yourself when it comes to user feedback.
Before we part ways, and thanks for hanging in there, this has been a very long post, I wanted to close with an important point. This can all sound a little harsh on the users, and that isn't the case at all. Feedback is vital to a good design process, and while it is often imperfect, biased and not always constructive, it is something that a good designer wants to understand. You will benefit from learning to look at things objectively, impartially, and not taking anything personally. There is a wealth of good feedback out there, you just have to know how to harness it...
...because I want to circle back to the start and leave you with a final thought...in particular in relation to MMO communities...
We do all know these guys. Every game community has them. Many developers often hate having to interact with them...sometimes rightly so...however, it is also worth remembering that Statler and Waldorf were at every single one of the Muppet Shows. They showed up every night. They might not have shown it, or expressed it, but you don't show up every night like that unless you truly appreciate that entertainment. Your players do care, they do love your games, they just often don't agree with each choice you make. They might sometimes express that displeasure too strongly...but they do care...there is a reason they are still around that it isn't necessarily 'cool' to admit to...
Likewise Statler and Waldorf there have the best damn seats in the house. Balcony booth above the stage? Those guys aren't just some of your most dedicated fans, they are often your best customers as well...
..and that's why I firmly believe the best designers learn how to take feedback, look beyond the what and how of the complaints and truly understand the all important 'WHY?' and then use that knowledge to craft better games