← Building One with Tomer Cohen
Building One with Tomer Cohen
Building Figma with Yuhki Yamashita: Collaborative Design, AI Teammates, and Building for Builders
00:29:19
Loading summary
Transcript59 lines
- [00:00]
Yuki Yamashita
There are terms like hovering, art director. Right. Which have a negative connotation where. Imagine your pm. 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.
- [00:21]
Tomer Coyne
When 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. 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.
- [00:47]
Interviewer / Host
Tool in the world, used by over.
- [00:49]
Tomer Coyne
95% of Fortune 500 companies. But when it launched in 2015, the idea of multiple people editing a single file was highly controversial. The 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 impact of the vibe coding mom. And what happens when AI becomes just another member of your team? And there's so much more to this episode.
- [01:37]
Interviewer / Host
Yuki, it's a pleasure to have you on the show. Thank you so much for joining me today.
- [01:41]
Yuki Yamashita
Thanks so much for having me. Tomer.
- [01:44]
Interviewer / Host
So I kind of 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 studied computer science, but you also had the role of a design editor for the 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? Was it a certain discipline that actually drew you in?
- [02:16]
Yuki Yamashita
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 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. So that's how I stumbled into it today.
- [02:55]
Interviewer / Host
When you look at all those kind of design, PM engineering, do you feel like you're kind of truly at the center or just like you're kind of. There's more of a design appeal to that or an engineering appeal to that.
- [03:09]
Yuki Yamashita
Yeah. Well, it's interesting because now all the roles are converging more I would say. And it's certainly been desiloed, 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.
- [03:31]
Interviewer / Host
So you came into figma, you came as an exec and you worked for multiple well known product companies. Microsoft, Google, Uber. I'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 in figma you learned because it was a unique design company?
- [03:52]
Yuki Yamashita
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. And so your specs are long and detailed and you had to think through every corner case. 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. But 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 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. Engineers made calls, designers made calls. So there I really learned the importance of defining the why the problem. 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. But the degree to which the community plays such a role in shaping our.
- [05:51]
Interviewer / Host
Product in Figma, given it's your first design, first company, how does it show up in the culture?
- [05:58]
Yuki Yamashita
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 steep sense of accountability. You know, a designer wants to build the best possible experience because it's their peers who are going to be using that. And you know, I think kind of automatically makes it so that people are craft oriented. And that's never the debate. Right.
- [06:26]
Interviewer / Host
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. And if I remember correctly, the design community was quite skeptical at the beginning because in many ways I remember the idea of co design or people looking at your file when you worked was considered something which is annoying, not something which is good.
- [06:56]
Yuki Yamashita
There are terms like hovering art director which have a negative connotation where imagine your PM inside your file. Exactly. And yeah, there's certainly a lot of resistance to it. It's less about the fact we're 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 we 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 STR strategy docs, right. And I could just send it early, knowing that after I send it I could keep editing it, or after I send it someone gives me feedback, I can keep making it better. And that kind of activation energy of sending it out, that totally changed for me. And the same is true for design work. There's so much kind of preciousness about sharing something 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 the optionality to update it, those are some of the things that I think people understood as value. So I actually think it works that there is 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.
- [08:38]
Interviewer / Host
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 and 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?
- [09:08]
Yuki Yamashita
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, right? You're like, wait, I just built that. Why does it keep changing? And 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 that 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 saved versions or we do have a branching and merging 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? And then there's like everyone else who is looking to us to on what is the standard way of working. But that being said, 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 10% of our customers use.
- [10:31]
Interviewer / Host
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? What's the way to frame it from how you think about those audiences when it has to come. How do you use figma?
- [10:49]
Yuki Yamashita
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:27]
Interviewer / Host
I 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 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. Is it that you're trying to find the middle ground or no? Sometimes you just want to win in enterprise developers. So I just want to see kind of that metric or that experience become extremely great.
- [12:06]
Yuki Yamashita
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 and if you start overly segmenting in that way, you end up inadvertently breaking up the user journeys of other types of users and it makes for a more complicated product.
- [12:35]
Interviewer / Host
What would you advise builders? Because that tends tension, like at a certain scale, that tension appears for everybody. I can think of so many examples at LinkedIn, right? Like LinkedIn, think about the app itself. It's really meant to serve so many use cases and jobs to be done from everything from. You know, 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 and you don't want to build different app for those. So that we have that inherent tension in the product, how do you solve for it?
- [13:22]
Yuki Yamashita
So, for example, we had Figma Slides as the product 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 over everything, and that's kind of why they build decks on Figma design 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 unlock all this power. 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 kind of 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. Right. I think one of the challenges of one of the most classic debates you get into in product is around IA information architecture. And usually that ends up being a discussion about, well, who's your audience and 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 balances the business needs with 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:08]
Interviewer / Host
When 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.
- [15:17]
Yuki Yamashita
It's a new thing in the toolbox that you suddenly have access to that really opens up the solution space in an exciting way. So, for example, when you think about some of the hard problems that we've been grappling with for many, many years, we've been contemplating the relationship between design and code, of designers and engineers speaking the same lang. And a lot of it was trying to solve this problem of like, wow, 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.
- [16:08]
Interviewer / Host
To your point, you know, right now I can use Cursor with MCP and figma altogether, and it will work really well. But 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?
- [16:36]
Yuki Yamashita
We recognize that engineers are now more than ever before using coding assistants in 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. Obviously 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, we think, the future where we want to allow people to iterate.
- [17:25]
Interviewer / Host
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 phenomena I'm sharing with you?
- [17:42]
Yuki Yamashita
None of these tools yet are doing what people want right in its fullness. And to be clear, I think these tools are really powerful and have unlocked a lot. Suddenly 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, right? But when it comes to, okay, 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 are 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. It's single player, it's extremely hard to give feedback on those, the 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.
- [18:59]
Interviewer / Host
You mentioned the audience you're focused on, first and foremost is the team, not specifically an individual, maybe playing more into that future.
- [19:06]
Tomer Coyne
What does that look like when AI.
- [19:08]
Interviewer / Host
Is part of that team or plays multiple roles in that team?
- [19:11]
Yuki Yamashita
The 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 is 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 recently, a few weeks ago, we announced another alpha of what we call a kind of 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, hey, do this. Change this desktop layout to mobile or turn this into dark mode. It 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 kind of 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, 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.
- [20:30]
Interviewer / Host
So I had a chance to check out specifically prompt to edit and it was really cool. Worked really well.
- [20:36]
Yuki Yamashita
I'm glad to hear it.
- [20:37]
Interviewer / Host
Yeah, you 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 and incorporating those. What are unique ways that you've seen at FIGMA do that's so great that you would Advise everybody to start implementing or at least experimenting with.
- [21:15]
Yuki Yamashita
Well, 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, and new models come, we want to test it out, but we want to test it out at scale and get feedback really quickly. And so that's manifested in something like this that kind of gets us building something really fast. Maybe it has some holes, right? But we find customers who are okay with a few holes here and there just so that they can help advance their product.
- [21:48]
Interviewer / Host
The push against it is just bandwidth on the team.
- [21:52]
Yuki Yamashita
No, I mean, I think it's kind of like the making sure that we're clear on what is the bar for alpha, what kind of expectations do customers have around subsequent support and things like that. How half baked can it be kind of thing. 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. 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. What 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.
- [22:45]
Interviewer / Host
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:10]
Yuki Yamashita
In the design world, for example, we've been kind of, I describe it as pushing designers up the stack. And that's kind of 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 kind of move up the stack, you kind of start to converge with the PM who's also up there, who's thinking about kind of like the user flows and user journeys and user problems. AI accelerates this because all of a sudden all the other functions get deobfiscated because everyone can code, everyone can design to Some extent. So I think that that is definitely what we're observing.
- [23:46]
Interviewer / Host
When you fast forward five years, do you see a team of full stack builders together or super builders, or you see kind of two full stack builders with two junior more distinct domains, functional specialists.
- [23:59]
Yuki Yamashita
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. And 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 like the generator and someone's a synthesizer.
- [24:42]
Interviewer / Host
So if you could solve one product problem with Figma right now by snapping your fingers, what would that be?
- [24:49]
Yuki Yamashita
I think it would be just making it so much easier to seamlessly move between a bunch of products.
- [24:55]
Interviewer / Host
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?
- [25:07]
Yuki Yamashita
Yeah, I mean, I always talk about the importance of storytelling and how I think everything I think of is through that lens and 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 a underrated capability.
- [25:39]
Interviewer / Host
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 insight. I've personally learned a lot and I'm sure all you support.
- [25:50]
Yuki Yamashita
Likewise. Thank you. Thanks so much.
- [25:53]
Tomer Coyne
I really enjoy talking with Yuki. And 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.
- [26:11]
Interviewer / Host
To an intense degree.
- [26:13]
Tomer Coyne
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. This is just a great reminder that every company has its own distinct way.
- [26:40]
Interviewer / Host
Of building and being successful, but they.
- [26:43]
Tomer Coyne
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.
- [27:05]
Interviewer / Host
Who is willing to help.
- [27:07]
Tomer Coyne
It's the connective tissue that powers everything from jobs to learning to search through feed. And at figma, that enduring principle is collaboration. That multiplayer mindset that leads to that single source of truth. And that core idea that is one. One file, one evolving source of truth for collaboration has guided FIGMA from the earliest, most controversial days to becoming the creative operating system for nearly every product team today. Third point, FIGMA attracts builders who want to build for other builders. And that naturally creates an automatic sense of accountability and craft. Designers know that their peers are their users, so there is built in peer pressure towards excellence. You get to a point where quality and empathy are actually non negotiable. The next point is that I very much appreciate it when it comes to AI. He had this observation that there's a feeling that AI has really siloed everybody. It's about you and your assistant, you and your copilot, you and your chatgpt. And his vision for FIGMA is the opposite of it. AI will be your teammate inside of the multiplayer file, collaborating with AI entire team, not just the individual. Lastly, Yuki shares that he sees storytelling as an underrated product skill. Think of the great product builders. You know, they have this innate ability to synthesize complex ideas into a coherent story that then goes and motivates teams and captures imagination. Just like product building, storytelling gets better and sharper with practice through writing, pitching, teaching and continuously refining your ideas until they finally click with others. I'm Tomer Coyne. Thank you for joining me today. I've learned so much and I hope.
- [28:49]
Interviewer / Host
You did as well.
- [28:52]
Narrator / Closing Announcer
You've been watching Building One. Our show is hosted by Tomer Cohen, LinkedIn's Chief Product Officer. Building One is produced and edited by Mason Cohn and the team at Coastal Production Works. This episode was mixed by Tim Bold at LinkedIn. Our team includes Rachel Karp, Sarah Storm, Dave Pond and Alicia Mann, with support from Alex Kuznetsova and Mujeeb Mehrdad. Until next time, keep building.