Every user research method answers some questions well and others badly. A usability study can show you where players get lost in a menu, and it cannot tell you whether they will still be playing in a month. A survey can tell you what 2,000 players think of an event, but not the moment they stopped enjoying it.

This guide is organized by question. For each of eight methods it gives the question the method answers, when to use it, the sample it needs, the evidence it produces, and its main limitation. The methods are the ones game teams use most: usability studies, concept tests, FTUE playtests, longitudinal studies, surveys, interviews, diary studies, and telemetry analysis.

For a wider introduction to the discipline, see game user research: what it is and what teams use it for.

Start with the question

If you know what you need to find out, this table points to the method most likely to answer it.

Usability study

The question it answers: Can players understand and use this part of the game?

A usability study gives participants a specific task, such as equipping an item, finding the daily reward, or joining a guild, and records whether and how they complete it. It looks at the interface and the flow: menus, buttons, icons, screen order, and wording.

When to use it: When a feature or screen is built enough to interact with, and you want to know whether players can use it without help. Usability studies work on prototypes and wireframes as well as finished builds, so they suit any point from early production to a live game's next update.

Sample: Five participants per round, per distinct player group. Jakob Nielsen and Tom Landauer's model found that five participants surface about 85% of usability problems. Nielsen Norman Group recommends running three rounds of five, fixing problems between rounds, over one round of 15. How many playtesters do you need? covers the reasoning.

Evidence produced: Task success or failure, time on task, the path participants took, where they hesitated, and what they said while doing it.

Limitation: A usability study tests whether players can do something, often after being asked to. It says little about whether they would do it on their own, or whether they enjoyed it. A game also needs some things to be hard, and a usability study is built to find difficulty and flag it, so its findings need judgment about which difficulty was intended.

Concept test

The question it answers: Do players find this idea appealing enough to be worth building?

A concept test shows players an idea before it is built: a pitch, key art, a short video, a mock store page, or a rough prototype. It measures interest, understanding, and appeal.

When to use it: Before production on a new game, mode, feature, or theme. It is the cheapest point to change direction.

Sample: For qualitative reactions, five to eight participants per audience segment. To compare two or more concepts and trust the difference, you need a quantitative sample, usually 40 or more per concept.

Evidence produced: Stated appeal and intent, the words players use to describe the concept, what they think it is, and how it compares with alternatives.

Limitation: Players react to a description or an image, and a game is experienced through play. Some concepts that sound dull play well, and some that sound exciting fall flat in the hand. Concept tests are best at catching ideas that confuse people or that the target audience does not care about.

FTUE playtest

The question it answers: What happens to new players in their first session, and why do some of them leave?

An FTUE (first-time user experience) playtest puts the game in front of players who have never seen it and records the first five to 15 minutes. It usually uses free play, with no tasks, so the researcher can see what a real new player would do.

When to use it: Before soft launch, before a major tutorial rework, or when analytics show early drop-off that the team cannot explain. FTUE: what the first-time user experience means in games covers this window in detail.

Sample: Six to eight participants per player segment is a common range. The aim is to see the same friction point repeat independently across sessions. If four of six participants stall at the same screen, that is a pattern.

Evidence produced: A session-by-session record of where players hesitated, failed, disengaged, or lit up. At Emhance, we add a second-by-second measure of emotional intensity and concentration from each participant's webcam, which shows where engagement dropped and what was on screen when it did. See how Emhance playtesting works.

Our Beginner's Guide to FTUE Playtesting walks through a first FTUE study step by step.

Limitation: An FTUE playtest covers one session. It cannot show whether a player who enjoyed the first 15 minutes will return on Day 7.

Longitudinal study

The question it answers: How does the experience change over days or weeks of play?

A longitudinal study follows the same participants across several sessions over a longer period. It might run a playtest on Day 1, Day 3, and Day 7, or check in weekly for a month.

When to use it: For progression systems, economies, social features, and live events, which only show their shape after repeat play. Also when you suspect the game is fun at first and wears thin, or slow to start and better later.

Sample: Usually eight to 15 participants, recruited with some margin, because participants drop out between sessions. The study needs enough people left at the end to see a pattern.

