Teams often say “we should playtest this” – but mean completely different things.
Sometimes it means QA. Sometimes it means watching a few friends play. Sometimes it means a structured test with external players.
Everyone agrees it’s important. But they’re not talking about the same thing.
One of the hardest problems in game development is team alignment – and a lack of shared language makes that even more confusing. When talking with fellow developers, it quickly becomes clear that whether we’re talking about ‘MVP’, or ‘feedback’, not everyone has the same understanding of what the words we’re using means. This is especially true for playtesting.
Not having a shared understanding of what playtesting is creates confusion, and teams don’t realise they are describing different processes, with different aims. Everyone is usually in favour of the idea of ‘playtesting’, but with a different idea of what that means.
Some common definitions of playtesting
When talking to teams, I commonly see three different definitions for what they mean by playtesting.
Internal play (“we played it ourselves”) – any activity that involves playing a build is playtesting. That can include QA (looking for bugs), or when developers are playing their own game to see how it feels. This definition is common in hobbyist or early career developer communities, from teams who haven’t seen that stuctured research with players is possible.
External exposure (“we showed it to players”) – any activity that involves exposing external players to the game to capture data on their experience.
An appeal-focused method (“we ran a multi-seat test”) – a specific playtest method, usually focused on seeing a lot of players at the same time play the game, and usually focused on getting opinion/appeal feedback. This is often run as a multi-seat playtest.
My definition of playtesting
I most commonly use the middle definition – playtesting is any activity that exposes players to gameplay in order to gather data. This is method agnostic (e.g. it could be observing people play, or could be gathering data from surveys), but the important part is that it’s players – not you or your team.
As you’ll see when working on games, there are varying degrees of quality of playtesting – different research methods generate different types and quality of data, and have an impact on how useful the findings are (the playtest maturity model intends to help teams recognise and address this). But even bad playtesting counts as playtesting.
One of the distinctions I try and introduce when working with teams is introducing the practice of games user research – taking the shape of playtesting (put players in front of the game), and professionalising it – improving the quality of each individual part, such as audience definition, method selection, data collection, and how this gets communicated to the development team.
It’s common that some developers will have had bad experiences with playtesting not being useful (which can usually be traced back to poor playtest recruitment, vague goals, ‘convenient’ methods and no clear way of inspiring action). With games user research we’re trying to address those concerns through better playtest design and delivery, to de-risk development & production decisions.
Make sure you’re speaking the same language
Recognising that you have a different idea of what playtesting is can help prevent expensive or time consuming misunderstandings later on. To avoid this kind of confusion, there are some simple things you can do in practice:
1. Define what you mean by playtesting up-front.
Don’t assume shared understanding. When talking about playtesting, be explicit about:
- What are the players?
- What are you trying to learn?
- What kind of data are you expecting?
Even a short definition can help avoid misunderstanding later.
2. Distinguish between different play activities, and their goals
Don’t treat all ‘playing’ activities as interchangeable. QA and finding bugs is a very different activity to discovering usability issues from players. Define internally a name for each activity you are doing, and distinguish between QA, playing your own build, and getting players involved.
Ultimately our purpose when exposing real players to the game (my definition of playtesting) is to help inspire confident decisions from the wider team – and having a shared definition of what playtesting is will help have meaningful conversations about how to achieve that.
