Building Figma with Yuhki Yamashita: Collaborative Design, AI Teammates, and Building for Builders

0:00There are terms like hovering art director, right? Which have a negative connotation where you You know, imagine your PM inside your file. Exactly. There's certainly a lot of resistance to it. Multiplayer is kind of a side effect of their true value, which is having a single source of truth.

0:20When building products, a single source of truth is digital nirvana. It lets teams collaborate seamlessly without wasting hours and sometimes days trying to figure out what's relevant or what's already becoming obsolete. it. Now, this problem has long been solved in coding, but not in design, which is why I'm excited to have Yuki Yamashita, Chief Product Officer at Figma, as my guest on Building One today. Figma is the most popular collaborative design tool in the world, used by over 95 % of Fortune 500 companies. But when it launched in 2015, the idea of multiple people editing a single file was highly controversial.

1:00The thought of your boss or even your peers watching every keystroke, every cursor movement felt very unsettling. It required a complete mindset shift. My conversation with Yuki, who previously held product roles at Microsoft, Google, and Uber, was fascinating. He shared insights about the power and pitfalls of designing for product teams. How can you design for nine designers and designers at the same time? The surprising amazing impact of the vibe coding moment, and what happens when AI becomes just another member of your team. And there's so much more to this episode.

1:36Yuki, it's a pleasure to have you on the show. Thank you so much for joining me today. Thanks so much for having me, Tomer. So I kind of, you know, had a chance to look at your career a bit. And from the start of it, you seem to be at the intersection of engineering and design. You started computer science, but you also had the role of a design editor for Harvard Crimson. And then you really started a product management career, kind of going through the ranks in Google, YouTube, and Uber. And I'm just curious, when you look back, what shaped your career path? Were you drawn to design, but wanted to learn the computer science aspect to it?

2:12Was it a certain discipline that actually drew you in? um growing up i was the person in my family just making all the holiday cards and you know things like that and i kind of entered college and i didn't really know how to make that into a professional thing necessarily i didn't even know that being a designer was a real profession like a ux designer uh going into college and i think not knowing exactly where to go and feeling like I can do a little bit of engineering, but I'm not a great engineer and didn't know design was a real professional career. I was like, product management feels like a good interdisciplinary thing, if you will, in academic terms.

2:52So that's how I stumbled into it. Today, when you look at all those kind of design, PM, engineering, do you feel like you're kind of truly at the center? Or there's more of a design appeal to that or an engineering appeal to that? Yeah. Well, it's interesting because now all the roles are converging more, I would say. And, you know, it's certainly been de-siloed, right? And it's more standard for a designer who codes or a PM who designs and things like that. But I would definitely say that for the most part, my center of gravity has been kind of in that design side. So you came into Figma. You came as an exec and you worked for multiple well-known product companies, Microsoft, Google, Uber.

3:39I'm wondering when you came in, what are some kind of principles you brought in from those other companies that you thought were great that you brought into Figma? And what were some that, you know, in Figma you learned because it was a unique design company? Every chapter I learned something different. For example, when I first arrived at Microsoft, it was very much a culture of caring about all the details, right? And so your specs are long and detailed and you had to think through every corner case. Like you literally had PMs who were responsible for Command Z and Excel. But it makes sense because you weren't shipping that often and you got to get it right.

4:15But I think it taught me a lot about kind of being detail-oriented in that way. Google, in contrast, I arrived and I went from being responsible for the left-hand nav in the Windows Mail app to, oh, you're just responsible for the YouTube app on iOS, which happens to be, at the time, one of the most popular apps in the ecosystem. And I quickly realized that the way I was working was not sustainable. I can't write these long specs, right? And I had to really make sure more than anything else that people on my team were making high quality decisions. And it was a pretty decentralized culture. Like, you know, engineers made calls, designers made calls.

