This creates bias in your data. Focusing too heavily on community feedback risks encouraging groupthink, and deferring to a minority of very vocal players. We covered player definition further in Issue 1000 of MCV/Develop.
FOCUS ON BEHAVIOUR RATHER THAN OPINIONS Opinions are like huge Steam backlogs. Everyone has one. However in a creativity focused process, we’re less interested in external opinions, and instead want to see if our intent is being experienced correctly by players. The best way to achieve this is to design a playtest that focuses on player behaviour - i.e. what they are doing in the game, over self-reported data. Although playtests frequently deploy mixed methods approaches (e.g. observe gameplay, interview players, survey them), the trustworthiness of each type of data differs - and we should prioritise objective behavioural data over subjective opinions. For teams new to playtesting, I see that they often
get the most value from reasonably simple one-to- one moderated playtests - watching people play their game without interfering, and looking at how players act. These observations of player behaviour can be compared to how you expected players to act, identifying gaps and inspiring creative resolutions to address them.
ANALYSE WHY ISSUES OCCUR Another trap with self-reported data is to directly act on what players are telling you. For example, they might write in a survey that a particular character is OP, or a weapon should be nerfed. Players lack your context about the intended vision
for each feature, what’s feasible in production, and previous design decisions have been made. This means their suggestions will be naive - they are likely reflecting a real problem or experience that the players had, but their diagnosis of what to do about it will be impractical or cause unintended side-effects.. When you have identified gaps between your
intended experience and what you saw in your playtest, don’t just act on it immediately. Think about the context, why players said that comment, or behaved in
this way, and make a joint decision with your team about how to tackle the true root of the issue - rather than just the symptoms.
RESEARCH IS A TEAM SPORT The goal of any playtest is to inspire action. If you’re not a solo-dev, this means effective communication is essential. Reading a report about a playtest is rarely inspiring, and is easy to dismiss. Instead the ethos should be bringing decision makers as close to the process as possible. This can be as simple as live-streaming sessions, or inviting your team to view playtests behind a one way mirror. For more advanced teams the wider research process can
be made collaborative - for example defining the research objectives together, running a group analysis session, or workshops after a playtest to inspire action. Teams will pay more attention, and ‘grok’ their players better, the more exposed to the process they are. Creativity should be at the heart of your playtest
process, and properly run research will support design & development decisions, rather than replacing them.
Steve Bromley supports publishers and studios across
the UK & Europe to level up their playtesting process, and support games throughout development. Learn more, and get his guides to playtesting at
gamesuserresearch.com
August/September 2025 MCV/DEVELOP | 51
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
