Javier Bargas spent over 14 years at Google, beginning as a UX researcher on YouTube and eventually becoming Director of UX Research in 2022. He led a centralized team of 25 researchers at Google Play and pioneered initiatives like the Rapid Research program to accelerate product optimization. He also developed scalable systems to measure Critical User Journeys and UX metrics. Just two months ago, Javier founded Astrolabium — a training and coaching company dedicated to empowering UX designers and researchers. In addition, he mentors at Design for Good and lectures in the Department of Psychology at the University of Basel.

Why focus on UX research?

Yuriy: Why did you decide to focus on research?

Javier: I started to study psychology because I wanted to become a clinical psychologist and help people with mental disorders. I realized early on that this wasn’t for me—it was too tough. I was always very interested in technology, always the kind of kid that would build computers and figure out the latest tech. But I always knew I didn’t want to code.

While studying, I discovered the area of human-computer interaction, which later became UX. I realized there's this overlap between psychology—humans—and technology. So that’s why I moved into research. It was the natural next step.

Empathy vs. science in research teams

Yuriy: When you build a team, do you focus more on people who are more scientists or more who feel people?

Javier: I don't think that if you are an empathetic or not that empathetic moderator really depends on if you're a psychologist or something else. It's not like when you study psychology, you necessarily learn how to drive empathetic conversations. It's more a personality thing. And personally, I think the best teams are always when you mix different facets, different backgrounds, when you have diverse teams that nurture each other and where you have different strengths. So for research itself too, like there is absolutely a place for maybe a very empathetic ethnographer that believes in deep research with one person, understanding them really deep, and then maybe having someone that is more on the quantitative side of research that wants to run A/B tests or surveys and so on.

If somebody reads completely like a robot, in an interview, then they're likely not that good of a researcher in the first place. So you can create a nice atmosphere where a user feels like in a good situation to open up without compromising your neutrality and basically becoming biased or something like that. That is what good researchers do.

The human connection in UX research

Yuriy: Some time ago, many argued that during online interviews, cameras should stay off. The reasoning? Once people see each other, they try to be liked. They behave differently. So the idea was to strip the interaction of human cues — just audio, minimal connection, no emotion. Has that mindset shifted? Or do some still believe less connection leads to more objectivity?

Javier: There will always be people that argue that way. If you think about psychology and how psychotherapy came to be with the beginning, like Sigmund Freud, he put people on a bed and had them talk to the wall for an hour. He wouldn't say anything, wouldn't look at them, would just take notes. Right? And there are still people who believe that's the right way to do it. I don't think that there is value in that.

Then, there's different purposes for research, right? And if we're talking about UX research, the main purpose for UX research is to generate insights that help the team move the product forward. And as such it is important that you speak with users, potential users, past users, and you create a connection. So yes, absolutely. You should have the camera turned on. You should create a connection with that user. You should make them feel comfortable so they are able to open up and also say good and bad stuff, right? That they can feel as natural as possible, even if it is an artificial situation. So I don't know who said you should turn off the camera, but I think that's dumb.

Nobody is a low performer

Yuriy: You posted about poor communication from companies that label people as low performers. How do you handle situations when someone stays a junior for five years?

Javier: If somebody doesn't progress, it is not always because they don't have the potential. Maybe they are in a situation that leads them to be in that position and they don't figure a way out and you try different things, but they get stuck. And if they leave to another team or maybe another company, they're in a new situation. 

Maybe that new environment gives them what they need to progress. So that's why I refuse to call somebody a low performer. Somebody might be performing low, like might not be performing well enough in that situation. And I do think that the team and the manager bear part of the responsibility for that, because as a manager, your job is to create an environment where somebody can prosper.

I have worked with people that struggle with performance. We have tried a lot of different things to help them get on the right path, but sometimes it just doesn't work out. And you have to admit to yourself as a manager and them to yourself, to themselves that this is not working out. And so changing the situation to a new one, maybe within the same company or even outside the company can be a healthy thing. And I've had situations where people came back afterwards to me and said, ‘This was the best thing that I left. That I did this new thing. Now I'm doing much better.’ But sometimes someone doesn't have it in them, right? They are at flying altitude. They cannot progress. And I've always questioned that attitude of endless growth, right? It's like everybody needs to always grow, right? And so if you're a junior, you have to become a senior. 