4:55So there I really learned the importance of defining the why, the problem. Like, how can I get everyone understanding why what we're doing is important? And then at Uber, I think I learned the importance of breaking away from process, kind of going first principles into things. For example, it was very humbling at Uber where an ops-driven email moved metrics more than anything I ever did. And you're like, okay, actually, I should be thinking about all these things and not just kind of what I can build with a software development team. And then I think at Figma, really realizing the importance of community and these other consumer companies definitely have been part of user studies and talking to users.

5:44But the degree to which the community plays such a role in shaping our product. In Figma, given it's your first design first company, how does it show up in the culture? I feel at Figma, both because we are a company that attracts people who likes to build tools in the first place, but also because people have a deep sense of accountability. A designer wants to build the best possible experience because it's their peers who are going to be using that. And I think it kind of automatically makes it so that people are craft-oriented and that's never the debate, right? You mentioned Figma's kind of focus on community, and it kind of ties back in many ways to Figma's probably boldest bet at the beginning, which is betting on the multiplayer, real-time collaboration.

6:39And if I remember correctly, the design community was quite skeptical at the beginning because, you know, in many ways, I remember the idea of, you know, co-design or people looking at your file when you worked was considered something which is annoying, not something which is good. There are terms like hovering art director, right, which have a negative connotation where, you know, imagine your PM inside your file. No, it's the hovering CEO. Exactly. And yeah, there's certainly a lot of resistance to it. It's less about the fact that we're a multiplayer and more about the fact that multiplayer is kind of a side effect of their true value, which is having a single source of truth.

7:17we were able to make a case of by having a single source of truth that could be continually updated, it also made it easier to bring more people into the equation. So when I first arrived at Google was the first time when I used Google Docs for work. And that was pretty transformative to me because all of a sudden I could send these work in progress strategy docs. right and i could just send it early knowing that like after i send it i could keep editing it or after i send it someone gives me a few i can keep making it better and like that kind of like activation energy of sending it out like that totally changed for me and um the same is true for design work right there's so much kind of preciousness about um sharing something you know that's final that can be reviewed but when you know that it's an evolving work i think the attitudes, expectations around it, and like the optionality to update it.

8:12You know, those, those are some of the things that I think people understood as, as value. So I actually think it works that there was a little bit of controversy. I think every great story, every great narrative has some tension. And this tension was an interesting one for the community to debate. And it was not just about kind of promoting a tool, it was promoting a way of working, a cultural shift. In many ways, it sounds like the principle was not about being collaborative. The principle was, back to your point about the why, it was about having a seamless single source of truth that actually emphasized that everything is a work in progress.

8:52And the way to do it was to be collaborative. And then I can assume that somebody, maybe at one point, looked at what's happening with versioning control, encoding, when you can just take your branch out, you can do your coding, you can merge it when you want. and saying, should we just do that? On one hand, developers are like, yeah, designs are moving so quickly that every time I get handed off a spec, that spec goes out of date. So that sucks. But on the other hand, it's really confusing when the spec keeps changing from underneath you. You're like, wait, I just built that. Why does it keep changing?

9:27And you feel like you're not done. And that is an interesting trade-off. And in some ways, you kind of have to land on one side or the other in terms of philosophically what you want to optimize for. But we also kind of had to do things like, we have views like show the diff with what you saw last or something like that to just kind of like help you gain a sense of control. Or there are people who use like saved versions or we do have a branching emerging feature as well for people who want more control. So we've had to build those things, but they are necessarily secondary to our experience. And I think this is always going to be a hard thing of, they're always going to have a sophisticated set of customers who really want specific things, right?

10:07And then there's like everyone else who is looking to us to, you know, on what is the standard way of working. But that being said, you know, as teams get bigger, they do want more control. And we want to respect the fact that there are different ways of working. And so how can you extend the model to allow for some of these things? But they're probably things that only like, you know, 10 % of our customers use. If I remember correctly, the Figma's mission is to democratize design, making it accessible to everyone. is it so that you're thinking of the designers as the active users and the rest as passive users?

