Giving Feedback

On this blog me and other writers have discussed how to use feedback, how to interpret feedback, what questions to ask of your testers, but never advice on how to give feedback. If you're anything like me, you associate with other designers and you play many prototypes. As people who understand and love design, we can probably better our community (and quality of games) by giving better feedback. Or, at least providing it in a more useful fashion.

This list is based on my experiences at GenCon, Protospiel, and casual test sessions. It's the result of pet peeves, great insights received, and things I'd like to see more of.

Save your perceptions until the end. I cannot properly express in words how frustrating it is to be told of a feature's imbalance 2 turns into the game, or to see a more casual friend bow up just by looking at the number of pieces. "Oh, it's too complicated! I won't have fun."

The thing is, your perception is useful. It really is. If you perceive an imbalance and that taints your enjoyment, that's something I'll need to try to address. If you think the game looks overwhelming, that matters because it may change my target demographic.

But, what's also important is how you feel at the end of the experience, or even just further along. For example, if you think the game is imbalanced from start to finish, that means one thing. If you thought something was imbalanced, but by the end felt that it wasn't, that means another thing.

These little gut quirks can be distracting for the test, both for you and the designer. When you get a knee jerk, take a note of it, check it at the end of the game, and bring it up with all the information.

My favorite example of this is random turn order in York. Without fail, someone goes "ugh random turn order that breaks everything!" Then they play for an hour and find that they don't really care (often). I've had people cry over the imbalance of a single Fleet card in Blockade, only to watch them devastate their opponent the very next turn.

Therefore: Note your gut reaction. Think on it. Provide input later based on the result.

Be aware of the current state of graphical presentation. Many prototypes look like garbage. Yes, there's a healthy (and interesting) debate about how nice a prototype should look. My stance is typically to focus on functionality and simple icons to represent actions in a less abstract manner.

It's not unreasonable for you to ask at the outset: What sort of feedback are you looking for in regards to the graphic design and presentation? The designer's answer can greatly focus your thoughts.

In my experience, it's very frustrating to be told my typeface choice lacks theme when I'm on an early prototype. On the other hand, it's very useful to be told the current layout makes a player think an action means one thing when it really means another.

Good things to point out are:

  • Whether you need a reference card to remind you of actions
  • Where text lacks clarity or supports multiple interpretations
  • Where diagrams could be added to improve understanding

When I took York to Gencon 2012, I found that the layout of my player boards did not properly highlight or organize important information. The round track didn't remind people of scoring, and the score reference didn't tell them how or when to score things. Getting feedback on this was monstrously useful.

Basically: Ask what to look for in regards to graphics. If it's time to nitpick fonts and the size of the icon, fantastic. But more likely, you'll need to help the designer improve functionality.

Share a little bit about who you are. I'm fairly decent at reading people, but often times, before I can properly evaluate your feedback, it helps to know who YOU are. This is a weird fuzzy point, but addressing it is a good way to give the designer an anchor point. Some things to tell them:

  • A few of your favorite games. This tells me what you think about Euros versus Ameritrash, luck versus skill, complexity, game length, theme choices/interests.
  • What you look for in a game, or, why you play games. Some people seek the aggression of war, or engine building, or thorough, long-term analysis and optimization. Or, seeking exploits. Some people just want story.
  • Some of your least favorite games. It helps knowing what experiences or mechanics really rub you the wrong way.

At GenCon 2013, my friend Cole tested his game Aphelion with a group of random guys on Wednesday night. Aphelion is greatly influenced by Talisman, so it was really useful to hear: "Hey, we love Talisman. This has a Talisman vibe we really enjoy." He knew they were arguably his target audience.

Conversely, if I were testing Blockade, a game about direct conflict and lots of dice rolls, and honestly, not an intense amount of deep strategy, my design friend Gil Hova would probably hate every part of it. I need to understand his point of view to properly evaluate his input.

Help the designer understand your point of view. Where possible, remove the cuneiform from the conversation.

Give the why. It's really simple. If you like something, or don't, the more explanation as to why you feel that way, the better. Remember, your feedback will hopefully spurn action items for the designer to improve the game. If you just say "I strongly dislike this mechanic," we're suddenly at a 4 way stop with no clue as to how we should turn.

This is an extension of who you are, as the why might vary from player to player and be influenced by your perception. But, provide the designer with additional, colorful input on why something did or didn't work for you.

Feel free to discuss the high level experience. Often, folks focus on the minutiae, which is useful as a designer may have a particular trouble spot or may ask for advice on improving a specific aspect. But, it's shockingly useful when someone comments on the overall experience of the game.

At GenCon 2012, some folks whose opinion I greatly respect told me that York's biggest issues were bad pacing and shoddy presentation. The game was slower and more confusing than it needed to be. That insight drove some of my best iterations on the game.

Recently, many peers noted that York is just too tightly wound. The tuning is unforgiving and there's just not enough flexibility. Again, this has driven a lot of good, useful changes.

Far too often people discuss the tiny details. This is very useful and appreciated. But, don't forget to take a step back and discuss high level things about the overall experience and vibe of the game.


As always, solid article.

I would also add to your point about waiting til the end to give feedback, and say that if its a short enough game, play it a couple of times before declaring something is bad. I've seen many games that have some randomness or swing wildly if you don't know the cards that are in the deck be declared "broken" because someone lost to something they did not expect. Treat the first game as a learning game, and then try to build your perceptions off of that.

Another great way to learn about your game is to watch someone else teach people how to play it. Explain the game to someone, then have them explain it to another new player (or have them help you teach it.) You will see very quickly what people get, what they miss entirely, and you get a glimpse into what your blind play testing will be like before the game is even ready for that step.

Good stuff, Grant.
I'd also add that it's best to focus on discussing the things that stood out to you (good or bad, or otherwise) and not to propose specific changes or new things without being specifically invited to do so. If you do suggest a new idea, explain what hole you're trying to fill, so that the designer can brainstorm other possible ways to address the underlying issue (or decide if that's even a hole that needs filling).