Post by: Grant Rodiek

In Friday’s post, I noted that the folks at Cardboard Edison had asked me two questions. The result of the first question was Friday’s post. The second question is answered, or so I hope, in today’s post. Thanks again for two great prompts!

Today’s Question: What do you do when a tester says “You removed my favorite feature?” Or, more broadly, what do you do when your iterations conflict with testers’ opinions?

If you’ve been reading my blog for some time, you’ll notice a few recurring themes. The first thing that comes to mind to answer this is one of my most predominant recurring themes: what is your goal for the game? If you can answer that question succinctly, and I think you need to be able to before you do ANYTHING with your design, the choice is clear.

Before you respond to your tester in regards to any feedback, positive or otherwise, you must be able to answer these questions for yourself:

1. What type of game do you want this to be? What are your high level goals for the experience?
2. For whom are you developing this game? Who is your audience?
3. What is the most important part of your design? To which part of your design will you allot the most complexity? Where do you want your players’ attention? What is their key decision point?

If you can answer those two questions, you can begin to answer these:

1. Why did you make the change in the first place? Ideally, it was to bring the game more in line with the answers outlined above.
2. Why do you think the change will do a better job of satisfying your goals?
3. What were the alternates that you considered before deciding upon this change?

To be explicit in my expectations, you need to know why you’re making the change in the first place. Never make changes to your game just to change stuff. Understand fully what the problem is that you’re trying to solve and why you think the change will address it. Otherwise, you will meander for months or years with no forward progress.

Let’s circle back for a moment. You know the game you want to make and your target audience. Ideally, your target publisher as well (assuming you’re solely the designer). You know what makes your game special. You also know 2 or 3 areas where your game is falling short. You know what you want to fix in order to bring it closer to the goal. You act decisively and remove a feature that a tester enjoys. They speak up about it.

Quickly, I want to note what’s important here: You’re coming to the table as an expert. You’re bringing as much data, logic, and science as you can to this vile hobby of ours. You’ll need that.

Before you ask questions, I find it useful to come to an agreement on terms. Or, in absence of agreement (which really you don’t need, this isn’t a democracy), you can at least state your personal goals. Provide a lens: This is the game I want to make. This is what I think is important.

Your first question to the tester is, “Why is it your favorite feature? What did you love about it?” There are a thousand ways to boil and egg (are there?), and once you know what their end goal is, you can deliver that in a way that suits your goals.

Your second question is whether they agree that the problem you intend to solve is indeed a problem. This is a really good way to take their temperature on the end result. If, ideally, you can both reach agreement that you have a problem, then you can move forward. You can then brainstorm and discuss potential solutions that better preserve their favorite feature and still address your problem. This is why question 2 immediately follows question 1.

Really, this is about having a directed discussion. It’s your design, your project. Enter as the moderator and drive the conversation.

Many of us want to placate our testers. For the longest time, maybe years, they are our only fans. They are the only people who have played our game. They’re the only ones who know what we’re trying to accomplish. The difficult truth is, they may be our only testers ever if we don’t sign the game. But, and this is difficult, in the same way one must learn to listen to feedback and leverage testing advice, one must also learn to ignore it or leverage it accordingly.

Just as bad as changing a design haphazardly for years under your own direction is doing so at the behest of your testers. Never forget that it’s your design. You’re striving for your name on the box. It’s your vision.

In conclusion, know what you want. Know what you’re trying to achieve. Know what is sacred in your design and why it’s sacred. Then, work to know what your players like and why they like it. Or, on the opposite side, what they don’t like and why this is so. Enter every discussion knowing what works with your game and what isn’t currently working. Design is an art, but development can be more scientific. Identify issues and eliminate dead ends. Do this by understanding your design and your goals.

Feedback, positive or negative, is only valuable if you know how to use it. A tester who likes your game is fine, but remember that you’re seeking an audience of thousands, unless they’re buying the entire print run.