Scaling a High Impact Remote UX Research Team

Om Tandon at UXDX EMEA. Video: https://youtu.be/-x_Q_hzqikA

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and background

[00:00:00] Hi everyone, I'm Om. 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. A few more bits about me: in my career I have worked across various platforms in gaming, right from the PC era to console to casino and lately mobile gaming. As far as my education goes, I have a bachelor's in economics honors, backed by a master's in advertising and graphics. I also studied behavioral economics, which helps me a lot with my research in psychology-related aspects of UX and UR work.

[00:00:37] 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 billion players worldwide.

[00:01:04] I'm also a bit of a globetrotter. My career path in the gaming industry and UX, and building UX teams, has led me across the globe. I started my career way back in India. Then I was part of a startup which also worked for a "beef well" [?] in San Francisco. Then I moved to Auckland, New Zealand, and finally, currently I am living and working in Dublin, Ireland.

Building UX in companies with low UX maturity

[00:01:32] All right, let's start with the topic for the day. The topic for the day is how to build high-performing UX and UR teams in companies which 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 today I'm going to share with you my experience. This is my fourth or fifth role working in a director position, and I've worked in startups which were as small as five or six people when they started out, and in global multinational giants, Fortune 500 companies which have close to 99,000 people across the world.

[00:02:10] I've come across orgs which either had no UX maturity, and what I mean by that is they've never had a UX or UR department before, or low UX and UR maturity, that is, they had some sort of UX and UR that they were doing, but it was not at the standard you would expect from more sophisticated, or what we call mature, UX and UR orgs like Apple or Microsoft.

[00:02:34] My journey with Wildlife started way back in 2019. Wildlife is one of the top 50 publishers of mobile games in the world, and the company reached a landmark in the last two weeks where the number of downloads reached three billion. Our games have been downloaded three billion times all over the world, which is a huge milestone. Wildlife works exclusively in the casual and midcore gaming space. 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 Zooba.

[00:03:11] As I mentioned before, my journey with Wildlife began in 2019. At that time I was working as a consultant. Wildlife is a 10-year-old company. It had explosive growth, and it was coming out of the space of being a startup to scaling to a bigger organization, with more processes and practices that they wanted to adopt into the production pipeline.

[00:03:32] In 2019 they were working on a product called Tennis Clash, which was in soft launch, not globally launched yet. They reached out to me for a UX audit. I looked at it, I used the lens of UX heuristics, did my research around competitors and best practices, and sent them suggestions and recommendations regarding pain points that I could encounter. I was very impressed with the way Wildlife was embracing the feedback. The moment I gave them the feedback, within 24 to 48 hours they were able to implement or change things in the game, which really impressed me. Long story short, in 2019 they launched the game worldwide, and kudos to the team, Tennis Clash became the 10th most downloaded game on the Google Play Store and iOS worldwide in the mobile games category, which was a huge achievement for them.

[00:04:25] During our interaction, I think the product teams did realize that they were missing this expertise of user experience and user research design, and they wanted to build a department around it. I was offered a job, but it was based in Brazil, as the company's headquarters [?] were there, and for personal reasons I could not make a move at that point in time. But as you know, in 2020 the pandemic happened and things changed. A lot of companies got used to working from home, and so did employees. During this time Wildlife also had an office 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 manage a distributed team of UX and UR folks who are around the world, based in Brazil, the US, Canada and Europe.

Learn to listen first

[00:05:19] All right, now let's get into the meat of the presentation. Today I'm going to talk about how to scale high-impact UX research teams remotely. This is a challenge, as I mentioned before. During my 15-year journey I've been in this position many times, where I had to build UX and UR teams either from scratch or scale existing ones in no and low UX maturity organizations. Today, even though the context is a lot within Wildlife, I'm also going to share with you in general what are the tips and tricks which have worked for me, the processes, what I've learned from them.

[00:05:54] One of the biggest key learnings 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? I always divide the kind of work that I have to undertake when I'm building a department into strategy and tactics. Strategy is a long-term vision which should guide your day-to-day tactics. Even if you go to these companies, you can find some common ground, some common day-to-day problems. For example, UX processes are not followed well in companies, people don't understand what the value of user research is, or UX designers don't have the bandwidth to cover all the projects. These are common tactical, day-to-day things that you will experience.

[00:06:44] These are common, but the strategy that is required, the long-term vision of how you want to build the department, depends a lot on 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. What I try to do is I don't go in with the biased mind that what has worked for me in the past will also work in this particular company. Go with an open mind, start with a clean slate.

