In this episode we are talking with Alex and Fendy about how they managed and led our design team migration from using a few several design tools such as Sketch, Zeplin and others into the Figma experience.
Figma is now considered as the de facto tool for product and interaction design, and in recent years, it took the world of design by storm.
Alex and Fendy worked with our designers to make sure this migration could go smooth enough without interrupting their work.
Tune in to learn how they did that as they share those learnings and more insightful stories.
In this episode we are talking with Alex and Fendy about how they managed and led our design team migration from using a few several design tools such as Sketch, Zeplin and others into the Figma experience.
Figma is now considered as the de facto tool for product and interaction design, and in recent years, it took the world of design by storm.
Alex and Fendy worked with our designers to make sure this migration could go smooth enough without interrupting their work.
Tune in to learn how they did that as they share those learnings and more insightful stories.
Alexander 00:00
One of the first things we did like to schedule interviews with designers from every single design team to sit down, you know, for an hour or so to understand, you know, how do they work today? You know, what do they like what works well, but also, you know, what are some pain points you're experiencing today? Try to figure out like, if we were to move to this new system, how would we organize things?
Fendy 00:21
project cannot be successful if you don't have people believing for the common goal of kind of improving how things are. So having that conversation early, kind of flagging any potential kind of misalignments setting expectations, right. So I think getting that trust, I think it's very important that people trust that we can build this together.
Nahum 00:42
Hello, and welcome to the design explorers podcast by the Agoda design team. agoda.com Is the global digital travel platform where you can book hotels, vacation rentals, flights and airport transfer. In this podcast, we'll 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 and I will be your host for the show.
Yuki 01:18
Nahum, what was your first impression of figma?
Nahum 01:22
So when I first tried figma, I was very excited about the possibilities it brings. Because you know, it picks up picked up where Sketch left with the idea of components and and this modular system that is following the the atomic design system, you know, where you could focus on actual actual designing and not worrying about maintaining all this components and UI patterns that we need to use as part of our design work?
Yuki 01:49
I definitely recall the first memory that I have with figma, I think it was creating my first child and parent component, and seeing the child component kind of shadow and mimic whatever changes have made on the parent component was just so satisfying to watch. And I believe that was the same excitement that all the other designers were having, when we have decided to kind of migrate our tools to figma. And the takeaway that I think Alex and Fendi has been repeating, as a pattern throughout this podcast was that there are greater problems that the figma migration will not solve, I think initially, they had this idea that, you know, we're going to change the tools, and therefore the way we've worked together, and it's going to change everything, the way we work and solve all the problems that we've had, since we're starting scratch. Right. But that's not the case.
Nahum 02:47
That is true. Figma, is just a tool. And I think like, like Alex was saying in the in the actual episode, he was saying, you know, if you expect that you will migrate to figma, and then all your problem will, will be gone and everything is solved. It's not, it's not really the way figma is there to help you with the process. But you will have to address the needs the pain points of all the stakeholders and users before even doing the migration.
Yuki 03:13
And yeah, figma has been improving for literally every single update that they have been releasing. And even within this week, I think there were some new updates from figma. And our internal design team was really sharing those updates and things that, you know, could improve our workflow. So we're really excited to see what they come up with in the near future.
Nahum 03:36
Yeah, I think that the future of the design tooling is very exciting, because there are still opportunities and there are gaps that need to be closed, specially moving from product design to product execution. And you know, not only designing in the tool, but maybe in the future, it will be possible to translate the deliverables into actual code that developers can use in production. So then it's become a real collaboration tool.
Yuki 04:02
So in this episode, Alex and Fendy introduces their figma migration project. They talk about their process and how they went through with their challenges some of their takeaways and reflections. And I hope you enjoy the show.
Nahum 04:20
Hi, and welcome to the ninth episode of the design explorers. Yuki and I are here today with Alex and Fendy who are going to tell us how they managed and led our team migration from using a few several design tools such as Sketch Zeplin and others into the figma experience. And for those who are not familiar with figma figma is now considered as de facto tool for product and interaction design. And in the recent years, it took the world of design by storm. Alex and Fendy worked with our designers to make sure this migration could go smooth enough without interrupting their work. And today we are going to learn how they did that. Alex and Fendy, welcome to the show.
Alexander 04:54
Thank you.
Fendy 04:54
Thank you man
Nahum 04:56
let's start by giving our listeners you know, some background about who you are how long you've been st Agoda.
Alexander 05:01
Alright, cool, I guess maybe I'll start. So yeah, my name is Alex. I've been with Agoda for about four years. And I worked both on the hotel facing side helping all our hotels to work with Agoda better you know, to provide, you know, the best prices, updates, the, you know, inventory, hotel information, etc. And as of one year ago, since one year ago, I've been working on the hotel facing side. So I'm currently designing packages solutions for people who want to book more than just the hotel with Agoda. And my role in the company right now is product design lead. So I would say that role is still an IC role. I'm still designing, that's my main job. But it's kind of a bridge between the leadership team and the IC designers, trying to both mentor more junior members of the team and also advocate for, you know, design quality and design challenges that we face as a design team every day to leadership and help to solve that.
Fendy 06:07
Hello, my name is Fendy. So I've been at a Agoda about four years. Prior to working in the design system team, I was in a few different teams. But now my area of focus is mainly design systems. And so design system falls under this kind of broader umbrella called Design ops. So we look at things like tooling, how definers are working, whether they're efficient, and whether they need help with some other processes around design or how they make design or how they ship products. And design system is kind of one of the core pillar within the practice of design ops. So yeah. Glad to be here.
Yuki 06:49
Awesome. Welcome, Alex and Fendy. So over the past two weeks or so figma has launched schema, the design systems conference. And I noticed within our internal design team, a lot of people were talking about it and in sharing some some things and insights that they have learned, right. And how about you guys, Alex and Fendy? Have you learned anything? Or what were your takeaways from them?
Fendy 07:14
Yeah, maybe I can start. I wish they did the whole conference in a more timezone friendly for the people in Asia. Yeah. So we I managed to catch some of the recordings after the conference was concluded. I think, when looking at some of the insights that were shared, I think that would be kind of useful for us if we had that when we were migrating to the Figma as a tool. So yeah, I think now, after kind of watching some of the material, I think we kind of slowly will take some of the findings and apply it in the next kind of updates or iteration or on how we build our UI kits, or how we maintain design systems, or how to be operated as a team. Within eventually, somebody was very useful for us to kind of push define systems like the Agoda slightly further.
Yuki 08:09
How about you, Alex?
Alexander 08:12
Yeah, no, I also watched it, I didn't sign up for it initially. Although we work from home, I also saved by the timezone issue there. So I have been watching several of the recordings after hand on YouTube. And, yeah, what I find super interesting is, you know, different design teams seem to tackle this in such different ways. You know, you had a Netflix team, talking about the importance of, you know, contribution from like, the, the whole design team, and how they kind of didn't want to be like nitpicking on, you know, how they organize the files, and you know, the design system itself, in order to kind of, you know, lower the barrier for for others to, you know, help out. And then you had some, you know, talks where they were really, really diving into the details of, you know, how to build these scalable components, best practices for doing so, extremely organized worksheets within figma. And it was pretty interesting to see as well. So there's a whole lot of different things to consider, as a design team. I think both, you know, yeah, like giving others autonomy to contribute, organizing things. How do we make it easier for designers to consume the components so that we're, you know, think of that when we build them? Yeah, a lot of very interesting nuggets there. To learn from for sure. So super interesting.
Fendy 09:39
I wanted to add on to that as well. I think some of the areas that were really kind of interesting or upcoming is how different teams are kind of augmenting figma with custom plugins that they built for the organization to kind of solve really unique organizational problems about how the approach organizes our info I think one of the examples that the Netflix team showed, I think they built this kind of content generator called Moriah. Basically, what they did is they just put the content API for Netflix for differential localization. And that is kind of integrated directly into the figma. workflow. So I think that saves a lot of time for designers to actually kind of design for different locale and things to imagine if we had that same capabilities at Agoda, to leverage our property API easily can pull all of the types of pipes, property images, I mean, whatever, I think we have a wealth of data or libraries that we can pull pull from, but I think that is kind of untapped. Yet a, that's something that we can look into.
Yuki 10:54
Everything from out for that, or push for that, I think that'd be great.
Nahum 10:58
Speaking of Agoda, you guys been working for how long? Like one year and a half on this migration to figma, something like that, or more than that?
Alexander 11:05
Yeah, pretty much, pretty much a year and a half, I would say,
Fendy 11:11
initial push was kind of full on biting now it's gonna, just providing support. So like, the effort is always ongoing, but maybe it's not for my involvement in just kind of minor iterations or improving workflows, the libraries structure and decay, but I think the initial phases were the hardest. Kinda, I think we had to migrate, I don't know, 4000 components from sketch to Figma, that means basically rebuilding everything from scratch.
Nahum 11:41
So for our listeners, you know, maybe they're not familiar with figma. And the whole word of, you know, migrating from sketch to to figma. Maybe you can give some background, what exactly was involved in this project? And what did you guys do?
Alexander 11:52
Yeah, sure. So yeah, I think there are like two, two major like components to this migration. One being the design system side, like how do we build a scalable design system, which Fenyi was kind of leading all of that work. But then the other side, where maybe I was taking more the lead on what's, you know, how do we set up like, all the different, you know, features and products that we have? And like, how do we make the whole like system work? Well, for all the designers, how do we encourage collaboration between teams? How do we make people stay aligned? So I would say like, there were two parallel tracks in our migration one trying to understand or figure out that part how to work together better and more efficiently, but also how to actually like migrate components, design systems, and make sure that people, you know, can consume those in a good way. So yeah, definitely, like those two tracks happening. And I think the whole project kind of started, yeah, about one and a half year ago, I think, plenty of designers on the team had sort of tried out the tool, like their spare time, or, you know, just played around with it for fun. It was a very up and coming tool. So everyone was naturally curious about it. But but also, we know what big effort it would be to, you know, move to the new tools. So what happened at that time was that we had a new design manager joining us from eBay. And he had just been through this whole migration with the eBay, the science team. And his experience with that was really positive. Like the designers seem to like it. Yeah, it was very well received within his team. So you know, he came to our team and said, Hey, why don't we start by looking at the costs of the existing tooling? And start to you know, like, figure out like, an analyze how does it actually work today? What are some issues, you know, we're having that we might be able to solve. So yeah, he kind of started this little working group of just a few designer within his own team that started to look into this. So that's kind of that's kind of how it all started, I would say. Yeah,
Nahum 14:05
maybe we can talk a bit about what was before, you know, how designer work at Agoda. Before the migration, and what was the big change? Actually?
Alexander 14:14
Yeah, yeah, sure. So the way we kind of work so way, way back in the days, like, we were using sketch, and people were like, sending sketch files, you know, putting them on servers, or sending them on Slack. Around the time when when I joined the company, so that was about four years ago. I think we had already started using abstract or we were like, kind of in the process of evaluating that as a tool. And, you know, at that point, I think everyone was just happy to, you know, have some sort of structure, whatever that structure was. So just, you know, we started to use abstract people where you use, you know, creating new projects, and you're like, dropping all their files in it. And, you know, started to work, and that's, you know, like, we did that for a few years. And it was definitely a big improvement. But as more and more people were working with it as the whole design team was, you know, starting to use abstract, we realized that there was not really any planning done to kind of use this tool, it was like everyone was so excited to have some kind of version control and like file management. So what we realized is that we had maybe like three, four different projects where we had design systems and UI components, they were not centralized, they were not managed by a centralized team. There are different versions of the design systems as well, scattered around, so people were using the wrong system. There was no like, consistency in the way we kind of set up teams and projects in abstract. So that was a bit all over the place. It's it took a long time for people to find stuff, and you know, to know where to look. And, and I think, finally, one of the bigger issues we had was that it really started to slow us down a lot, you know, loading the files could take minutes, committing changes took a while, syncing to the servers, it just, you know, it became a real issue. Where, as we found out, when we were interviewing designers across the team, a lot of people kind of went rogue and like, downloaded the files on their computers, and just ignored abstract after a while. And some teams were like sharing the files on on Slack again. So we're kind of back to, you know, like back to the starting point where, where the tool wasn't really solving our issues anymore, or at least not in a in a good enough way for us to continue. Yeah, and it was expensive too,
Fendy 16:42
to add on to the kind of how abstract wasn't sufficient enough to support some of our kind of design work or the nature of the design work is, I think what effect doesn't offer was this kind of idea of a real time collaboration. So what happened with abstract was, there was a project and then there'll be 100 different branches of that project. And what happened most of the time is this branches will not connect close back into the actual muscle of our master design. So we end up with having a lot of permutations of a design that nobody knows whether it was up to date, whether it was taken or whether it was archived. And so that causes a lot of confusion about what's the latest design, or where the latest design file is. So I think moving to figma, I think the advantage that figma head was this idea or this notion of real time collaboration. So if you're kind of duplicating someone's work, there's an opportunity for you to address that conflict now. So you can address the conflict now versus abstract, where you hopefully think that let me address this conflict one year down the road. And when you address a conflict, then you don't know how to be console, or these changes that that that basically had happened. So there's a lot kind of merge conflicts happening in abstract, partly because of I think, bad practice. Like Alex said, there was no clear guidelines how you should commit, or when should you merge your designs or whatever. It was more like, it was better than previously, I would say it was more of this organized, organized chaos. Moving to figma allows us to address some of these fundamental issues.
Yuki 18:24
Yeah, and I think, of course, there are a lot of reasons looking back why migrating to figma made a lot of sense. And so I think getting towards like the nitty gritty detail of how we actually executed the entire migration project. So what was like the first very first step that you took to begin this project?
Alexander 18:45
Right. So I mean, to begin with, we were there were quite a lot of designers who wanted to be involved in this. So first of all, we needed some sort of buy in to even approach this right. So the very first thing we did was to look at all the costs that we're spending on licenses. So you know, we did a breakdown of every single design tool that we we had, and the cost of it. And we estimated that cost versus what if we would, you know, like cancel most of them and switch to figma. How much would we save? And you know, it turned out there was a quite significant savings per designer. But the biggest saving that we found out was by removing Zeplin, we would also save all the costs for developers because you know, sure, we're a pretty, pretty big design team. But nothing compared to the development team. You know, when you have hundreds and hundreds and hundreds of developers who need a license, which is something that sapling charges for, that really started to add to the cost. So yeah, by us providing like those numbers black and white to the leadership there We're very enticed, you know, like to dig deeper into this. So that kind of gave us the buy in and time to continue the process. So that was the very first step. And I would say, once we had that sort of buy in what we did was, you know, to really explore what other design things were doing. So we were reviewing, you know, YouTube conference clips, where people talk about figma, design systems, conferences, medium articles, podcasts, we basically had this slack channel where, you know, we'll we'll just share all these resources when we found something interesting. Like for everyone to, you know, like, read up on or listen to, to really like, gain a lot of interesting insights from other companies that had already done it. And we also had our sister company booking.com, in Amsterdam, who had been migrating to figma, a year earlier. So we kind of set up a call with them, like talking to some of their designers and design systems team to understand how they went about migrating what the challenges were. So that was also very helpful. And something that I kind of realized at that point was that wow, you know, like, there's such momentum for this in the design community. And there's such excitement, both to do this migration for a lot of design teams, but also to share the learnings. So a lot of these companies had been, you know, like, very, very transparent with how they set things up all the little, you know, tips and tricks and tweaks they have done. So we found it super helpful. At the time, I would say.
Nahum 21:42
So Akex you mentioned getting a buy in from senior leadership, but also you probably had to get some buy in from the designers, because you're about to change the way they work they process. How did you handle this kind of almost a paradigm shift in their mind?
Alexander 21:55
Yeah, for sure. That's very true. So I think like, one of the first things we did, like, Okay, we did all this, like research looking into other teams like what they were doing. But we also took time to schedule interviews with designers from every single design team. So you know, both the enterprise side consumer side, all the different horizontals and verticals, to sit down, you know, for an hour or so to understand, you know, how do they work today? You know, what to do? Like, what works? Well, but also, you know, what are some pain points you're experiencing today, both with the tools for the design, process, collaboration, and we sort of, you know, documented all of that. And at the same time, within the team, what we did was, we had a few workshops, where we started to kind of try to figure out, like, if we were to move to this new system, how would we organize things? You know, would we, you know, let all the app designers like work in the same project and in the same team? And, you know, or would we organize things by, you know, maybe consumer facing and enterprise side would have different products in different teams. So we really started to, you know, we had a couple of whiteboarding sessions trying to like lay out all these different options. And then we also laid out, you know, what would be the pros and cons for each of these? Which one do we think works better. And then we came up with some initial drafts, okay, if we do it this way, this is how this team is going to be organized. This will be the pros and cons that we can think of. And then we took those proposals out to each in these interviews when we talked to other designers, and we show it to them. And we asked them, hey, you know, if we were to migrate, and here are all the issues that you mentioned, here are some different ways that we could potentially organize ourselves. And here is like, what that would solve. And, you know, like, all these issues that you mentioned, like this solution might be helping, or if there's something we haven't thought about, maybe we can actually improve it this and that way. So it was kind of like a road show where we had this initial draft, and we took it from team to team and kept adding and changing and tweaking and improving. So I think that by the end of like that, maybe that took like a few weeks to do, because I mean, all of us had our day to day work to do as well. But yeah, after that time, I don't think anyone in the design team could say that their particular team had not been involved, or they didn't know, everyone had been involved in one way or another. Everyone got to have a say and and help to kind of develop this this plan. So I think just by involving people, making their voices heard, you know, hearing that, okay, these are the issues that you're having, and this is how we plan to fix them. I think that really helped us to gain momentum within the team. And, you know, get that sort of buy in internally as well.
Nahum 24:49
And Fendy, were there any challenges from the execution integration part?
Fendy 24:54
Yeah, so when when the whole team decided that figma is the de facto tool I think it came, it was a great opportunity for design system as well. Because prior to figma, like Alex mentioned, like, there were a few kind of siloed UI libraries or sticker sheets that nobody knows, or haven't been maintained. So for us, the goal moving to figma was pretty clear if designers are onboarding to figma for centerlized tool. And when that shift happens, we need, we need to be ready to support that, for all future design work that needs to happen. So meaning all our components that were previously can maintain in abstract or sketch needs to be ready by the time migration happens so that there was a lot of work in kind of making sure when this migration of 50 designers and all the developers to this tool that all the components are ready to be kind of pick upon and build and use for whatever design work. So part of that was the goal for design system, but also part of it is trying to understand how to structure our libraries in figma. Because previous that we maintained through Abstract as a kind of central library, but Figma have different ways of managing files or project and structure. So part of it is how do we kind of mirror the same idea. So what we ended up with was kind of similar to how maybe if you're familiar with atomic design, or how things are built, so we have our foundational base layer, which are all our design, tokens, spacing, color, typography, what have you. And the next layer are all components built through that foundational token. So through that, you're able to kind of even manage internally for design systems designer, to maintain our libraries in cascade changes easily. So there was a lot of kind of trial and error to kind of structure the files and how it works, how dependency works within design system libraries, and also how dependency works on designer tickets, what using the design system libraries in your design, and how to manage changes around that and things like that. Yeah, so it was a big kind of effort, especially when we had to recreate every single component.
Alexander 27:06
Yeah, I think I think, you know, like, the, like the time it took for us to sort of evaluate different options, how to like structure things, how to set you know, the files up, how to work with Source of Truth, etc. Like that was, you know, quite a lot of work that went into that. And a lot of work that involves, you know, like many different designers as well. And I think that's time that like, like, my side of this migration, like we're spending a lot of time on this. During that time, I think that gave Fendy some time to sort of like work with his team and the design system team to figure out a lot of things under the sciences inside, and even, like, start to prepare components. So that's why, like I mentioned before, like, we work on two parallel tracks, you know, at one point in a project, we sort of like collectively decided that, okay, figma is the tool that we do want to use, we think this is way superior, for XYZ reason. And after that, you know, Fendy and his team could could straightaway go and, you know, work on that stuff in the background, while while we were, you know, figuring the rest out with the team. So that's also kind of gave you guys a little bit more time, I think to, to do that.
Fendy 28:14
Yeah, that was really helpful. Because when it was decided that this is going to be the default design tool, I think the incentive for others is we are able, again, to make sure components are already and part of that kind of migration is all the master files that were previously can update that have a chance to be updated with the newer components, make sure they are as close as possible to what we see on the actual product.
Yuki 28:42
Are there places do you think there can be a little bit more conversation around optimization? I think Alex and Fendy both went to discuss about, you know, the iteration process of getting feedback and making sure everyone in the design team is involved in this process. But I'm sure there are places where you had to make trade offs, right, between, for example, collaboration and visibility between the teams and so on and so forth. Did you have any challenges towards like, you know, making a trade off? And how did you work around those challenges?
Alexander 29:23
When it comes to you know, alignment, and when it comes to, you know, communicating with each other and different things. One thing that we did realize in this migration was that, like, eventually the tool is not going to solve all our problems, right? Like, in the end of the day, like there are like, I don't know, 4050 designers trying to you know, get good work done. And that requires more than than use the tool. And so, what what we initially what we did was that okay, we realized we had all of these issues, we had talked to a lot of designers, they mentioned this that you know, like aligning and communicating and like that, that stuff, you know, it's hard. So we try to solve that by, you know, like adding our super rigid process where, okay, you need to do this and this and this and this and this, but eventually realized that, you know, the more stuff we add to a process, and we tried to shove that down each designer's throat, you know, the less people are gonna, you know, be inclined to, to actually follow it, you know, it just becomes too much. At some point, every designer has their own very unique way to solve problems, to communicate. So we definitely wanted to make sure that, regardless of which approach we take, and how we set up things, and structure things, there's plenty of room for each designer to work in the beta work in a way that works best for them. But with that said, instead of like telling people what to do, we do try and provide, you know, some checklist, for example, where they can, you know, like, this are reminders, I guess, you know, remember to, you know, like ping to the sign systems team for feedback, you know, remember to, if you're working on someone else's, you know, feature page, ping them for feedback as well. So that's more there for like ensuring that, you know, we maintain a good quality of the design, but how you actually reach it, when you do that, how many times you do it, if you do it on figma, or on Slack, or set up a call, like that's, you know, really not something that we are interested in, you know, micromanaging,
Fendy 31:23
maybe I can add on to that, I think it was not coming from a place of trying to enforce or dictate how things should be done, I think we have, I mean, I will use a word I think we recommend people to follow. So it's more recommendation. And always, I think when we build systems and things like that, it's always a question of a balancing act, right? It cannot be too rigid, or is too close. At the same time, it cannot be too awkward, or too flexible, then it's too chaotic. Right. So I think it's always finding, what's the right balance point that can fulfill most of the requirements that designers need to do in how they interact with the system. So I think it's always a delicate kind of line or balance within too close to open, and how do we can shift that balance slightly left and right, depending on the needs and situation at what stage of the design process or how mature the design team is thinking in terms of how they approach things. So yeah, it's never I would say, Never set in stone, it's more like recommendations, and always trying to balance to fit the context of the situation.
Nahum 32:35
So you know, we started talking about schema in the beginning and the conference and all these companies sharing their learning and takeaways. And of course, it came after you already the migration, so it's not too late. But what what are some of your takeaways? What are some of your learnings from this actually ongoing project so far?
Fendy 32:54
Yeah, I think Alex product grouping is to get people involved as early as possible, because this ultimately will impact how they proceed with the work. And also we're kind of mentally gonna get their buy in, because like I said, this project cannot be successful if you don't have people believing for the common good, of kind of improving how things are. So having that conversation early, kind of flagging any potential kind of misalignment and setting expectations, right. So I think getting that trust, I think it's very important that people trust that we can build this together, it makes a lot of the conversations moving forward much, much easier, even though people might agree or disagree, I think there are certain trade offs that we can have to make sure that you're actually doing a greater good, that helps everybody.
Alexander 33:42
Yeah, I think there are like a couple of like, bigger topics that it seems like most design teams are still kind of struggling with and still trying to understand how to do even after migrating such as, for example, you know, aligning with the tech side. So you know, how do we keep a tight alignment between, you know, like, the design components that we have, and what the developers consume, how to close that, you know, gap, like there were a lot of people mentioning that in the schema talks, in their different ways of trying to solve that, you know, aligning on the way they named stuff, the way they even set up variants to match with, you know, how, how the coded component would look like in code. So that like that, that's something that I think, is definitely a big challenge that I think, I hope that's maybe figma can actually at some point help to improve in the tool, like somehow, like, find a way to bridge that gap even better. And also, of course, knowing like, you know, which components are deprecated like, how do we use the components, even if you have a component, there's plenty of ways to to break them in a design and use them in a way that is not intentional. How much do your documents, you know, like we can over document every single thing, but who's gonna read that documentation? How do we make the documentation accessible, and you know, where people actually need it. And there are a lot of those things that definitely still, we can still improve and can still figure out, and I think those things, we can improve with time, like we see people coming up with super, like nifty solutions. For example, someone mentioned in one of the talks that, you know, like we were talking about, like, how do you name like, icon? Is it a heart icon? Is that a favorite icon? Is it a Save icon? Or something else? And there's not really one answer that is correct, right? It really depends on everyone's context and the way people's minds work. And then someone had to district that, okay, there's a description for a component. And in the description, you can add all of these different like tags, if you will. And that way, if you're searching for components, whether you search for heart, or save or favorites, it's still going to show up. So like these kinds of things, I think we can always learn from other teams and like, improve as we go. It's impossible to figure every single thing out in one migration and like do it right from the beginning. Like that's, I think, would be a bit unrealistic. So yeah, it's definitely plenty of things that we can improve.
Nahum 36:22
If you had a chance to start it all over again, or there it was, is there anything that you would do different differently in the process?
Alexander 36:29
Oh, no, nothing? Actually, it was perfect.
Fendy 36:33
I mean, if if you asked me, I think if we had more development help from the start, especially from design system, I think it'd be really, really helpful, because I think some of the pain points I think sounded designers or end users are facing right now. It's some of the components that were built in design, or in figma, that lives in our UI libraries are not available for their developers counterpart. So there's this gap, where it's available in design, but it's not available for developers. So that when decisions like that, or when conflicts like that happen, there always be a kind of fallback. Either people build something that is not aligned, or there is no catalog and it leaves somewhere in the world. Nobody knows. It's not accounted by design system is not maintained by design system, but it's there. So over time, if many kind of people are doing that, then I think it bloats the whole product experience. So I think if you're seeing if I can redo, I think if I can get developers to basically mirror what we've done in figma. On front end, I think that would save a lot of headache for designers, and also for us, because we need to communicate all these differences from time to strike. But
Yuki 37:49
yeah, I was gonna say, so if you had to give advice to people who are considering, you know, migrating to figma, or any software for that matter, you would say something similar to, you know, keep everyone aligned. And it really depends on your team. So make sure you you do collaborate, and it's a team effort.
Fendy 38:11
Yeah. And I would say you need to look at the nature of the design work, right? Like, what's the approach to how the company builds or defines what's stable? Is it more messy experimental, with different branches. And I think if you have that as a constraint, then I think we're gonna help you understand how to build, or how to use figma as a tool. And I think tools are just tools, it's not a silver bullet, that will solve all your organizational problems or design problems, right, they are just supposed to help you do certain things. But of course, tools might be inadequate, but I think part of it is trying to figure out how to use these tools to kind of support how your product team is thinking about designing or how to define how to ship products. So I think you need to understand the nature of the design work and look at the tools and maybe it supports it or it doesn't think like that.
Alexander 39:04
Yeah, I definitely agree that, you know, you it needs to be very clear that that's like a tool can only so sold so much. If if you kind of go go in with this with a promise of, you know, like this promised land that we're gonna move to this beautiful figma and it's gonna solve everything, then it's just doomed to fail. So I think that's maybe something that we learned that we maybe we thought it would, it will solve a little bit more than it actually could, like, we did realize a few times that oh, this is an organizational issue, or this is a communication issue or, or whatever. So that's, I think something too, you know, you set the expectations and set the tone with the rest of the team like this is these are the things we're looking to solve and these are things we actually have to solve as you know people and and a team. That's that's definitely one thing. That I think is pretty important. And another thing is, you know, I don't think you can just look at what other people did and copy paste it. We We looked at many different companies, we looked at, you know, booking.com, Spotify, Uber, we looked at so many different and smaller companies, you know, all having very different approaches to how to do things. So I think if you look and get inspired by them or by us, by that mean, I think that's fine. And you should, but also trying to understand, like, why did this company do it this way? Versus like, you could have done it this or that way. And then, you know, trying to figure out what's best for your team? It's the same as when people ask me Oh, like, what, why don't they have like a, you know, like, pre made UI kits that I can start to as well, every single design team needs different things in their design system, they needed to be built in different ways to support, you know, the tech or the products or the way the designers work. So that's why it's not that like, it's hard to like, come up with a template that works for everyone. Initially, we thought that we would mimic, you know, the way Spotify is set up, like their source of truth, for example. But it turned out after a couple of iterations, with the different designers that didn't really work for us, or we thought we had a better way to, to solve that. So and that's fine. You know,
Nahum 41:08
what, what was unique about the Agoda problem is something that we can identify, or just in general, it was different from the rest of the companies.
Alexander 41:16
I think like one big part of it, that you can't forget this, like, you have a lot of legacy, even if you migrate to a new tool. You know, like, if you have done things in a certain way, you know, like, not all like, Okay, first of all, the way maybe your sketch files or XD files, whatever, like the way they were set up, the way this design system was set up before, you might actually have to consider that when you migrate as well. Otherwise, you know, it's just gonna be too big of a task to completely change everything all at once. I think it's too hard to both completely changed the way you work with the files and migrate to a completely new tool, onboard developers and product managers and others, like it's, you have to kind of pick what, where you do it improvements. So that's one thing. And the second thing, I'll say, like, the way like our teams are set up the way we work with our product teams, the way products are defined in Agoda. Like, the way we define a product, the way we like, split up different product managers and developments in Scrum teams is never going to be the same as how other teams are doing it. And we of course, want our, you know, structure and figma to mimic that in a good way so that developers and product managers can find, you know, their products, their designs, work with their teams in the most efficient way. We don't want people to have to move around and like, go into 100 different teams and projects to find stuff just because well, you know, Spotify works this way. And we wanted to mimic them. Like that wouldn't make sense at all. So like that context is you have to work within that context and find what's, you know, how to tweak that and make it work Good.
Nahum 42:54
Maybe we can switch to talk a bit about the future. So you know, with your experience with figma, and the migration, where do you see this word is going to like, what, what's next, in terms of tools in terms of the way designers collaborate?
Fendy 43:07
No, I think that's interesting, because I think figma did send out an invite to the extent that the kind of plugin capabilities to fig jam. So I think because of COVID, and people are now working from home, and I think figma, as a company, is definitely looking at how collaboration can be made much, much easier to connect remote work. So I think the future of figma, if you asked me, I think is definitely they are moving towards that kind of remote work and how they can facilitate or make collaboration in a remote work environment much, much easier. And I see that because they have just extended fig jam, which used to be kind of close. But now I think we can open up the jams or allow kind of custom plugins to kind of augment Vic jam maybe to build certain features that are uniquely to certain design organization and things like that. So I think the future is definitely gonna be more work, kind of decentralized workforce and how they collaborate kind of visually on figma. Things like that.
Alexander 44:13
Yeah. I would say like, definitely. To add on to what I talked about before, I do think that closing the gap between you know, development and design, it's something that there's still huge opportunities to do. Like, I think it's certain stuff, you know, are just not really aligning, like the design tools today don't align with how things actually work in code, you know, like, for example, why shouldn't I be able to set like, if I have this container, I have a card, and I want to have like that red border on the top, but not on the sides or the bottom. Like that's just impossible. Today's thing, simple thing that like, you know, like, it's very simple CSS, yet no design tool has figured that out yet. It's kind of mind blowing, to be honest. And there are many of those examples, I think the way you know, you need to use hacks today, right? But But then if you're going to hand off, if you're going to hand off that hack to your developers, they're going to build this box with an Inner Shadow. They're not supposed to. That was not the, you know. So like, yeah, that gap, I think still can be tightened much more. And also, I don't know how, but you know, logic, I think, like, it's something that is completely missing in all design tools. So obviously, like, when you like code, something, there's a lot of logic that, you know, like, do the work for you. But for us, you know, building up edge cases, building out, you know, like, or like prototypes, for example, all this kind of stuff requires a lot of a lot of manual work, because you need to lay out every single thing, like duplicate it and do it once again, and change and tweak, if there was a way to crack that, you know, issue to, to mimic the way you can work with logic to reduce the the design on effort that we need to do. That will be pretty cool. So I would like to see something for that. And of course, like more advanced prototyping, like a lot of us do, you know, user labs online these days. Many times, those are not moderated. You know, you might send out like a figma link to like 20 participants to do a lab and something goes wrong, you know, like, then you're screwed. And there's only so much you can do in figma. With prototyping. They do improve it all the time. So that's great. But I think there's still room for more complex prototypes. And yeah, again, adding more logic to it. That's something that would be great to see.
Nahum 46:45
Alex and Fendy, we want to thank you for coming to our show today. I think this this project is very interesting, the way you migrated to figma. And like you mentioned, you know, there were two aspects here dealing not just with the, with integration and the technical side of it, but also with the organization and leading the people in and you did some great job with Agoda and we were we move from using a few tools into one integrated tool that everyone can share together. So thanks again for coming today. Thank you.
Alexander 47:16
Thanks for having us
Fendy 47:16
Thank you for having us.
Nahum 47:19
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.