10:43What's the way to frame it from how you think about those audiences when it has to come as you, how they use Figma? I actually think about the user as the product team because necessarily the act of building a product is a team sport. And so from that perspective, yes, it's true that designers are probably the ones in our files every single eight hours a day, five days a week. And that's really great. And that's not always true of every other function. At the end of the day, what we're trying to do, we're not trying to build a tool that just helps people design mocks. Our job to be done, if you will, is helping teams build products and amazing products.

11:27I can imagine it could be, again, at the scale of Figma right now and the audiences you're serving, which is very diverse, very big. I can assume that could look very complex over time. Even within designers, you have you can have enterprise designers, we have design pattern systems and there's a whole code and manual to how it works. You can have early stage designers who just want to prototype quickly and it's less about sticking to the current design systems in the company. Like, is it that you're trying to find the middle ground or no, sometimes you just want to win in enterprise developer.

12:00So I just want to see that metric or that experience become extremely great. There is some danger in overly fragmenting or segmenting your users. And the danger comes in a few forms. One is that roles are blurring. And in many companies, people wear multiple hats, right? And if you start overly segmenting in that way, you end up kind of inadvertently breaking up the user journeys of other types of users and it makes for a more complicated product. What would you advise builders? Because that tension, like at a certain scale, that tension appears for everybody. I can think of so many examples at LinkedIn, right?

12:44Like LinkedIn, think about the app itself. It's really meant to serve so many use cases and jobs to be done from everything from, I give the example that a user in the same day, like in the morning, they might come to see what's going on in their industry with their network, what's happening in the news. And then midday, they're about to meet somebody, so they want to check out their profile and what they worked on and who they work with. And then later in the day, they had not a great experience with their manager, so now they want to see what's out there for them. It's the same user, same app, completely new, different use cases.

13:15And you don't want to build different apps for those, so that we have that inherent tension in the product. How do you solve for it? So for example, we had Figma Slides as the product, right? a few years ago and that was our deck building product. And there's this inherent tension of, okay, well, we know designers want so much control for everything and that's kind of why they build decks on Figma design in the first place. But on the other hand, the whole point is making it easy for everyone else and making it approachable. And so right now we have this feature where you can be in Figma slides or you can be in design mode inside Figma slides where you kind of unlock all this power.

13:54And I think there are ways in which we can lean into things like modalities so that maybe you're working on one singular artifact, but everyone has different lenses depending on who they are or the use cases at hand so that they're not overwhelmed by all the UI or become victim to what every piece of software ultimately ends up being victim to, which is feature bloat. I also think that in today's world, there's so much opportunity with AI of creating more dynamic interfaces as well. I think one of the challenges of, you know, like one of the most classic debates you get into a product is like around IA, like information architecture, right?

14:32And, you know, usually that ends up being a discussion about, well, who's their audience? And like, you know, what are their mental models and et cetera, et cetera. And you end up making some compromises that kind of averages out something that kind of like balances the business needs with like different people's mental models. But I think we're quickly approaching a world where actually it's much easier to create dynamic interfaces. And not just personalization at large, but also interfaces maybe even on the fly or things that can get quite creative. Or delivering people, cutting through traditional interface problems by delivering something more directly.

15:08When you look at this new era of AI, when you look at your mission to democratize design for everybody, it's really a massive boost to that mission. It's a new thing in the toolbox that you suddenly have access to that really kind of opens up the solution space in an exciting way. So, for example, you know, when you think about some of the hard problems that we've been grappling with, it's been, you know, for many, many years, we've been contemplating the relationship between design and code of, you know, designers and engineers speaking the same language. and a lot of it was trying to solve this problem of it's so hard to translate these designs into code and so much is lost in translation and in some ways it's very challenging to make a designer think about everything just like you would building code but with AI it helps with that there's room for interpretation but it can actually accelerate that conversion from design to code To your point, like, you know, right now I can use Cursor with MCP and Figma all together and it will work really well.