[00:07:08] At Wildlife, that's what I did. For the first two weeks I had just one job: I focused on information gathering. I put my listening ears on. It's more about learning to listen. Often when you join a company in a manager position, a lead or a senior position, I'm sure all of us have felt this unsaid pressure. Either you might think your boss and your stakeholders expect you to hit the ground running, or you yourself put this kind of pressure on you: "I'm in this position, I have this much experience, I'm supposed to hit the ground running." There is this unsaid pressure where you want to immediately jump into the middle of things and start fixing things around.

[00:07:52] But in my experience, it's better to invest time in learning and listening rather than jumping in and starting to solve problems, because you have to find out what are the right problems to solve before you start reacting to what people are telling you. 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, my stakeholders were remote. We were all over the world.

[00:08:21] There were a couple of ways I gathered this information about what the pain points are, what the company mindset is, what the mindset of stakeholders is. I did a lot of Zoom interviews with my stakeholders. This could include my boss, his boss, VPs, GMs, product leads, just trying to understand their mindset. At the same time, you're also trying to gauge: are they supporters of UX and UR, or are they skeptics? This is very important. Nobody would openly say it, but you can gauge it from the demeanor. It's important because as you launch initiatives down the line, you know who are the people you can approach immediately, and the other people whose hearts and minds you have to change, which is very important.

[00:09:03] The next thing is to do team one-to-ones. I'm trying to gather information all the way from the top of the chain to the grassroots level. A lot of the pain points around what the problems are, what the issues are, what we are lacking, I learned from my team through team one-to-ones. Then I also wanted to understand what the project teams with whom we work, whose work we complement, like product managers, QA, game designers, user interface designers, what issues they are facing. I wanted to make sure that I was also capturing information from these project teams. To be honest, there were close to eight to ten project teams, because Wildlife had live products and they also had games which were in development, so new products and live products. In order to get feedback from this wide array of stakeholders, I used Miro, I used design thinking workshops, and that way I was able to gather feedback from 30 or 40 different people outside of my core stakeholders and team.

[00:10:13] The idea was to learn to listen. That's what I did for the first two weeks, and then I put all this together in a doc. I made sure I could analyze what were the commonalities, what were 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 may be down the list in their list of priorities. I gathered all that, I narrowed it down using the convergence and divergence techniques of design thinking, and presented the findings to my key stakeholders, my boss in this case. To be honest, my boss said, "It took you only two weeks to figure out what the gaps are. It took me two months." That was a compliment, and I think it was time well spent. Rather than going in and saying "I want to fix this, I want to fix that," take your time understanding the company vision, the OKRs and the pain points everybody is experiencing.

Put out the small fires, but treat the causes

[00:11:11] In this document, obviously, I wanted to identify what the gaps are, but I was not trying to solve everything in one go, because there were problems which would take longer to solve. But you definitely have to focus on solving the immediate fires. In any company that you join, there will be immediate fires for which you have to design stopgap solutions. They might be temporary, but they need to be taken care of. Otherwise you'll always be caught up in those small issues and won't have time to think more strategically.

[00:11:41] Examples of these small fires were work overload for my UX team. There were two people, three people including me, and there were eight to nine projects. And even though UX was being embedded in certain projects, the process was not followed, and research was undervalued. 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. 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. There are always these tactical issues, for example, people are overloaded with work, or there are immediate fires that you need to take care of.

[00:12:20] The way I do it normally is I make sure that my resources' capacity is tracked. I ensure that every designer or researcher is working only at 80% capacity, and they are only working on either a large feature or a small feature at any given point in time. Then they have this 20% floating capacity which they can give for consulting to other projects where they cannot work hands-on. Because it's about scaling impact: how can we add value to projects which have high priority, but at the same time give consulting bandwidth? They might not work on those projects hands-on, but they are able to give two or three hours a week to those PMs or designers as they walk them through their designs, and point out from a heuristics perspective what is working and what is not working.

[00:13:03] The reason I wanted to free up some time for my team was because I definitely wanted to start pushing them in a direction where we are thinking about growth, we are thinking about strategic initiatives. Neither they nor I could be in that mind frame if we are bogged down heavily in our day-to-day work. Often I found that these tactical issues are symptoms, not causes. My key takeaway here is that even though you have to treat the symptoms sometimes with stopgap solutions, never forget that these symptoms have deep causes which need to be taken care of. For example, if people are not following UX and UR processes, it's very likely that there's a lack of stakeholder education. It is very likely that they do not understand the value UX and UR is adding, and these kinds of initiatives require more time to solve. While you want to treat the symptoms, you want to focus on the causes. You want to treat the disease, not the symptoms alone.

