Thinking About Games User Research — We’re Not So Different, You and I
This is Part 2 of my journey diving into games user research. You can read my previous series primer. Learning resources are listed at the end.
I’ll be blunt: games user research felt like a space I wasn’t sure I was allowed to occupy.
Some of that is the culture. There’s an unspoken credentialing that happens in conversations about games, which makes it easy to assume that a flaming passion for the medium is a must for working in it. So if you didn’t clock hundreds of hours or your play history has gaps, you start to wonder whether you’re allowed to do the work.
I sat with that doubt longer than was useful.
While reading through the Games User Research textbook and seeing the game development lifecycle laid out, something clicked. I was seeing the cycle as a sequence of questions: What does the team need to know here? What decisions are on the table? What should change if a player doesn’t get it? Working through it phase by phase. I had answered versions of these questions before. The context was unfamiliar. The craft wasn’t.
Real GUR nuances
Before diving into the overlap, it’s critical to emphasize the real, tangible differences between “traditional” user research and Games User Research.
Steve Bromley dives into them in his post, but I’ll recap them here:
Games are considered art. Creative vision behind games is explicit and deliberate. This forces researchers to shift focus from defining players’ experiences to evaluating whether real experiences match the intended goals.
Friction is not failure. Traditional UX hinges on minimizing users’ difficulties as much as possible. In games, it’s a critical facet of delivering an engaging experience. Researchers must be careful to differentiate between insights on users’ challenges that are accidental versus fun.
Methodology limits exist. Secrecy is critical in the games industry. This implies that not all methods of user research may be appropriate for GUR. Researchers then face the challenge of strategizing tactics which are both needed to address the team’s needs and actually feasible.
The Dev Lifecycle, With Research Mapped In
Game development is iterative and messy. Timelines can look tidy on paper, but shift under production pressure. If you’ve shipped any tech product, you know that squeeze, the one that quietly eats the time budgeted for research.
Below, for each stage of game development, I:
Summarize the research strategies set out in Steve’s course and the other learning resources listed below.
Pull in the traditional UXR lens and zero in on the real potential for transferability.
Ideation, The Pitch
At this point in game development, a small team is working out what the game wants to be. Concept, mechanics, tone, target audience. This is the stage where the game’s vision is defined before anyone budgets money against it.
If looped in, a skilled researcher here would be challenging assumptions baked into the premise. Do the target players actually connect with the idea the way the team imagines?
Familiar UXR techniques can help to bridge the gap, like interviews, low-fi prototyping, and card sorting. The goal here, like when operating in other product design teams, would be to test assumptions early to save resources and costs on pivoting later.
In some cases, there may be a need to explicitly define, and actually understand, who the target players are. This sounds basic, but like a lot of product visions, it can be skipped — so a user researcher can advocate for establishing a solid, shared understanding of the audience to shape scope and success.
The Link: This is discovery research by another name. Nielsen Norman Group describes the discovery phase as researching the problem space and framing the right problem before a team builds anything, and its whole value is aiming the work at the right target from the start.
For example, I ran this kind of pre-build discovery for a healthcare data product that didn’t exist yet, interviewing and surveying the people who’d depend on it before any design direction was locked.
Pre-Production
The team is building foundations. Core features, design direction, and the first rough version of what the game will actually be. This is when the “vertical slice” comes together, a small playable section meant to prove the concept is both feasible and entertaining.
Pre-production user research focuses on the early bits before they harden into design. In this part of the cycle, researchers can lean on prototype studies and usability observations to check whether the intended experience is landing while the builds are still rough enough to change.
A potential flag to raise would be an apparent mismatch between the team’s intentions behind a core mechanic and how players receive it. At this stage, the game is still early enough to catch easily changeable fixes, but fleshed out enough to introduce players to the gameplay.
The Link: The logic mirrors low-fidelity prototyping in traditional UX. NNG’s case for testing rough paper prototypes is that they surface usability problems for almost nothing, before money goes into building the wrong thing.
For example, I’ve run concept tests on early wireframes and prototypes to catch the gap between what a design assumes about users and what they actually need, while the direction is still cheap to change.
Production: Alpha, Beta, Gold
Steve mentions that this is the longest phase, it arrives in stages, and each phase is a different level of readiness.
At Alpha, the game is playable end-to-end but rough. Researchers can ask whether core mechanics are landing, whether players can orient themselves at the start, and whether difficulty is calibrated in the right direction.
At Beta, the content is fuller and more refined. Researchers can work on a larger scale to explore how players feel across the whole arc, not just at individual friction points. Insights can point to the emotional experience the team intended when actually showing up.
At Gold, the game is close to release. Researchers now catch what slipped through and check whether the experience holds up across different kinds of players.
Overall, a researcher deeply embedded in production processes, someone who can flag something while there’s still room to move, has a fundamentally different impact from that of someone who is shipping end-of-sprint reports.
The Link: An embedded researcher shapes what gets built, not just what gets reported. It’s the same argument for tying research to the product roadmap in traditional UX, where validated findings raise a team’s confidence in what to prioritize and reshape the requirements that reach developers.
For example, I ran a longitudinal benchmarking program measuring whether a redesign actually improved the experience, where the findings fed straight into what the team focused on next rather than landing as an after-the-fact report.
Launch and Post-Launch
Playtesting never represents 100% of users. There are chances that issues that survived playtesting unscathed get challenged in the wild. In the gaming industry, teams lean on early signals from community spaces, reviews, and behavioural data to figure out what to prioritize first.
Post-launch is its own sustained phase, especially for games that keep evolving after release. New DLCs need to be evaluated. Updates need tracking against how the player base receives them. Like any product, the question shifts from “Are we building the right thing?” to “Are we keeping people engaged?”
The Link: This is the familiar limit of any sample. Even a well-powered quantitative study can only represent so much of a real population, which is why traditional UX also keeps measuring after release instead of treating pre-launch testing as the final word.
For example, when I ran a national survey where no single sample could represent everyone, realistic sampling and a traceable validation trail were what let the team trust findings drawn from a messy, real-world pool.
What Connects All of This
Despite the real fundamental differences between developing a product and developing art, there are a few patterns that hold.
The clearest pattern is: the earlier research enters the process, the greater impact it can provide.
The Playtest Maturity Model dives into this premise further. The four levels of playtest practice range from studies that happen by accident and get loosely interpreted, up to research that works as a shared team discipline where player insight genuinely shapes what gets built. Bromley is honest about what that progression takes. It’s not a methods problem. It’s a culture problem. Higher maturity means changing how an entire organization makes decisions, and that’s far harder to teach in a workshop.
If that sounds familiar, it is. As Sara Fortier makes the same argument in Design Research Mastery, outside games entirely, user research influence isn’t a byproduct of good methodology — it’s a capability skilled researchers build on purpose.
My key takeaway: UXRs coming from other domains are not starting from zero. The vocabulary is different. The intent shifts. The tools are refined. But you are well-versed in advocating for a well-timed validation of assumptions that do not serve well for success, which is one critical thing you already know how to do.
Learning Resources
Games User Research edited by Anders Drachen, Pejman Mirzan-Babaei, and Lennart E. Nacke
Chapter 2 by Veronica Zammitto (EA)
Chapter 3 by David Tisserand (Ubisoft)
Chapter 4 by Ian Livingston (EA)
How to Be a Games User Researcher by Steve Bromley
Part 1 — How Games Get Made
Moving into games user research from other UX jobs by Steve Bromley