How to Give Great Feedback on Your Friend’s New Game

I've written before on best practices for playtests (it turned out to be a meaty enough topic for a two-parter, actually). The earlier articles covered both sides of being involved in a rigorous playtest, with testers playing the game numerous times over multiple iterations of design. But there was a consideration that I didn't really cover in those articles: the relatively common situation (at least, in my line of work) where a friend or coworker has asked you to try playing their game with them to give feedback.

This sort of first-impression, informal test doesn't usually involve the same level of detailed reporting or data aggregation as a formalized playtest, nor does it take as long. As such, it usually isn’t compensated (except in appreciation, and perhaps a “time trade” for that person’s help with your own projects). It can also be a bit intimidating to be asked to give feedback on a friend or colleague’s game. If someone cares enough to ask your opinion, there may be a lot of emotions riding on your answers. But it’s important step nonetheless: a designer needs to know how their game will be received by a newcomer, after all, and this sort of playtesting is an excellent way to get much-needed fresh eyes on a game.

These are a number of the methods I’ve found for giving great feedback on this sort of informal peer-to-peer test, and delivering that feedback in a way that doesn’t end friendships.

Tip One: Always Take a Note

J. Walter Weatherman didn’t die for you to forget.

J. Walter Weatherman didn’t die for you to forget.

In my experience, the easiest way to tell a seasoned game designer at a playtest table is that they save their comments to the end. Blurting out every concern as soon as it springs to your mind leads to two things:

First, it disrupts the flow of the test and probably drives the designer up the wall. Trying to explain a game, especially an unfinished game, is difficult. Trying to explain a game while simultaneously justifying your decision-making to three different people is especially harrowing. While explaining things and answering clarifying questions, most designers aren’t in the right place to process and weigh feedback properly.

Second, and perhaps more importantly, getting stuck on a detail can prevent you from seeing the big picture of the game. Sometimes, an unintuitive element or unconventional design choice has important ramifications across the whole game that you won't be able to perceive initially. It can be hard to tell if something is actually a problem or if it will click into place later until you have a sense of its role within the full game. Alternately, the scale of the problem might be very small, leading you to spend time belaboring a point for something that is actually quite easy to change. For instance, if the game is at the minimum viable product stage, chasing typos in text might cause you to miss more fundamental problems that affect whether the game is actually fun or not. That text probably won’t survive to the final incarnation anyway.

If you need to know how something works to play, certainly ask those questions. The designer might ask you to try to figure it out (to see what you do differently than intended, thus exposing where their instructions have weaknesses or their decisions were unintuitive), or offer an answer so the test can move forward, but questions of procedure are generally helpful.

But what do you do with your critiques and comments? That’s why you were asked to play the game, after all - to see if it’s fun! Take all of these reactions or observation you have and write them down, to address with the designer at the end. Typos, nitpicks, personal preference matters - write them all down! You can always scratch them off the list if you decide they don’t matter later, but this way, you won’t forget, and you can present them to the designer when they’re most open to feedback: when they’re not also trying to keep the test moving forward.

This also leaves a written record of your feedback. While you probably aren't going to type up a formal report for this sort of test, you can still tear out that sheet and give it to the designer (or text over a picture, or whathaveyou). Comments delivered only orally tend to disappear into the void, but comments with a physical record often stick.

Tip Two: Level-Set Your Input

It’s a delicate balance.

It’s a delicate balance.

Asking calibrating questions can help you understand the purpose of the game, its intended audience, and the designer's goals. This is something I covered in detail in my articles on playtest design. For more informal tests, this can take the form of a few quick questions. “Who is this game for?” “What do you want to communicate with this game?” “Is your goal primarily commercial or artistic?” Knowing why someone is making a game should guide the feedback you give.

If a friend is making a card game for fun in their spare time, the most important thing is probably that the act of creating the game makes them happy. If a fellow professional is asking you for input on a game they want to pitch as a product, the most important thing is making something that will sell to a commercial audience of some sort (though there are many different types of commercial audience, with different desires).

You can level-set your feedback, too. For instance, if you think your friend’s spare-time card game has real commercial potential, but only if it drops some of its main features for a tighter gameplay experience, you can present pros and cons as part of your feedback: “Streamlining the game might make it more marketable, but if you’re not planning to sell it, that might detract from the experience you want to present.” This lets the designer know what to actually do with the feedback you’re offering. It expand open their horizons to something they hadn’t considered before for the game, or it might help them narrow in on their vision for the project - and they can make that choice with full information if you explain your premises clearly.

Tip Three: Focus on Experiences, Not Specific Solutions

There are a lot of ways to depict the moon, all true.Left: Full Moon, Limache, Chile, by Alfredo Helsby  Right: Moon and Autumn Plants, by Sakai Hoitsu

There are a lot of ways to depict the moon, all true.

Left: Full Moon, Limache, Chile, by Alfredo Helsby Right: Moon and Autumn Plants, by Sakai Hoitsu

Game design is more art than science, and the thing about art is that two different artists are unlikely to handle the same fundamental problem or question in the same way. This is, in my mind, what makes art interesting: seeing a window into how someone else perceives and experiences the world around them shows you a world you might never have considered. From a technical standpoint in games, however, this means that there are essentially as many different ways to "solve" a problem in a game as there are people who look at the problem. While there are certain best practices that generally work out, ultimately, the only thing that really separates a good solution versus a bad one is how much the intended audience accepts it. And more importantly to our discussion here, there are likely numerous good solutions.

When helping test a game, it can be easy to fixate on the various virtues of your proposed solution to a problem you’ve encountered, or your way of emphasizing a part of the experience that you really liked. It's yours, after all, and you want to feel like you contributed something to the project. Just remember that the greatest value you provide to the designer here isn't in identifying one possible solution, but in spotting the need for a solution, or a place where something good can be elevated further.

Of course, people may ask for how you would solve a problem (I often do, when testing with friends). In that case, certainly elaborate as you see fit. Just remember that there’s a good chance they’ll move forward with a different solution than the one you proposed, due to the way iterative development works. But whether or not your solution is implemented in the end, the bulk of your contribution was identifying the importance of finding it.

As a small sidenote, there will be no new article next week. Instead, I’m taking the time to work on some games, so look forward to new content in the much-neglected Games for Download section in the next few weeks!

Previous
Previous

Reflections on the Role of Community in Games

Next
Next

Complexity Pitfalls: The Weight of Learning