Change management and a human-centered design institution

[00:14:05] All right, the next step is change management. What do I mean by change management? Imagine that you are coming into a company and you are there to do a shake-up of the department or the processes. Your team and the existing product teams are used to working in a certain manner, and when you come in and try to shake things up, there's always a bit of resistance. Change management requires not only changing the company's mindset but your team's mindset as well. 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.

[00:14:44] What do I mean by that? It will become more clear as I talk about this HCD approach. When I was trying to build the department, in my mind I wanted to do something more aspirational. I didn't want to build just a team of high-performance UX and UR folks. I didn't want to build just a department. I wanted to build an institution, a human-centered design based user experience and research institution. The reason for that is if we strive for something more aspirational, you will be inspiring and motivating the team more. And it's about legacy. I want to build something which will continue even after I have left the company, even if the team members leave: this institution, which is a repository of knowledge, of processes, of pipelines, which anybody who's coming in, either in my place or my team members' place, is able to go through and pick up the job from there. I wanted to build an institution, not just a department or a team.

[00:15:44] The way we structured ourselves, we call ourselves the UXR team, the user experience and research team, and I chose that we should be more human-centered design than user-centered design. This is a learning that has come to me. A lot of design teams out there, even the design teams I've built in the past, are more user-centered design, and as you know, in user-centered design, design happens around the user. The user is the center of the focus. But with human-centered design, I believe we broaden the definition.

[00:16:13] Often I've seen in companies which are very UCD-centered that there is an unspoken rift between the business and product stakeholders and the design and research teams. You often hear business talk about LTVs, revenue numbers, while as designers and researchers who are focused on the UX and UR craft, you care more about engagement, retention and satisfaction. Often there is this head-butting which happens. You can see that rift, and I see this frustration often in teams that I've handled. Researchers and designers say, "Nobody gets the value of it. They just don't understand what we do."

[00:16:53] With human-centered design we've broadened the definition, and what we say is that the experience of every person who touches the product is important for us. This definitely covers our customers, our players, but also our stakeholders, our developers, our QA people, designers or product managers who are building the product, because they are the ones who are actually building our products. We extend the empathy umbrella from customers all the way to stakeholders. With human-centered design, we try to position ourselves in a place where we are not just solving customer issues but also stakeholder issues. We are solving player issues, player pain points, and we are also taking upon ourselves to complement and help solve stakeholder issues.

[00:17:41] Under the HCD, human-centered design, umbrella, I wanted to incorporate a UX stream, which we had, with two 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. That's why I wanted to incorporate design thinking, user research and UX together under this HCD institution that I wanted to build.

Vision and strategic pillars

[00:18:14] "Aim for the stars and you might just reach the tree line" [?]. Like I said, I always like to have aspirational goals, because you do need a North Star, something which can guide you to get there. Not today, not in six months. It's fine if it takes us two years, three years, five years to get there, but we do need that North Star guiding light: why are we doing what we are doing today? It's always good to have aspirational goals, even if they're too far out, even if they're so high in standard that you might not achieve them immediately. That's fine, because that's what I find inspirational about them.

[00:18:53] Here's an example of the Games UXR vision. We built our entire strategy document, but this was the main vision for us: develop a world-class human-centered design experience and innovation institution by bringing together a great talent pool and cutting-edge tools, empowering our game teams to move fast, validate design hypotheses and capture underserved player needs and values. If you look at this vision, even though the document had a lot more detail in it, this is a distillation of the expectations and pain points of my team, who wanted higher standards, more cutting-edge tools, great processes. And at the same time, the stakeholders: one of the company values we had is "we move fast." We are good at innovating, so we work at a very fast pace. How do we help our business stakeholders decide when they have a hypothesis? How do we help them validate design problems using research? That's why we wanted to capture these statements in our UXR vision.

