Breaking into Games UR
One frequent question that comes up in the Games User Research SIG discussion group on linkedin is:
"How do I break into Games User Research"
I totally get it. It's a sweet gig if you can get it. Fun products to work on, interesting problems to solve, and an excuse to do "competitor research" (one time my mentor at MS caught wind of me doing that for Deus Ex: HR and I ended up with new tasks very quickly).
The question comes from people of every career stage; from fresh-faced student to weathered veteran looking for more than life than doing usability tests on the Startup Of the Week, and has very different answers. There are, however, some universals for all career stages:
- Know your games. This should be a no-brainer, but if you don't love playing games for fun, you need to at least be conversant in recent titles, understand current trends in the industry, and be able to talk about them in exhaustive detail, because the other people applying for the job certainly will. I've observed that User Researchers either "get" games or they don't; it's very hard to instill the in-depth game knowledge expected for our industry if you don't play.
- Know the people. UR is a relatively small field. Games UR is an order of magnitude smaller. While UR is becoming more common in the industry, there are still only about 1000 of us in the GUR SIG (including students. I'd estimate the total number of practitioners at <400). As a result, it's relatively easy to get your networking on by going to the annual GUR SIG meeting, joining the linkedin group, or by going to one of the meetups that are held at consumer and professional game conventions around the world. Assuming you make a good impression, it will help you immensely to be able to send a personal email to the hiring manager you shared a beer with at a mixer when a job opening comes up.
- Know how your skills transfer: Despite what I said above about how it's difficult for someone who doesn't "get" games to do well in GUR, many of the methods used in GUR are similar to or identical to those used in other domains. The important thing is to know which ones do and which ones don't. I've seen URs freak out because they haven't done games before, yet they've done work on, say, HUD usability for major car companies or designed A/B tests to measure the effectiveness of gamification. True, some methods--like playtest--are unique to games, but a smart job applicant will bone up on those methods by taking a gander at one of the excellent sources on GUR-specific methods that are out there.
I also have a few cautions for anyone who wishes to try their hand at GUR:
- You will get paid less: while there are some exceptions, generally speaking game salaries are less across the board than comparable positions in non-game domains. We work on games because we love them, and the employers pay less as a result.
- You won't always work on games you like: When I was a contractor at MS I got lucky and was able to spend 18 months working on Halo. I have also worked on titles I liked much less. Some I even hated so much I will never look at them again. Be prepared to do your best work even when you don't like or would never play the game in question.
- You can't fade into obscurity: I mentioned above that GUR is small, and it truly is. If you mess up a job and get fired or embarrass yourself in front of your peers, it will be known and remembered. I still hear about a particularly painful dinner I was at where an over-eager student was trying way too hard to get hiring managers to pay attention to him. He ended up having a lot of trouble finding a job in the field. I've also been pinged by former coworkers that had questions about an applicant I've worked with in the past.
Hopefully these tips are helpful. If I see interest, I may do follow up posts on breaking in as a student and mid-career.