0–3 years: UX Research @ Google
A collection of interviews exploring the experiences of designers with 0–3 years in various UX-related roles in various types of working environments.
Wanting to spend my COVID lockdowns in a less miserable manner, this project was born. It’s spurred by a number of things: an awareness of UX becoming more multidisciplinary, a curiosity at how my fellow UX peers are doing, new UX people asking me how I broke into the industry, and the desire to take full advantage of my LinkedIn Premium trial.
📝 This is part 1 of an ongoing series, read: part 2 about Service Design or part 3 about UX Writing/Content Design
Veronica Lin — UX Researcher @ Google
At the time of this interview, Veronica was a UX Researcher at Google, working on features for Google Maps. Previously she worked at Commonwealth Bank in their digital stream. Currently, she works as a Product Designer at Zendesk.
We go through topics about being a UX Researcher, from the research industry to some good skills to pick up. Contents include:
- Getting into UX research
- The highs and lows
- Expectations vs reality
- Growth
- Skills (Statistical significance, anyone?)
- Tips for job hunting
Tell me about yourself, and how you got to where you are currently.
V: Originally I did a Bachelors of Commerce at UNSW, majoring in information systems. That exposed me to the world of tech, and specifically UX.
Like any penultimate student, I was freaking out the year before I graduated, and thinking that I needed to find a job, so I applied to a bunch of places, one which was Commonwealth Bank of Australia’s digital stream where they decided I‘d do UX. In retrospect, it wasn’t really UX, it was just doing user testing sessions and trying out Axure. But that was my first glimpse into user experience and I was exposed to the whole product design process, from research to testing to building a product. As I was exposed to UX designers and researchers, it got me thinking about what it would take to be one.
Just before I was graduating, a UX research internship popped up for Google. To this day I still don’t know how I got in, but I asked my manager and she said ‘You know, we just saw potential in you’. But that’s how I got the summer internship at Google, and that was my leg into UX research.
At Google they gave me a really substantial project where I did a research project end to end where I was really able to make an impact from the research. Fast forward to now, I’ve been working there as a contractor in the Google Maps department. However, as we speak, I’m in the process of changing to a product designer role since it’s more end to end.
Retrospectively, what were the main things that drew you into becoming a researcher in the first place?
Yeah, I think two main things. The first thing was that I really enjoyed and found that I had a knack for talking to users. When I was an intern, I was interviewing a bunch of users relating to a specific feature that we were thinking of launching and really validating the need for this.
The second thing was, I really enjoyed storytelling. I enjoyed synthesising a lot of information to deliver impactful insights to my stakeholders, and also engaging them in a bunch of creative ways to jam the insights. My research gets used as part of the sprints we do at Google to get ideas going. I was able to see how the work that I did made an impact, and I felt really good about it.
You mentioned that you’re transitioning from research into product design, what’s the reason?
I think two reasons. First reason is that, although I love research, it’s a really focused role at Google. The designer decides what to do with the research you’ve handed off. You might have something you really highly recommend but you can’t force them to do it. So, your impact somewhat ends there. I felt that I was missing the ability to take my research into something more tangible.
The second reason is that I’m still really early in my career and I want to figure out if research is something I want to do for the rest of my life. I could definitely have climbed the ladder of being a researcher, a senior researcher, a lead researcher, etc. However, this year was really about evaluating what career I wanted to have, what skills I wanted to build.
Going down the product design lane would allow me to explore research and design and make that impact that I really wanted while figuring out what I want. Eventually maybe I might just go back to research knowing that I had a gig running as a product designer and I’ll come back as an even better researcher.
You’ve talked about all the good things about research but what are the not-so-shiny sides that are important to know?
V: At Google, research has a really big seat at the table. But industry wide, I don’t think that’s necessarily the case for all companies as that not every company has the budget or resources to have a really dedicated research team. Although across the industry more teams are beginning to see the importance of research to strategy and product development. However, it’s often seen as something that’s tacked on at the end, like ‘Oh, let’s just bring in research to validate this design’. Depending on your company and how it respects or perceives research, you may not be put into projects, or slotted in at times where you would have the most value.
Working at Google, research is really end to end. You’re coming in at the very beginning to figure out questions like ‘Is this the right thing to build? What are we going to build?’ And then once you’re building something, validating how you’re going to build it, and then at the very end, measuring whether that was successful.
At smaller companies where there aren’t dedicated researchers, or they may be the first researcher, it might be hard to fight for that seat at the table and enter yourself into teams.
I’ll give you an example. There’s a particular product that Google’s bought out, and I know the researcher is the very first researcher. She’s personally talked about the struggles of joining a team of engineers who built this feature without the need to research. Suddenly there’s someone coming in telling them ‘Oh, you need to change this and that’.
It’s important to build really good relationships with your stakeholders, take them along that journey, and identify yourself as a partner as opposed to a service that just gets tacked on at the very end.
Have you personally found yourself to be in a situation where you’ve really had to advocate for your research to get heard?
I’m still considered more of a junior researcher in terms of levels at Google, and that means that I have senior researchers to help scrape out a lot of my work. So they actually do a lot of the grunt work to get research plan scoped and really push for research. Personally, I haven’t had the challenge of trying to convince a stakeholder that research has to be done, I’ve mainly been in the shoes of executing, following up and continuing to push for research.
In terms of just deciding whether research has to be done in the beginning, it’s been really good in my team. Google just has a big philosophy and culture that you must really talk to users. Often times, they’ll be like, ‘We’re undecided on something, let’s just test it’, and we’ll go to users and get answers. But I definitely know that’s not the case with every team, but I personally haven’t experienced those struggles yet.
Looking back at when you initially joined vs now, was there anything unexpected that you realise is actually really fundamental to being a researcher?
The amount of collaboration needed. The structure of Google is your typical triads or quadrants with a designer, a product manager (PM), an engineer. At Google, there’s a researcher and PM to almost every team, which I didn’t really expect. I thought it would be like a centralised research team that would do the research for everyone, which is the structure for other companies. At Google, you’re embedded within your team, and you’re working with them hand in hand to figure out what to build, how to build it, if the build was successful etc. Every step of the process, you’re almost like what a designer would be in a team but split into two because you have a dedicated researcher.
What that really highlighted was the amount of collaboration that’s involved as well.
My perception was like, ‘Okay, researcher sits more on the side, and we sit much further ahead to lead the way with insights’. We do that but while we’re looking ahead, we’re also in the day to day making sure that things are running, being tested and being validated.
I’m curious to know whether you see any cons with having a research resource embedded into each team?
One negative is that our teams are set up to work on features not products. For example, Google Maps is a broad product, and features are just like little tabs or different experiences within the product itself.
If you’re having researchers on each feature, which should inevitably bubble up to an overall experience, it means that there has to be also a lot of alignment between the researchers to not overlap with the research that you do.
But overlap can often easily happen since you’re silo-ed and you never really get to talk to your fellow researchers besides a critique where you talk about your projects. This means money and time costs, since you’re repeating research that has been done.
One thing that Google is trying to improve on is how to create a centralised repository of research to alleviate this problem. We have something, but it’s kind of old. It hasn’t kept up with the needs of researchers at the moment in terms of ensuring that people aren’t repeating things, being able to tag search, having smart search etc. So I guess within my broader product area, we’re trying to figure out a way to ensure that people can pull on research other researchers have done and apply that to their own domain. At the end of the day, we’re working in the area of transportation, and there’s definite connections internally to be made.
Let’s segue to the topic of growth. What do you think is something that’s really helped you grow as a researcher?
So, I’ll give the honest truth. But I also know that this may not be something everyone can do, so I’ll give another tip that more people can follow.
So the first thing is, I was just lucky to have access to a lot of senior researchers at Google who’ve been doing this stuff for 5–10 years and from many different backgrounds. I’ve worked with over 7–8 different types of researchers and have been exposed to their different styles and thinking. What really helped me grow was being able to get feedback from those seniors.
Also, learning how to communicate my findings to my team, and then getting them to actually act on those insights. That was a big process of building a good relationship with them, and really understanding the point of why we’re doing that research.
When I finally understood that, that was the key. It became more about not doing research for research sake, but about really understanding what your team is trying to solve and what the research problems are. At the end of the day, you’re here to help de-risk solutions, you’re here to help reduce ambiguity. If you can really do that for your team, and they find value in you, your career directory will grow because you’re achieving your goal as a researcher.
The second part of that is, before you can grow, you just also really got to learn the basics. What this really means is just know your fundamentals, know the methods and be okay with just being given a project, and just learning the method and doing it properly. It’s not about trying to work on the most fancy thing or knowing all the different methods.
Once you know how to do the methods, you know when to apply them, and knowing when to apply what method is more important than knowing all the methods.
Also, don’t worry about not knowing all the methods, because when the time comes, you will learn it on the job, and you’ll apply it. There are researchers that are quite senior who have never done certain methods like diary studies, because the opportunities never come up. You don’t just randomly do a diary study for the sake of it. Learning when to use them and why you use them trumps going through a box of ticking off a list of methods to use. So focus on how to do something right and when to apply it.
Let’s pull apart some things you mentioned earlier. What are some things that really helps in making insights actionable and getting better stakeholder relationships?
I think one of the biggest things have just been involving the team throughout the process. So not just pulling them in at the very end being like, ‘Okay, I’m gonna do a readout of the report on this usability study’. It’s about pinging them into the doc and telling them what these screens are that you’re going to show your users, or asking your PM what do you think of this, and asking engineers to be involved in the debrief etc.
For example, we ran a RITES study, which is a Rapid Iterative Testing and Evaluation Study — big mouthful. We did a collaborative analysis and also a collaborative debrief for the insights. We jammed with the UX team on what we do next. So it was also about being a researcher facilitator, as opposed to someone that just does the research and goes away for a week and then reports on the insights and came back.
The one thing that really stuck with me in the very beginning when we adopted these methods was an engineer came up to me and said that they felt really excited to build this feature now because he’s seen it change and because they were involved every step of the process to see it go from iteration one to final iteration. He said that he had some ideas about how they might go about reframing and designing things. It’s all about involving your stakeholders on the process and making it fun.
I’ve tried to make things fun in terms of sharing insights, like with watch parties. So making highlight reels of different research sessions, and doing quizzes based off the research findings. More recently, we’ve taken use of Figjam to debrief on research, which we’ve never really done before.
At Google, I would assume everyone’s always pretty open to working together. Is that the case?
50–50. I’ve been on some teams where everyone’s been really super enthusiastic and evolved, some other teams where not everyone is as keen, especially because everyone’s busy, and particularly some engineers as well. They kind of feel overwhelmed when it comes to collaborative analysis and debriefs. It goes back to the whole, ‘What am I good at? What value can I provide?’ And oftentimes, they feel like they can’t provide any value. So it flips on you to make them feel really comfortable with being involved. Make it super easy for them.
For example, at Google, when we do usability tests, we get our stakeholders to write notes for us because we don’t have any tools to transcribe anything. We tell them they have to come and note take, otherwise we don’t have any documentation. But it’s simply just for empathy. We make note taking sheets, where it’s super simple to follow. They can fill that out and we can talk about it when it comes to debrief. Or, when we do watch parties, we’ll call them out and ask ‘What do you think about x?’. We break into smaller groups and have discussion points to talk about something so they’re not left on their own, almost like holding their hand while empowering them through the whole process.
All you really want them to do is to feel involved and feel invested in the process, because they don’t want to be given a design at the end of the day where they have no idea what decision making was involved.
This matters once something gets to development stage, sometimes engineers would decide not to do something because of issues like feasibility or they personally feel that it’s not important. But if they came and understood why users need this, then it helps them feel more invested enough to build it.
It’s really about bridging that gap. It’s so much easier said than done, it just takes a lot of patience and it takes making it fun. Often times it feels like a big burden on research because you always question why you have to put in so much extra effort just to have others listen to your work. But it always pays off in the end, when it comes to things being developed or when decisions have to be made, since everyone’s on the same page.
Aside from some soft and hard skills you’ve mentioned already, are there any other soft or hard skills you find important?
Critical thinking and product thinking for hard skills. Really thinking about the why behind why you’re doing something. Also being able to critically assess whether something is the right method to use given the constraints of a business.
This leads into a really important skill about making trade-offs.
To become a good researcher in a product team, you need to think about the constraints of the business, and how you can adapt your method to deliver the insights that are needed at a bare minimum to get the team going.
I initially thought as a researcher, I needed to produce solid truth and do things completely right. It’s a science somewhat, and you’re using scientific tools to produce results, and you want those results to be as accurate as possible. But that’s just not the true reality.
One other non-mandatory hard skill is statistics. Google specifically, we do a lot of quantitative stuff like surveys, and comparisons A/B testing, we look at logs and metrics and all that kind of stuff. And you need to know how to interpret that data. In my internship I actually had to brush up on a lot of stats that thankfully I learnt in my commerce degree, but honestly you can pick it up on the job as well.
I think it’s so important, not only for research but a general good skill to know how to interpret data, and be able to derive meaning without bias.
That’s super important as a researcher, especially if you are going to end up running surveys or anything like that.
Personally I hate stats and I remember specifically being deterred from a psychology degree solely because someone told me it’s majority stats. For those who don’t really know much about stats, how would you start building that skill?
To make you feel a bit more confident, I also learned on the job. And all those stats sounds like a really big scary word. It sounds like you have to be really good at maths. Just to put it out there, I’m not good at maths.
I would say like the most important concept to understand in research that would be exposed to you on a product level is statistical significance. Understanding how to compute that and interpret that. Also learning to display in a meaningful way.
So, learning what type of graphs to use, learning how to display the data to make it meaningful, and to help your stakeholders interpret it. So you’re then having to apply the insight on top of the data in a way that makes sense. This stuff I learnt through the senior researchers that I was paired up with, but it’s easily something you can learn through YouTube videos and Googling it. Often what I did was, I just have to Google what was the outcome I wanted from this piece of research. Then I’d tweak my graphs or tweak my data to reflect that. Data at the end of the day is also just about storytelling, there’s so many ways you can split data to tell a story.
Tell me more about statistical significance, I’d love to know more.
So statistical significance, it means, if we wanted to know whether experience A was better than experience B when experimenting, being able to confidently say that A was better than B and interpreting that data. That’s like bread and butter, because you could definitely interpret the data as like’ Yeah A is definitely bigger than B based on how the bar graphs look like’, but if they’re not statistically significant, they’re actually exactly the same and you’re telling a lie to your stakeholders.
Another example would be, let’s say I wanted to test copy with one string, and then copy with another string to determine which performed better, that’s an A/B test. You might find that 3% more people clicked on A than B, but you need to make sure that the differences are significant because the amount of people you might have interviewed may have been really small. And given that, there might not actually have been real differences, because let’s just say you’ve only tested 100 people, and that’s really low. But let’s say you test 10,000 it’s probably going to be different. So how you calculate that is all about looking at statistical significance. It was something that I had to learn on the job, which was really important and critical. It’s really important because you could be telling your stakeholders, yes, A is better than B. Or you could be telling them that and it’s not the truth, because there’s no confidence between those numbers.
So if I’m interpreting it right, it kind of sounds like not warping results to be proportionally biased and having validity and confidence behind your results.
Yeah, and then also just like computing the fact that it can be statistically significant. There’s actually a way to determine it using something called confidence intervals, which determines it based on how many people you surveyed, what the difference is, and whether they are different. To apply this in another context like clinical trials, and figuring out whether did vaccine A was better than vaccine B. If you found that there was like, higher likelihood for vaccine A to work better but then you find out that the confidence interval is really big, and they overlap, then you actually can’t say with confidence that vaccine A is better than B. So it’s really important to know the concept of statistical significance, because you could run a bunch of surveys and just be looking at the numbers as is. But that’s not the true story, you have to be looking at it through confidence intervals and also how you display the data.
I wanted to touch more about hardships and growth as a researcher or just personally as someone new-ish to the industry. Are there instances you can think of?
I worked on something really big, and eventually, the feature got canned and none of my insights got used. But more recently, my research is being used for something else. Even though the research I did technically had shelf life, at that moment it wasn’t used straight away and I felt really bummed about it. I was like ‘Oh, what’s the point of a researcher my insights can’t be used’, because really, your impact as a researcher is your inputs being used. But often times, this is a huge learning that I made that defined my growth as a researcher is that your research should have a long shelf life.
That’s really empowered me knowing that good research doesn’t necessarily expire and that’s how you really make impact when teams down the track will still use that research later since there’s longevity and durability. Insights about humans may not really change, it’s just the context that might change, you don’t necessarily have to do it all again — it’s about changing the question or angle, and understanding what’s durable and not durable.
It’s not about producing new research all the time, it’s often about going back to what you already know, and flexing it in a different way and applying in a different context because some things will stay true no matter what.
What are some key indicators about whether someone will enjoy a career in UX research?
I think if you enjoy talking to people, that’s a really big thing about being a researcher. Even though I’m pretty introverted, I still really enjoy talking to people and understanding them. As a researcher you’ll be doing a lot of talking to people. Other
Questions to ask yourself is ‘Do I have a knack for storytelling? Do I like synthesising a lot of data and making meaning out of it? Does that seem exciting to me?’.
If it does, then consider being a researcher, because that’s really what your job is about — being able to understand the why, and then synthesising the data from the investigations that you’ve done, and then making some meaning out of it and some recommendations.
Also, if you really enjoy working with others, and getting them excited to make changes, it’s also something you might want to consider. If you don’t like working with people, or you prefer to have just a job where you work more on your own, you might not like research since it’s rather collaborative since you have to advocate for your users, your changes and your roles. There’ll be debates and sometimes you might have to challenge others, so if you don’t like that then reconsider.
And when it comes to strategies for the job hunting process, do you have any tips?
First, candidates should be able to really demonstrate why they chose to do certain things. Second, be able to link transferable skills from your current experience to research roles.
I think there’s two types of people that go into research. They’ve either never had an academic background, but have business/product thinking. Or, they’ve had academic background, but no business/product thinking.
Being a researcher is all about being able to synthesise data, make meaning from lots of insights, communicate those findings, and collaborate with others. If you can touch on those key important skills of being a researcher from other areas of your life, then that’s a really good way to present yourself.
For applications to tech companies, a lot of them would expect you to have a portfolio presentation. Even for my interview for Google as an intern, I was expected to present a portfolio. Whether that’s personal projects, research experience, or something related to research that you’ve done at uni, put those in. You don’t necessarily have to reveal specifics of the project, but really talk about what decisions you made, why you chose xyz methods, how were you able to come to insights, what challenges you faced and how you overcame them? If you can’t talk about any challenges, then it’s likely that you didn’t really complete the project, because there’s always challenges.
Also for interviews, there’ll be interview questions on things like communication, creativity, collaboration, ability to synthesise data.
I’m going to wrap up with a classic question — What last words would you impart on people in the research field?
If you’re already in the field, then take it easy, and you’ll learn things as they come. Have the mentality that there are a lot of things you could just learn on the job, but have the curiosity to get better and ask for feedback from others.
Get feedback on your methodology, insights and framing. If you don’t have that ability, talk to stakeholders and get feedback on how you presented something, and whether the insights that you’ve developed was useful.
Also, it’s okay if you don’t get the chance to learn a method. It’s more about learning when and how to apply it than having the chance to apply it, so don’t beat yourself up over it.
If you want to break into the research field, then really welcome building those transferable skills, because you don’t necessarily have to have been a researcher to get a research role, so definitely don’t let that prevent you from getting started. Just be really curious about learning the why of something.
Frame it on your wall
✨ It’s really important to build good relationships with your stakeholders, take them along that journey, and identify yourself as a partner as opposed to a service that just gets tacked on at the very end.
✨It’s not about producing new research all the time, it’s often about going back to what you already know, and flexing it in a different way and applying in a different context because some things will stay true no matter what.
✨ To become a good research in a product team, you need to think about the constraints of the business, and how you can adapt your method to deliver the insights that are needed at a bare minimum to get the team going.
🚨Looking for: Game Designers, Visual Designers, Interaction Designers, VR/AR Designers, UX Strategists to feature! (Or any other design related discipline I missed)
// Still to come : UX Writer, Service Designer, Product Designer //