Why is that? Right? Like, why do we hire a junior in a company? We hire a junior company because there is junior work to be done. Right? If all the work we have is for seniors, why would we hire a junior? So we're hiring a junior because we think that there are specific tasks, there's specific work that can be done by a junior. If somebody stays junior for forever, they can't progress. Is that necessarily a bad thing? If we have junior work to be done, right? Can we not say. 

Well, if that's how you feel comfortable and you're doing a good job as a junior, right? You're performing, you're delivering, right? You're cheap because you're a junior. So we don't have to pay you a lot, but like you're happy. Right. And this is like, why can this person not stay junior forever? Right. Why does everybody have to grow until they're at the level where they're maybe like the Peter principle, you have promoted yourself to a place where you're incompetent.

At Google, it was like that. There was this expectation of people having to grow, right? So it could become a problem if you're at the same level for too long. But I don't know. From a human perspective, I think that's wrong. And I also think it's not possible to grow forever.

Yuriy: I totally agree. Maybe the problem is with the name of the position because junior means that you are somebody young and if you got older, you have to become a senior.

Javier: Yes, maybe. But maybe the assumption that junior means you're young is just wrong. There is really an ageism part there. I’ve had women on the team that moved at the later stage of their career into research because they studied something that they had that had babies. They had a break, and then they came back and they studied something else. And then they moved into research when they were like way above 40. They were junior researchers because that's what they were. Like they had not worked as a UX researcher before. And that was fine. So I don't think that assumption that junior is young is correct, but I agree there is this perception in the industry that this is what it means.

Tech push vs. User pull in the AI era

Yuriy: With AI, we see tech being pushed before understanding if people need it. Like the Humane AI pin.

Javier: Let’s detach this from AI for a second. Successful products solve problems. It will be hard for you to come up with a good example of a product that solves no user problem, but is super successful. And, history is paved with failed products that have been built without really solving a problem. Part of hype, which is something like the Gartner term, like the hype curve.

Part of hype when a new technology comes in is that everybody jumped on that technology. It is a hype and they start developing a lot of stuff with that technology inspired by the possibility of the technology. And what happens in these hype curves is that companies stop looking at problems and start focusing on technology. So instead of being a user centric product development, it becomes a technology centric product development. And whenever that happens, you can show examples of why that didn't work and how products failed.

So there's a lot of companies and also big companies like Google, just jumping on that and shoehorning AI into their products without thinking what problem is it solving. And if we're talking about what problem is it solving, I don't think that you have to go and do research. So it's not the research and me saying, wait, wait, before we do something with AI, we need to go study users. Because we have studied users for years. All product teams at Google know what the main problems are with those products. 

So you have a long list of problems that are unsolved, right? And you can take those and say, okay, with these hundred problems that we know, which of those can be solved with this new technology called AI? And I give you an example for where this was done really well – YouTube. 

For YouTube, we do, we didn't know for years since YouTube exists that one problem that we have is that the access to videos from people that don't speak the language. The world is big, YouTube is global. So, we've built band-aid solutions. Such as captions. Okay, you can upload captions, but who has the money or the time to actually afford creating those captions?

So that is not, then there's auto captions, which have been traditionally really poor but that was kind of like at least something so you can watch a video and understand it. Now, AI comes along. And with that, the possibility to automatically have a voice track in another language, which is pretty good. And so that's what YouTube did. They created this new feature that larger YouTubers already have access to where your video, like if it's in English, will be automatically in 20 different tracks. You can add some experimental languages. So it's not fully flesh out, but now somebody in Japan can watch my videos in Japanese. That's an amazing application of AI. 

A bad example for that, where it's also a problem, was this AI pin, Where you would say, okay, we developed this new device that is like this assistant in a device that you take with you that you ask for stuff, such as book me a flight. I mean, that was one of the examples, right? Book me a flight to New York, which we knew already that this was not a real problem. Like nobody wants to book their flights through a voice interface. At Google, we did the same mistake for Google Assistant. We developed the entire process of somebody through Google Assistant booking a flight or a hotel. It was a total failure. Nobody used it because it turns out nobody really wants to book their flight that way. And that we knew before. 

