‘Dopamine Simply Doesn’t Work Like That’: An Interview With A User Experience Researcher – Aftermath

After a short hiatus, we are back this week with a fresh entry in our What I Do series, a collection of blogs explaining just what, exactly, individuals working in the video game industry do every day.

There’s nothing I love more for this feature than getting deeply specific, so it’s with great pleasure today that I introduce Ben Taels, who has spent a big chunk of his career working as a User Experience Researcher at places like Epic Games. And if you think that involves focus-testing or experiments in dopamine release, Ben is here to share his experiences and dispel some myths.

Luke Plunkett: Hey Ben, thanks for taking the time out to chat with us! Tell us all about yourself.

Ben Taels: I am from a small town in New Zealand and my first contact with video games was when my dad borrowed a Sinclair computer from a friend. It had this plane game on it (that you had to manually program in) where you had to clean, via dropping bombs, a landing field before your plane reached the bottom of the screen. When I say plane I mean single pixel moving from left to right and then right to left. It was really, really hard, but also amazing. I then had an Atari, an Amiga, and then a Mac. I didn’t want the Mac, because I wanted to play DOOM! Luckily I found Marathon (by Bungie) and then all was well. In fact, l would go on to be the game reviewer for New Zealand’s best (only) Mac publication, MacGuide Magazine. 

When I wasn’t playing video games or TTRPGs I was really interested in biology and animal behaviour. As such, I enrolled in an animal behaviour course at university and even worked for a year as a zoo keeper at a local zoo. The course was jointly taught by the biology and psychology departments and via the psych department I was also exposed to the idea of “human factors psychology”, which is a branch of psychology that studies technology and humans and as a principle believes that technology should be made for humans and the capabilities of humans. That is to say that people shouldn’t have to suffer or struggle because of technology asking them to do things humans aren’t physically or cognitively good at. Human factors also acknowledges that behaviour is systemic and arises from a web of interactions. Therefore the designers and owners (governments, businesses, etc) of those systems have the biggest responsibility for the outcomes of those systems.

Human factors psychology really spoke to me. There are so many systems out there that don’t seem to care about the people interacting with them at all, and that should change. So I did a master’s in human factors, focused on road safety. Then after some time working for the NZ government as a road safety scientist I discovered that games UX research existed within the games industry! It was a pretty new field back then and the most prominent lab was at Microsoft. So I wrote them a message and they very kindly replied, put me through an interview loop, and then let me know, amongst other things, that really I needed a PhD (no longer the case, but the field was newer back then). I had always wanted one of those, so I headed off to the Netherlands, got a PhD, and more importantly also was lucky to find my partner while in Europe! 

My PhD in human factors psych was also focused on traffic safety, but I always kept an eye on the games UX research world and taught some courses about UXR to game design students at a local university in the Netherlands. I also gave some talks at GDC EU. I was then lucky enough to get my first role as a Games UX Researcher and entered the games industry around 12 years ago. 

LP: So you’ve worked in the same space for over a decade, what was the last job title you had?

BT: My first role was as a Games UX Researcher at a consultancy in the UK called Player Research. We worked mainly with indies and mobile game companies, and in the two and a half years I was there I worked on around 75 games.

I then moved on to Epic Games in the USA, around nine years ago. I started as a Researcher, but then moved into management of the UX Research team. My move to leadership happened a little while before Fortnite Battle Royale came out, and most recently my title was Director, User Experience Research. 

I left Epic a few months ago to move back to NZ for lifestyle and family reasons. 

LP: Across both your user experience roles, both as a researcher and managing a team, what did your job actually involve? Like, on both a daily basis and a more long-term basis?

BT: As Director, User Experience Research, I viewed my main role as making sure my team was happy, healthy, having fun (we work on games so fun should be part of the work environment!), and had what they needed to do their job. Effectively as the top level of the UXR team system my role was to design it as a positive place to be. This also included knowing what the priorities were, where the work is most needed, and advocating for games user experience research and my team. 

To talk more broadly about what games user experience research can do, I see it as typically having four main functions: 

UX research with external players: There are a range of methods that can be deployed here, but the most important and valuable is running observational UX tests with external players and users. The primary goal of this is to put real, representative, players/users into contact with the in-development games and products to observe and research what happens. These players are not familiar with the game and therefore better represent the behaviours of the player population. Another aspect of this can be checking to help make sure the game is accessible for a range of players e.g., looking at things like is the UI colour blind friendly? Are simulation sickness triggers minimized? etc.

Competitive and UX analysis: This is where UX researchers use their training and education to examine a game or product for what makes it work and what may be issues. This can be a full description of a single game or looking at a particular mechanic or system (for example crafting systems) across multiple games.

Internal playtesting: Setting up, running, and collecting and sharing data on the results of internal (employee) playtests. This can also include being involved in the technical side of making sure in-development builds are ready and working. The goals of internal playtests are to let developers play/use and provide feedback on games and products being developed at the company. This is important as it lets teams experience what they and others have been working on and fosters a feedback culture. At some companies this function is owned by QA, and at others by UXR. 

