Playtesting
How to interpret playtest feedback
A player asks for their character to deal more damage. Do you need to change the balance, or make their attacks feel more effective? Separating their experience from their proposed solution is the first step in deciding what to test.
Key idea
Take the player's experience seriously, investigate its cause and treat the suggested solution as a hypothesis.
Receiving criticism about a game can be difficult because many decisions represent hours of work, intuition and personal attachment. However, separating the designer's identity from the current state of the prototype is a necessary condition for learning from tests.
The player's experience is data
When someone says they did not understand what they could do on their turn or that a phase felt long, their experience is valid even if the designer knows a broader explanation of the system. The rule may have depth in later games, but in that particular session someone became lost or bored. That observation deserves analysis.
Not every criticism means the game should change. An isolated opinion may reflect personal preferences or an exceptional circumstance. A repeated pattern across different participants, however, usually reveals a part of the system that needs attention.
The player describes the pain; the designer investigates the cause
Testers often suggest solutions: remove a phase, increase damage, make a card cheaper or allow more actions. Those suggestions are valuable, but they should not be applied automatically. They are often the most direct way someone finds to express a frustration.
A request for more damage may conceal a lack of feedback: the attack works numerically but does not convey impact. A request to remove a phase may reveal that it offers no meaningful decisions, lasts too long or requires repetitive operations. Applying the literal suggestion may address a symptom or remove a part that served an important purpose.
Turn comments into decisions
The practice is to record comments, observe behaviour during play and look for relationships between apparently different reactions. Slow turns, uncertainty about what to do and dislike of a resource phase may all come from the same missing information or a rule that adds no value.
The designer knows the system's dependencies and goals; the tester provides evidence of how it is actually experienced. Design work lies in bringing both perspectives together to identify the cause and evaluate solutions. Criticism stops being a personal judgement and becomes material for investigation.
Apply it to your game
- Record the comment, the situation in which it arose and the behaviour you observed separately. Do not turn the suggestion into a task yet.
- Look for recurring problems and propose alternative explanations: values, information, pacing or a lack of decisions. Compare them with what happened in the session.
- Choose a hypothesis and design a test with one specific change. Decide what to observe to tell whether it solves the problem without harming other parts of the game.
If an exception seems to be the problem, check which decisions that rule changes. To evaluate an explanation before producing it, design a prototype that answers a question.
The Shadow Strike case shows how to compare several solutions to an aiming problem and assess their effects on the stealth experience. Read the comparison of solutions in Shadow Strike.