OVERCOMING THE FEAR OF PLAYTESTING
Steve Bromley reminds us that, when it comes to playtesting and user
research, the only thing we have to fear is fear itself
P
laytesting and user research can be an emotionally difficult process. Putting your ideas in front of players to ‘receive judgement’ requires a level of open-ness which can be a
difficult to reach in chaotic development environments. Despite this, much like visiting the dentist, teams understand
that they should playtest regularly; the pain of putting it off will only create much bigger problems later on. In this article I wanted to focus on some of the common fears that teams experience and give some guidance on how to help your team overcome them.
FEAR: PLAYTESTING MEANS GIVING UP CREATIVE CONTROL Games represent creative decisions, which can include ideas that players might not immediately agree with (such as high difficulty, or delaying the reveal of narrative beats). When running a playtest teams can worry that players will not understand the design intent and demand that the game is simplified and friction removed. The answer lies in turning the design intent into testable
hypotheses. For each important element being tested, have a discussion internally to decide what player behaviour is expected, and which player data would be a warning sign that this feature isn’t working as intended. Use these criteria to inform whether the feature is working, not just players stated opinions. Where possible observation-based data is safer than opinions to base decisions on. In my experience, even without clear hypotheses, this fear is
often unfounded. Properly recruited players (who are experienced players in your genre) understand the genre conventions and won’t be trying to ruin the game.
52 | MCV/DEVELOP May/June 2026 In all playtests, players will give you opinions. They can’t help
it. But that doesn’t mean you have to listen to them. Defining your expected behaviour before-hand will help avoid giving up creative control to players.
FEAR: THE GAME ISN’T READY YET. Spoiler - it never will be ready. By the time the game is in a state that everyone is happy represents the final experience, everything will be too locked down, and it’ll be impossible to make the changes required when you find problems. Instead, we need to work out where the gap is between
“something that represents the design intent is ready” and “it’s too late to make changes”. This will be different for every feature or aspect of the game. In a research roadmapping session we’d typically go through each of the highest risk features with a team to identify when is the right time to act - planning each test around addressing one of the biggest risks to the game’s success. Running multiple, smaller, tests is usually more successful than
one big test, allowing you to identify issues when there’s still time to fix it.
FEAR: PLAYTESTS WILL SLOW THINGS DOWN, AND DISRUPT PRODUCTION Playtests will throw up unexpected results and create new priorities for the team. Excellent coordination with production is essential to make sure that this is built into the schedule, and that playtests are aligned with ‘when can we act on what we learn’. Again, intentionally roadmapping your playtests can help with this.
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56
