Game Design: Effective Playtesting Feedback

I've been struck over and over again with the reality that many people simply don't know how to properly give effective feedback. So, let's dive into the principles of giving effective feedback during the playtesting process.

Purpose

The purpose of playtesting and giving feedback is to answer certain fundamental questions about a game so that future improvements can occur. These questions include:
"How clear, consistent, and streamlined are the rules?"
"How interesting is the theme and how applicable is it to the rules?"
"How balanced are the mechanics (i.e. how fair is the game for each player)?"
"How clear and streamlined are the layout and procedures of the game?"
"How satisfying or unsatisfying is the overall length of the game?"
"How interesting are the decisions the game requires the players to make?"
"How fun is the game to play?"
"How can the game be improved?"

Attitude

Be kind but honest.
-You are not doing anyone a favor by telling them their game is better than it really is -but honest feedback doesn't have to be conveyed disrespectfully.
-Designers should welcome honest, intelligent, and respectful criticism as it will provide opportunities for discovering new ways to improve their game.
-Give compliments to designers on good aspects of their game.

Extent

Keep feedback appropriate to the game's phase of design
-For example, don't be overly critical of the quality of components used in a game that is still in an early phase of design. The game will not have had much of a chance to take a solid shape yet. However, if a game is in a late stage of design, the components can and should be given more scrutiny.

Give other playtesters time to provide feedback
-Don't monopolize the discussion. Different minds have different perspectives and hearing a wider variety of perspectives tends to result in better overall feedback. Keep in mind that someone else might bring up something that you were going to bring up and might do so in a better or more insightful way than you would have done. Trust that the other playtesters have equally important feedback to offer, allow them the time to offer it, and refrain from interrupting others while they are giving their feedback.

Focus

Address the roots first, then the branches (if necessary)
-Prioritize feedback by discussion the most important issues first. Remember that a "Saturation Point" can occur where too much feedback "saturates" the group and/or the designer - resulting in fatigue with the process. Thus, it's important to discuss the more important issues before that point sets in.
-Actively look beneath the surface for more fundamental problems and direct attention there (don't un-inquisitively fixate on the surface symptoms of a potentially greater problem).

Example of prioritizing feedback:
Discussing how the game has a potential runaway leader problem before getting into a discussion about how the wording on one of the cards needs to be changed a bit.

Example of actively looking beneath the surface and not fixating on surface symptoms:
"Hmm. I find Rule X to be a bit cumbersome. But, rather than tinker with Rule X, let's ask ourselves why Rule X is there in the first place...Well, it seems to me that it's an attempt at fixing a balance problem. So, rather than focus on Rule X, let's look at the places where a balance problem might be originating from in the game and see if we can't correct those first." In the discussion that follows, Rule X may eventually become completely unnecessary if other areas of the game are corrected. Thus, a lengthy discussion about tinkering with Rule X may appear productive but, by looking beneath the surface a bit, one may find that Rule X is merely a symptom of a deeper problem in the game that should be addressed first.

Skills and Methods

Making Claims
-Making a claim about a game is not stating an opinion. It is making a statement and portraying that statement as a fact.
-Claims are made with the intent of proving some important fact about the game to the group and/or to the designer. Claims are usually followed by a debate with people taking a "side" on the issue. Ex "I claim that this rule is unfair".
-Claims are naturally confrontational and, as such, should not be made about arbitrary issues or about smaller aspects when a greater issue is involved. (Ex. "This scoring track is unclear" is a claim about a significant issue while "you should use a diamond instead of a circle on your scoring track" is a claim about an arbitrary issue and/or a smaller aspect of a greater issue.)
-Don't make a claim unless you are willing and able to support it with evidence (don't be rash and don't jump to conclusions). Ex "The wording on that card is unclear and my evidence is that I can justly construe a meaning from those words that the designer did not intend."

Making Observations / Proposing Hypothesis
-Making an observation or proposing a hypothesis is making a statement about the game but from an admitted standpoint of uncertainty. Ex. "I think this rule might be unfair."
-Observations are made - not with the intent to prove anything - but for the purpose of instigating a discussion about an issue.
-Usually, people make the mistake of making claims when they really should be making observations.

Posing Questions
-Posing questions is a covert way of offering suggestions that is non-threatening and allows for a variety of responses. It also helps people remain open to newly presented ideas whereas making claims requires a more immediate response of acceptance or rejection (again, it requires people to take a "side" on the issue). Ex. "I'm wondering how the game might incorporate more player interaction and what that would do for the game's intrigue?" - is a more effective means of instigating change and keeping people open to considering potential changes than trying to introduce the same idea with a claim like "The game needs more player interaction".

Making Suggestions
-Suggestions are usually made in the discussions that follow from claims, observations, or questions that are posed.
-Suggestions should be phrased as "possibilities" rather than as imperatives. This is because phrasing something as if it were a command makes people naturally defensive while phrasing something as a possibility takes away that unwelcome pressure of having to accept or reject it immediately. It also prevents the designer from feeling like you are trying to "take over" the design of their game. Ex. "One possibility you might consider is using a coloring scheme to make your cards clearer."
-It should be remembered that, often, there are several viable ways of accomplishing a task and, because of this, suggestions should not be phrased like claims. Bad example: "You need to use a coloring scheme."
-Remember that, often, playtesters will be making suggestions but will inadvertently phrase them imperatively as claims. Be patient with people if they do this because it's a common error.

Asking Questions
-Asking questions involves actively asking the designer about the intent or the methodology behind some particular aspect of their game. Obviously this would not be a possibility if the situation were a blind playtest but, in non-blind playtesting situations where the designer is present, it's a very good idea for the following reasons:

1. Asking questions prevents the "Saturation Point" from occuring as quickly for the designer (an active, two-way dialogue is more interesting and involving than a passive, one-way monologue where someone is going on and on with their feedback).

2. Asking questions makes it much more likely that the designer will actually listen to your criticism because they will be listening to someone who has actively sought out and comprehended their position on the issue first. Otherwise, a designer might dismiss good feedback by telling themselves "this person just doesn't get it".

3. Asking questions can save time. Ex. "This information track is unclear. What solutions have you tried in the past to make this more clear?....Hmmm. Ok, well, you might try this as one possibility..." - versus - "This information track is unclear. Perhaps you could try (blah blah blah blah)....Oh, you've tried that already."

Expressing Opinions
-Opinions are not claims nor are they observations. They are statements concerning personal preference and, as such, are completely arbitrary. Ex. "I personally don't like how you've named these options".
-Because opinions are arbitrary, they should be qualified so that they aren't portrayed like claims. Ex "For me personally, I don't find your theme very interesting" instead of "Your theme isn't very interesting".
-Keep in mind that some people will not like your game regardless of how good it may actually be. This could be due to a number of reasons:

*Different preferences for theme

*Different preferences for the level of strategy involved / Different levels of comprehension (if you present a heavy strategy game to a person who prefers light party games, then you're probably going to get a bad reaction)

*Different preferences for the amount of luck involved in a game (if you present a very luck driven card game to a person who strongly prefers perfect information games, then you're probably going to get a bad reaction)

*Many other factors

-Because of the wide variety of preferences and personalities there are in the world, it is best to playtest your game with a diversity of people to see how different types of people respond to it.

-Because opinions are arbitrary, they should be taken with a "grain of salt". But, if you recognize patterns in the opinions you get from people - especially people who tend to fit the gaming demographic your game is intended for - then you might consider giving those opinions a little more weight in planning out future designs or versions of your game.