[00:19:59] For the strategic UX pillars, we kept it simple. There were three strategic UX pillars. Build world-class experiences with players, and for that we defined what world class looked like for us when we looked at ourselves and the competitors, and made sure that our practice reflected it. Continue to build a player-first mentality. Now, this is something which comes under changing the mindset of the organization. We wanted to invest in stakeholder education, because it's not just the UX and UR people's responsibility to ensure that our customers get a good experience. It's the responsibility of every person who's touching the product. Through this player-first mentality initiative, we invested in internal processes where we are doing all-hands, we're talking to different departments, we are sharing case studies and benchmarks to educate them on the value of UX and UR and the broad range of techniques we can offer. And the third part was to empower game teams to innovate with research. We wanted to empower game teams in terms of decision making, decision making through user experience design, through user research of quant and qual data, and of course use design thinking for innovation.

Structuring a small team

[00:21:07] Given we had these goals and this vision, we were a very small team, so we started out with a service team approach: three designers who had their priority projects, to which they would give 80% of their bandwidth. 10% of their bandwidth would go as consultants on some other projects, and another 10% was reserved for the strategic initiatives that we were trying to do. Because there's so much we have to do: defining processes, benchmarks, OKRs, vision. Who's going to do that? I really like to do that with my team. I like to involve my entire team, so I definitely made sure that we had that 10% bandwidth committed for it.

[00:21:45] This allowed us to cover wider ground, add more impact, and lead by example. Like many of you might have found, even though you are a people manager, you have to be hands-on, and I think that's a good thing in certain instances. Later the ratio moves from 40/60 to 30/70, how much time you are spending as a people manager and how much time you're spending hands-on, but it's a good way to lead the team by example.

[00:22:14] Given that we were a small team, the concept of creating a full-stack UX designer appealed to us. We wanted to create a UX designer who was not a unicorn per se, but had the capabilities to conduct UX audits using usability heuristics, and could do user research. Now, I did not expect them to do deep user research like diary studies or 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 didn't have those skills, we wanted to invest time in 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 UXR department and then later use it with their project teams. The idea here was to create a jack of all trades, master of some. This way we could ensure that we were in a position to demonstrate the value of research, design and innovation practices while we worked on our goal of hiring more team members and building out a more dedicated UX and UR department.

Tip one: hiring is job number one

[00:23:31] Next I'm going to talk about my three top tips. These are some of the common elements which I've seen have worked for me throughout my career journey in different organizations where I had to create a team from scratch or scale it up. The first one is: hiring is job number one. There's no surprise there, because the kind of department you will build and the kind of performance you will get depend heavily upon the quality of talent.

[00:24:07] My advice is, if you're building a team from scratch or scaling up a small team, hire seasoned, industry-experienced people. They could be seniors or they could be leads, but given a choice over juniors, I would definitely go with hiring seasoned, industry-experienced seniors. And if they are from the industry that you are in, that's even more relevant, because they will bring a wealth of experience from the same domain. These people are good at communication and stakeholder management, and they bring more autonomy to the table. 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 UR, you do need people who are good at what I call hard skills, the 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 benefit. You can, of course, as your team expands, add mid-tier people down the line, but initially I would always start with seniors or leads.

[00:25:14] To give an example, in my current company I was told they had hired a junior user researcher a few years back, before I joined. I looked at the work. She was very good at what she did, but she was a junior who came from education, not necessarily gaming. While she did good work, she got frustrated that her work was not generating traction. She was probably not able to engage the team. She probably hadn't developed the stakeholder management or communication skills, or the ability to point the teams to exactly what recommendations they should be looking at. That was one example where, even though you had a good resource, it failed to catch traction because of all these other soft skills, which are very important.

[00:25:59] 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, which I'm very comfortable doing down the line, but not right now, when I'm trying to build this department and take up strategic and tactical initiatives. For my research team, I started with hiring a lead user researcher for our existing product lines, or live games, and a principal researcher for our new products.

Tip two: getting a foot in the door, push and pull

[00:26:39] The second tip I can share with you is getting a foot in the door. I'm sure you've heard this one before. In any company which has no or low UX maturity, as we established earlier, you will need to prove yourself. You need to prove the value of UX. If you are incorporating a new technique, you'll be asked why we need to do it, is it going to add more time? Obviously these things do add time. Same for user research. Most of the time the advice, and it's good advice we've heard, is try to get a foot in the door. If you can demonstrate with just one study, which is very precision-driven and brings value for the stakeholders, for product or business functions, you can show some improvement in metrics, or something which aids the decision making. Slowly show them the value and then the door will open.

