Games user research is a popular career for people post academia, or looking to move from another UX field into an area they feel passionate about. But the industry is so secretive – it can be hard to discover what the job is really like, and what to expect from a career in games.

I want to demystify that.

In this post I’ll go through what the role of a games user researcher is really like – what you’ll spend your days doing, and why people love working in games. 

This is my own experience

I’ve always worked as an external researcher for teams – both while I was working at a publisher, and as a consultant. This means my experience of moving focus across multiple projects will be different to someone who is embedded within a single team and spends years working on a single title. 

Also this isn’t really a ‘day in the life’. Preparing, running and analysing a study might often be two or three weeks – so we’ll look at what the complete lifecycle of one playtest or study looks like. 

Games User Researchers Run Studies to inform game design decisions

A game is made up of a lot of decisions. This extract from The Door Problem, an essay by Liz England, summarises just a few of the decisions a designer has to make for something that feels as simple as introducing Doors into your game.

I like to describe my job in terms of “The Door Problem”.

Premise: You are making a game.

• Are there doors in your game?
• Can the player open them?
• Can the player open every door in the game?
• Or are some doors for decoration?
• How does the player know the difference?
• Are doors you can open green and ones you can’t red? Is there trash piled up in front of doors you can’t use? Did you just remove the doorknobs and call it a day?
• Can doors be locked and unlocked?
• What tells a player a door is locked and will open, as opposed to a door that they will never open?
• Does a player know how to unlock a door? Do they need a key? To hack a console? To solve a puzzle? To wait until a story moment passes?

Liz England, The Door Problem (many more examples are in the full article)

Game designers are making decisions every day about how games should work, how to communicate information to players, and how to convey their creative vision to players. Many of those decisions are made by intuition. However, some teams value data to inform and inspire their decisions – which is where we step in.

We run studies.

Those studies typically look to identify how players behave, or what they do. This information allows game developers to iterate their game before launch, and increases the chance that the game they release matches the vision in their head.

So what does a study look like?

Good studies start with context and understanding team needs

Some of the common topics that game teams want to explore include:

• Appeal (do people like this?)
• Usability (will players understand this)
• Balance (is this too easy/too hard)
• Retention (will we lose players?)

Before diving into planning a study, first I’m looking for context. 

I need to know ‘what decisions are the development team making’, ‘what are the team’s priorities’, and ‘what are the team worried about’. By understanding this, I can make sensible recommendations about when and how to run a user research study.

This ends up being a bunch of meetings. I’ll spend time with the relevant leads (often producers, or game designers) and learn as much as I can about the current state of the game and the team.

Context can also be gathered from other routes. Reading previous research reports, reading the documentation the team have created about their game – everything available to bring me up to speed and make sure I can plan a sensible, relevant and credible study.

All of this usually ends in a more formal kick-off meeting, where we agree on:

• What do we want to learn from a study
• An outline for the methods I’ll use, and how the study will be run.
• When will the study occur
• Who are the participants for the user research study
• Who needs to know the results

With this, I get started preparing the study.

Defining and preparing a study

Recruiting participants can often be the slowest part of the process. Depending on where you’re getting players from, it can take over a week to book them in for a study. This means it’s probably the most time-pressing thing to do first. 

In order to book players for the right time (and decide whether we’ll need them in person, or to join a video call), I’ll need to make some decisions about what the study will look like. This usually starts with playing a recent version of the game (‘the build’), and understanding the state of the game. Sometimes it will be lacking tutorials or sections of gameplay, and this will influence what we decide to do in the playtest. 

After playing the game, I’ll then finalise my decision about recruiting players – deciding how many we want, when we want them, and what we want to tell them in advance. I’m lucky that I often work with external recruiters or recruitment panels – so I just need to give them a definition of the type of player I want (‘a screener’), and they handle the recruitment and scheduling. 