So, starting with a problem is key, especially for AI, because it's really expensive, not that much to build it, but to run it. Run those models, need data centers, you need processors. It's just costly, right. So if you build a feature that nobody's asking for and nobody will use it, and so you wasted a lot of resources.

The launch trap: Perfect vs. Good

Yuriy: This is also interesting because on the podcast yesterday I heard some developers sharing their experience about Google Gemini and they said that that was one of the biggest mistakes of Google because they were so in a hurry to launch their own AI that they had to... and everybody was saying, 'Okay, you have to try it, have to try it.' And everybody tried this product and then the quality wasn't as good as some top state-of-the-art models and now everybody thinks that Gemini maybe is not so strong and it's much harder now to ask people to try this again.

We had similar situations with many products that introduced AI too soon. People tried to use it, but didn't see the value. And then, for example, in ClickUp, when I log in into ClickUp, every time it pushes me to try our AI again, we have a new AI feature. Maybe now you will see the new value there. Because I tried it a long time ago, I didn't see the value, and then I stopped using that. And now it's much much harder for them to convince me to try it again.

Javier: I agree. And that is the problem of this stupid mantra of perfect is the enemy of good. So that's like what they always say when you're like, it's, this is not ready to launch. You go like, perfect is the enemy of good. Like I wish we would be talking about perfect. We're talking about good, right? So it's actually not good enough is the enemy of good. Right. And quality matters, especially to users, right? When they try it out, it's a very delicate moment.

Yesterday I tried out a tool to automatically translate Google slides. In Google slides, 60 slides, it's in German, I need it in English, automatically translated. It's actually not that difficult, but AI made up stuff and added sentences that were not there. I mean, this is so bad. I will never try that again. You should be careful before you launch crap to users. And it's not that Google doesn't know that. Like Google has made that experience many times. But it is part of the Google DNA to break things to learn, right? That was since the beginning. It's like ‘Launch fast and break things and then improve, improve along the way.’ And that worked when Google was smaller, but when you have billions of users and you launch broken crap, then the consequences are different but Google can't get rid of that DNA.

The post-pandemic research landscape

Yuriy: After the pandemic boom, demand for UX researchers is down. What’s the future?

Javier: First of all, I have to say that this is not a UX research specific thing. In the pandemic, all disciplines hired like crazy, PM, Eng, design, all facets of UX and all that demand has gone down. I have not seen data yet that would show convincingly that research was impacted harder than other disciplines. And I'm working with a lot of people helping them to find jobs, And it's not like, despite me being a researcher, I work with many designers, right? So it's important to not create that perception that research has been somehow hit differently. Product development in general has experienced layoffs and you have people of all disciplines struggling to find jobs.

Hopefully, companies will stop laying off people one day because right now they seem to like it a lot and they passionately lay off people over and over again, which means the market is flooded with talent. And as long as this happens, the situation will stay very difficult. But as companies hopefully will stop doing that in the future, things will normalize. And as product teams will grow, that means design and research and all the disciplines will have their place there.

So I don't see a future where you can develop reasonably like good products without generating user insights. Now the question, if there will be a hybrid model of design and researcher, that's kind of an old thing. It's actually not a new question. It's an old one. Like UX generalists, they were called. And if you look at the maturity development of UX teams, that is typically where it begins. So low maturity companies will have generalists. So maybe they have no UX discipline and then suddenly go like, what is that? We need something like nobody thinks about the users. What should we do? Well, we need to hire a UX. So they hire and the job posts, you can read them. It's like a UX specialist or sometimes it's called UX designer, but it lists research, right?

As the UX teams grow and mature in that company, maybe the next couple are also generalists, but then eventually the UX discipline itself will say like, well, this makes no sense. Right? Like we need good designers and we need good researchers. We shouldn't have people that do both and we should not have people test their own stuff. So we need to split and then they might add research later on. might add writing and other disciplines too. And so as they grow in maturity, they move away from people that do design and research.

