Can data play a meaningful role in design solutions and processes – or should designers stick to experience and visuals, and leave dealing with data to math people? Join us as we explore these questions and more with Design Manager Joshua Zhou and Senior UX Designer Javier Lo, who together actually tried making data relevant to our design team. Did they succeed? Find out.
Book recommendation: A Practical Guide to Designing with Data by Brian Suda
There is more nuances between behavior change and conversion performances. So actually that that's something that makes our design works even more interesting than that before.
We remove the guesswork in anything that we're designing, or even before we design some solution, it's sort of help us like to prioritize which problems to tackle first, right.
Hello, and welcome to the design explorers, a podcast by the Agoda design team.
Agoda.com is a global digital travel platform where you can book hotels, vacation rentals, flights, and airport transfer.
In this podcast, we will be sharing the awesome work of our design team. Discuss interesting trends in relation to design and travel, and talk about product design in general.
My name is Nahum Yamin and I will be your host for the show.
Today's episode is all about the relationship between data and design.
Here at Agoda We trust data to inform our design decisions and provide the best experience for our users. I've sat down for a conversation with Joshua Zhou, a design manager and Javier Lo, a senior UX designer to talk about how designers in our team are using data.
Have a nice listening, and I hope you will enjoy the show.
Welcome to our first episode of the design explorers. I am very happy to have Joshua and Javier here with me today to discuss about how we are using data in the design process and how they have started this initiative of making data more accessible and meaningful for our design team. Joshua and Javier, welcome to our show.
Thanks, Nahum. I'm very excited to be here.
Yeah, so pleasure to be here.
Before we start with our topic for today, let's give our listeners some background about who you are. And what is your role here at Agoda. Joshua, maybe we can start with you. You've been at agoda for almost five years now starting as a UX designer and grow into becoming a design manager.
Yeah, you're right. I've been here for almost five years. And I witnessed the design team's growth over this almost five years. So for the first three years, I worked on the consumer facing product, you can understand as a web, and also mobile app where the users can use to book their hotels for their trip. And we practice a lot of like AB testing at that time.
Because you know, I got a is a data driven, so we rely heavily on that. And now, thanks, thanks for the opportunities that, you know, managing a team working on the the enterprise side. So basically, how you understand this enterprise side. So you can simply understand that, you know, the product that are the ones that we allow our hotel, hotel partners to manage their inventory on the platform, and also the product for a consumer experience specialist to handle the customer support. So in this particular scenarios, we define the term of user or say customers are actually the hotels or our partners, service specialists, but not the travelers who use the app to book the trips.
And have your your senior UX designer that has been working on the experience of both the Agoda web and app for almost four years now. Right?
Yeah, you're right. I've been here for four years now. And mostly working on the traveler's side, which is involving both platforms, which is app and also web. And I sort of started backwards, actually. So when I first joined, I worked on booking form, and then move back to the funnel, which is property page. And then also search page, basically. So that's pretty cool. And then I've learned a lot throughout this years. And then the cool thing about like, being able to work in finance is that it sort of helped me to understand what type of data that is available in each funnel in each page. And then also like to understand the business as a whole. So it's been pretty long journey, and then also painful journey, like it's quite fun actually. And luckily, I still haven't feel bored yet.
Yeah, yes, they have a lot of stuffs. Still got great learnings here. I think that's why, you know, we are still working. You know, In Agoda here,
In our first episode, today, we are talking about data. And here at Agoda as you know, we as designers have a lot of data at our disposal. But it is not always easy for us to include it as part of our design process. And you guys are actually working on making it easier. But before we go into that, let's begin with the basic question of what does data even means.
Okay, so, just for this podcast purposes, let's all agree that when you talk about data we talk about we are talking about quantitative data right. So within Agoda itself, like the types of quantitative data can be anything that we are tracking on on our product, it can be like number of clicks, or number of visits, how many people are have seen this this element or UI element, and things like that. So, yeah, so basically, those are the type of data that we are, we use often, right? mostly in the front end basing. World.
Yeah, just now Javi mentioned about quantitative data. So I think there is a very simple way for us to differentiate quantitative versus qualitative. For for us, you can, if you go to a Agoda.com, you are trying to do a destination search, or typing the city and click the search button and when you go to the search result page. So if you if you notice that we have a filter on the top, the filters can the users can use to filter for the price range for special offers or something like that. So the filter on the top is something we sorry, okay, so for the filters, if the users use this filter to get that result and make the bookings or not. And this actually, is the insights of qualitative insights.
So anything that you observe, right?
Anything that you observe that if the if, what is the user behavior look like? That's how the user behave on the on the on the side? That's the the qualitative side? That's the core is qualitative insights? And how so if if we if if the user actually use the filter, And we know this is a user pattern, and how to you know how to understand the pattern there is? Okay, what is the percentage of the user actually use the filter to make the booking, then that's then this is a quantitative insights.
Yeah, actually, the actual number, like, for example, and how many users are actually using free breakfast, for example, and then booked a hotel. So this was a qualitative quantitative survey. And also the expand on the qualitative side, like, the easiest way to to look at it is also like, any type of data that you get from user testing, for example, like a user lab, right, or? Yeah, I think that's the easiest way to distinguish between those two types of data, basically.
So quantitative help us understand what is happening. Yeah, yes. And qualitative. Help us understand why it's happening.
Yes, yes, exactly why, exactly what is happening? And also, to which extent that with that happened,
Okay, so let's talk about your ongoing initiative, which is basically trying to make it easier for designers in our team to access and understand data, what and how, you know, made you start this initiative?
Okay, so, do you want an official answer? Or a personal?
I want your answer.
Okay. Cool. So yeah, officially, I think everyone's thinking about what is the next step for UX designer to succeed, to succeed in the internet company, like I go to. So I think for data is something that we can use as a domain to upskill yourself, but actually, from for personal story, actually, that that was a very funny at first, you know, I when I was working on the product that, you know, specifically targeting a certain user segment. At the time, I bother, you know, our data team a lot by sending them a lot of emails to asking some stupid questions sometimes, but most of our questions are, you know, data related. So, what, what I what I experienced is Okay, so, I send a question to them, usually takes usually took like two weeks, before they actually get to get their questions answered. And sometimes I need to, you know, rephrase the question again and again. So get so that I can get the similar data points result based on the same theme that I asked for. So and, and at that age times, I think the question is, is very easy, because of the waiting queue is very long, I need to wait another, you know, months to get my question answered. So that which means I missed a lot of good opportunity opportunity for me to pitch a very good design initiative to the to the key stakeholders.
So basically, you're frustrated with this flow,
Not not really frustrated, because we have a official procedure for managing those data requests is all of the teams and design team is also part of it. So actually, the data data team is very supportive. But because Agoda is a very big company we have 1000s of employees here
So they cannot they cannot really answer every you know, person's data question.
Every request you every request as he should they have like, probably 1000s of requests per week, basically.
Yeah, yeah, yeah, you can see that workload is very, very high. So I think instead of, you know, suffering from waiting, I think, hey, what if I learned how to query by myself, it sounds like a crazy idea at the beginning, because I've seen some, you know, like, crazy codings in the SQL query that, you know, the data team is working on, but I think maybe for some simple questions I can start with, so that's why I started to learn the SQL query, you know, but that, you know, everything was changed at that time. So I think learning SQL query actually open another new door for me to, to step into the business world of Avada. Because Previously, we work on the design. And we were, we were not really having a very strong standpoint in the organization. And sometimes, if you want to drive something, from a design standpoint, the flow that we went through is we need to, you know, be well prepared for the rationale of why we should do this, because our Agoda is performance driven. And now we have, you know, capability of, you know, data now, we can ask the data, you know, the right data question, and then we can, you know, back up our design decisions. So, I think that's Yeah, that's, that's simply how things started from from from my side. And actually, because we are working as a team, and, you know, we we have been here for a while. And the team actually growth for growth for a while, for the for the past couple of years. And we also need to think about what is the next step for the team as well. So team maturity level, are related to the design quality, but also could be related to the data driven culture, because agoda is data driven company. So that's why that's the initiative come out.
And Javier, how did this initiative started for you?
So, to me, it's very natural, in a way, I think it's so basically, it all started with, like Joshua mentioned is the need, there's a need for the team to level up. And also, working with all the product managers, makes me realize that we also need to speak the same language as them. Because all the PMs here are basically only speaking one language, which is data. Right? So for us to work smoothly with them. I think it's, it makes sense for us to do understand data. Right? And yes, starting from that, we sort of like, naturally goes into this, this world, similar to Joshua. And then Joshua also mentioned that he learn SQL and has also started learning SQL by myself. Right. And then, which is that I had a background before but you just need practicing. Right? Yeah. So yeah. So that's how it started?
Yeah, yeah. Cool.
So let's, let's talk more about this point. Why should we as designers actually care about it? And why should we consider including it as part of our design process? Shouldn't we just leave it for the experts?
To me, I think the best way to think about data is based so why write the Why is basically it's quite simple, right? It helps us validate our design decisions more, right, so we remove the guesswork in anything that we're designing, or even before we design some solution. It's sort of help us like to prioritize which problems to tackle first, right? So, it gives you like, hard proof to what you should design or how you should design it. Basically.
You know, what I think about is design and data relationship more like the two components in the whole loop of the product development cycle. You know, we are designers, we're not artists, and we propose are designed to solve both user problems and also business problems. So, instead of being artistic, I think we rather need to be more rational to include data into the design process to get more buy ins from stakeholders, like I said, you know, we So, we solve both user problems and business problems. You know, the definition from myself like business problems are usually one quantified is conversion rate problems by our product managers. So, basically, they they focus on the pump conversion rate. And to solve this conversion rate problems, I think product managers will form high level product hypothesis. For example, you know, a very typical example for the product hypothesis could be like based on or prior data in data insights or data signal, or a competitive benchmarking. If we build up a new feature, then the This new feature will bring us X amount of conversion rate increase. So this sounds like, you know, the business side need to be achieved. So product hypothesis is more about, you know, high level goal, like I mentioned, and high level measurement, and to designers the ways to form design hypothesis and more about interpretating, the factors that lead to the high level product hypothesis, through observing the user behavior changes, and the psychological influences that behind these behavior changes, right. So, though, psychological influence might be a qualitative term, but in a mass majority is, but but it is very much reflected in the result of the quantity, right, for example, how many users change their behavior. And the good thing is, we have the luxury of improving those behavior patterns by AB tests. So, let it go that we have 1000s of tests running for each month. So, you know, study and get and getting familiar with this kind of data actually helps us sharpen our instincts. And, you know, for long term wise, I think, makes us proposed design faster. And with less wrong design hypothesis, possibly. So, that's why I think data is important, and should be included in our design process. And one thing I think might need to be, I think one thing I might need to point out is, you know, design hypothesis doesn't really necessarily positively impact the product hypothesis every time since the behavior change might happen because of the design. But the conversion performance might not be predictable, even though we have very strong confidence on the possible behavior change. So I think there's, so there is more nuances between behavioral change and conversion performances. So actually, that that's something that makes our design works even more interesting than before.
Okay. So we understand and agree now that data is important, and can be very helpful in the design process. But you know, data can mistakenly be considered as something boring, and a subject that deals only with numbers, especially for designers or sometimes perceived as visual creatures. What are we doing to make it more accessible and less intimidating for them?
So there are a couple of initiative to make it less intimidating, right? And then it's all in the form of learnings. Right? So what Joshua did before is to organize classes, but with partnership with a data science team. Right? So which is very helpful. And the goal for those classes is to basically tell our designers, what are the types of data that is available? And what are the tools that is currently being used by everyone here? Right. And then there's another initiative is also form of learning, which is the data guild, that me and Joshua is currently running, where designers, so we divided into two session where the first session is basically to learn how to form a design hypothesis better, right? And then the second session is more of a technical side. Were, like learning about the tools like learning, about all the
So you guys are breaking it down into different components to help designers better understand.
Yeah, yeah, yeah, exactly. And yeah, I think I think Javier pretty much mentioned all the things that we are trying to do right now. But I think for, for a simple start, it's very easy actually, maybe reach out to whatever the people from the data team, or the business intelligence team, reach out to them and see, because we are UX designers, we have the strength of making their tools easier. So let's do a quick audit for their tools and start to build up the connection between them, they start to do something for them. And actually, we ask asking something back from them is okay. So we should we should build up a very long term relationship. And then we can actually make the have made that happen for all of those activities, like Javier mentioned about,do like data Guild, data trainings, and also the follow up, like learning clubs that we can do together with them. Yeah,
Yeah, actually, Joshua made a good point. Like, I cannot stress enough that building a relationship earlier is the most important thing. Right? Right. So just looking back, what I did with the design experimentation team is that like, they needed a designer and then like, then we sort of don't have enough resources for it.
we still do stuff them designing like a online analytics tool for them on the site like outside of our current scope, which which in turn, makes them wants to help us more. Right? Yeah. Which is pretty cool. Yeah.
Just be positive and reach out to them first and try to do something for them, and or maybe even organize a lunch with them and talk about, hey, what are the so if like Javier mentioned about, I'm working on the booking form. So what are the data points that we are tracking on the booking form, so that you can start from those kind of data points conversation. And after that, you can, you know, ask them to navigate navigate you to the database and show you Okay, so for the booking form, these are the data that we're tracking and what other data is actually related to the design related to the user behavior, then we can start a second conversation to follow up those, you know, conversation that actually you need. Yeah.
So in, in doing this process, what are some of your biggest challenges, the one that you're facing or faced in the past? By trying to make it easier for designers? To understand data?
The most challenging thing for me is basically, including this extra component into my design process, and then also sharing it to other people.
Right. Yeah, I guess. This when when we started working on data, I think there's more questions like, pops out here in there.
And especially when it when other designers are relying on you to sort of have all the answers like those are the toughest part, because I think, even now, like, even me, and Josh are probably wouldn't have all the answers. Right? And that you're including that into our process. And it makes things a bit slower. In terms of executing design. Right. Yeah. And, yeah, basically, those are the main challenges that I'm facing right now.
So it's an ongoing process that you guys are still learning by doing?
yeah, I think that cultural, cultural shift is, is actually the biggest challenge, you know, the first time we initiate that, you know, data driven design, or is, is not really a big topic like that. But we at first were thinking about, we should include more data thinking to the design process. And we, but we actually advocate this concept to different people. For example, sometimes the PMs actually don't understand, hey, why you guys would like to learn this data tools, for example. They, at the beginning, they don't really understand why design, some of the designers must like myself and are heavier, learn SQL. So I think, for learning SQL for myself, either for hobby, I think, is not about learning the SQL clause themselves. But it's more about learning how we track and store the data so that we understand the business components better. Because what we, what we open the door is we open with the learning SQL is actually learning that opened the door for us to step into the data world, and also trying to look into the business components instead of the high level ones. Because I think for designers, we have tried, so long time just focus on the high level goals, but what are the actual components within that something that we should break it break down into a deeper look at it? So that's why I think we should we should we should shift the culture and and, you know, actually advocate that, you know, data is a is a is a very important process for the for the for the, for the designers, and after we have try to learn those tools and try to learn a Data Domain. I think, for the bare minimum, I'm seeing a lot of good, you know, designers actually, you know, asking good data questions from now, which is very visible. And like before, we don't have this capability yet.
Speaking about learning, what are some of your biggest lessons learned that you kind of wished you knew before you starting this process?
So to me, one of the biggest lesson and I also think it's one of the most important lesson is, when you look into data, you are more prone to confirmation bias. Right? Like, say, for example, if you have, especially when you have a design solution ready at all, especially if you have like a strong belief in in one idea, then you sort of can be like sort of bias in terms of like what type of data that you're looking at. So that can be dangerous, basically. Right?
So confirmation bias, you mean, you're trying to prove your...
you try to prove your design belief, basically. So those things can, you can easily do it with data. Because any type of data that you're looking at, you can sort of twist the type of data that you're looking at to be confirming your initial belief design belief basically. So those are the things that is quite important, and quite dangerous, right?
Yeah, I totally agree. So I think for my personal experience, like you mentioned about confirmation bias, right. And also, I made a lot of mistake of selection bias. That's the begineer mistake, but I think it's okay. There's a very good learning for me as well. During the process, I've been talking to different PMs and also data, guys, and also developers and trying to avoid that happen again. So basically, the mistake was, you know, from a user standpoint, when we look at the agoda, website search result, you will see the search result, the search result page looks a little bit busy for you, we display on a lot of information, like different badges of benefits, breakfast, breakfast, breakfast is important, by the way, but we have different so many different badges, colorful graphics, visuals happening on the cards, which made the card which makes the card very big, and very busy. So at that time, my hypothesis is, if I am, you know, from a user standpoint, and also I know from my own experience of booking, make bookings on agoda, actually not really looking at those components on the car. So that's why I formed hypothesis, if we, you know, if we simplify the UI, that maybe can make the user experience better. So because we can display the core messages to the user so that it makes it easier for them to make decision. But But how do we actually quantify the term of simplify, because we've simplified the UI, okay, you can simplify the color, or you can simply simplify the information, or maybe we can shorten the language that we use on the on the card, but my approach at that time is make the card smaller. That was that was the, that's that was my personal interpretation of simplify it. So because because my hypothesis is simplify, which means we make the cart smaller, can help the user can actually help the help the conversion, that's my hypothesis. So that's why I go back and take a look at, you know, the past experiments, the the past a B tests that, you know, could possibly make the cart smaller, for example, like if someone removed some components in the card, if someone change maybe the height of the card, so I was trying to find out those experiments to prove my hypothesis. And I actually did, actually did a lot of query. Oh, by the way, at that time, I already I already know how to do query. So that's why I pull out a lot of experimentation. And trying to use that to support my hypothesis. And when I show it to our senior PM, he's, he's he's a very nice and he, he told me that, hey, Joshua, you are going in a wrong direction, because you cannot avoid the selection bias. And at the time, I asked him, What is the selection bias? Basically, you know, the result first, and then you try and to find the tests? Are the final AB tests supporting your hypothesis by those results. Or by your, by purposely, you ignore the rest of ones? For example, if if the rest ones, by simplifying the cards actually do hurting our conversion, but I ignore that,
so that you only select the one that was winning?
Yes, yes. Yes. That's, that's a that's a typical selection bias. Yeah. So okay, I think that's a very good feedback for me. So that's why I follow up. And, okay, this time, I used the same query, and I and I pull out pretty much, pretty much the same experimentation. But but more with experimentation, have more, you know, results, not just for positively impact on the bookings, but also negatively, or maybe a flat test. So I put together or every experimentation that I can found that physically that I think physically it can make the card bigger or smaller, because you cannot really look at make it smaller, you need to, you know, compare the both ways. So that's why I pull out experimentation could potentially make the cards both smaller and bigger. And I don't put the conversion numbers. I just put the list of the experimentation. And I sent to the developers and asked them to, you know, to tell me, technically, is this experimentation make the card actually smaller or bigger. And then after reading, I get that there is the list from develop developer teams, and I put the numbers for each experimentation. And after that, I feel more comfortable and more confident to propose the same concept again, because I'm still seeing the parent But that pattern is more solid than before, because you back up with the developers, you know, how to say, developers? measurement? Yeah. And developers evaluation on the, you know, if the test can physically increase or decrease the size of the card. And, and that actually, you know, makes me more confident.
So essentially, essentially, what both of you are saying is, don't fall in love with your solution and try to be objective when you are working with data,
correct? That's correct. Yeah. That's the overall suggestion in trying to avoid that, and I'm pretty sure that people could, especially for designers who spent stepping into this world, they could, you know, make the same mistakes that like, like we did.
So let's talk about this, these new designers and designers that are very new to the idea of data. And also, you know, Here at agoda, we have the luxury of being empowered to access and use data, but some of our listeners might be working in smaller companies, and with less resources, what would you recommend those guys? How can they start an approach this subject of data in that case?
Yeah, this is this is this is an interesting question. But we, I don't think there is a very good answer to that. I think the concept data, you know, data is all about measurement, or say assessment. So I think they could be reflected in the form of number but also could be reflected in the form of certain customer behavior. Right. So for designers who don't have the luxury of accessing data team, I would recommend them to start from the business result. I mean, you know, what the business is going to achieve. And trying to reverse engineer the business result, to see what other components in it and know a lot of times that the result was achieved by cross functional teams. So it could be joint efforts, but what are the parts that mostly relevant to design, so thinking about that, I think that's something that we as designers can do, and also tried to split them out from the expected business outcome, and trying to figure out how you can make sure you're getting You're doing good job, you know, doing good job of influencing the user behavior. So basically, I think , get yourself closer to the data thinking, even though for the short term, maybe data support is not there is no very feasible to you. But I believe running every business, there is no escape for anyone to touch data. So there must be data here in there for you to discover. So start from the result, follow the path leading to the result, you won't miss the data. That's, that's what I think about
it to me, the other way to utilize that to sort of start into this world is basically to utilize whatever you have right now, within your, your company. Like Joshua mentioned about, start with the end results, right? Like, I'm pretty sure the business intelligence people, if you have any, or even your CEO might have an end goal in mind, which means that obviously, for some company, they might be focusing on growth, and some company they might be focusing on, on any other metrics, right? So I think start by asking them, like, Okay, so what are the things that you want to achieve? And then have we track this on it? And if you haven't tried anything at all, then I would suggest start by doing that, at least talk to the developer, and ask them like, whether you guys are tracking the, your product or not? Because I think right now, nowadays, it's very hard for business to survive without, like, any data at all. Actually, yeah,
So better understand the objectives and the goals,
yes. And better understand the objectives and goals. And also better understand like, what are your current resources, basically, like, like you said, like not, not everyone have realized data team, right? When you can sort of start with your developer. And then if they don't have tracking, and they use sort of Ken, as the designers like you, you need to be proactive enough and ask them to sort of add the tracking, basically.
Okay, we're coming to the end of this episode. And Joshua and Javier, I want to thank you for taking the time today and discussing with us about this interesting subject of data. Before we close Do you have some any recommendations, some books, or some advice for our listeners?
I think, Okay. My recommendation for the designers who would like to step into the data word will be you know, start from asking data related questions. So, you know, for ourselves, we ran the sessions called question burst on data points. By the ways question burst. is a very useful brainstorm tool that invented by Hal, Gregerson, who is the executive director of the MIT Leadership Center. So what we did was based on the product hypothesis that came out from our product managers, we ran the existence of a question based on trying to, you know, ask the question around two topics. One is what are the user behavior data points that we should look at, before and after the new feature is built. And the second one will be if the product hypothesis is true, what will be expected is a behavior pattern change should be reflected on those data points. That's something that we started with. And I think could be a very good exercise for designers who like to step into the data world to try as a big as a first step.
I think to me, if you talk about books, there are books that I think it's quite important. To me, there is one book called A Practical Guide to designing with data by Brian Suda, like, and then I think, start by reading a lot of books is quite important, right? I mean, of course, like you wouldn't be able to apply everything that you read, right? At the start, but trust me, like somehow, like, while you're doing your day to day job, you sort of can receive an idea of like from the books itself, right. So I think it's pretty helpful also.
All right. Thank you guys. Thank you very much.
Thanks, Nahum. Very happy to be here today.
Yeah, thanks for inviting us.
Thank you so much for listening. If you enjoyed this podcast, please leave us a review on Apple podcasts, Spotify, or anywhere you are listening, and share it with your friends and colleagues. Don't forget to subscribe to our show to get notified when we are releasing a new episode. And if you want to learn more about the work of the design team at agoda, visit agoda dot design.
Thanks again for listening and hope to see you in our next episode.