Survey research: Creating, sending, and analyzing surveys. Surveys can be sent via email (to people who opted in) and/or built directly into games (for example has Fortnite Battle Royale ever asked you how powerful you thought bananas were?). The goals of this function is to find out how players were feeling and thinking via representative surveys. In the banana example, by having players rate the banana, alongside also collecting ratings for, say, the Kamehameha, it can give comparison points and context for the data. 

Across the functions above, ultimately, the goal of user experience research is to be a partner to other devs and help them make sure their design intent/vision is reaching the players/users. So for example, is a new game mechanic clear? Can players use it the way the designer intends? Is it too easy to use? Then once it is out, is it being received and interacted with as intended?

One example of a UX test finding from during my consulting days was a game where at a certain point you had to “press tab”. I watched a player in a lab not press tab over and over and then went to talk to them. At that point they told me they had seen the instruction, but couldn’t see a tab (as in a tab in a browser) anywhere in the UI to press. Which was an important lesson in how mental models can differ, particularly in a world where often the “tab” button on keyboards may not be labeled and its use is relatively rare. 

Another way to look at it is that the goal of user experience research is to use the scientific method and what is known about how psychology and physiology to:

– Help make sure the intended game/product design is being experienced. Including that the friction/difficulty the designers want is being achieved.

– Help make sure any unintended friction that gets in the way of, or blocks, the intended design is found and addressed.

– Finally to help find any unexpected/emergent experiences that may not have been fully intended, but are awesome. 

Then we use the above data to help inform design. I do want to flag the use of “inform” there as very intentional vs the idea of “data driven” design. I have found that data is a poor driver, as it is often short sighted, lacks context, and is overly reactive. Where data really shines is when it is used, in partnership with the expertise of other devs, to inform a design. It is here that data can contribute to long term views and mesh well with the art of games. 

LP: That’s certainly a lot! Out of all that, what would you say was the thing you loved most about the job?

BT: The clear answer is the people I have had the privilege of working with in my career so far. They are all just the best people; smart, funny, and awesome to work with. 

In addition, to be able to raise players’ issues and concerns and to highlight what they think is cool is another wonderful thing. To see a game come through UX tests, design iterations, reach players, and then see the behaviour we saw in the lab also being shown by millions of players and to know they are loving it! That is really a great feeling. To have the collaborative process of game design come together.

As someone who loves research it is also really fulfilling to be able to take the knowledge I have of why, cognitively speaking, a motorist may not see a cyclist at an intersection and be able to use that to investigate why a UI element or enemy in a game may also not stand out. Every survey, every UX test and every playtest, it is just exciting to me to see the data, whether it is surprising or completely expected.

LP: On the flipside, what are the downsides? Are there any challenges you would face regularly, and are there fresh ones you see coming on the horizon?

BT: A regular challenge would be dealing with the misconception that UXR dumbs down games and makes them easy. Also, that we are all inherently evil and working to manipulate players into spending money. Neither of these is true about UXR.  

Part of the reason I have worked in games UXR and not, say, microwave UX, is that games can be designed to be hard in a way that just isn’t the goal for consumer UX. Games can be confusing and challenging. If that is the intent of the designer, then that is what we work to support in UXR. In my 12+ years working in games UX research I have far more often highlighted that some design element was too easy for players than I have said something was too hard. 

In terms of the manipulation I do understand where that comes from. So much of the online world now has been made to intentionally work against the user. But absolutely that is not what I am interested in, nor is it what games user experience researchers should be supporting. Our goal is to represent the players. This means if something around purchasing is unclear it is our job to find that and point it out. 

Two other things regularly bug me. One is calling what games user research does “focus testing” or “focus groups”. A focus group/test is a specific methodology where you get a group of people together and get them to talk about a product, design, or idea. It is a flawed method, and not one I use or recommend. If I were to pick one method that is most representative for UXR it would be observational research. Watching people play and writing down what happens to collect their actual behaviour i.e., not what they say they do, but what they actually do. So, please if you are going to generalize say: we do playtesting or UX testing, not focus tests. 

The other is when people throw around scientific terms like “hit of dopamine” or “dopamine rush”. Dopamine just simply doesn’t work like that at all. Also we really shouldn’t be using drug metaphors in general when talking about games. 

LP: Thanks so much again for your time. Is there anything else you’d like to add before we sign off? Shout outs to peers, advice for folks, ill tidings for the industry?

BT: If anything I have said above is interesting to you, you should check out Games User Research, which is best place to go on the Internet for information on games UX research, including an active Discord server for connecting with and talking with others in the field. 

Finally, a big thanks to my previous teammates, colleagues, and teachers. Y’all are wonderful.

If you’d like to read more What I Do blogs, featuring interviews with everyone from age ratings managers to composers to narrative designers to lawyers, you can find them here.

Stay in touch

Sign up for our free newsletter

More from Aftermath

See all posts