So typically when you look at job posts of generalists, these are either startups that don't have enough money to afford multiple UXers or it's companies that have no UX tradition and they're starting to move into that direction. And so that's what they're looking for. But I don't think that the future is people doing both. And in fact, like when I work with people that struggle to find jobs, it's very often people that have a profile where their resume says, I'm a UX designer and researcher. And the first thing I do is like, you need to focus, right? Are you a designer or a researcher? We throw that stuff away, we rewrite resumes and suddenly they get interviews because now the recruiter sees, that's a designer. And they don't think, like that person doesn't know what they are.

Integrating research into product teams

Yuriy: Some companies treat research as a service org. Researchers drop in, validate, and leave.

Javier: The problem here of what you described is actually not the research problem, but it's a service model problem, right? Because some companies even have that for all of UX, right? Like UX is a central entity. And if you need UI support, you will go and ask for a designer. And then maybe you go and ask for a researcher and exactly what you described happened. And so if a company has a situation, it's because they build up a crappy org, right? They don't understand UX and they don't understand product development, frankly. We don't understand that product development is teamwork and that you need the people that work on the specific products or features to work together. And that includes also research. So the researchers need to be part of the team. Yes, you typically have less researchers than designers.

So you have between design and research, maybe you have like two-three designers per researcher, which means a researcher will work on more than just one product. When I started at YouTube, like 2011, I was in charge for YouTube in the creator space, for the upload flow of YouTube, for analytics, which is like how traffic to videos, and for annotations, which is no longer around, which is kind of like you could write stuff in your videos and things. And these were three teams, and I supported all three of them. But I was part of those teams. I would maybe not sit with him all the time, right? There would be phases where I wouldn't sit with them because deep down I didn't need to do research, but I knew about the three products. I knew about all the stakeholders. I was involved in that.

That is how it needs to work for design and research and writing and other disciplines. They need to be part of that team. It cannot be a service org. And so if, if companies had that problem, that's just because they built up the wrong org and that serves them rights. If they build up the wrong org, they will have bad results.

On engineers dismissing UX research

Yuriy: A Twitch engineer claimed UX research can’t reach top creators and is ineffective. His name is Theo Browne, and here’s what he said: ‘Doesn't twitch have user research though? The problem with user research is the people that you want to get info from which are the top creators they don't respond to user research requests and if you're doing user research the people who get that email from twitch and they're like yeah I'll dedicate an hour to telling twitch what's wrong they go in and complain about how hard it is to be a small creator and if you listen to those people you're going to ruin the platform I know that because they ruined the platform so no there there is no user research that works at a company that has that level of teering between its users you can't interview the users that matter you have to understand the users that matter you have to be friends with them you have to be the person they call when something goes wrong there's no world in which twitch's user research could ever have solved these problems it just doesn't work that way.’

Javier: Well, yeah, I don't know that engineer, but I think he is full of s*it.

So, you should teach PMs to, have maybe not beers, but coffee with, with, with their users. I, that is a discussion I have regularly with researchers when I go like, no, my PM wants to talk with users. I'm like, yeah, let them. It's important. You need PMs to have empathy for the users. You need, you need to understand, they need to understand the problems. They need to have those relationships. Absolutely.

The advantage of having a researcher that is in charge to generate user insight only, like specifically, is that this person has the skills, knowledge, the tools, and the time to ensure that you're not building your product based on a few voices that you had coffee with, right. That you don't over index on that, but you try to get a broad perspective of different type of users. And if that person had the problem that in Twitch or wherever it was, the researchers only spoke with small creators, then that's obviously a problem of how that was set up there.

For instance, when I worked in YouTube, like we did research with small YouTube creators, but with the biggest, the largest, I've had the biggest creators, like we went to places where they were, or we like gave them enough incentive to speak with us very often they are the first ones to actually use those features that are built for creators, right? They get access to those features before the small ones. And so, you need to build up the entire organization. So obviously your products will not be optimized only for SMBs. When I was in ads, right. And we would not optimize our products for the small mom and pop shop, right. We would make sure to also figure out how they're using the products, but we will work with large TV advertisers. We've worked with Coca-Cola and all like the big spenders because for them it also needed to work.

