Organising a playtest usually means navigating a series of conceptual and practical obstacles.
Conceptual
- Who should you ask?
- What exactly should they test?
- How should they provide feedback?
- How do you get the game build onto their devices?
- How do you collect feedback?
- How do you manage updates and timelines?
Test it yourself first
Before asking other people to spend their time testing your game, it’s always a good idea to test it properly yourself.The easiest way is to test the game locally. Pretty much any agentic coding tool can help set up your workstation so you can transfer your game to a device for testing.
For web products, you can run your own server locally and access the product through a browser. For mobile games, you can install debug builds on both iOS and Android devices using Xcode and ADB/Android Studio respectively.
If, for whatever reason, those options don’t work for you, on Android and Windows you can also simply sideload the application and run it directly on the device. macOS and even iOS support similar approaches too, although, rather predictably, they are more complicated.
So if your testers live nearby, you can potentially manage testing from the same workstation you used for development.
If, instead, you want to test with people remotely, you’ll need to set up App Store Connect and Google Play Console.
You’ll need those tools anyway if you ever want to distribute your game publicly. Setting them up takes a little while. First you need to create a developer account, pay your dues, submit various bits of evidence depending on your legal status, and only then can you start creating apps.
LLMs can help you work through the process if the native guides aren’t sufficient.
Finally, once your store account is up and running, you can start getting your game into other people’s hands.
All major store owners - Apple, Google, Steam, Microsoft - support some form of testing track. Using them is fairly straightforward, even though the exact steps differ from platform to platform.
In most cases, you collect the email addresses of your testers, add them to a testing group, and send them an invite or a link. That’s how they get access to the build.
When my game was ready for testing, I gave my testers a heads-up, created one test group called Family and Friends, and started sending out the build.
I immediately encountered the usual issues: someone didn’t get the invite, someone didn’t know where to find the build, someone wasn’t sure how to install it. Eventually I wrote a short set of instructions myself just to make it easier for everyone to get their hands on the game.
Gathering feedback
At an early stage of game development, the most useful feedback you can get is qualitative.You need to let people play your game and then talk to them about their experience. Observing people while they play is even better, especially if you can persuade testers to voice their thinking process as they go.
That’s basically what I did. I gave trusted people access to the build, waited a few days so they had enough time to play, and then had a half-hour conversation with each of them to hear their thoughts.
The feedback was very different between people who had experience with similar games and people who did not. Both perspectives gave me tons to think about and eventually led to a much better version of the game.
Another invaluable benefit of early alpha testing was discovering how the game looked and behaved on all the different devices my testers had.
Predictably, real devices behaved differently from emulators, and some things simply didn’t work.
I remember one especially embarrassing early build where, on Android, part of the game interface was covered by the top system icons and the camera cutout.
Asking testers to take screenshots or record short videos revealed a lot of device-specific problems that I then needed to address.
As for technical stability, app stores provide some basic statistics around crashes and usage. But don’t expect too much from them. Store data tends to cover the bare minimum: downloads, installs, uninstalls, crashes and similar metrics. Even getting something as simple as daily active users might require additional tooling.
So if you want detailed analytics or behavioural tracking inside your game, you’ll probably need a third-party tool.
I decided quite early that my game didn’t need in-depth analytics. It’s a simple game, and I wanted to keep it as small, offline and privacy-friendly as possible. So I decided not to track or store any data about my users.
Listening to feedback vs trusting your taste
Testing your game is both exciting and daunting.What if no one gets it?
How do I get their honest thoughts?
Who am I kidding thinking I can make a game?
These and many other doubts start flooding your brain when you put your work out there.
Even if “out there” only means your friends and family.
And friends and family are a tricky test group. Unlike strangers, who have no particular reason to be nice to you, people close to you might want to encourage you, protect your feelings and provide more positive feedback than your product actually deserves at that stage.
As a product manager, I already knew a little about how to approach this kind of testing.
A while ago, I read a fantastic book called The Mom Test, and since then I’ve been using concepts from it in my professional work with great success.
This experience became especially relevant because now I needed to execute the actual Mom Test.
My mum was my first and most important tester. It was for her that I made the game in the first place, so her opinion mattered enormously to me.
Luckily, she has never had much trouble giving me honest feedback.
No, she’s never harsh. Her usual attitude is more along the lines of: “Can’t it be better? Can you do more?”
And that is exactly what you want to hear from your first testers: some excitement, some investment, some criticism, but most importantly, an ask to do more.
Usually, that’s a good sign that you have a genuine product on your hands that is worth continuing to build.
What you don’t want to hear is silence.
In a business context, silence from testers is a powerful insight in itself. It often hints at a lack of value, poor UX or simply indifference.
But with your close ones, you probably won’t hear silence. Well, if you do, I’d reconsider your choice of friends.
Your family and friends will respond because you asked them to.
So what they actually say matters much more.
A generic “good job”, even if followed by a heart emoji, is a sign of politeness, but it might be bad news for your product.
A concrete question, a passionate opinion, an argument about one of your decisions or an act of sharing the game with someone else is a much stronger signal that the product resonated.
Either way, initial feedback, good or bad, is rarely a reason to stop working on making the product better.
I also got a mixture of feedback from the first playtest of my game. Some of it I implemented immediately. Some of it morphed into something else over time. Other feedback I disregarded completely.
How did I choose between them?
By trying to separate genuine problems from personal taste.
For example, several of my early testers independently asked me the same question about one of the game’s main concepts. That made me realise the problem wasn’t with them: it was with the game. I needed to improve the first-time experience and the How to Play content.
In another instance, I was told that the main tune I chose for the game was annoying.
That one I ignored.
I happen to like the tune, and music is a very personal thing.
Your taste matters
Especially with highly opinionated, creative products such as video games, your taste as a creator matters.You can, of course, read every guide, run thousands of tests and optimise your interface into oblivion. But at some point you need to ask yourself: what are you actually trying to achieve?
There is no “one perfect game”, just as there is no one perfect movie or one perfect book.
People choose art that resonates with them. And as a creator, you are much more likely to make something distinctive if you harness your own style rather than constantly trying to follow trends or satisfy everyone.
Of course, this is much easier as a solo creator.
It’s just you and your taste.
Once you create as part of a team, and especially inside a bigger organisation, things become much more complicated.
It wouldn’t be an exaggeration to say that an enormous amount of time and effort inside companies is spent aligning the personal tastes and preferences of the individuals and groups involved.
Engineering vs design.
Product vs sales.
Legal vs everyone.
Each brings its own perspective, experience and taste.
In the best case, this produces a much better product because those different skills and perspectives combine successfully. Normally, someone still needs to act as a referee and make the final call: sometimes beneficially, sometimes detrimentally.
The worst case is decision paralysis or design by committee.
That’s how some of the worst products out there get made.
So if you find yourself in the unusual position of being a solo creator, use your personal taste to shape the product.
It might work. It might not.
Either way, it will be yours and yours alone.