Go back

Leveraging design thinking for work processes enhancement

33m 33s

Leveraging design thinking for work processes enhancement

Anita and Eric, senior product designers at Agoda, created a standardized Figma workflow template to address growing pains in the design team. As the team expanded from 10 to about 40 designers in a short period, they observed increasing inconsistencies in design solutions, poor cross-team collaboration, and fragmented user experiences across the product. Common issues included designers not fully understanding requirements before starting, struggling to get early feedback, and lacking proper handoff and experiment tracking after design completion. The two designers were independently working on solutions until their design manager connected them, and they officially launched the initiative during the company's migration from Sketch to Figma. They applied design thinking principles, interviewing designers and developers to map pain points and ideal workflows. The resulting template provides clear guidelines on what designers should do before, during, and after their work, helping standardize processes, improve efficiency, and enhance transparency. Despite initial resistance from a fast-paced culture that views new processes as slowing things down, the team recognized the need for change to maintain product quality. The project took about a year, starting in late 2019, and is now being rolled out across the organization, including the supply side where one of the podcast hosts works.

Transcription

5447 Words, 29326 Characters

English
We try to provide some guideline to the designers so that they can be more well-informed about things that are going on within the team and guide them about what is the right thing that designers should do before doing and after they're working process. So with this standardized design process, this not only help designer follow the same workflow and then improve work efficiency, but also provide a better collaboration and transparency costings. 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 Nacho Miyamin and I will be your host for the show. Hello Yuki, how are you today? I'm doing great, how are you? I'm good, I'm good. This is your first appearance on the podcast. This is changing the format a bit, we're having a call host which I think is really cool because it's given us opportunity to reflect on the episode, get other people take on the discussion. So maybe you know can give some brief introduction for our listeners about you. Definitely. I'm super excited to be here and learning along the listeners as a background. I myself is joining the Agoda Design Team as a full time in the next couple of weeks, but I've been here as an intern. So that's how we've kind of gotten connected. And since then, you know, I really wanted to get involved with the community of designers at Agoda as well as in Asia in general. And so I thought this was a great opportunity for myself to talk to many people and great designers and learn amongst the listeners as well. And so I'm super excited to be here. Awesome. And I really, you know, I really enjoy your enthusiasm and now we wanted to participate in that. So I'm very happy to actually having you co-hosting together. I think it's going to be really fun. Yeah, I'm hoping to bounce on great ideas and learn some things with everyone. Yeah. And yesterday we actually recorded our first episode together, which is a seven episode with Anita and Eric. Two of our designers. We talked about how they improved, you know, the design team processes and workflows, which is really cool because they're using their super power, their design skills to actually solve their own problems. And their team problems. Yeah. This one was particularly interesting to me in the sense that, you know, designers were a lot of times we're focusing on digital experiences through screens. But I think when we're designing internally for people in terms of process, I think that's a very different skill set where you can still apply the same framework. And so it was an interesting conversation. I think there's a lot that I genuinely learned from them. And so I actually wanted to ask you like, you know, we had these issues that was raised by Anita and Eric in terms of what the process tried to kind of solve. Did you feel like those were the same issues that you were experiencing as well? Maybe not so much for me. I guess they were solving more issues of, you know, the main core team that collaborate together and working more on the UI, not the things that I'm working on my day today. But I do feel that they overall improve the design team workflow. And what's cool about it also is that, you know, they saw some problems and instead of just complaining about them, they took initiative and actually thought how they can fix those. So I think that was really cool. Yes. Definitely. Yeah. As a reminder, you were working on the supply side, is that correct? I'm working on the supply side and I'm working on more of the strategic UX, I would call it, right? Less about the UI implementation or the visuals, thinking more about the bigger problems that we have a supply. And supply to explain the listeners that might not know is how we handles all our supplier. We have a system to help hotels and other service providers to connect to a good. That's great. Yeah, I think they're slowly rolling out their templates or process that have built to the supply side as well. Yeah. That's what I've heard. It might be a bit different. It might not be exactly the same as core. So it will be interesting to see how it works. Definitely. So you, you were a new joiner in our team. So I'm curious, how do you feel? You know, about our conversation with Anita and Erick. Yeah, it's actually quite empowering to see that there is a process that is already strongly embedded within the team. I think a lot of times based on my experience when you join a small team and there isn't a strong process. I think you have to wear many hats and push yourself. Many times out of your comfort zone to really learn and then actually get used to, I guess, hidden process that is never outlined anywhere. And so having a process that is agreed upon by everyone and that you can look at as a guidebook will definitely be helpful in terms of whenever your stock or what you should be doing throughout each phase of the project. And we're really looking into, you know, studying what they've made in detail and actually living and going through the process that they've made. Definitely. And I think, I think, you know, probably most many of our listeners are also maybe in their beginner of the beginning of the career on new designers. So this kind of perspective might apply for them as well, right, when they're just joining new teams or starting their first steps in this field. I think it's going to be very interesting for them. I think Eric actually touched up on that a little bit and then you can find out a little bit more in just a couple of minutes. You sure will. So with that note and we know for the RDo, let's begin the show. Hi and welcome to the seven episodes of the design explorers. I'm here with you, and our guests today are Anita and Eric, two of our senior product designers. Anita and Eric have been working on improving our design team processes and workflows to ensure we provide a consistent and optimized user experience to our customers. They've identified some of the pain points and roadblocks that our design teams and individual designers are facing during the day to day job and created frameworks workflows that mitigate those issues. Today they're going to share with us all about this Anita and Eric, welcome to our show. Hi. Hello. Let's begin by giving our listeners a background about who you are and how long have you been at the Gora? Hi everyone. I'm Anita. I have been in a Gora for more than four years. I'm currently working on property page on their consumer facing product. I have been working on homepage, search page, booking form, basically the entire hotel booking funnel, which is the major part of helps Gora making profit. I'm also briefly working on supply side, now hotel accommodations and other products. Yeah, that's pretty much it. Nice to meet you guys. I'm so on work. I've also been here around the same time as Anita for like four years. In my early days here, I work on product marketing team like pricing, loyalty program, SOS core accommodation funnel, search team and property page team. I'm currently working on flight team, which I helped to optimize and build great foundation of the product that are user friendly and highly converting in terms of business. Awesome. Today we are talking about some of your initiative that helped our design teams with their day to day work and processes. Maybe you can explain to us what exactly you did. How did you improve the work? Basically, Anita and I, we created a Figma workflow template. This is what we called in the Gora. This template aims to set a standard of the way we should work within design team basically. We try to provide some guideline to designers so that they can be more well informed about things that are going on within the team and guide them about what is the right thing that designers should do before doing and after the working process. That's like a brief what is Figma workflow template. Yeah, so the working template is the key result we have with this project. But we actually improve designers working process and we make it standardized. So with this standardized design process, this not only help designer follow the same workflow and then improve work efficiency. but also provide a better collaboration and transparency cost things. - Can you share with us a bit more, what exact problems were you solving, what need you were identified as part of these improvements? - Yeah, so the needs were actually coming from ourself in the first place. We actually identified some issues during our everyday design process. So we tried to solve this from our end. And later on figure out lots of designer are facing similar pen points. So in order to dip dive on these pen points, we start interviewing designers, course teams and see some patterns in different design stages. So some issue were identified before design, during design and after design. Common pen points before designing is like, how can designer fully understand the requirements and define a problem statement and hypothesis. And do a design process is like, how can designer better collaborate and get feedback in the early stage? An example after designer finished their exploration will be like, how can we have a proper hand off and make sure designers track their experiment after? So these are a lot of needs we identified during interviews but we prioritized the most important one and try to improve upon that. - So you're saying what triggered your motivation is actually some problems that you were facing. It's part of the team. - Yeah, the design of the team encountered this in our daily work. Ever since the team grows bigger, it involves with a lot of team collaboration. The core team with the side funnel and even with the design system team. For example, design of the front teams working on the similar ticket, but they both are now aware of. So two design solutions might end up having different direction. Or even designers don't reuse or follow the design system properly. So those examples, my sounds really minor, but think about all these little things get accumulated. It will create a lot of chaos on our product. So me and Erg were actually trying to solve this problem separately. And later on, we figured out, okay, we are actually doing this at the same time. And then we start working on this to get us a team. Yeah. - It's actually really interesting how you guys, everyone, you said, kind of face these problems, but how was it that you and I and Erg kind of got together and wanted to actually do something about it? - It's actually pretty funny, just like what Anita mentioned. We both of us were trying to solve this same problem at the same time because we weren't aware that we are also doing the same thing. And then really our design manager was someone who actually put us together that, okay, hey, you guys are doing similar things. Why don't you guys collaborate? And we actually had this thing called a Sigma Migration Project, which is a migration of the software from sketch to Sigma. And the team kind of like saw the opportunity that like on Sigma, we can work more effectively by just like the software feature itself. Like we can put them on each other. It's more collaborative, it's more real time. So why don't we just like use this opportunity as like official takeoff to kind of like, do the process improvement within Nagota? So I think that's just like official starting point to work on this. - And yourself, Anita, you wanted to say something or add something to that? - Yeah, and on to Erk's point, we actually started working on the process improvement before a Sigma Migration. We have defined and standardized the workflow. But as Erk mentioned earlier too, since we have to migrate our tool from sketch and also there's an abstract and zapping altogether to the Sigma, the original process need to be iterated based on it. And yeah, that's why we have this working template on Sigma in the end. - And I guess I wanted to kind of go more into the why of why these things actually happened. And so you mentioned that everyone was facing all of these problems. Did you share some stories or like a certain point in time where you felt like this was something that you needed to do something? - Of course, I think like what we started to feel like we need to do something about it is when we see that the problem is getting bigger and bigger because the team is also gradually growing really big and it's become more obvious when the problem starts to reflect on our product itself. Like when we work in an efficient, ineffective way, we kind of like started to see that, hey, the product started to become inconsistent the product started to be inconclusive. Like we see the thing that are so fragmented in like our user journey in within the quota. So we feel like if we don't do anything about it, then it will become like a really bad problem for us to have for like a product company. But that's why we started to take it seriously and then we see if there's any other way that we can like try to make all the teams work in a more seamless way and then in a more peaceful way. Like let's frustrated what they want to mean. So yeah, I think that's how we just started. - Think about our quota culture. I think everybody knows that we encourage everyone to run experiments on every product. And you know, we don't really need to ask anyone for permission and I think good side about this is that it keeps us moving fast and being flexible. But think about this on the other hand, the flow and then the overall experience might seem fragmented on one product. Like typical examples that we actually have this is an as our foundation in the front end design. However, designers sometimes don't follow the design language and guidelines with some reasons. Maybe because of the business requirements, time constraints or even like the technical limitation. So we often time realize this after we saw the experiments already launched and it was kind of like too late to fix. And then like this kind of things keep happening. So we step back a little bit and look at the whole picture and we can't realize design can not play an important role in this process. And how can we bridge the gap from our end and try to make more cohesive user experience design? - I see. And so just to give our audience a little bit more context about, you know, you mentioned as we scale, as our design team scale, we kind of began to start facing these issues with inconsistencies. When did you kind of feel like this was the problem that we started to experience at Agoda? - I think probably like two, three years ago when our team started going to a much bigger team. I think Nahoo probably know better than any of us here. When the time Nahoo joined, the team was much smaller. We were sitting together in a corner to a point that some designer would in a different floor or area. So it's really hard to communicate with each other. When there's more teams and people, yeah, it's really hard to see what's already designed working on. And we kind of lose the sense of transparency. And I think this kind of problem just revealed more when things grow bigger. Yeah. - Just to give more context about it, like, you know, when I need to mention that Agoda was like really small at that time that was like no stand out or whatsoever that like, you know, new joiner could like follow. Like we don't exactly like know what to actually do. Like we normally just like work within our team and we report to our like product manager, we only work within our circle, which it was okay when the team was small because it's the impact is not as big. But when the team is getting like a lot bigger, it's become a problem because each one of us become like a huge chunk. So that's when it's like, you know, what I mentioned that the impact, like the the results started to show. And that kind of like, it's like pretty bad on like having an ineffective working process within a big team. - Can you give us like a number in terms of like, how big the team was when you started having this problem? - It was from like, from 10 designer to like 40 designer, then we started to feel like it's become a big problem. And the scale like, it's like, it's scaling up so fast, it's like from 10 to 40. It's over like a year or two. - Wow. - So it's pretty like, pretty quick to kind of like, go to team and I guess at that time, we didn't have like a strong foundation for design, for designer to kind of like follow the right process. - And you've been working on this initiative for how long about six months to a year, something like that, right? - I think about one year. - One year. like since 2019, like the end of 2019, I think. So I want to take you back on time because this is a huge problem. It's not an easy problem to tackle. So I want to understand when you begin, when you started, like what were the initial steps that you took? Because this is not an easy task. It's not an easy problem to solve. Yeah, we start with interviewing designers and devs as the first step. We ask around and see if we find out some similar pen points from different designers. And we also interview devs because our design process also involved them when we are handing over our spec. So it's kind of like we design solution for our customer, right? We do interviews and we find out their needs and pen points. So we just cannot apply the same methods. We do this. So we were actually applying some design thinking to this problem. Yeah, it's actually like the design design, design, design process to solve the problem. But it's like you're not the problem for a customer, but it's the problem within our design team. So it's actually pretty fun. And just like from what Anita mentioned that we try to get the insight from interviewing, when we get the insight Anita and I, we actually like you came back and I followed it the insight and then just trying to map it out to like how we think the ideal process should be and what it's actually like you know how a go to design process is actually so we kind of like map it in together and come up with like kind of like a diagram of like okay what is like you know how how should one designer start what would be like you know their contact person who we have to talk to what they need to do before doing an after the design in order to make like you know a more well-informed environment that like everyone is kind of like aware of what everybody is doing by not adding too much effort into like you know trying to make this thing work. And you mentioned you know you spoken with all these different stakeholders with different designers, different developers. So I assume you also were facing some challenges right from that perspective. Everyone have their own way of working their opinions. How did you handle what sort of challenges were you having with all the different stakeholders and how did they handle those? I think obviously like you know when at a go to we are pretty fast-paced as everybody might know. Time is like a really limited resources and once we want to introduce anything any process anything that they need to follow they will look at it as like additional steps that will slow them down. But I guess then everyone kind of like agreed that we have this problem where it actually you know show on our product design quality. We are more kind of like willing to take you know any like proposed solution in order to make this thing better. But of course it's not perfect like when we offer what you call it like cerebral ball like the things that we kind of like propose to design team was like a template right the template in consists of like the blind template that for designer to fill in like you know all the design problem. Design statement how would you measure it and all the checklist that they need to kind of like talk to people to make sure that they don't miss anything. At first we just kind of list all the extensive list of all the things that they need to do and obviously it's too much like nobody has got time for that one. But like once we launched the template we actively like monitor for the feedback from the designer about like okay what are the challenges that they have with this curling implementation like what are the things that we could make it better. We definitely like when it is to decide some of the things that might not have a lot of impact. Because some of the thing is already something that the designer are already doing it by. We just put it there as a reminder so that no one is missing that. So we just kind of cut the thing that it doesn't really like you add any value to it and really simplified into a way that it is seamless enough to be integrated into designer working process. So I guess there is like no one solution but a really important thing is we need to be actively reaching our feedback from the user. So I think that's like similar to the design process design thinking like you know we think about it we test it we measure it we iterate more and more so like that's pretty similar. Yeah I think also like we started with in the core design thing first to start small. And then like it helped to kind of like you know apply this on the core thing first. And then later on we try to apply on the supply side. But then yeah because on the supply side they have a different workflow compared to the core thing because we are working on more mostly like velocity tickets compared to you know supply side. So then we try to like create another template for supply side more like a milestone template for them to you know kind of like fulfill their needs. So that's also something we are like I think this what we were doing right because I think this working process is for sure will be keep iterating and based on you know the designers or the workflow and stuff. And then that's for sure like the as I mentioned right our first iteration we launch and then later on we kind of like launch the survey and ask for feedback. And then we have a second iteration and then this will keep going. Are you still working on those or is it like an ongoing initiative. I think we are also trying to work for the next step will be combining this with the guilt template. Because I think one of the one of the feedback from the designers that like they do this template but then it's the context is similar to the guilt right and then the guilt session is like the review section critis section on the design in the in the design team and then if we kind of like combine those two others one template and they will say design a lot of time they don't have to do exactly the same thing over again. So that's why we also trying to do as well. Can you briefly explain our listeners what what are the guilds actually. Yeah yeah so guilds design guild session is like the meeting that you know our designer gather around like once a week and then we kind of like share our design. And then you know designer can share the feedback and then critique about like the design and then before we show into the PM. That will also help the designer to kind of like has a different perspective on their on their end. So that's kind of like a yeah design critique section but we we call the circuit. Awesome and yeah so like I think having been doing this for a year or so now as you mentioned when did you kind of were there any proud moments where you felt like the ball really started rolling as you mentioned like the first iteration was just a template and and there were a lot of things that needed to be improved and that have been improved. But were there any points where you felt like okay this is we're getting traction people are slowly adopting the process that we have created. For me it was when we were able to have like a better onboarding session for new joiners to design team like let's as I mentioned before like we had nothing to kind of like onboard designer to within a go to team. But now I think the process become more smooth and then it's like we are more prepared like we we can answer like almost not all question from from the new joiner but at least we have said that good foundation to get them started it and like you know when they ask us question we know like how could we improve it. And then like we we know that like what we come up with is clear enough is it like intuitive enough. I think that's that's when like you know I I feel like what we did actually like make quite a big impact to what the science team to create something that we didn't have before. And I guess like right now even though it was pretty hard for us to kind of like get that adoption rate for the designer to disuse our template. But now once it's kind of like integrated in a way within like their daily day to day thing even though it's kind of like a small thing. But I think we have seen like a quite a drop in terms of report on you know things that designer or each team are not aware of I think that thing has been proved like quite drastically even though it's not 100% but it actually like quite quite improve in terms of okay the. We can work more peacefully we are there's no frustration we don't have to kind of like stop the problem in a really limited amount of time so I think i'm really happy with that. So the change happening designing is that there's more transparency costs team and we we have better collaboration when we work on our design. We see designers start informing and tagging each others in the early stage we also have this feature on a thick month designer can tag each others and pns or devs whatever involved in this project and we can leave a common on the design and get a quick feedback have a better communication and alignment. I think one thing I want to mention is that our design flow heavily involved with this as a sitting as well and we also see better collaboration between part of design team and design sitting. Yeah it's not 100% applied like what are mentioned but we definitely see some improvement yeah. Wow, such I think I'm going to be personally joining the team later on. So I'm looking forward to kind of studying the actual, I guess, design workflow. But just to wrap things up, having kind of completed or taking part in this ongoing project, what are some tips that you might have for other designers and other organizations that are starting to feel the pain points that you felt maybe a year or two ago? Do you have any tips or recommendations for them as to what they should be doing? So every design thing has different culture and different possesses and issues. So they need to kind of resolve it by themselves. And it also depends on how big is the team and other factors. I couldn't say much on the public itself, but what I can say is that as a designer, if you identify some issues on your end, no matter it's within your team or outside your team. As long as you see this opportunity to improve and can actually benefit on a group of people, don't hesitate. Initiate it and figure out a way to resolve. Try to zoom out a little bit and think in a more holistic way. There's a lot of ways we can gather feedback and ideas. We just need to kind of prioritize them and focus on the critical ones. And we try to come up with the solution and keep either ready on it. I think that's just the way. For me to personally add on to my biggest takeaway from doing this project would be to look at the product in a bigger picture always. Even if you are a small big team, it's always important to collaborate and to be aware of what actually going on within the whole team, the whole organization, especially for a big team like us. It's really easy for us to look at that side of the product picture. Most of the time we tend to focus on one or two areas that we work on. But at the end of the day, the user comes to a go-to.com or a go-to.s. They would just ask from the entire experience from the beginning to the end. So if everyone jobs to make sure that we provide a great user experience through our product, holistically, and it can start from our day to day working process, I think that's what I believe after I overcome this kind of project. Alright, we're coming to the end of the show. Anita and Nurek, this is really awesome how you use your design skills to solve our designers' problems. And thank you very much for coming to the show today and sharing this. And hopefully, you know, this will inspire our listeners to take similar initiatives. Thank you so much for having us as well. Thank you. 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.design. Thanks again for listening and hope to see you in our next episode.