So, participants are ordered -the next priority is to prepare everything we’ll need for the test. Depending on the exact playtest method, this can include writing some tasks (that I’ll be setting the players), creating questionnaires, and designing the flow of the session. This becomes a ‘discussion guide’ that I will take with me when talking to players.

There is also technical preparation required for the playtest. This includes getting the final version of the game we’ll be using for the playtest (and checking it works – there are often problems!). User research sessions often capture data through multiple methods – including telemetry built into the game, recording their screen and interview, and capturing survey data. I need to set up the technology for all of those so that it’ll work on the day! 

This preparation should end with a pilot test – a practice session with a single participant to check that everything works as expected, we’re collecting the right data, and that we’re ready for the real test. 

Moderate a study with players

Many user research studies involve a moderator being live in a room with players. I love this bit of the process, as it usually involves a degree of improvisation to react to player behaviour. 

At the start of every session, I use the discussion guide to explain what we’ll be doing to players, since they are likely uncertain about what’s expected of them – putting players at ease will help create more natural behaviour (and we want players to act naturally!). 

Moderation then involves watching the player perform some tasks (like “play through this level” or “upgrade your character”), and jumping in with questions where required. I’ll be keeping the study objectives in mind when watching players, to inspire questions I might want to ask. I’ll also be being quiet – I don’t want to introduce any information artificially into the playtest that the players wouldn’t have at home, to avoid impacting the quality of the data we’re collecting.

The discussion guide will inspire the tasks and questions, but there should also be a degree of reacting to what players are telling you, or what you’re seeing, to probe deeper. This semi-structured format is one of the greatest strengths of moderated research as a method. 

It’s hard to take notes while being a good moderator, so I’ll record the session and take proper notes after (or ask someone else to take notes for me!).

The number of players depends on our objectives and methods, but for a typical one-to-one study it’s likely I’ll be seeing at least 6-8 players, spread across multiple days. 

Analyse the data to draw conclusions

Studies generate a lot of data, in many different formats. This can include observations, interview notes, survey responses, telemetry from the game, and more. 

I need to make sense of this and draw conclusions about ‘what did we learn’. This can include a lot of time spent in whiteboard or mind-mapping tools to theme the data, reviewing the research objectives, and coming to conclusions. 

It’s typical for playtests to uncover a lot of issues, which then need to be prioritised – game developers already have a lot of demands on their time, and won’t be able to react to everything. By anticipating what the most impactful issues will be for players, we can help game developers spend their limited time wisely. 

Share what was learned and help game developers take action

I’m not sure about trees and forests, but I know that without good communication, our user research studies won’t make a sound.

My job is to help games get better, but I don’t programme or design anything myself, so I need to make sure game developers understand the conclusions from the study.

This often involves making and giving a presentation, to share the conclusions with the game team. It can also include creating different kinds of reports for different audiences, or running workshops with game developers to help them decide what to change after the test. There’s an example report, and some tips from other games user researchers on best practice, in this article. 

Then the cycle starts again. I’ll keep an eye on what the team are up to, see when they are ready to test again, and start planning the next study.

Why do people love this job?

I love user research, especially in the games industry.

First of all – you spend a lot of time understanding people. Interviews with players about their habits and behaviour is a rich, fascinating topic. If you like understanding how people think and make decisions, time spent interviewing players is always valuable.

Making games people love is also great – in the games industry we’re lucky to have extremely enthusiastic fanbases, and there’s a great atmosphere when players are coming to play a game from a series they genuinely love. I worked on the Karaoke game series SingStar, and moderating a group of four players attempting to sing Bohemian Rhapsody is an experience not offered by other industries.

And I like the permanence of game development – you’ve created something new. When on a game team, it ends with your name in the credits, and I find that infinitely interesting to think that it’ll be there forever (you might also be interested to read about how Cole Davis got his first game credit before joining the games industry!).

If you’re looking for a fulfilling career that combines scientific methods with game development, I recommend becoming a games user researcher.