16:15But I could also potentially start doing design with Cursor or, you know, Cloud Code and other tools. Or I can see a world where I can just do coding with Figma and just use that tool to do it. Do you see it as you're also partially competing with a coding tool that started as a coding tool? We recognize that engineers are now more than ever before using coding assistants and all sorts of IDEs. And so our job is how do we supply that AI assistant with as much context as possible so that they're successful in generating high quality code. And so as we think about, for example, our recent investments in Figma make, we're like, okay, how do we create a place where we both understand code, understand prompts, understand direct manipulation, and make the three of these things work well together so that no matter what you're comfortable with or maybe for the given use case at hand, maybe you just want to change the color.

17:13Obviously, you don't want to prompt that. Or maybe changing one line of code is faster than trying to design it all out. That's kind of, we think, the future where we want to allow people to iterate. When you think about the role of AI with specifically Vibe coding tools, everybody's kind of ultimately gravitating towards a specific tool that makes their need the easiest possible. Do you see that as well, or is this a unique phenomenon I'm sharing with you? None of these tools yet are doing what people want in its fullness. And to be clear, I think these tools are really powerful and have unlocked a lot.

17:52Suddenly everyone has access to this really powerful medium called code. But I think a lot of people are finding it hard to get to that next level. You can actually get to a proof of concept or one that communicates the idea well or one that feels good enough. But when it comes to making it feel like it belongs to your company or when it feels like something that you're really proud of to push to production, there's still things that you need to do to make that work. And so that's kind of where there's a lot more innovation to be had, I think, because we're kind of back to the stone age of product development where most people are working solo.

18:32It's single player. It's extremely hard to give feedback on those things, those outputs. It's extremely hard to riff on it. And you're designing one screen at a time, when really you want to look at flows and branches and collaborate on different parts of that flow. And so what I would say is we're still in the early beginnings of this category or this new way of working. You mentioned the audience you're focused on first and foremost is the team, not specifically an individual. Maybe playing more to that future, what does that look like when AI is part of that team or plays multiple roles in that team?

19:10The feeling with a lot of tools today is that AI has re-siloed everyone, right? It's you and the assistant and everyone has an assistant. And that's powerful, right? Everyone is producing higher quality work, potentially, or faster anyway. What's lost from that is, Well, so much power also came from working with your teammates. And really the kind of ideal feeling is that AI is just in the teammate. And so when we thought about that, a few weeks ago we announced another alpha of what we call a prompt to edit. And this idea was that you could be in your multiplayer Figma design canvas and you can start pointing to elements and be like, okay, do this, change this desktop layout to mobile or turn this into dark mode.

20:03It can get a bunch of these things fired off. But so too can your teammates, your teammates are inside there too. And they can also be watching that or being in the file with you. And I think that feeling, I'm not saying it's perfect yet, but that feeling of like, oh, AI is just another teammate in the file. I think that's really powerful because your other human teammates have a lot to say and have a lot to contribute to. We can't forget that. We are part of your alpha, so I had a chance to check out a specific prompt to edit, and it was really cool. It worked really well. I'm glad to hear it.

20:37You talked about the idea of alpha, so I want to play with that a little bit because we're doing a couple of alphas with you guys, and an alpha is basically very early, a few teams come in, companies, and my team is really excited because they can give you direct feedback through stack, directly to your engineering team and to your PMs and your designers. I'm curious, just take a step back. I think Figma has done some unique ways with user feedback in incorporating those. What are unique ways that you've seen Figma do that's so great that you would advise everybody to start implementing or at least experimenting with?

21:14Well, let me first address the alpha point because it's interesting and it's an interesting debate we have had of like, wow, we have so many alphas now. Is that a good thing? And I think it's reflecting this reality today that everything in the world is moving so fast and new models come, we want to test it out, but we want to test it out on scale and get feedback really quickly. And so that's manifested in something like this that gets us building something really fast. Maybe it has some holes, but we find customers who are okay with a few holes here and there just so that they can help advance their product.

