Game Playtesting for Indie Developers

The whole playtest loop, sized for a small team. Session 1 covers choosing a research question, recruiting the right players and deciding how many you need, picking between moderated and unmoderated tests, writing a plan and discussion guide, and running a session without leading players. Session 2 covers organizing what you saw, separating patterns from one-off opinions, prioritizing by severity, and turning findings into development decisions your team agrees on. In between, you spend an hour with Mariya on your own game.

Mariya’s free guide, how to playtest your game, gives you a minimum viable playtest you can run on your own, and it’s a good place to start. The course goes further in two ways. It covers what the guide only touches: recruiting and screening, choosing between methods, and the analysis and prioritization in Session 2. And it applies all of it to your game: you bring your plan, study or feedback to a one-on-one hour and leave with recommendations specific to your project.

Yes. Recruiting is where most small teams compromise, and it’s a core part of Session 1: identifying the players who match your research question, deciding how many you need, and writing screening questions that keep out testers who’d skew the results, such as other developers or superfans. Friends, family and your Discord still have a place, and the course covers what each group can and can’t tell you. You can bring recruitment questions to your office hour.

That’s what Session 2 is for. It covers organizing notes and recordings, telling one player’s opinion apart from a pattern across players, and ranking problems by how badly they damage the experience you’re designing. You also learn how to present findings to designers and developers so each one ends with an owner and a next step. Many teams join for this half.

Yes. A suggestion is usually a player’s guess at a fix for a problem they experienced, and the problem is the useful part: a player asking for stronger weapons may never have found the upgrade screen. Session 2 covers reading suggestions as evidence, avoiding the trap of building every request, and deciding what to fix, what to ignore and what to test next, so player feedback informs your design without taking it over.

Those channels give you access to players, and that’s valuable. What they don’t give you is a clear question, the right players for it, or a way to turn forty scattered comments into a decision. This course covers the parts around the build: what you’re trying to learn, who you need to learn it from, how to observe without biasing results, and how to analyze what comes back. It works with the tools you already have.

Yes. The course assumes no previous user research experience and was designed for developers, designers, producers and founders doing research because nobody else on the team can. If you’re already an experienced UX researcher moving into games, the games user research course goes deeper and will suit you better.

Two live sessions over two weeks, plus your one-hour consulting session. Outside class, the only work is preparing for your office hour, such as drafting a playtest plan or pulling together notes from a past test. Most participants can fit it around active development.

Yes. Both live sessions are recorded and shared with the cohort, and your consulting hour is booked at a time that suits you between sessions.