Life isn't always easy when you're the only UX researcher on a large team with strict deadlines. But Shavika makes it work, thanks in part to her focus on process and operations. She's also able to draw from experiences and learnings in her past, which has helped her get a jump start on Research Operations at Twilio.
It's always fascinating to learn about a person's journey to their UX career. Shavika's path is a great story that hopefully inspires others to be curious and seek out opportunities for themselves. Let's dive in:
Sofia: Let’s start with a little bit of background. When did you join Twilio?
Shavika: I joined Twilio over two years ago. I actually started as an executive assistant to our head of sales at the time. Over the course of a year and a half or so, I moved over to the R&D side and supported our VP of Product which was a key role in helping me finally transition to UX Research.
Sofia: How big is your team?
Shavika: Currently we are about 55 product managers across all products, 10 product designers and 2 design managers, and myself as a UX researcher.
Sofia: How is design embedded in the product development process at Twilio?
Shavika: Design hasn't traditionally been a key part of the product development process at Twilio, because our products are communication APIs. Twilio is a platform for developers, built by developers, and design has not always been at the forefront of our process. As a company we invest a lot of time thinking about our users and our developer community; learning more about them, their needs, and what their mindset is around wanting to build with our products. We even have actual customer shoes hanging all over our office! Of course the shoes are just a reminder to think about our customers as we make decisions, but learning how they think and designing with that in mind is a critical part of that. So, UX Research is the newest addition to our development process and its been a very interesting challenge learning how it fits into the broader process.
Sofia: Being the only UX researcher at Twilio, you are also building the foundations for Research Operations. How are you thinking about it?
Shavika: So it’s funny, because I didn’t realize I was going to become a ResearchOps person until very recently. I thought I was a UX researcher, and recently as I started to run into repetitive issues I realized I needed systems in place, and had the thought, “Oh, I guess I'm also in ResearchOps!” Historically, we’ve operated without research as a main part of the process, so there's a lot of to figure out, which is where the operational part of the role comes in.
You start by getting to the surface of things, and then you realize there's a lot more underneath it. For example, if I'm going to have to recruit a very specific user or research participant for one product initiative, and I know another product's users are going to be totally different; it's going to be a new process each time. My goal is to ask myself, how can I optimize that process across all the products? What kind of systems can we implement now that can scale out and become more agile? Currently I ran into the issue of participant recruiting and had to find a way to optimize it. I ended up creating a large database of pre-screened users, and then selected participants that fit my needs from that database. So there’s quite a bit of design thinking as a researcher too.
Sofia: Can you tell me more about the importance of process in the context of research?
Shavika: I think coming from an operational role in product, I bring a lot from my previous experience into my current role. A lot of what I was doing in my previous role was implementing product processes, and helping teams to communicate across silos. Twilio has one console with all of our products, and it's important that we present a consistent view and point of view.
In a lot of ways it was a natural progression to my research role now. I'm still doing the same thing—I'm working across various small product teams and advocating for their users. But then it's also: here's the data from this team, and here are some interesting insights from a survey that we ran on this other team. You can take that cross-silo information and empower yourself with knowledge, and you don't have to necessarily invest the time and resources on your own team. We can work collaboratively even though we are small teams.
Sofia: Do you envision Twilio having a ResearchOps team in a couple of years? Or do you think that one person can lead that completely?
Shavika: The way our team is structured today is a hybrid embedded model. We have what we call our PD core team, the product design core group, and they work agency style across many of our products. We also have a few dedicated designers that work within our product initiatives. This hybrid style of embedded model works for Twilio. That said, as the team grows, its possible larger teams could require their own ResearchOps teams.
Sofia: Why do you think this is the right moment to start building processes around user research? Is there any organizational change taking place?
Shavika: There's that famous saying—if it's not broke, don't fix it. But just because something isn't broken doesn't mean it can't be improved, right? What we've done to date has worked, and we're starting to see that we can do a lot more, and we can do a lot better. And there's also that idea of working hard and working smart. By including design and research as part of the process, I think you can work a lot smarter.
And often you uncover insights and potential product features or goals that you wouldn't have earlier. We’re starting to see a transition where things have been working, but there are some systems that are a little out of date. And if we’d had that design thinking earlier we would have reduced a lot of our technical debt. I think the sooner you start building lightweight processes, the better, but you do need to have an idea of what kind of system or process will work before you build it, and that’s not always an immediate discovery.
Sofia: If we were to fast forward a couple of years, where do you think the whole conversation about ResearchOps would be? What will we be talking about?
Shavika: What is interesting to me currently as a UX researcher is that there are a lot of resources and information that directly apply to traditional academic research in universities, or at large legacy companies, and then there are researchers in start-ups. Of course the principles are the same, but there are different needs. When I connect with researchers who are more academically focused, it’s been challenging to explain the constraints of our systems, our timelines and our product ship points. A lot of our product ship dates and timelines mean I need to turn over research findings and results quickly, and often don’t get to run my experiments as accurately as I would like. So I hope to see more start-up or industry focused resources: at least that's currently what I'm interested in!
Sofia: Can you tell me a little bit more about that difference? And where did you see the most dramatic difference between somebody working in tech and somebody working at a completely different place?
Shavika: Tech is fast moving, constantly changing, and can be a really competitive landscape. I’m sure it’s like that in other industries as well, but the sense I get when I connect with other researchers is that they are able to plan further into the future than we are at a fast growing startup. One example that comes to mind is participant screeners. Recently I found a great one from a university, but it had a lot of demographic information like age, gender, location, etc. which doesn't really apply to a developer experience which is core to Twilio.
What matters to me are things like, how long have you been developing? What languages do you code in? What stage of development are you in? And having to identify those variables is new. I haven’t found too many resources in that area, so it’s tricky.. Where do traditional demographics matter and where don't they? What are our demographics?
Sofia: You have managed to successfully transition to very different roles over the years, from Sales to Product and now to ResearchOps. How did you do it?
Shavika: Not without struggle and stress, that's for sure! When I was an assistant and I wanted to move over to design and research, I was doing two jobs at the same time, which was exhausting. The great thing about it was it provided exposure to our product meetings and design reviews, which I really took advantage of. What’s also been so incredible about moving from departments and teams is that it's almost like working at a new company every nine to twelve months.
There's a skill set that you develop—anyone can—where you come in and treat it like you’re meeting a new client, so you build a framework around it. You start to learn the questions to ask. Eventually you answer those questions and you figure out how to put yourself in those positions.
Whether I was an assistant in sales, engineering, or product, I was learning to put the puzzle pieces together in each of those different teams, and that's how I now treat all of my projects in research. Surprisingly, there are a lot of borrowed skills.
Another important point is curiosity. A good portion of my week is actually researching things I should be researching and knowing. And communities like Medium are incredible—the UX design community in Medium is huge. There's a Slack group called Designer Hangout that I reference a lot. I also spend a lot of time doing cold reach outs to other people in my position, and I’ve found that learning by doing is probably one of the best ways to grow.
And you know, that learning doesn't always have to come from your discipline. Back when I was an EA, seeing product managers trying to pitch and make a case for their products and features taught me quite a bit, especially from the executive standpoint. We have a great level of transparency at Twilio. So by attending those meetings and watching and learning from others I picked up on their skills. Everything from negotiating, learning how to frame a meeting, and learning how to think about products and designs at all angles as prep for your meetings—those are the types of skills I’ve witnessed from the people around me, and I believe can serve you well in ResearchOps and in your career generally.