21:48And the push against it is just bandwidth on the team? No, I mean, I think it's kind of like the, you know, making sure that we're clear on what is the bar for alpha, right? What kind of expectations do customers have around subsequent support and, you know, things like that? Like how half-big can it be kind of thing, you know? Going back to your question about feedback and interactions with customers, I think the biggest thing is just, I think it's about building relationship and trust. And I often talk about the fact that many of us on the product team have people that we can text to be like, hey, customers in our community who are like, hey, we're thinking about doing this.

22:33What do you think? Or, hey, can we just put this quickly in front of you and get your real talk, what you think? And cultivating that relationship is a huge part of our cultural values. At LinkedIn, we have a vision to empower the notion of full stack builders. People can take an idea all the way from insight to launch and really kind of moving away from distinct kind of lines in the sense of roles and kind of really in many ways like birthing a new archetype, which is a full stack builder. Is this change happening in Figma or are you thinking about it more in specific areas or across the whole development cycle?

23:09In the design world, for example, I describe it as pushing designers up the stack. And that's the goal of a lot of design systems and companies, to make sure that designers aren't bogged down by those details. But when you move up the stack, you start to converge with the PM, who's also up there, who's thinking about the user flows and user journeys and user problems. AI accelerates this because all of a sudden, you know, all the other functions get de-obfuscated because everyone can code, everyone can design, you know, to some extent. So I think that that is definitely what we're observing. When you fast forward five years, do you see a team of full stack builders together or super builders?

23:52Or you see kind of two full stack builders with two junior, more distinct domains, functional specialists? we will definitely see more people who are kind of that full stack builder persona. I think that there still will end up being specialists who are going deep in their craft. I've been in situations where people have tried to both PM and design the feature at the same time. And that can sometimes be hard. Because on one hand, you need to be pushing all the constraints and standing up for what users believe in, even regardless of engineering or business constraints. On the other hand, you're trying to be pragmatic and balanced.

24:30And so it may be that there are people who are coming from different centers of gravity because some of the best partnerships come from when maybe someone's the generator and someone's a synthesizer. So if you could solve one product problem with Figma right now by snapping your fingers, what would that be? I think it would be just making it so much easier to seamlessly move between a bunch of products. For anybody listening to you who is an inspiring young builder, what would you advise them to learn, to work at, to think about as they think about their product career? Yeah. I mean, I always talk about the importance of storytelling and how I think everything I think of is through that lens.

25:16And the act of synthesizing a lot of things into a cohesive story itself, especially as a product person, stories are your vehicle for motivating people, for capturing your customer's imagination. It can take a lot of different forms, but I think that it's still kind of an underrated capability. Some of the best entrepreneurs are amazing storytellers. They have to be because they have to sell their vision to people. This was a wonderful conversation. Thank you so much for all the insights. I've personally learned a lot and I'm sure all these will learn as well. Thank you. Thanks so much. I really enjoyed talking with Yuki.

25:54And before we go, here are my main takeaways from the conversation. First was how clearly he could distill the essence of each company he worked for, almost like his personal playbook of product philosophies. For him, Microsoft was all about nailing the details, thinking through the edge cases to an intense degree. Google was about empowerment through clarity, define the why, and then trust teams to make their own high-quality decisions. Uber was about leading with first principles and speed, breaking away from legacy processes, and valuing real-world impact. And Figma is all about community as a design principle, building with your users, not just for them.

26:35This is just a great reminder that every company has its own distinct way of building and being successful, but they do it to a high degree of craft. Second, more often than not, the most successful companies stay anchored to their founding ethos, that principle that defines how they create value. You know, at LinkedIn, that principle is the network itself. The belief that every opportunity, every piece of knowledge, every step in your career can become much, much better through someone who is willing to help. It's the connective tissue that tars everything from jobs to learning, to search, to feed.