When players call a level too hard, changing enemy health may solve the wrong problem. The obstacle could be unclear information, demanding controls, an unfamiliar rule, or an expensive retry. Build a playtest that distinguishes those possibilities. Consider a small action game where the third arena introduces a shielded enemy and suddenly produces repeated failures. The useful question is what players cannot understand or execute in that arena.
/01
Describe the obstacle as a sequence
Break the encounter into player decisions and required actions: notice the shield, wait for an opening, move into range, attack, and recover. Mark where failures occur and what feedback the game provides. Separate being unable to identify an opening from being unable to reach it in time. Those observations point toward different changes, even when both produce the same defeat screen.
Microsoft's difficulty guidance recognizes that different gameplay demands affect players differently and that configurable options can reduce specific barriers. Use that distinction in your plan. Record the settings, input device, and relevant player experience for each session. Avoid treating a single standard difficulty label as a complete description of the challenge or interpreting an accessibility setting as a failed test.
/02
Hold the test context steady
Create a repeatable entry point with the same equipment, health, and enemy configuration. Preserve a route through the preceding arena when learning transfer is part of the question. Starting directly at the shielded enemy may hide a missing explanation that normally should occur earlier. State whether the test concerns first exposure, learning across retries, or mastery after practice.
Write a brief observation sheet before recruiting participants. Record recognized cues, attempted actions, failure cause, assistance requested, and time spent returning to meaningful play. Let participants describe their expectation after an attempt without suggesting the answer. If a bug or performance hitch interrupts the session, classify it separately; an inconsistent simulation can imitate a difficulty problem and invalidate the comparison.
/03
Compare variants that test a specific cause
Choose one hypothesis and one bounded change. If players attack without recognizing the shield state, compare the existing cue with a clearer cue while preserving attack timings. If they recognize the opening but cannot respond, compare a wider response window. If they learn successfully but dislike repeating earlier content, test the checkpoint or restart path. Keep these as separate experiments.
Decide how to handle order effects. A participant who already learned the enemy cannot provide a fresh first-exposure comparison for the second version. Use new participants for that question or explicitly evaluate experienced play instead. Keep the candidate values and build revisions with the notes. An observed preference for one version is useful feedback, but it is not automatic proof that its difficulty is appropriate for everyone.
/04
Judge learning and recovery alongside completion
Write acceptance criteria tied to the intended experience. For the shielded enemy, a useful target might be that a new player can explain the opening after observing it and deliberately attempt the correct response without coaching. Then check whether execution succeeds under the intended settings and whether failure gives another understandable opportunity. Select numerical targets with the team before testing rather than inventing them from a convenient result.
Review the distribution of causes across sessions instead of reducing everything to an average completion time. Keep a difficult but understood challenge distinct from an unexplained failure. Verify that the chosen change does not trivialize later encounters, break assistance options, or create a new exploit. The handoff should name the chosen adjustment, the supporting observations, the remaining uncertainty, and the exact follow-up encounter to test.
Keep this in mind
Key takeaways
- Separate comprehension, execution, and retry cost before changing difficulty values.
- Use repeatable entry states and controlled variants matched to one hypothesis.
- Judge learning and recovery with completion, and state the limits of a small playtest.
Sources & further reading
Consult the source documentation for the version and platform you are working with.