Building a High Impact UX Research Team at Wildlife Studios

Om Tandon shares his three-step approach to building and scaling high-impact UX Research teams.

Building a High Impact UX Research Team at Wildlife Studios

How would you recommend someone starting if they need to build a UX research Team?  

Here are three tips when creating a UX Research team. These are basically some common elements which I've seen that have worked for me as I've worked throughout my career in different organisations where I had to either create a team from scratch or scale them up:

  1. Hire seasoned industry professionals
  2. Get your foot in the door
  3. Encourage innovation

Hire right

The kind of department you will build and the kind of performance you will get depends heavily upon the quality of talent. My advice is if you're building a team from scratch and scaling up a small team - hire seasoned industry people they could be senior or they could be leads. But given a choice over juniors, I would definitely go with hiring more seasoned industry experience, seasoned seniors and if they're from the industry that you are in you know what's even more relevant because they will bring a wealth of experience from the same domain. These guys are good at communication and stakeholder management and they bring more autonomy to the table.

When you are scaling a team in an environment where you still have to prove the value of UX and UR, you do need people who are good at what I call hard skills, their technical skills like wireframing, prototyping, researching but soft skills play an important part because you have to do a lot of stakeholder management and you have to do a lot of communication back and forth up and down the chain.

And that's where I think seasoned veterans are a better fit of course as your team expands to mid-tier and juniors down the line but initially I would always start with seniors or leads. To give you an example, in my current company I was told they hired a junior user researcher before I joined a few years back. I looked at her work and she was very good at what she did. But she was a junior who came from education, not necessarily gaming. I think while she did good work she got frustrated that her work wasn't generating traction. She was probably not able to engage the team and she still probably hadn't developed you know the stakeholder management or communication skills or ability to you know point to the teams exactly what are the recommendations they should be looking at. That was one example of even though you have good insights they can fail to get traction because of the missing important soft skills.

Another advantage I see is it frees up your time. If I hire a lot of juniors and mid-tier designers and researchers who are coming from  other domains I will spend a lot of my time mentoring them and upskilling them. I'm very comfortable doing this down the line, but not right now when I'm trying to figure out to build this department and focus on strategic and tactical initiatives. For my research team, I started by hiring a lead user researcher for our existing product lines or live games, and a principal researcher for our new products.

Get your foot in the door

The second tip I can share with you is get your foot in the door. In a company, which has no or low UX maturity you will need to prove yourself, you will need to prove the value of UX. If you are incorporating a new technique you will be asked why you need to do it because obviously these things do add time which is the same for user research.

If you can demonstrate just one study which is very precision-driven and brings value for the stakeholders in product or business functions it can help to get your foot in the door. You can now show some improvement and metrics which aids a decision making. Slowly show them the value and then the door will open. I think that's a great approach.

Strategically I divide the initiatives that my team has to take the UX and UR team into two buckets: a pull bucket and a push bucket.

A pull bucket is all the initiatives and all the features that the product team or our business stakeholders want us to take. For example if a product team is building a feature they might reach out to us and say, "Hey we are trying to build this feature but we are not sure that it will appeal to our players - can you do some kind of research to let us know? Who are the players to whom it will appeal? And what do they think about it?" We might think of some user research study. Or they might want us to do a usability test session to just check whether you know if the feature is easy to understand. Will it work for our players?

So all these initiatives where the request is coming directly from your project teams fall under the pull bucket but then there is this push bucket where nobody's asking us for anything, probably because either they don't think those initiatives will add value or they simply don't know they exist. These are under the push bucket. In the push bucket we try to take up these initiatives which might need more time.

Another good example for a push bucket is when I started doing UX audits of our existing live games. What we did was look at the game from a heuristic perspective. We looked at the quant data; we looked at how the market is performing, how these competitors are performing in terms of revenue, downloads, retention, daily average users. We also looked at player data like kind of reviews, pain points players were talking about you know we looked at the strengths and weaknesses of our game. We compared it with the strengths and weaknesses of other games and we made recommendations. What should we solve in the short term? What can we focus on in the midterm? What are definitely things we should look at in the long term? So these reports were created. They were sent to this project team and we received good feedback but then that was it, or so it seemed.

Later, the teams had to start looking at what is the roadmap for the next quarter or year. They were looking for the pain points in their game. Where can we improve? They remembered that we did this audit and asked us to send it back to them. So that's the beauty of these push initiatives. It doesn't matter that you did these initiatives on your own and they didn't create an immediate impact but down the line, as the need arises, people will start reaching out to you again. That is an example of a push bucket. We did other things as 14-day diary studies and monitored usability testing on Zoom which was very challenging in the pandemic because we couldn't get players in but we figured out a way.

Encourage innovation

The third pillar of the UXR department is innovation. And you have to create a safe place to fail. People often are afraid of innovating or trying new things because they're like “What happens if this fails?”. It will fall on my face and I will look foolish. And because of their fear they either do not speak up or are not willing to innovate. For me, I like to create a safe place to fail experiments within the department.

How I do that is I create weekly rituals. We have weekly rituals we call fire drills for design thinking where we can have problems related to projects people are working on or a project that we might take up as a department. We try to brainstorm around it to understand what the problems are and techniques for more new ideas generation. That gives a low-stakes setting for the team to practice innovation techniques and methods.

Innovation challenges

If I go in and say "Hey there's this new feature coming up which is due to be launched at the end of the month, can I try a new usability technique? Can I do a focus group to understand whether it will appeal to the players or not? Or can I do some A/B testing of prototypes I've built in different ways just to see how we can solve this problem in different ways?" Chances are you will be told no, it's too close to launching.

Second, this is a multimillion-dollar product you don't want to make a costly mistake which is causing heavy losses to the company just in the name of experimentation.

We de-risk our initiatives by looking at the six-month roadmap or one-year-down-the-line roadmap and picking up a feature that is coming down the line, maybe it's due to be launched in four months or six months. Because the feature that is not an immediate priority we can front-load the UX and take it through our entire UX process and pipeline and demonstrate value to the stakeholders.

What has building a UX Team enabled you to achieve?

Our services have been able to support our game teams and stakeholders from everyday tactical stuff to all the way to long-term strategic goals.

We piloted almost eight new features, methodologies, and techniques in our first six months using the Push and Pull approach and enabling safe to fail experimentation.