Podcast Summary

Key Points:

  1. Anita and Eric developed a standardized Figma workflow template to solve design team process issues at Agoda.
  2. The initiative was triggered by team growth (from 10 to 40 designers) causing inconsistencies, poor collaboration, and fragmented user experiences.
  3. Common pain points included unclear problem definition, lack of early feedback, and inadequate handoff and experiment tracking.
  4. The team used design thinking methods (interviews with designers and developers) to identify needs and map an ideal workflow.
  5. The template aims to improve work efficiency, collaboration, transparency, and consistency across the product.
  6. The project started around late 2019 and took about a year, leveraging the Sketch-to-Figma migration as an opportunity for process improvement.

Summary:

Anita and Eric, senior product designers at Agoda, created a standardized Figma workflow template to address growing pains in the design team. As the team expanded from 10 to about 40 designers in a short period, they observed increasing inconsistencies in design solutions, poor cross-team collaboration, and fragmented user experiences across the product. Common issues included designers not fully understanding requirements before starting, struggling to get early feedback, and lacking proper handoff and experiment tracking after design completion.

The two designers were independently working on solutions until their design manager connected them, and they officially launched the initiative during the company's migration from Sketch to Figma. They applied design thinking principles, interviewing designers and developers to map pain points and ideal workflows. The resulting template provides clear guidelines on what designers should do before, during, and after their work, helping standardize processes, improve efficiency, and enhance transparency.

Despite initial resistance from a fast-paced culture that views new processes as slowing things down, the team recognized the need for change to maintain product quality. The project took about a year, starting in late 2019, and is now being rolled out across the organization, including the supply side where one of the podcast hosts works.

FAQs

It is a standardized template in Figma that sets guidelines for designers before, during, and after their workflow, aiming to improve efficiency, collaboration, and transparency within the design team.

It addressed issues like inconsistent design solutions, lack of collaboration, poor handoffs, and fragmented user experiences that arose as the design team grew from 10 to 40 designers.

They interviewed designers and developers to uncover common issues across different design stages, such as unclear requirements before designing, poor collaboration during design, and inadequate handoffs after design.

They started by interviewing designers and developers to understand their needs and pain points, applying design thinking methods to the internal problem.

As the team scaled from about 10 to 40 designers in a year or two, lack of transparency and inconsistent workflows led to fragmented product experiences, making a standardized process essential.

Designers viewed the new process as additional steps that could slow them down, but the team's recognition of product quality issues made them more open to proposed solutions.

Chat with AI

Loading...

Pro features

Go deeper with this episode

Unlock creator-grade tools that turn any transcript into show notes and subtitle files.