Evidence produced: Change over time: what players returned for, what they stopped doing, where their understanding of the game deepened, and where interest fell away.

Limitation: Cost and time, since the study runs as long as the period it covers. Participants also know they are in a study, which can keep them playing longer than they would on their own.

Survey

The question it answers: How many players think or feel a certain way?

A survey asks a set of fixed questions, usually with rating scales and a few open-text fields, to a large group. In games, surveys run in-game, by email, or as part of a playtest.

When to use it: When you need to measure how widespread an opinion is, compare segments, or track a number over time, such as satisfaction after each season.

Sample: Nielsen Norman Group recommends 40 participants as a floor for quantitative studies. Surveys of a live player base often reach hundreds or thousands, which lets you compare segments such as payers and non-payers.

Evidence produced: Numbers and distributions, plus open-text answers that can be grouped by theme.

Limitation: A survey records what players say, after the fact. Answers are shaped by memory, by how the question is worded, and by who chooses to respond. Players who stopped playing are the least likely to answer an in-game survey. When we compare what we measure during play with what participants say afterward, 50% of in-game emotional responses never come up in surveys or interviews. Playtest questions that produce answers you can act on covers question wording and scales.

Interview

The question it answers: Why do players think, feel, or behave the way they do?

An interview is a one-to-one conversation with a player, usually 30 to 60 minutes, following a loose script. It is often paired with a playtest, as a short conversation before play and a debrief after it.

When to use it: When you need to understand motivation, context, or reasoning: why players chose one class over another, why they stopped playing a competitor, what they hope to get from a game in your genre.

Sample: There is no fixed number. Researchers usually keep interviewing until new interviews stop producing new themes, which for a single player segment often happens within five to 10 conversations.

Evidence produced: Rich verbal accounts, quotes, and themes.

Limitation: Interviews record what players can put into words. People are often poor at explaining their own behavior, and they tend to give reasons that sound sensible. An interview with a player about a session that ended a week earlier mostly measures what they remember of it.

Diary study

The question it answers: How does play fit into players' everyday lives over time?

A diary study asks participants to record short entries over a period, usually one to four weeks. Entries might be a written note, a voice memo, or a screenshot after each session, answering a few set prompts.

When to use it: When context matters: when and where people play, what pulls them back, what interrupts them, how a game competes with others on their phone. Diary studies suit live games and long-term retention questions.

Sample: Often 10 to 15 participants, with extra recruited to cover drop-out.

Evidence produced: A timeline of each participant's experience in their own words, captured close to the moment.

Limitation: Diaries depend on participants keeping them. Entries get shorter as the study goes on, and some participants drop out. Like every self-report method, a diary records what participants notice and choose to write down.

Telemetry analysis

The question it answers: What are players doing in the game, how many of them, and where?

Telemetry is the event data a game logs as people play: sessions, level starts and completions, purchases, deaths, menu opens. Analysis turns it into funnels, retention curves, heatmaps, and cohort comparisons.

When to use it: All the time, once a game has players. Telemetry is the first place to look when something changes, and it tells you where to point every other method.

Sample: Your whole player base, or any segment of it.

Evidence produced: Precise counts and locations: how many players reached level 5, where they stopped, how long they played, what they bought.

Limitation: Telemetry shows what happened and where. It does not show why. In our Merge Mansion study, the event log recorded idle time the same way whether a player was planning a move or stuck. Analytics or playtesting for Day-1 churn? shows those two players side by side.

All eight methods at a glance

Combining methods

The strongest studies pair a method that finds where something happens with one that explains it. Telemetry with an FTUE playtest is the most common pairing in mobile games: analytics shows that players leave before level 3, and a playtest shows what they experienced in the minutes before they left.

Peaksel used that pairing on The Vault. Analytics showed players dropping off before level 3. The playtest, with six players, found that the tutorial trained them on a single vault face, and the live game then asked them to work across several faces at once. Engagement fell within 45 seconds of live play. After Peaksel redesigned levels 1 to 3, 9.6% more users completed level 3. The Peaksel case study covers both halves of that pairing.

Emhance runs FTUE and usability playtests remotely, on participants' own devices, with second-by-second engagement data alongside interviews. Book a demo to see a study on your own game.