Describe what you were trying to do, what you expected and what actually happened. Explain why the difference mattered to your decision, then separate that observation from any suggested fix. Specific feedback gives another person something to investigate without requiring you to design the solution yourself.
“The combat feels wrong” can be an honest reaction. It is also a difficult place to start a conversation. Was the turn confusing, the outcome surprising, the pace slow or the decision uninteresting? Those problems can feel similar while needing quite different responses.
We like game discussions that get down to one concrete moment. Here is an invented example of how to make that moment useful, whether you are writing a forum post, answering a playtest question or comparing notes with a friend.
What details make tactical feedback useful?
Include the situation, your intended action and the result you observed. Add the version, mode, difficulty and relevant settings when you know them, because the same description can cover several different rule configurations.
Imagine a fictional turn-based game in which a unit has two actions. Moving to a nearby tile costs one action. Reloading costs the other. The interface highlights reachable tiles but does not show whether a reload will remain available after movement.
Now imagine choosing a farther tile that consumes both actions. The unit reaches it, but the reload button becomes unavailable. “Movement is broken” jumps past an important distinction: perhaps the movement rule worked exactly as designed, while its consequence was poorly communicated.
A more useful account would be: “I wanted to move and reload. I thought the highlighted destination cost one action, but moving there spent both. I could not find a cost preview before confirming the move.” This is a hypothetical report, not a fault we have observed in an existing game.
The worksheet keeps the player's experience separate from a proposed solution. It describes an invented interface example, not a completed playtest.
How do I separate an observation from a suggested fix?
State what happened before explaining what you think should change. Treat your proposed fix as one possible response, because the same symptom may have more than one cause.
In the example, “show the action cost beside the destination” is a suggestion. “I expected one action to remain” is the expectation. “Both actions were spent” is the observation. Keeping those apart helps a reader ask whether the cost was absent, easy to miss or explained somewhere the player had not looked.
You can absolutely offer a solution! Just leave room for another one that addresses the same difficulty. A clearer destination marker, a better preview or a more explicit rule explanation could each be worth considering. Automatically changing all movement to one action would also alter the tactical decisions, not merely clarify them.
| Part of the report | Invented example | Why it helps |
|---|---|---|
| Goal | Move and reload this turn | Explains the intended plan |
| Expectation | The move leaves one action | Reveals the player's understanding |
| Observation | The move spends both actions | Identifies the mismatch |
| Impact | Reloading is now unavailable | Explains why the mismatch matters |
| Suggestion | Preview the destination's cost | Offers a possible remedy |
Our time units and action points guide explores why a movement budget changes the plan. A feedback report can use that same precision without needing a long argument about which system is best.
How can I describe confusion while it is happening?
If the session allows it, say what you are looking for and what you expect before acting. Capture the uncertainty as well as the eventual answer; knowing a rule afterwards can make the original confusion harder to reconstruct.
Nielsen Norman Group's explanation of thinking-aloud testing describes participants verbalising their thoughts while using an interface. It also discusses limitations, including how prompting can influence behaviour. Applying that method to this tactical example is our interpretation, not evidence from a study of this imaginary game.
For instance, “I am checking whether this tile leaves a reload” says more than silently hovering over several icons. If you are observing someone else, avoid immediately explaining the rule you want them to discover. Ask a neutral question about what they expected, and record any help you gave rather than treating the result as unaided play.
What is the difference between a bug report and a design preference?
A bug report describes behaviour that appears inconsistent with an established rule or function. A design preference describes the experience you would enjoy more; feedback can contain both, but they need different evidence.
If a preview explicitly says one action and the move spends two, record the steps, starting state and result. A save or short capture may help someone reproduce the mismatch. If the preview correctly says two but you dislike that cost, explain what the rule prevents you from doing and why you would prefer another tradeoff.
Neither kind of feedback is automatically more legitimate. “I understood the rule and found the choice tedious” is useful information. It simply does not establish that the rule malfunctioned or that every player will feel the same way.
How should accessibility needs shape feedback?
Describe the barrier and the conditions in which it occurs, without assuming your experience represents everyone. Relevant context might include display size, input method or a cue that depends entirely on colour.
The Game Accessibility Guidelines recommend involving disabled players in playtesting because a general checklist cannot provide every game-specific insight. A single person's report can reveal a real barrier without measuring how common that barrier is.
“I could not distinguish the two movement ranges using their colours” is actionable even before anyone chooses a fix. Our note on readable isometric battlefields discusses how shapes and labels can help carry that information.
What should I include before sending feedback?
Keep the report focused on one moment, with enough detail for someone to understand or investigate it. Remove assumptions about the designer's intentions and label anything you could not verify.
- What was I trying to achieve?
- What information did I use to form my expectation?
- What action did I take, and what happened next?
- Why did that result affect my plan or enjoyment?
- Which settings or circumstances might matter?
- Is my suggested change clearly separate from the observation?
You do not need to write a technical specification to make a useful contribution. A clear account of one confusing turn can open a much better conversation than a confident verdict about the whole game.
Join the studio conversation on Discord to discuss games and the design choices behind them. When discussing a specific game, follow its feedback guidelines and mark spoilers.