For this week's podcast, we had a great conversation with Javier Andrés Bargas-Avila, Google's UX Director. Ever wonder how Google ensures its products cater to user needs while balancing business and engineering demands? Javier shares his journey from psychology student to UX research leader, revealing the intricate process of integrating user insights into product development. From prioritization challenges to the concept of Critical User Journeys (CUJs).
Featured Links: Follow Javier on LinkedIn | Javier's website | About Google | Javier's talk and slides at the Pendomonium+#mtpcon roadshow Berlin
Episode transcript
Randy Silver: 0:00
Hey everyone, randy here. So you all know that every week we bring you audio chats with amazing guests, and you should hopefully know that we've now got video versions too, so you can check out the episodes on YouTube. But this week we have something else for you, something special for you too. So I chatted to Javier Bargas, ux Director at Google, at the Mind the Product and Pendo Roadshow in Berlin and we talked after his great talk about critical user journeys, you should absolutely also check out that talk and write up to see the visuals of all the CUJs, and that's all available on the mind of product site and you can find the link under this video. Let's get to it.
Lily Smith : 0:42
The product experience podcast is brought to you by mind the product part of the pendo family.
Randy Silver: 0:47
Every week we talk to inspiring product people from around the globe visit mindtheproductcom to catch up on past episodes and discover free resources to help you with your product practice. Learn about mind, the products conferences and their great training opportunities.
Lily Smith : 1:04
Create a free account to get product inspiration delivered weekly to your inbox. Mind, the Product supports over 200 product tank meetups from New York to Barcelona. There's probably one near you.
Randy Silver: 1:22
Javier, thank you so much for joining us A live in-person in Berlin. That for joining us today. Live in person in Berlin, that's right.
Javier Andrés Bargas-Avila: 1:27
Yes, in person.
Randy Silver: 1:28
So for people who haven't seen you on stage and don't already know about you, can you just give us a quick introduction? Tell us what are you doing these days and how did you get into the world of products and design in the first place?
Javier Andrés Bargas-Avila: 1:39
Of course, my pleasure. Yes, my name is Javier. I'm a UX research manager, ux research director at Google. I've been there for 13 and a half years now. That means I build and scale and manage UX research organizations. So these are researchers like closely integrated in product development teams. That like generate user insights for those product teams in the early stages of product ideation, but also more tactical research throughout the development process and then also after post-launch research, evaluative research. And yeah, I've done that in multiple products at Google. I've been in YouTube, I've been in ads, I've been in Google Cloud and also in Google Play.
Randy Silver: 2:29
And how'd you get into this world in the first place?
Javier Andrés Bargas-Avila: 2:31
So I'm a psychologist by training. So I originally I started studying psychology to learn how to treat. I wanted to become a therapist, but I always had this passion for technology, and when I started studying psychology I realized there is this overlap human-computer interaction it was called at that time, later on, user experience that melts technology in humans, understanding how people interact with human-made things. And so I specialized in that and that's how I moved into that field.
Randy Silver: 3:05
Fantastic. I bet you do get to use your therapist's training all the time.
Javier Andrés Bargas-Avila: 3:13
I don't have a form of therapy training, but understanding humans can be very helpful. When you manage people, that's right, and when you work in product development, there is a lot of personalities and egos and things to take care of. So, yes, I do use it.
Randy Silver: 3:27
And I know lots of people who try to do it without being licensed. Don't Mixed results.
Javier Andrés Bargas-Avila: 3:32
Never, happens, never happens.
Randy Silver: 3:35
So one of the things we want to talk about today was you work in user research. You help teams to understand what the priorities are, what the user needs are, but we sometimes get well, we often get prioritization wrong. It seems like something that should be pretty simple we do the research, we understand the users, we understand the company and we just go from there. But what do you see going wrong in prioritization?
Javier Andrés Bargas-Avila: 4:02
Well. So I think there is this question that is difficult to answer because obviously different companies, different product teams, operate really differently, and so, but in general, if product teams have user research and user research generates user insights, not all product teams use them the same way. Some don't use them at all, and then it's a waste. Some just cherry pick whatever they want. Others figured out how to really integrate it into the process and use it also for product prioritization, and so there is there is multiple facets of problems there in how you integrate that, but there's also multiple angles to that right.
Javier Andrés Bargas-Avila: 4:44
You have obviously the user researchers, who will always think that their insights are the primary source of knowledge to prioritize things, which sometimes can be wrong, because researchers not always also put on their business hat, and so there's also obviously product and business lenses to put over that, and then at the end, it's always a compromise between the different disciplines in product development, so engineering and product and UX, and so the outcome ideally will never make everyone happy. That's when you know we're probably on the right path. If you have product owners being super happy and engineers in UX are not, then that's a bad sign, and the other way around too.
Randy Silver: 5:31
So one of the tools you like to use to get people aligned to understanding both the business goal and the user needs is critical user journeys. That's right. Tell us a bit about them.
Javier Andrés Bargas-Avila: 5:42
So critical user journeys is a tool that has been developed at Google 10 years back, so we have been using it for almost a decade now at Google, and it stems out of a time where UX was rather nascent at Google.
Javier Andrés Bargas-Avila: 5:59
It's the youngest discipline at Google and we were shipping our org structure in most of her products at that time, and so the anecdote there is, which I actually never figured out if it's really true, but the anecdote is that Larry had tried to help a friend set up a new Android phone to send out a text message, and the amount of steps he had to do to actually be able to do that from creating a Google account, creating I don't know like it was like multiple accounts and then connecting them and so on were so broken that he got so upset and said, like we need to fix this.
Javier Andrés Bargas-Avila: 6:39
This is not the experience that we should be shipping, and so this critical user journey effort was born out of that, and the main idea is that, as a central tool in product development, we should have a way to look at the most important things that users are doing with their products and build this into the entire product development cycle. And so these critical user journeys, which consist of the user's goals and the tasks that they have to do to accomplish what they want to do with our products. We define them and then measure them, and then use them along the entire product development lifecycle to always remind us about the most important things that users need to be able to do with their products.
Randy Silver: 7:28
So let's go into the components of this. What does a good goal look?
Javier Andrés Bargas-Avila: 7:32
like yeah, so that's actually something really difficult to get right and we got it wrong, especially in the beginning of this, of this movement within Google.
Javier Andrés Bargas-Avila: 7:44
So the key idea of a goal is that this is something a user wants to achieve. It's like their motivation to do something and it's like pretty high level, in a sense, that it's not concrete task that they're trying to do with your product. Right, it's not about a feature, it's about what they're trying to achieve. So if you think, for instance, about you using Google photos right, then a goal of somebody using Google photos would be I want to share memories with families and friends. That is your goal, right, your goal is not to use the share feature within the Google Photos app. Right, it's not at that level.
Javier Andrés Bargas-Avila: 8:28
It's like what you're actually trying to achieve, and so, like we say, a good amount of of CUJs, of goals for a product is typically between five and seven. So if you have a lot more than that, then you might have moved it to the task level. So now you're saying, like, a user's goal is to figure out your privacy settings, right, and that's not your goal ever, right? Maybe you, as a user, want to control how your data is being shared, right, but using the privacy settings is not your primary goal.
Randy Silver: 9:03
Okay, but you said the goal is something that should be measurable as well, so something that high level, where it's not directly aligned to tasks or specific KPIs. How are you measuring that? Is it a qualitative or quantitative, or both or Um?
Javier Andrés Bargas-Avila: 9:20
it's both. So the a COJ consists of two key components the goals and the tasks, right, and both of these things need to be able. Uh, we need to be able to measure. The goal is what you want to achieve, and so typically you measure that through asking users. Now, here, a key thing is that, uh, we, you often get surveys in your products, right. Oh, how, how satisfied are you with this product? Right, if you move this a level down to goals, you can ask people about goals, like, how happy are you with Google Photos when it comes to sharing your photos with families and friends? Right, so you can ask users how happy they are with that specific goal that you have defined that is important for your product.
Javier Andrés Bargas-Avila: 10:06
On the task level, you need to figure out, you need to define which tasks people have to do to achieve that goal, and then you can look into them. And there's two ways. One is you use just logs, and here what we started doing is moving, like to a more granular level. Right, a lot of people measure kind of completion rates, which is like okay, somebody started doing something, how many people achieve it, which is a very down version of what you actually should be doing, because there's many ways you can achieve or not achieve something. So here we move to a more granular level.
Javier Andrés Bargas-Avila: 10:41
But we're trying to understand which are actually the flows that people are taking and are they, at the end, completing the tasks or are they abandoning, exiting, these kinds of things? And so you measure those flows and you understand which path people are doing, which tasks they are aggregating to achieve that goal, and you're trying to understand if they're taking the optimal path, if they're like taking deviations and if they are, why, and if they're not achieving it, you're measuring those two things. If you can't measure it through logs, which sometimes is a problem, especially for companies that maybe have less infrastructure you can also do it with qualitative methods. You can do benchmarking studies where you observe users doing these things and then you measure it that way. But it's very critical that if you define those CUJs, you define your goal and the tasks, that you're also measuring them so teams know how well they're doing in achieving those CUJs. You defined your goal in the tasks, that you're also measuring them so teens know how well they're doing in achieving those CUJs.
Randy Silver: 11:42
This episode is brought to you by Pendo, the only all-in-one product experience platform.
Lily Smith : 11:47
Do you find yourself bouncing around multiple tools to uncover what's happening inside your product?
Randy Silver: 11:53
In one simple platform. Pendo makes it easy to both answer critical questions about how users engage with your product and take action.
Lily Smith : 12:00
First, Pendo is built around product analytics, enabling you to deeply understand user behavior so you can make strategic optimizations.
Randy Silver: 12:08
Next, Pendo lets you deploy in-app guides that lead users through the actions that matter most.
Lily Smith : 12:14
Then Pendo integrates user feedback so you can capture and analyze how people feel and what people want.
Randy Silver: 12:20
And a new thing in Pendo session replays a very cool way to experience your users' actual experiences.
Lily Smith : 12:27
There's a good reason over 10,000 companies use it today.
Randy Silver: 12:31
Visit pendoio slash podcast to create your free Pendo account today and try it yourself.
Lily Smith : 12:37
Want to take your product-led know-how a step further? Check out Pendo and Mind, the Product's lineup of free certification courses led by product experts and designed to help you grow and advance in your career.
Randy Silver: 12:49
Learn more today at Pendoio slash podcast. So you said there were products should have no more than about five to seven goals. Yeah, how many tasks should there be aligned to each goal? Is there an objective number? That is good.
Javier Andrés Bargas-Avila: 13:07
That depends a lot on the goals, and so there can be only a very few tasks, right. It can be many, and in some cases it might be that some tasks are not even done in your product and you can't measure them Right. You need to figure out like workarounds for that. Imagine I've worked in Google Cloud for four years and Google Cloud, by definition, you never own the entire thing, right. It's like always like there's multi-cloud, people are using on-prem systems, they're like combining different things, and so you will always be only able to measure part of the journey. So that's part of the complexity of working products that are part of an ecosystem that you don't own.
Randy Silver: 13:49
That makes sense when you're writing that task down. Though. What does a good task look like? Is it just move thing from A to B? Did this KPI, or is there something more subjective about it?
Javier Andrés Bargas-Avila: 14:05
But tasks are components that are needed to meet to achieve the goal, right. So it should be so. For instance, if you think about I want to share a photo with my friend, then it would be okay. One task is to go into the app and search for the photo, and then the next task is to click on the share dialogue and then the next task is to select the way you share it, right? So you look at what is needed to achieve that goal and then you define those tasks. Sometimes you know which tasks are needed, Sometimes you don't. You actually need to observe what people are doing or look into the logs, these kinds of things. So the I would say that the right level is a description of the different actions people have to take. So task is always behavioral. So you will have a behavior, a user behavior, that you can measure to achieve that task.
Randy Silver: 14:58
Okay. So this all makes a lot of sense, but it also sounds a lot like OKRs, in that the goal is an objective, the tasks are KRs, to a degree at least at the framework level. Is it similar or am I oversimplifying things?
Javier Andrés Bargas-Avila: 15:12
It is absolutely compatible with OKRs right? Ideally, I would say and that's something we advocate for at Google is that OKRs should always have CUJs attached to them. So you have a goal and then you measure the success also through measuring those CUJs. Right, ideally, if you achieve the goals that you have set out, then you will see an improvement of those CUJs. You will get some metrics moving and obviously they can be business metrics, such as revenue and these kind of things, but there should also be user metrics attached to that, which would be the CUJ metrics. So I see this as completely compatible. We have been using OKRs for many years at Google, like since Google exists, but we have not had CUJs in the past. Many OKRs, you might argue if you look at them, like there is an apparent lack of a user perspective in those OKRs, and that's what we're trying to solve with that framework.
Randy Silver: 16:05
And that's exactly where I wanted to go next. So the three components. You said users, goals and tasks. We talked about goals and tasks. The user in this case. What is a good definition of a user? Is it always the person who is the customer using the product?
Javier Andrés Bargas-Avila: 16:23
Is it sometimes Google is the user? No, google should not be the user, absolutely not. So it's always going to be the users of your products, right? In some cases it might be that Google uses a product too, but that's a biased view, so let's not go into that. So it should always be typical users that you also ideally know through research. Like you have a bunch of personas that you know. These are the type of users that are using my, my product. Obviously and I mentioned this before right, the users, the user needs, are not the only component to look at, right, ideally, you have, like, also product engineering needs, right, and these all need to be aligned, but typically there's never a shortage of including business requirements and engineering requirements into the product development lifecycle. It's typically the user needs that are the ones that are not always integrated ideally, and so CUJ is trying to change that and make it more user-focused.
Randy Silver: 17:21
And then for something like a B2B product, you'll have different CUJs based around, say, purchaser needs, administrator needs and end-user needs.
Javier Andrés Bargas-Avila: 17:30
Yeah, exactly you could have, like in B2B. Also, think about ads, right, you would have different type of advertisers. Like an SMB account that mostly is self-serve will have very different ways of using the products, compared to a large advertiser that has a bunch of people at Google doing all those things for them. So, yeah, it obviously differs.
Randy Silver: 17:55
One of the problems with all of these things OKR, cejs and everything they're great as an organizing principle and we get very enthusiastic about them and then we start to work, but actually keeping it front of mind all the time, making it useful, making it a habit as part of our development process. How do we do that? How do we keep measuring the outcomes? Make it part of our daily routines?
Javier Andrés Bargas-Avila: 18:17
How do we do that? How do we keep measuring the outcomes? Make it part of our daily routines. Yeah, well, if you invest the time to define the CUJs and then measure them, right, the only way this can pay out is if you integrate it into the product development lifecycle, right? There's many ways to do that, but at the end, it should be like the goal should be that you use them for the different stages, right? You can think of early stage, think about product prioritization, right? You can say, okay, here's the hundred things we could be working on. How do we use CUJ to prioritize the right thing?
Javier Andrés Bargas-Avila: 18:45
So now you attach to the different efforts, you attached the CEJs that they would impact. Maybe you already know that you have those three CEJs that are not doing well. The others are fine because you're measuring it right. So now you can say, okay, why don't we prioritize the efforts that will improve the CEJs? We're not doing that well. You can use them in PRD stage, where you describe what you're going to work on, and now you say, okay, these are the CUJs it will impact and as success metrics, like here's how we're going to measure if this launch is successful through those CUJ metrics. Right, so we are expecting these things to improve.
Javier Andrés Bargas-Avila: 19:24
When you describe it, so suddenly you're integrating user perspective in your process and so that goes along the entire lifecycle, right, you can use them in prototyping. When you describe, when you show, like in the prototypes, the entire CUJ instead of just that feature that you're working on, you can use them in triaging user feedback into okay, we've got all this feedback and these are the bits about CUJ 1 and these about CUJ 2 and so on. And then you say, okay, in bug fixing, we know we're not doing good in CUJ six, right, so let's look at all those problems we have that align to CUJ six and fix those first. So through the entire lifecycle there's always these points where you use the user perspective to understand how we're doing and shift the perspective from business and pure business and pure engineering to hey what do our users need?
Randy Silver: 20:20
And the critical thing, it sounds like, is your definition of success is not that any individual task is good, it's that the person is actually achieving the outcome that they want.
Javier Andrés Bargas-Avila: 20:34
Yes, I mean it's both right. I mean you're measuring how successful and healthy the tasks are that are needed to achieve a goal, and you're measuring also how happy people are with that goal, and the combination of both is what will give you the holistic perspective about how things are going.
Randy Silver: 20:54
Makes sense who owns the.
Javier Andrés Bargas-Avila: 20:56
CUJ, the entire team? That's a super important question and it's actually something that, especially in the beginning of this effort, led to problems, because for many years there was the perception at Google, especially from product and also from engineering, that COJs were this UX thing, that is a thing UX cares about, and if that's the outcome, then COJs will be a failure. You will invest a lot of time in developing them and everything, and then nobody will use it because it's this UX thing. If you invest in COJs, then it has to be something that is owned by the entire team and there is an agreement that this is needed to make the product development more user centric. And there's obviously UX will own, like some of the evaluation, some of the understanding, reporting of CUJs right, maybe updating some of the CUJs and so on. But, but PM needs to own, like, okay, well, let's integrate that into PRDs, let's, let's use it for product prioritization, right? So there's the different players need to use them for different things, uh, and only if that works then it can be successful.
Randy Silver: 22:05
And when you say the entire team, do you mean just individual product development team level, or are we talking more at an organizational level?
Javier Andrés Bargas-Avila: 22:13
It's both right. So it's obviously the most important thing is the individual teams, because if they're not using it, nothing will happen right. But it's also at an organizational level, like imagine executives saying, like okay, in business reviews, I want to see how the CJs are doing and I want to see how they're improving, how they're changing. What do we do to improve those? Right? So it's also like an accountability from the executives where they're like okay, I do not want to see only revenue, right, I also want to see how our product is doing product house wise and how what users are saying and if they're asking for it, suddenly the teams will also want to use it and they prove it and report it. In this kind of thing I think we've got time for one last question.
Randy Silver: 22:59
So, for anyone who wants to adopt CUJs and start using them in their organization, what's one thing they should start doing tomorrow? What's what's a common mistake you see when people start using it?
Javier Andrés Bargas-Avila: 23:10
The most important thing is that to move in that direction, to define CUJs and then later on start measuring them you need to do this in a cross-functional way, so don't start it as a UX thing and do it by yourself and then you come to the team and go like, surprise, here's that stuff Right, here's that stuff right. It needs to be done from the ground up as a cross-functional effort together, like starting through the definition, workshopping, getting user insights into that. All of that needs to be done as a team so there is afterwards like there's a shared ownership, and that way it can become a success.
Randy Silver: 23:49
Javier, thank you so much.
Javier Andrés Bargas-Avila: 23:50
This has been fantastic. Thank you, randy, it was a pleasure.
Lily Smith : 24:04
The Product Experience hosts are me, Lily Smith, host by night and chief product officer by day.
Randy Silver: 24:13
And me Randy Silver also host by night, and I spend my days working with product and leadership teams, helping their teams to do amazing work.
Lily Smith : 24:20
Luran Pratt is our producer and Luke Smith is our editor.
Randy Silver: 24:24
And our theme music is from product community legend Arnie Kittler's band Pow. Thanks to them for letting us use their track.
