Scaling a High Impact Remote UX Research Team


Scaling a High Impact Remote UX Research Team

Product Direction

In this session, Om talks through insights from building a world class UX and Research team within 6 months. Om will discuss how the team works best alongside data scientists, software engineers, PM's, Directors and other business stakeholders to deliver multiple projects. Topics Om will address include:

  • Approach to educating the company divisions and stakeholders on the value of UX & Human Centred Design (HCD)
  • What it means to manage a team of diverse UX designers and User Researchers
  • Building digital capability of the wider org - more aligned delivery
Om Tandon

Om Tandon, Head of Market Intelligence and UX,Wildlife

Hi everyone I'm Om Tandon. I work as head of market research and UX at a company called wildlife. I've been in the gaming industry for the last 15 years. Few more bits about me. So in my career, I have worked across various platforms in gaming right from PC to console to casino and lately mobile gaming. As far as my education goes I have a bachelor's in economics honours backed by a master's in advertising and graphics. I also started behavioural economics which helps me a lot with my research in psychology-related aspects of UX and your work. I also consider myself very fortunate that during my career journey I have worked with some of the best brands and franchises in the world. Some of them include IPs like Ice age Star Trek, My Little Pony, Wizard of Oz, and Marvel to name a few. And I consider myself extremely lucky that the products that I've worked on have been downloaded and used by over 5 million players worldwide. So I'm also a bit of a globetrotter. My career path in the gaming industry and UX and building your teams have led me across the globe. I started my career way back in India. Then I took part in a start-up. I was part of a start-up that also worked for a brief while in San Francisco then I moved to Auckland New Zealand. And finally, currently, I'm living and working in Dublin, Ireland. All right. So let's start with the topic for the day. The topic for the day is how to build high-performing UX and UI teams in companies that either have no UX maturity or low UX maturity. I'm sure a lot of you have come across those kinds of hurdles in your career. And I'm going to share with you my experience. This is my fourth or fifth role working in a director position. And I worked in start-ups which were as small as five people or six people when they started out and global multinational giants Fortune 500 companies that have almost close to 99000 people across the world. So I've come across organs that either had no UX maturity. And what I mean by that is they've never had a UX or your department before or a low UX and UI maturity. That is they had some sort of UX and you are what they were doing but it was not at the standard you would expect from you know more sophisticated or what we call mature UX and you are organs like Apple or Microsoft. So my journey to wildlife started way back in 2019. Wildlife is one of the top 50 publishers of mobile games in the world. And the company reached the landmark last two in the last few weeks where you know the number of downloads reached three buildings. All games have been downloaded 3 billion times all over the world which is a huge milestone. By-line works exclusively in casual and Mitko gaming spaces. We have games in the sports genre like tennis clash which is the number one tennis game in the world on mobile. We also have some shooter category games and multiplayer games like Zumba. So as I mentioned before my journey with wildlife began in 2019. At that time I was working as a consultant. And so wildlife is a 10-year-old company. It had explosive growth and it was coming out of this phase of from being a start-up you know to scale to a bigger organization with more processes and you know practices that they wanted to adopt into the production pipeline. So in 2019, they were working on a product called tennis class which was in soft launch and not globally launched yet. They reached out to me for a UX audit. I looked at it using the lens of UX heuristics, did my research around competitors and best practices and you know sent them suggestions and recommendations regarding pain points that I could encounter. And I was very impressed by the way with which my life was, you know, embracing the feedback and movement. I gave him the feedback within 24 to 48 hours and they were able to, you know, implement or change things in the game which really impressed me. Long story short 2019 they launched the game worldwide. And kudos to the team. Tennis last became the 10th most downloaded game on Google and Google Play Store and iOS worldwide in the mobile games category which was a huge achievement for them. So during that interaction, I think the product teams did realize that they are missing this expertise of user experience and user research design and they do want to build a department around it. So I was offered a job but it was based in Brazil as the company is headquartered there. But for personal reasons you know I could not make a move at that point in time. But as you know, in the 2020 pandemic things changed. A lot of companies got used to working from home so their employees and during this duration wildlife also had an office. I'm in Dublin. So they again offered me the job and I was more than happy to join them. I've been with them now for close to one and a half years and I managed a distributed team of UX. And you are folks who are around the world based in Brazil, the US, Canada, and Europe.
All right. So now let's get into the meat of the presentation. Today we're going to talk about how to scale high-impact UX research teams remotely. So this is a challenge. As I mentioned before during my 15 years journey I've come many times you know I've been in this position where I had to build and either from scratch or scale existing UX and your team in no and low UX majority organizations. So I'm going to share with you even though the context is a lot within my life. I'm also going to share with you in general what are the tips and tricks which have worked for me. You know processes that I've learned from them. So one of the biggest key lessons for me is that no strategy has a one size fits all approach. You need to approach each company's culture with an open mind. Now, what do I mean by that? So what I mean by that is I always divide the kind of work that I have to you know undertake when I'm building a department into strategy and tactics. You know the strategy is a long-term vision that should guide your day-to-day tactics. So even though if you go to these companies where you know you can find some common ground you can find some common day-to-day problems like for example UX processes are not followed Well in companies people don't understand what the value of user research is our UX designers don't have the bandwidth to cover all the projects you know these are common tactical day to day things that you will experience. So these are common but the strategy that requires a long-term vision of how you want to build a department depends a lot on whether you know what the culture of that company is and what the goals of that company are because your strategy has to be aligned with the goals of the company. So what I try to do is I don't go with the bias-minded what has worked for me in the past will also work in this particular company. So go with an open mind and start with a clean slate. And in my life, that's what I did. For the first two weeks I had this one job I focused on information gathering you know I put my listening ears on. And it's more about learning to listen you know often when you join a company in a manager position or lead or a senior position you feel this kind of you know I'm sure all of us have felt unsafe pressure either you might think yeah your boss your stakeholders expect you to hit the ground running or you yourself you know put this kind of pressure on you Hey I am. So you know in this position I have this much experience I'm supposed to hit the ground running. So there is this unsaid pressure where you know you want to immediately jump into the middle of things and you know start fixing things around. But in my experience, it's better to invest time in learning and listening rather than jumping in, you know, and start solving problems. Because you have to find out what are the right problems to solve before you start reacting to what people are telling you. So the first two weeks I just spent information gathering and I used a range of techniques for it. Remember this was at the peak of the pandemic so I was working remotely, my team was remote and my stakeholders were from a remote view all over the world. So a couple of days I gathered this information about what are the pain points you know about the company mindset. What is the mindset of stakeholders? I did a lot of zoom interviews with my stakeholders. These could include my boss, his boss, VPS GMs, and product leads who are just trying to understand their mindset. And at the same time you're also trying to gauge whether you know are supporters of UX and you are or they're sceptics you know this is very important. Nobody will openly say you know but you can gauge from the demeanour. And it's important because as you launch initiatives down the line you know who are the people you know whom you can know and approach immediately and who are the people whose hearts and minds you have to change. This is very important. So the next thing is to team one to one. I'm trying to gather information all the way from the top of the chain to you know the grassroots level. So a lot of pain points around what the problems are, what the issues are, and what are we lacking. I learned from my team to team one to one. And then I also wanted to understand what is it that the teams or the project team with whom we work who's worked we complement like product managers QA game designers you know user interface designers what are the issues they are facing you know so I want to make sure that I'm also capturing information from these project teams. And they were, to be honest, close to eight to 10 project teams because while I've had you know live products and they also had games which were in development so new products and live products so in order to get feedback from this wide array of you to know stakeholders I used Myro I used Design Thinking workshops. And that way I was able to gather feedback from close to you know different 3040 people outside of my core stakeholder and team. So the idea was to learn to listen to this. That's what I did the first two weeks and then I put all this together in a dog. I made sure you know I could analyse what were the commonalities and what are the common pain points everybody was talking about.
But more importantly, I also wanted to see what the priorities are. It might be that people are talking about one thing which is very common but that will be down the list in there you know the list of priorities. So I gathered all that and narrowed it down using convergence and divergence techniques of design thinking and presenting the findings to my key stakeholders, my boss in this case. And to be honest my boss said yeah it took me only two weeks to figure out what the gaps are it took me two months. So that was like a compliment. And it was I think time well spent you know rather than going in and saying I want to fix this I want to fix that take your time understanding you know the company vision OKRs and the pain points everybody is experiencing. So in this document obviously I wanted to identify what the gaps are but they were also I was not trying to solve everything in one go because they were problems that will take longer to solve. But you definitely have to know how to focus on solving the immediate fires in any company that you join. They will remain immediate and vice versa for whom you have to design stopgap solutions. You know they might be temporarily there but they need to be taken care of. Otherwise, you can never know you'll always be caught up in those small issues and you won't have time to think more strategically. So an example of these small fires is work overload for my UX team. There were two people including me and three people and they were like eight to nine projects. And even though UX was being embedded in certain projects the process was not followed and research was undervalued. So these are some of the immediate tactical issues that you always see. And I want to make sure that I'm getting these out of the way. So the way I usually do this is I ensure first of all that we are tracking all the work tracking all the requests that are coming our way. So there are always these tactical issues you know, for example, people are overloaded with work or their immediate fires that you need to take care of. So the way I do it normally is I make sure that my resource capacity is trapped. I ensure that every designer or researcher is working only at 80% capacity and they are only working either on a large feature or a small feature at any given point in time. And then they have this 20% voting capacity which they can give for consulting to other projects where they cannot work for hands-on you know because it's about scaling impact how can we add value to projects which are high priority but at the same time give consulting bandwidth you know they might not work on those projects hands-on but they are able to you know give two-three hours a week to those PMS or designers as they walk them through their designs and point out from a Hero Six perspective what is working what is not working. And the reason I wanted to free up some time for my team was that I definitely wanted to start pushing them in a direction where we are thinking about growth and we are thinking about strategic initiatives. And neither they could you know be in that mind frame nor I if we are bogged down heavily in our day-to-day work. So often I found that these tactical issues are symptoms, not causes. So my key takeaway here is you know even though you have to treat the symptoms sometimes it's a stopgap solution. Never forget that these symptoms have deep causes which need to be taken care of for example if people are not following UX in your processes it's very likely that you know they are not there there is a lack of stakeholder education it is very likely that you know they do not understand either what you value UX and you are adding and these kinds of initiatives require more time to solve. So while you want to treat the symptoms you want to focus on the causes you want to treat the disease, not the symptoms alone. All right. So the next step is change management. So what do I mean by change management? Imagine that you are coming into a company. And you are here too, you know, do a shake-up of the department or the processes of the team, your team, and existing product teams they're used to working in a certain manner. And when you come in and try to you know shake things up there's always a bit of resistance. So chain management requires not only changing the company's mindset but your team's mindset. Change is not a one-way street. It's not that you just have to change the people around you.
You also have to change yourself and your team's mindset. Now, what do I mean by that? So it will become more clear as I talk about this on CD abroad. So when I was trying to build a department in my mind I wanted to do something more aspirational. I don't want to build just a team of high-performing UX and UI folks. I don't want to bury Justin's department. I wanted to build an institution, you know, a human-centered design-based user experience and research institution. And the reason for that is if we strive for something more aspirational you know we will be inspiring and motivating the team more. And it's about legacy you know kind of I want to build something which will you know continue even after I have left the company even at the team members leave this institution which is a repository of knowledge or processes or pipelines which anybody who's coming in either in my place or my team members please is able to you know go through and pick up the job from there. So I wanted to build an institution, not just a department or a team. So the way we structured ourselves we call ourselves the UX team, the user experience, and the research team. And I chose that we should be more human-centered design than user-centered design. Now, this is a learning that has come to me. You know a lot of design teams out there even the design teams built in the past were more user-centered in design. And as you know user-centered design happens around the user. The user is the center of focus. But with the human-centered design, I believe we broaden the definition often I've seen in companies that are very UCD centered there is an unspoken rift between the business product stakeholders and the design and research teams because you often hear businesses talk about LTVs you know revenue numbers while as designers and researcher who are focused on UX and UI craft you care more about engagement retention and satisfaction. So often there is this head-butting which happens you know you can see that rift. And again I see this frustration often in teams that are handled by researchers and designers like they're like Yeah nobody gets the value of it you know they just don't understand what we do. So with human-centered design, we broaden the definition of what we say is the experience of every person who touches the product is important for us. And this definitely covers our customers, our players but also our stakeholders, our developers, our QA people or designers, or product managers who are building the product because they're the ones who are actually building our product. So we extend the empathy umbrella from customers all the way to stakeholders. And with the human-centered design, we try to position ourselves in a place where we are not just solving stakeholder issues but also customers so we are solving player issues and player pain points but we are also taking it upon ourselves to complement and help solve stakeholder issues. So under the SED Human Centered Design umbrella, I wanted to incorporate a UX stream that we had to UX designers. I wanted to create a user research team to complement the UX team. And the third part that I wanted to emphasize was design thinking.
Design thinking is great for innovation. It is a great problem-solving tool and innovation tool for stakeholders. So that's why I wanted to incorporate design thinking, user research, and UX together under this sad institution that I wanted to build. Now aim for the stars and you might just reach the Tubelight. So like I said I always like to have aspirational goals because it's okay that you know you do need a Northstar, something that can guide you to get there. Not today, not in six months. It's fine if it will take us two years, three years, or five years to get there. But we do need that Northstar Guiding Light. Why are we doing what we are doing today? Why are we doing it? So it's always good to have aspirational goals. Even if you know they're too far out there to such a high standard that you know you might not achieve them you know immediately but it's fine because that's what I find inspirational about them. So here's an example of you know the game's UX our vision we built we built our entire strategy document but this was the main vision for us. Develop a world-class human-centred design experience and innovation institution by bringing together a great talent pool and cutting-edge tools empowering game teams to move fast, validate design hypotheses, and capture underserved player needs and values. So if you look at this vision even though the document had a lot more details in it this is kind of a distillation of the expectations and the pain points of my team who wanted you to know higher standards more cutting-edge to great processes. And at the same time stakeholders, one of the company values we had is we move fast. You know we are good at innovating. So we work at a very fast pace. So how do we help our business stakeholders decide when they have a hypothesis? How do we help them validate design problems? You know, using research, that's why we want to capture these statements in our UX vision. Of the strategic UX pillars we kept simple there were three strategic UX pillars to build world-class experience with players. And for that, we define what world-class looks like for us when we looked at ourselves and the competitors and made sure that our practices reflected a continue-to-bet player-first mentality. Now, this is something that comes under you know changing the mindset of the organization we wanted to invest in stakeholder education. Because it's not just the UX and UI people's responsibility to ensure that our customers get a good experience. It's the responsibility of the player, sorry it's the responsibility of every person who's starting the product. So through this player force mentality initiative, we invested in internal processes where we are doing all hands we're talking to different departments.
We are sharing case studies benchmarks to educate them on the value of UX and you and the broad range of techniques we can offer. And the third part was Empower game teams and innovate with research we wanted to empower game teams in terms of decision making and decision-making through user experience design through user research of quant and qual data. And of course, use design thinking for innovation. So given we had these goals in this vision, we were a very small team. So we started out with the service team approach of three designers who had their priority projects to which they will give 80% of their bandwidth 10% of their bandwidth would go as consultants on some other projects and another 10% goes reserved for the strategic initiatives that we were trying to do. Because we are saying there's so much we have to do to define processes benchmarks you know and OKRs vision who's going to do that. I like to do that with my team. I have to involve my entire team. So I definitely made sure that we had that 10% bandwidth committed for it. So this allowed us to know to cover wider ground and add more impact. And lead by example definitely I think like many of you might have found that even though you are a people manager you have to be hands-on. And I think that's a good thing in certain instances. So yeah 3060 or 70% ratio later it moves from you know 4060 to 3070 how much time you're spending as a people manager how much time you're spending hands-on but it's a good way to you know lead the team by example. So given that we have a small team the concept of creating a full-stack UX designer appealed to us. So what we did was we wanted to create a designer who was not a unicorn per se but had the capabilities to conduct UX audits you know using usability heuristics they could do user research. Now I don't expect them to do you know deep user research like diary studies or you know creating player motivation studies but definitely focus groups benchmarking research usability tests this is something we can expect a UX designer to do. And if they don't have those skills we wanted to invest time in you know, bringing them up to speed wireframing prototyping. And I also included training my entire team in design thinking because I wanted them first to use it within our UX department and then later use it with their project teams. So the idea here was to create a jack-of-all-trades master of some but this way you know we could ensure that we are in a position to demonstrate the value of research design and you know innovation practices while we work on our goal of you know hiring more team members building out a more dedicated UX in your department. So next I'm going to talk about my three top tips. And these are basically some of the common elements which I've seen that have worked for me as I've worked throughout my career journey in different organizations where I had to either create a team from scratch or scale them up. So the first one is hiring is job number one. This is also the first step. And there's no surprise there right? Because the kind of department you will build and the kind of performance you will get depends heavily upon the quality of talent. And my advice is if you're building a team from scratch scaling up a small team hired seasoned industry experience they couldn't be seen here though they could be leads. But given a choice over juniors, I would definitely go 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. And these guys are good at communication and stakeholder management and they bring more autonomy to the table. And to be honest with you when you are scaling a team in an environment where you still have to prove the value of UX. And you are you do need people who are good at you to know 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 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 and you know mid-tier and juniors down the line but initially I would always start with seniors or leads. So 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. So 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. So that was one example of you know even though you are a good resource it failed to catch traction because you know all these other soft skills which are very important.
So 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 you know other domains I will spend a lot of my time mentoring them and upskilling them which I'm very comfortable going down the line but not right now when I'm trying to figure out you know to build this department you know take up strategic and tactical initiatives. So for my research team, I started by hiring a lead UX lead. You are a design user, sorry lead user researcher for our existing product lines or live games, and up principal researcher for our new products. Okay, the second tip I can share with you is getting your foot in the door. I'm sure you've heard this one before. So in a company, you know where you are either which has no or low UX maturity as we established earlier 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. You know if it is going to add more time obviously these things do add time. Same for user research. So most of the time the advice is you know good advice we've heard is try to get you to know your foot in the door if you can demonstrate by knowing just one study which is very precision-driven and brings value for the stakeholders for product or business functions. You can now show some improvement and metrics which aids a decision making you know slowly show them the value and then the door will open. So I think that's a great you know approach. But I take this metaphor even forward for me. A door opens two ways you can open a door. For most doors you can push your door to open it or you can pull a door to open it. So strategically I divide the initiatives that my team has to take the UX team into two buckets: one bucket and a push market. So what is the pool 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 want they might reach out to us and say Hey we are trying to build this feature. But we are not sure that you know 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? So 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 where they are pulling us in our fall under pull bucket but then there is this push bucket where nobody's asking us for anything. The kinds of initiatives where nobody's asking us probably because either they don't think those initiatives will add value, those methods or techniques from us your repository will add value or they simply don't know they exist. So these are under the push market and the push bucket we try to you know take up these initiatives which might need more time.
But one good example is in my life when I joined I started doing UX audits of our existing games. So these are live games. So what we did was look at the game from a heuristic perspective. We developed our own heuristics for games specifically. And we looked at our game and our competitor and we used mixed methods. 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 you know 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. You know, okay, 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. You know we didn't receive much. Actually afterward we did these at the beginning of the year and six months down the line the teams had to start looking at what is the quarter for a roadmap for next year. And they were like yeah what are the pain points in our game? Where can we improve? And they're like Yeah we remember that you guys did this audit can you send it back to us? So that's the beauty of it. You know 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 you know people will start reaching out to you again. So that is an example of a push bucket. We did other things as you know 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. And yeah another thing I always tell my team is to invent a safe place to fail an experiment. Now. I think as I mentioned the third pillar of the CSR department was innovation. And you have to know 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. So for me, I like to create a safe place to fail experiments within the department.
How I do that is I create weekly rituals. So we have weekly rituals we call fire drills for design thinking where you know we can have problems related to projects people are working on or a project that we might take up as a department and we try to brainstorm around it to understand what the problems are and techniques for more new ideas generation. So that gives a low-stakes setting for you to know the team to practice innovation techniques and methods. And one of the ways I go about it is I look at a product team. I look at the product and look at its roadmap. Chances are 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 AV testing of prototypes I've built in different ways you know, not their product design prototype just to see how we can solve this problem in different ways? And chances are you will be told no it's very close to launching. And you know we won, we don't have time. Second, this is a multimillion-dollar product you don't want to make a costly mistake you know which is causing heavy losses to the company just in the name of experimentation. So what we try to do is de-risking and creating a low-risk environment. And how I do that is to look at the six-month roadmap or one-year-down-the-line roadmap and pick up a feature that is coming down the line, maybe it's due to be launched in four months or six months. That is, it will reach the production or development stage after three, four, or six months. And that's a good way to de-risk if you take a feature that is not an immediate priority and you start front-loading the UX and the pipeline stages you are proposing. For example, you might say Yeah we want to first start with user research. Do players really see this thing as a problem? And if they do, is this the right solution? Just concept testing you know nothing is built yet then we can also you know as we gain traction try to create multiple ways to prototype multiple ways to solve the same problem. So the idea is if it is something that is not an immediate priority you can, you know, take it through your entire UX process and pipeline and demonstrate value to the stakeholders. They might come across information that might make them think we never asked this question. Yeah, this is interesting. We would like to use more of this. And using these kinds of approaches. Here's my third top tip: By creating a safe place to fail we were able to offer a gamut of services to our game teams and stakeholders. And as you can see this is the complete portfolio of services we offer. And it starts all the way from insight mining high-level research and understanding our players all the way to vision building. So this is a combination of techniques and methods we offer for both tactical and strategic initiatives. For example, there is stuff like UX audits user interviews Persona modelling, and prototyping that you need on a day-to-day basis but if you go towards the right side of the arrow you will see we have vision building future casting Ecosystem Assessment for example we can look at the data for how game category or product category performed in last five years. What are the trends? Are they going as uncertain metrics going up going down? If yes, what is causing it to be a combination of mixed methods of quant and qual research? And then even go to our stakeholders and say Hey, would you like to do a workshop where we can, you know, look at what's going to change? What's the direction we should be taking in how the market will be evolving in the next two or five years? So the gamut of services we offer is from everyday tactical stuff to all the way to long-term strategic goals. And as I mentioned we piloted almost eight new features, methodologies, and techniques in our products using the Push and Pull approach using say migrating safely to fail experimentation space which was never done at Wild light before. So UX audits focus groups high-effort prototyping moderated concept testing using zoom. You know our in-house resources design thinking workshops. These were our concept tests. Some of these things that we have never done before that we've never done before in my life we were able to do within the first six months. So thank you, everyone. I hope you enjoyed the presentation. Cheers for now.