I mean, you can always, this is the same as if I just like to take a random example for when an engineering team was not performing, right? They were creating crappy codes and a legacy platform and then eventually it broke, right? And then say that is basically how engineers work and use this as an example why you should never have engineers in your team, right? And that makes no sense. So yeah, you'd need to build up the UX research discipline in a good way and integrate it into product development so it creates value for users, for the business, for product development.

Advocating for UX internally

Yuriy: I would say, always think about it like it's my fault that I didn't promote enough the value of research and design in the company, it's just because it's easier to say, okay, the product manager doesn't understand, engineers do not understand, clients do not understand our role. So we are so important in the product, but nobody understands our role. So our job responsibility, I don't know, do we need to write this in responsibilities? But it's building the culture in the company that helps to support this culture and show the evidence that our work really helps, that we do work well.

Javier: Yeah, it's part of a UXer's job to evangelize and to explain what UX does over and over again. And whenever I have, like I have research in my team, they work with a PM, the PM is fantastic. The PM moves on and a new PM comes and then the PM doesn't know how to work with research. And so they come to me and say, no, I have to start explaining it again. Right. I'm like, stop complaining about that. That's part of your job, right? It's part of your to-do list. It will always be like that because you will have a PM that worked in a seller on a backend system. Something never worked with any user facing stuff like doesn't know that. And it's your job to explain to them how to work, how to work together.

It's also a researcher's job, frankly, to figure out if research is having an impact and what to change so it has an impact. In this case, with this engineering, a person you told me, right, if they had the problem that research was creating insights based on very small creators that were not important, right? That feedback needs to go to the researchers. And researchers need to listen and say, like, okay, we need to change how we do research because apparently we're targeting the wrong audience. It's not helpful for a product development team if it creates those insights. And if you don't do that, you have these disjointed teams where they're, like, not work collaborating, where they're actually doing their own thing. And that's when bad products are being developed. But then that's a leadership problem, right? You have their, like this engineering leads and the UX leads of Twitch or whatever, like they should have worked together to figure out like, which is the right way to set up research. So it's actually delivering value.

The future of UX research

Yuriy: How do you see the future of the profession?

Javier: I see the future of UX as bright. I am, it is changing. But frankly, all the disciplines are changing, right? If you think about the job of an engineer, it's changing. AI is impacting how to develop products, right? If you think about the discipline of, of, of PM, of marketing, of, of sales, like everything is changing through these new developments in AI. And that obviously creates some angst in people because it's always, it's easy to basically do the things the way you have always done them. And when they change, creates fear. Will I still be relevant? Will I still know how to do that? Will I be able to learn about that?

I have seen UX change along the last 30 years where I've been in UX. I've seen UX change many times, right? When, when I started to study, right, UX was all about desktop computers. And then later on the internet came and later on mobile came and then new options like AI. before that, before AI, like AR VR, like different aspects of technology changed the way the UX professional works. And, and that was always exciting. So for me, that's an opportunity to learn new things. And if I think about research specifically, right, we have AI impacting research in how we do our work. So, how can we use tools to make research more effective, like faster and better, and to alleviate some of the burdensome tasks that researchers have and focus on cooler things?

Yuriy: Developers will always need someone to validate ideas, especially with large-scale products. AI can’t replace user insight.

Javier: Agreed. At Google, we ran thousands of experiments — but without understanding why something worked, you lose knowledge. AI-driven experiments without hypotheses can stifle innovation. Google once got stuck only optimizing shades of blue. Innovation returned when leadership said, "enough."

Rapid fire: Javier’s favorites

Yuriy: How would you explain your job to your mom?

Javier: I stopped trying, but I’d say: I help people develop better products.

Yuriy: Book that influenced you most?

Javier: The Art of Possibilities. It teaches how removing boundaries frees thinking.

Yuriy: Best product experience ever?

Javier: My first Mac—Macintosh Plus. It changed everything.

Yuriy: What keeps you excited after so many years?

Javier: I love people. That’s the magic.

Yuriy: Who would you love to have dinner with?

Javier: Steve Jobs. I’d ask about his gut-driven design philosophy.

Yuriy: Most valuable career lesson?

Javier: “Hard work beats talent if talent doesn’t work hard.” You need to put in the work.