[00:27:32] I think that's a great approach, but I take this metaphor even further. For me, a door opens two ways. You can open most doors in two ways: you can push a door to open it, or you can pull it to open it. Strategically, I divide the initiatives that my team, the UXR team, has to take into two buckets: a pull bucket and a push bucket.

[00:27:55] What is the pull bucket? The pull bucket is all the initiatives, all the features, that the product team or our business stakeholders want us to take on. For example, if a product team is building a feature, they might reach out to us and say, "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 check whether the feature is easy to understand and whether it will work for our players. All these initiatives where the request is coming directly from your project teams, where they are pulling us in, fall under the pull bucket.

[00:28:42] But then there is this push bucket, where nobody is asking us for anything. These are the kinds of initiatives where nobody is asking us, probably because either they don't think those initiatives, those methods or techniques from UX and UR, 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.

[00:29:05] One good example: at Wildlife, when I joined, I started doing UX audits of our existing games. These are live games. We looked at the game from a heuristic perspective. We developed our own heuristics for games specifically, and we looked at our game and our competitors, and we used mixed methods. We looked at the quant data: 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 reviews and the pain points players were talking about. 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 things we should definitely look at in the long term.

[00:29:53] These reports were created and sent to the project teams. We received good feedback, but then that was it. We didn't receive much traction afterwards. We did these at the beginning of the year, and six months down the line the teams had to start looking at the quarterly roadmap for next year, and they were like, "What are the pain points in our game? Where can we improve? We remember that you did this audit. Can you send it back to us?" 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 immediate impact. Down the line, as the need arises, people will start reaching out to you again. That is an example of the push bucket. We did other things like 14-day diary studies and moderated usability testing on Zoom, which was very challenging in the pandemic because we couldn't get players in, but we figured out a way.

Tip three: invent a safe place to fail

[00:30:46] Another thing I always tell my team is: invent a safe place to fail and experiment. As I mentioned, the third pillar for this UXR department was innovation, and you have to create a safe place to fail. People are often afraid of innovating or trying new things, because they think, "What happens if this fails? It will fall on my face, I will look foolish." Because of that fear they either do not speak up or are not willing to innovate. I like to create a safe place to fail and experiment within the department.

[00:31:24] 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, and we try to brainstorm around it, understand what the problems are, or try techniques for new idea generation. That gives a low-stakes setting for the team to practice innovation techniques and methods.

[00:31:54] Another way I go about it is I look at the product team, I look at the product, I look at its roadmap. Chances are, if I go in and say, "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," not dev prototypes, design prototypes, just to see how we can solve this problem in different ways, chances are you'll be told no. It's very close to launch. One, we don't have time. Second, this is a multi-million dollar product. You don't want to make a costly mistake which causes heavy losses to the company just in the name of experimentation.

[00:32:41] What we try to do is de-risk it, create a low-risk environment. How I do that is I look at the six-month roadmap or the one-year roadmap and pick up a feature which 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. That's a good way to de-risk it. You take a feature which is not an immediate priority, and you start front-loading the UX and UR pipeline stages you have proposed. For example, you might say, "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, nothing built yet. Then, as we gain traction, we can try to prototype multiple ways to solve the same problem. The idea is, if it is something which is not an immediate priority, you can take it through your entire UX and UR process pipeline and demonstrate value to the stakeholders. They might come across information which makes them think, "We never asked this question. This is interesting, we would like to use more of this."

The portfolio of services

[00:33:48] Using these kinds of approaches, and here's my third top tip, creating a safe place to fail, we were able to offer a gamut of services to our game teams and stakeholders. 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, understanding our players, all the way to vision building. 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 modeling 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.

[00:34:31] For example, we can look at the data for how a game category or product category performed in the last five years, what the trends are. Are certain metrics going up, going down? If yes, what is causing it? A combination of mixed methods, quant and qual research. And then we even go to our stakeholders and say, "Would you like to do a workshop where we can look at what's going to change, what's the direction we should be taking, how the market will be evolving in the next two or five years?" The gamut of services we offer runs from everyday tactical stuff all the way to long-term strategic goals.

[00:35:11] As I mentioned, we piloted almost eight new features, methodologies and techniques in our products, using the push and pull approach and by creating a safe-to-fail experimentation space, which were never done at Wildlife before: UX audits, focus groups, high-fidelity prototyping, moderated concept testing using Zoom with our in-house resources, design thinking workshops. These were some of the things that we had never done before in Wildlife, and we were able to do them within the first six months. Thank you everyone. I hope you enjoyed the presentation. Cheers for now.