Kris Rasmussen - Figma

What a lot of people don't recognize is that Figma is like a traditional web application, but it's also like a game engine. Not only are we like using these lower level technologies, we're also building kind of our own low level in-memory abstractions for doing rendering.

Hello, welcome to the DevTools FM podcast. This is a podcast about developer tools and the people who make them. I'm Andrew and this is my co-host Justin.

Hey everyone. Uh, we're really excited to have, uh, Kris Rasmussen on. Uh, Kris, you're the CTO of Figma. Uh, it's a real great honor to have you here. Uh, Andrew and I have both used Figma quite a lot. We use Figma for this podcast to like put together some of the social stuff. So it's really, really great to have you on. Uh, we're excited to talk about like what Figma's working on. Uh, but before we dive into that, would you like to tell our listeners a little bit more about yourself?

Yeah. Um, so yeah, I'm Kris. I've been at Figma for going on 8 years now. Um, I started back in 2016, just a month before we launched our first product. Um, I think, uh, when, when people think about Figma, I think the first thing their mind goes to is a product design tool, which is definitely, um, a good way to think about us. But, uh, I think what a lot of people miss is that we've been building for the entire product team from day one. And a lot of our new products that we've been launching are evidence of that. So the way we think about it is we're just trying to help people go from imagination to reality or design to production as quickly as possible. We know it's a very iterative process and a very cross-functional process. And so from day one, we've tried to build not just the product design tool, but all of our new tools in a way that makes them readily accessible to anyone in the company so that everyone has a single source of truth for the future vision of their product and they can align together and ultimately get that stuff translated into working production code or production assets that they can consume directly.

So we were talking to somebody else on the podcast, I can't remember who, but they said that the original demo for Figma was just like a WebGL ball of water and that it somehow went from that to what we have today. So can you fill us in a little bit on that journey from ball of water to like design tool?

Yeah, that's, that's a great question. You know, honestly, I don't think I was there when that first ball of water was created, but I think what people are referencing is Evan, who was the— is the co-founder of Figma. And was the CTO of Figma. Before Dylan and Evan got started, Evan was doing a lot of prototyping with WebGL when it first came out. And Evan's a brilliant graphics programmer and he created this simplified fluid dynamic simulation in WebGL with a ball that you could displace a 2D fluid field on top of it. And it was really cool. And I think it just gave people a glimpse into what browsers were now capable of. And I think that's ultimately what gave Evan and Dylan even more confidence to pursue bringing a professional design tool into the browser, which way back when, like, no one ever thought it would be possible, myself included.

Yeah, I mean, I'm reminded of the time before Figma when Sketch was the primary design tool that, like, designers that I know interfaced with. And, you know, native Mac app, they really sort of focused on performance and sort of this native quality as the thing that, like, really differentiates them themselves. And that was important and valuable. But I think the Figma team has shown that you can get performance and good quality on the web. And also, I think unlocked something else that's really sort of set a different tone in the entire industry, which is multiplayer and collaboration. That's now the price of entry. So could you talk a little bit about your sort of strategy, technical strategy around collaboration and like how you all think about that internally.

Yeah, um, so I guess like first and foremost, like we, we always recognize that we're a professional tool, and I think when you're building professional tools, especially like tools that you live in 8 hours a day, 5 days a week or more, um, every ounce of performance always matters. In particular, when you're kind of designing applications, you want to be able to look at a lot of different ideas and screens all at once. And so oftentimes, like, the level of performance you need for a design tool, or at least the performance characteristics you optimize for a design tool, are even more advanced than what, like, you're actually going to need when you create the production application and only render a single screen at a time. So we knew from day one that we had to care about performance, but we also felt like the design process was a little bit broken. We were still stuck in this kind of world of, you know, almost like print artifacts, like, you know, where, you know, you're creating something and like you're literally shipping the result and you're just like embedding it into, you know, a newspaper or, you know, a simple static website or something like that. And the reality is like design has become so much bigger than that in the context of building digital products. You're not actually even producing the end result oftentimes. You're usually, you know, visualizing what the end result could be to help bring your team along in the line. And so it's just inherently a much more collaborative and iterative process. And so we knew that we wanted to build an experience that really made it completely accessible to the entire team and got rid of all the friction that I think a lot of us were feeling back in the early 2000s around, you know, having to go through this very kind of complex coordination process around handoff and, you know, trying to understand a lot of the intent of these, these mocks and designs and trying to keep track of how they're changing and what the right version of the file was and stuff like that. And so, I think that, you know, we made the decision to bet on the web very early. And I think it turned out to be the right call. Way back then, I think there were still a lot of people, even when I joined, that were second-guessing whether or not we would be successful on the web. To be honest, Figma wasn't always, you know, super, super fast. We had a lot of different edge cases we had to optimize for over the years as our customers kept pushing us to our limits. But I think we showed the team and we showed the world that even though there are some limitations to the abstractions that we build on, on the web, those weren't the actual barriers to performance. There was ways to change the structure of the problems and the nature of the problems to work around those relatively minor limitations in retrospect. But yeah, ultimately, I think building for the web was the strategy because everyone knows how to share a URL. We made sure that viewers were free so that you never had to worry about whether or not someone could view your file. Um, and it just made it that much easier to, to get everyone on the same page and actually build an experience, not just for the, the professional designers, but also for all the other professionals that they're working with to bring their ideas to life.

So speaking of web technologies, like as you said, to build a product like Figma, you need a lot of things from the browser and those things were like either very new or just coming into existence when Figma was coming around. Uh, one of the things that you guys, I think, are kind of famous for is like you guys use WASM in the browser, but, uh, I don't think many people know where like the line is on that. So, like, how did you guys use WASM? And, like, have you used it in more and new interesting ways since then?

[Speaker:JASON] Yeah. So, yeah, it's kind of like a fun story. So, I think in the very, very early days, WASM didn't exist. And there was this thing called ASM.js, which is like this kind of subset of JavaScript that you could use that browsers, like, would run in a more WASM-like way, more like as if they're running some sort of virtual machine code. But that had its own set of limitations and wasn't as efficient as WASM at the time. And then WebGL was still relatively nascent when I think the company was founded and also evolving. And so, actually, in the very early days of Figma, the team actually built their own programming language to transpile the application logic and the rendering logic to different platforms, including the web and also native to sort of hedge their bets. But by the time I joined, it was pretty clear that these lower-level browser APIs, even with ASM.js and just WASM— or sorry, WebAssembly— not WebAssembly, WebGL at the time were sufficient to build a pretty compelling experience. And so by that time, we went all in on the web and we kind of got rid of the transpilation step and the intermediate language and whatnot. But yeah, I mean, I think what ultimately happened is as we continued to kind of push them to the browser and other people in the game industry and other areas did as well, the people developing the browsers were also trying to enable those sorts of new use cases on the web. And we owe a lot of credit to the teams, you know, at Firefox and Chrome and everywhere else that was pushing these limits. But ultimately, when WASM came around, it wasn't that hard for us to just change our toolchain to compile to this new target and start to explore the potential there. And so we did that really early on. And at first, it actually had some trade-offs. Like, I think not all browsers were caching the compilation artifacts. There was some additional initialization time required relative to what we'd been doing before. But we worked with the companies who were developing these technologies who also happened to use our software. And a lot of other people did too. And ultimately now it's in a position where it works extremely well for our use case. And we're very happy with it. But our use case is pretty unique. I don't think everyone needs to be using WASM all the time. It really depends on what you're trying to do and also what other libraries you're trying to consume. So in our case, we consume a lot of the same lower-level font shaping libraries and whatnot that operating systems and browsers themselves consume. And browsers didn't provide the right abstractions, and I don't think they still do, to directly access that type of font information. And so it's actually very— it's much easier for us to just consume those C++ libraries and then compile them to Wasm than it is to rewrite them. So that's another motivation for it.

Yeah, another big use case there was the plugins. I know that originally when y'all were designing plugins for Figma, there's generally a hard problem if you have a shared application that's collaborative and you want people to run code on it without a bunch of security issues. I think generally y'all were looking at Realms. I'd sort of like read some of the early articles about like, you know, trying to build the plugin infrastructure. So it was like Realms is like a way to like isolate JavaScript and it's sort of like on RAM or whatever. And turns out that like that wasn't ready yet and they, you know, had like found some issues and ended up going to WASM. Do you recall like much of that journey and like have you had learnings from the plugin? Ecosystem so far?

Yeah, yeah, that was a really interesting time. I think, like, to your point, I think a lot of people nowadays take it for granted that it's like totally possible to allow third-party developers to run custom code inside of the same kind of web process that your application is running and not get access to sensitive data and whatnot, or not totally screw up your application. But we knew that like we wanted to provide an extensibility model Sketch had a very vibrant plugin ecosystem at the time that we were developing, and we knew that we needed to be competitive. But we also had learned that there was a lot of problems with the model they had created and that they had exposed their entire internal kind of object model to third-party developers. And as a result, every time they updated their application or their own, you know, their own kind of object model, a lot of plugins were breaking. And so we want to be really intentional around what we expose to third-party developers. Both from the perspective of security but also from the perspective of like ensuring that they're binding to the interfaces that we actually can maintain over time. And so, yeah, we explored Realms, which had some issues at the time. I'm not actually up to speed on where it's at now just because we don't really need it anymore. But ultimately what the team did, which I think it just— it still sounds so crazy, is we basically found a small JavaScript runtime that we could compile into a WASM executable inside of our address space. And then we expose scripting languages or scripting interfaces via that runtime, just like you would in developing a game engine. And essentially use that embedded JavaScript runtime that's running inside of effectively a JavaScript runtime as a sandbox in order to really control what these third-party developers could do with customer files and limit access accordingly to build trust and ensure that people could install things without worrying too much about it. So yeah, it's, it's amazing in retrospect that all of that worked out and that, you know, it's as fast and performant as it is. But yeah, it's credit to the team for really taking their time to look at the solution space and pick a— pick something pretty bold that ultimately I think contributed a lot to our success over the years.

We'd like to stop and thank our sponsor for this week's episode, Mux. Mux is an awesome platform that makes adding video to your product Super easy. Video is one of those things that it seems simple at the surface, but as you dig more and more into it, you realize it's a lot of infrastructure, whether it's uploading, storing, streaming, or even playing the video. There's a lot of hard technical engineering challenges and a lot of stuff for your team to own. That's where Mux comes in. Mux makes it incredibly easy to build a platform that has video. One of the things I like to highlight on this week's episode is they have a new thing called Player.Style. When building a, a video player, there's lots of things you have to worry about. Playback speed, hover thumbnails, sharing, picture-in-picture, styling all the native HTML elements. There's just so many things to worry about. That's why Mux came out with a new thing called Player.Style. Player.Style is a frontend component for playing back video. And then styling it however you want. It's super nice. It's feature-packed. You can make the thing look like any player that you want, really. I can't see why you wouldn't want to start with something like this. And that's coming from me, the person who actually built and maintained Descript's video player. So if you want to save yourself a bunch of time and add video to your platform super easily, I'd head over to mux.com right now and check them out. With that, let's get back to the— um, so running, uh, an app as big as Figma must come with some challenges. Like, you serve countless customers, you have collaboration, which has to happen on the backend. So what are, what have been some of like the challenges of deploying and running Figma at scale?

Yeah, there, there are like a lot of bespoke challenges. I, I like to think I've had like a, a fairly diverse career and seen a lot of different architectures and stuff, and I feel like Figma is, is one of the most unique. What a lot of people don't recognize is that Figma is like a traditional web application, but it's also like a game engine. And not only are we using these lower-level technologies, we're also building kind of our own low-level in-memory abstractions for doing rendering and managing the file format and scene graph. We're not always using standard DOM and whatnot. And so we have sort of the same set of challenges that any kind of large-scale web application would have, but we also have a lot of the challenges that building a game engine like Unity or Unreal would have in terms of, or an operating system or a browser or something like that. And so we have really, we always like to say that it doesn't, a lot of people I think traditionally have thought of backend as being harder problems because even in simple applications, you can run into these complex scaling problems. But at Figma, I think some of our hardest problems are actually on the frontend. And we also have some pretty challenging backend problems. So the kind of problems we run into is On the front end, we have to create this experience that feels like a native desktop application. We don't ever want to slow down someone's ability to go from an idea to a visualization of that idea by waiting on a server or something like that. And we also want to make sure that people can co-create in real time. It really helps to maintain that single source of truth and not have diverging explorations. And to do all of that, we have to basically load a lot of things at once. And make sure that they don't use too much memory or too many system resources and slow down the experience as a result. And so we end up with these massive files with hundreds of different pages and complex dependencies and relationships because a lot of what we do is we bring in abstractions from programming languages into the design tool ecosystem. And all of these things have to be run in a way that ensures that they feel local. And they feel immediate. So the user is never getting slowed down waiting for a slow network or waiting for someone else's change to propagate to their machine. And so it's just a lot of traditional engineering optimization work. I like to joke that there was this meme in Silicon Valley that like, why do people ask these weird algorithm questions? And we definitely had some, but they were literally the things that we had to work on at Figma every day. They were super relevant. I think a lot of these questions came from people building early operating systems and game engines and browsers and whatnot. And so in our case, it was actually very relevant to what people would do. And then I think the other thing that I think is easy to kind of miss is that everything we do in Figma essentially operates like this eventually consistent distributed data store. So each Figma file is being simultaneously like, you know, checkpointed in our infrastructure and then also streamed as quickly as possible in real time. To all the other connected clients. And it means that not only do we have to build all of this, like, kind of real-time infrastructure and have extremely high write throughput and whatnot, but also every single feature we build, you have to kind of reason about it as like a distributed system, like this eventually consistent system. And so a lot of the, like, you know, the basic product features that I think people take for granted, which are, you know, inspired by programming languages, are kind of built in a way where They actually need to be like, or work like a programming language, which I think people appreciate is kind of complicated, but also like work knowing that they're gonna be streamed, you know, through these network connected devices and, and have to come kind of make sense and be eventually consistent and correct when they eventually kind of recreate themselves on different people's computers. So those are the, the kind of like bespoke challenges I think that we, uh, we run into at Figma that a lot of people don't always realize.

Yeah, I can't, I can't imagine the sort of like scale and complexity of that. Just like the rendering problems alone, it's like you just want to render sort of like what someone's seeing, but as they scroll, you want it to be performant, responsive. It's a wild problem. Maybe let's switch gears a little bit and talk about some of the sort of new features and new work that you're doing. So you recently announced DevMode. So what is DevMode and how does it make handoff simpler?

Yeah, um, so, uh, as I mentioned earlier, I think like early on in Figma's history, we, we knew that like our end users weren't just professional designers, they were also developers that they work with and product managers and everyone else around them. And, uh, and so early on we actually did have some, some pretty basic inspection features, um, that enabled developers to go into a file and, uh, and start to kind of look at things from the perspective of like what a developer actually needs to consume. So for example, like, um, rather than just kind of visualizing colors in the properties panel, you could actually see the hex code for colors, or you could see some basic CSS snippets and whatnot. Um, and we knew that, that people found that functionality valuable, but we also knew that we needed to go a lot further to really kind of deliver on this promise of helping people, um, go from design to production as quickly as possible. And so the, the sort of initial premise of dev mode was like, we needed to create a mode in Figma. That could really truly be tailored to the needs of productionization of designs without compromising on the core design experience, without, you know, cluttering the UI or taking things away. And so we launched Dev Mode with that premise and a bunch of improved features for developers, including the ability to very quickly find parts of a very large design file that are actually ready for development. So we have this feature called Ready for Dev. So designers can tag things, and then developers are taken into like a curated view of the file that shows them exactly what they need. And then we've also really like upleveled all of our inspection features to generate code in different languages and also built out, you know, yet another kind of plugin extension framework for developers so the developers could access plugins which previously were only available to people who had edit access to files. Those plugins do everything from add new forms of codegen to doing full screen codegen, to integrating with other development tools like Jira and whatnot. Then we also built a parallel view for developers inside of Visual Studio Code so that you can get all this information contextually and we can start to surface things as you're working on the code. Rather than you having to context switch between these different experiences. So that's how Dev Mode started and it's evolved a lot over the years and we have big plans for it in the future too. We're still in its— I think it's kind of basically still in its infancy. But some of the new stuff we're really excited about is one of the kind of key pain points that a lot of teams face is they put all this effort into building these design systems. And the design systems, I think, as engineers, we all kind of know we've had code libraries shared code libraries that created these reusable UI elements for probably decades. But the idea of a design system and a design tool didn't really catch on until the last decade. And one of the benefits beyond just making designers more efficient and helping them get ideas into a format that other people react to faster is that it actually creates this sort of higher-level abstraction for communicating with engineers and reusing existing code and ultimately creating more accessible, consistent experiences across your products. And so we've been working with a number of our customers who had been building kind of internal prototypes and internal tools to connect their Figma design systems to code so that it's very clear that like there is already code that your team should be using, right? Because sometimes like we, we build these like complex engineering design systems, but then we struggle to get people to use them. People like end up recreating the same button over and over again. You get all this accidental complexity and one button's accessible, the other one's not, or whatnot. And so now with dev mode, we have this ability in code to configure the mapping of your code libraries, like say your kind of SwiftUI framework or your React frameworks, and the corresponding design systems in Figma so that when you're inspecting files, you can see not just which code component to use, but exactly how to use it to recreate the exact same parameterization that you have in the design file. And this has been something that a lot of our customers have been super excited about. And I think it's just like the beginning of thinking about how to help people kind of go from design to existing code faster, which I think in some ways is more important than generating new code. Generating new code isn't always the hard part. It's actually a fairly mechanical process. The hard part is generating code that reuses the code you already have. So you're not creating a lot of accidental complexity and duplication.

[Speaker:JASON] So like in that, if I'm creating like a menu for my design system, what is it like to hook up the menu to the menu code? Like, can I, like, render a menu and then, like, Figma somehow figures out, like, what the components might be? Or is it, like, all manual and I'm just, like, adding links and, like, docs directly into Figma?

[Speaker:JAMES] Yeah. So, that's how we started. So, when we first released dev mode, you could, like, attach links to components and they would be accessible anywhere instances of the component was used. But Code Connect takes that a step further. So, it's fairly easy to understand in basic. The way it works is we basically provide a bunch of kind of framework-specific, language-specific code as configuration libraries so that you can go into your code base and you can create these Code Connect configuration files that essentially more declaratively show us how a Figma component's structure, like, you know, the properties and parameters that you pass into it and the code component structure, properties and parameters you pass into it, map to one another. So that when we see an instance of a menu or something in Figma, we can figure out the corresponding code component for mobile or for web and also the corresponding set of parameters you need to pass into that code component to recreate the same kind of state and configuration and look and feel. So at a very basic level, it's a convenience layer to build a mapping from a Figma component to code output. Like a framework-specific code output. What I'm really excited about though is that it's manual right now. And even though it's a little tedious, I think you get pretty good economies of scale out of setting it up. But I think it can also be automated over time. And I think there's a huge opportunity to just more automatically go from, you know, whatever's in your design tool to your coding environment and help to reconcile these things and even give you more visibility into where there is duplication and where there's opportunity for consolidation.

Like if this code mapping's happening, it feels like the next natural step is like, okay, we can map the design to code. Like why, why not just go from like design to like mostly complete app? Like, is there a future there? Cuz I know there's like, there's countless companies that try to be like Figma, but it actually makes an app for you.

Yeah. Yeah. So we definitely think there is a future there, but we don't think it's quite as like black and white as I think, you know, it's natural to want to believe. Um, I think just, just like with like the way it, like a lot of coding AI tools are being adopted, I think that you definitely, um, want to help kind of streamline parts of the process that can be, um, more easily streamlined. Um, but there's always going to be a level of, um, actual understanding that an engineer has about the broader system you're connecting to that frequently is not going to be available to any sort of underlying mechanical transformation or AI model or something like that. And so you gotta do it in a way where it expedites the process, but also does it in a predictable way that you can still control and fine-tune and adapt. And so for us, like, um, CodeConnect in its current form is, is essentially like a basic primitive in that process. So it's like, um, a way to, uh, more explicitly view the mapping that the system has and potentially will come up with in the future and then fine-tune it accordingly. So you still have control over that output. And then of course the next step from there is now that you have this, you know, these, these mappings, it's essentially like if you think about in modern AI terminology, like you have, you have a lot of information that provides a very good kind of RAG-based workflow to find the right context to continue to kind of streamline the conversion and remove a lot of the tedious aspects of the process of translating from this design medium to this code medium. The thing that I think people underestimate though is that It's not just about direct translation. There's definitely a lot of things you can just directly consume from a design tool in code. But oftentimes the design process is like optimized to build alignment more so than to kind of build explicit details. And what a lot of engineers are doing, I'm sure you all have experienced this, is trying to actually infer that intent from not just the design file itself, but also what you know about the codebase and the company. The designer you're working with and whatnot. And so that's why oftentimes, like, you know, going all the way to working application is imperfect because there's, there's missing context, right? The tool, um, even if you could encode it in the tool, people don't always take the time to encode it in the tool. And so I think the other area we're really excited about with Dev Mode and the design tool in general is figuring out how to help people bring these sort of designs closer to the level of explicitness that is required to, to correctly implement them in production. I think that can happen on both ends of the spectrum. It can happen magically when the code's getting generated, but it can also happen magically when you're designing so that it's more easy for you as a designer to explore how things look in different states and different form factors and whatnot. That's an area that we're really excited about too.

[Speaker:JASON] Yeah, there's definitely so many aspects of design that are hard to codify or very tedious. I mean, having worked with a lot of designers, it's like they're not going to design a component or a view for every breakpoint. They're like, okay, here's the largest, here's the smallest, figure it out, or you have a design system that you fall back on or some design guidelines or something, but there are a lot of pretty tedious, if you're going to do everything, and then there are other things that are hard, like motion, like doing animations and designing for animations. We did an episode recently with one of the founders of Rive, who were doing really cool things, animation app in the browser. It gives me like Figma vibes, but that's another like challenging aspect. I know Figma does a lot of like, has a lot of animation tools as far as like transitions between visual states, which is a huge thing. But have y'all thought like about like motion as a thing at all? Or is that just something sort of like kind of like separate to the sort of core goal of like figuring out what the base design is.

Yeah, I think it's definitely an interesting space. And I'm a fan of Rive too. I think that ultimately, we've been focused on meeting our customers where they need us to meet them. But we also aspire to going further over time. So it's something we pay a lot of attention to. And we're constantly adding new features to our prototyping experience to enable richer animating as well. But yeah, I think similar to Rive, I think that there's just this opportunity to basically make it so that when you can fully encode something and it's natural to do so in the tool versus in code, you can more directly translate it to code or consume it in code. Um, I think that like it's, uh, we're oftentimes limited by the file formats we can export to, um, and there's a lot of opportunity to kind of continue to up-level that pipeline of export so that things that are already fully, uh, explicitly represented in the tools can actually be just translated directly to the coding environment without any additional kind of manual steps in between.

So, uh, Dev Mode has been, been out for a while now. It's been about 8 months. Uh, how has it gone? Have people responded to it well? Have like some of your original theories like not panned out how you thought they would?

Yeah, it's gone extremely well. Um, we, we couldn't be more excited about the reception and the adoption. Um, you know, we just came off of, uh, one of our strongest years ever. So I think this is, uh, it's You know, a lot of it is attributed to DevMode. Um, and I think what's, what's really exciting is like, it's, it's opened up kind of new conversations and new opportunities within our customers to learn more about what they actually need, um, to, to bring the best ideas to life faster. And so, uh, we, we're just like excited about all the new things that we hadn't even thought of last year that we now realize are just like obvious opportunities to continue to improve the overall product development process. For the customers that we already serve. And it's really cool to just have a seat at that table and be able to talk to engineering leaders now as well and really kind of make sense of what everyone's trying to do. One of the things I think that we've come to kind of fully internalize is I think a lot of people have a tendency to conflate design with design tool. But I like to think of design as a process. And it's not just product designers who are designing, right? Like, as you mentioned, oftentimes there's edge cases or important aspects of a design that aren't fully represented, you know, when the developer comes into the picture. And I think as developers, we all have to kind of reason about those things as well. And we're sort of designing on a different end of the spectrum with a different set of concerns. But I think ultimately, like, our job at Figma is to really help people go through that entire process as fluidly and seamlessly as possible. And also make sure that people are strongly aligned as they do that, because Oftentimes, like, the hardest thing about bringing an idea forward is just having the confidence and conviction and courage that you actually know you're doing the right thing and that other people are bought into it as well. So I think there's a ton of opportunity now that we have developers really, really deeply engaged with our product and actually sending their own set of feature requests and ideas and opportunities to us.

Yeah, I could imagine just the amount of plugins, uh, that developers are writing has kind of just exploded now that a lot more developers are looking at the tool.

Yeah, that's exactly right. We see customers like building kind of bespoke code gen use cases and using us like for like alternative kind of design tooling needs where they'll, they'll kind of inspect our file format and translate it to some radically different use case. Like, you know, potentially even like a CAD design type use case. So it's, it's just cool to see the, the different ways people are, uh, using that new extensibility mechanism.

Yeah. Here, here at Descript, we've been doing something very similar where we generate all of our design tokens from a few files in Figma using using the export formats that you guys have.

That's great. That's awesome to hear.

Yeah, when I was at Oxide, we were doing the same thing. It's like generating a lot of design system stuff straight from like Figma tokens or whatever. It was a workflow.

Very cool.

So let's switch over and talk a little bit about somewhat of the elephant in the room. You can't like exist in this industry right now without talking about AI. And we've already sort of like touched on some of the cases. right? You were talking about like generation, generation not being just like a one-shot process, being this like process of you don't want to just like generate code. It's like you want to sort of like meet developers and designers where they're at and sort of like enhance their workflows. So given that like AI is like taking up, or LLMs have taken up such, so much of our mindshare now, how are you internally thinking about like where AI has a in place at Figma and how it can be leveraged to sort of help people in their design process?

I think there's just, I mean, because AI is at the basic level of technology rather than a, you know, a product in and of itself, I think there's just so many different ways you can apply it, especially in the context of, um, the, the ecosystem that we're creating in Figma. Um, there's a couple different like kind of extremes that we, we tend to kind of anchor ourselves on just for the sake of discussion and alignment. Um, I think like, uh, Noah, our head of design at, at our config a couple years ago, sort of laid out this kind of framework of thinking, um, around like, you know, using AI to lower the floor for design so that more people can, can participate in this design process. And as I said, it's not just about, you know, using the design tool, it's also about figuring out how to bring designs to life and, you know, handle all the different responsive edge cases and whatnot. Um, I think we can also raise the ceiling of what people can create. I think like Figma is a testament to the fact that like differences in degree can yield differences in kind. And we've been able to basically really focus on, you know, these key performance optimizations and, you know, making things available in the browser so that it's that much easier to share. And you see like different ways that people now use our tool and different use cases as we just talked about. And so I think AI can really kind of like help to kind of raise the bar for the kind of creativity that that professionals can express and the kinds of ideas they can, you know, bring to production. And I think even if you're just like speeding up that process, ultimately you're going to enable more iteration and you're going to enable better experiences as a result. So those are kind of like the two extremes that I think are interesting to anchor on. I think that, like, as we were talking about before, I think there's a, there's like a little bit of nuance too. So I think like, you know, on the base level, you think AI, okay, it's going to like enable me to make something out of a prompt. But as we just talked about, that's not, that's not actually, uh, what professionals want, right? Like, it's, it's kind of like, you know, at the end of the day, um, you can only be so expressive with natural language. Um, and I think like for those of us who are engineers, like, we know that at a certain point when you're pair coding with someone, you just want to grab the keyboard and, and change things directly. You don't want to have to keep telling people how to change things. I think in the same way, you don't want to just keep telling this model like, no, no, you don't, you didn't get what I said, I really meant this thing in the top right, or whatever. So I think that we're like really excited about exploring for our own use cases how to marry the best of these new input modalities that the technology unlocks, like natural language, you know, maybe voice someday and whatnot, with like existing interfaces and direct manipulation. And in, you know, trying to give people the choice so that, you know, maybe when you're just kind of roughly trying to visualize someone else's idea, you can ask the tool to kind of help you get started. But do it in a way that is consistent with your brand and your identity and, you know, your existing code base. But then you still can just like, you know, grab the keyboard or grab the mouse and, you know, go click on the thing and like drag a color wheel and figure it out. Um, and build up your own strong mental model. Um, so you can reason about it better for yourself rather than relying on some, some random model to do so with the context you give it. So I think there's just a ton of opportunity, um, for us. And, um, we're excited about all aspects of it. I think we're excited about helping people explore the design solution space faster. We're also excited about how to help designers do more of the productionization inside of the tool and then engineers basically consume that more directly. So basically trying to figure out how to infer a lot of the kind of implicit context that we all take for granted that actually takes a lot of time and it's very tedious to make explicit.

Yeah, I like how you guys are approaching it. It's like a lot of AI tools are like one shot. I'm just going to generate everything. I have no ability to like go in and tweak it and like you wouldn't want something like that in Figma. And you guys aren't just stopping at like generation. You're also like the— where I find AI features like really sing is when you don't have a prompt and like AI is away from your mind. So an example of that is common problem in Figma. You make this huge design, you go look at the sidebar and go, wow, I'm never going to be able to organize that into something a human can understand. Like using AI to organize that I think is such an awesome feature because it's like That's not work I want to do as a human, but it's work that I need to be like fully expressive and productive in this tool. So I, I love all those little tiny features that are more like baked into the UI rather than just like, here's a box and we'll do stuff for you.

Yeah, that's great to hear. Yeah, no, definitely. I think, um, we've been trying to think through like how do we balance what these models can do off the shelf, um, that are immediately valuable to the existing workflow of our customers. With like, um, what are the capabilities that we need to help these models learn or, um, grow into in order to really unlock kind of Figma-specific, um, power-ups. Um, so, uh, we're working on both fronts simultaneously.

Are there any, uh, specific implementations or features that are either shipped or in progress that you are particularly excited about?

I'm also excited about the, the layer renaming feature that we just talked about. Um, I think that, uh, it's just such a, a simple thing that goes a long ways towards just actually doing something that a lot of people don't like doing but is actually very helpful. I think that there's work we're doing to automatically explore how to like set up Code Connect and things like that as well. Like so many people are excited about Code Connect in our community. I just went to this conference, this developer conference in Berlin a couple months ago, and we actually had like the longest booth at the conference, the longest line to our booth, which was really cool to see. We didn't expect it. But at the same time, it still takes time to set up and we want to try to make that as streamlined and seamless as possible. And I think there's a lot of opportunity to do better there.

Sort of like a last sort of category question here on just the implications of AI and inner tooling. So you started this by saying, it's like one of the things that we see is it can really lower the barrier of entry. It's like more people can get in and start expressing their ideas and design. So do you think AI and LLMs, or maybe even its specific application inside of Figma, will be something that sort of changes what it means to be a designer or how you interface with designs? And maybe the same for an engineer, like how you go through the design process?

Yeah, I think, so maybe taking a step back. So I think one of the things that I it's always easy to like kind of imagine what could be, but I think one thing I feel pretty strongly about is one part of like being an engineer is having sort of the persistence and the desire to learn specific technologies and specific tools. And those tools are oftentimes changing year over year, decade over decade. And I think like even within like the field of like product engineering or frontend engineering for that matter, we've seen like specializations emerge over the years. And I think on some level, some of us have been like a little like uneasy with it. It's like, why, why is this like specific new like framework, you know, getting like higher job offers than this other framework, which ostensibly is like, you know, requires the same level of aptitude and expertise and engineering knowledge. And so I think like, you know, there's a reason for that, just like, you know, some of these things are valuable at the time, and finding someone who, who has that expertise already is super valuable. But I think, like, one of the things we're going to see is, like, that sort of expertise is easier to come by by virtue of these models helping us find it, helping contextualize it, helping translate things more rapidly. And you could say, like, oh gosh, that's, like, a bad thing. But, like, the reality is, like, that was already happening. Like, very quickly, those, those, like, specific roles, like, maybe, like, a, you know, early days of mobile, like mobile engineering, that they like the value of being specialized decreased as, you know, it became more normal. And I think on some level, I think like AI has the potential to really kind of like help us focus on the essence of what it means to be a maker. And, you know, there'll still be like opportunity to kind of maybe focus more on like the ideation and alignment phase of building versus the productionization and you know, system design phase. Um, but at the end of the day, I'm actually kind of like excited to see like how it might help us as makers really like get to the essence of our craft and what we do, rather than focus on some of the like the just pure like memorization, like implementation detail kind of things that really aren't why most of us got into what we do in the first place. Um, so I'm excited to see that shift. I think, um, it could actually be a really good thing. And then I, I also am excited to see people like have the kind of courage as a result to wear more hats and, and like collaborate more strongly with one another so that we don't have these like waterfall handoff processes. We have like just really strong collaboration where, yeah, one person might be constantly trying to kind of envision like the, the kind of next, you know, opportunity or, you know, visualize it in a way that brings the rest of the team along and another person. Is working on, you know, making sure it really sings and works well and is a part of like a cohesive maintainable system. But they're also working together and like they're giving each other feedback at both ends of the spectrum much faster, much more rapidly. And as a result, you know, you see a lot more innovation and just more excitement and people don't feel like they're just doing, you know, doing downstream work from someone else. So I think a lot of that stuff is going to happen as we sort of democratize the specialization. But I think there's still going to be room for people to really like focus on the aspects of the process that they were always excited about in the first place.

Yeah, something I like to think about in this space is any creative, like, pursuit, but especially design and engineering. The big thing that you have to deal with is you have a lot of decisions that need to be made kind of all the time. And there's a lot of context around those decisions. And there's a lot of decisions that you end up having to make even if you don't want to or don't need to. Just because it has to be made by somebody. But like, there's almost like this, like, decision deferral that you can do, sort of like, I'm going to defer this decision to some external entity and then get back some result and then use my expertise to sort of like hone down on the things that are actually important and matter. And I think that, that like, you know, we, we have so much energy and being able to just like have more energy for the important decisions, I think is an incredibly exciting thing. And And I'm really excited to see how, yeah, Figma continues to push on this very specific thing. Like we're talking about layer names, making a bunch of decisions about layer names may be important, but it's not fun or super necessary. And if you see a layer name that's like misnamed after the thing goes through it, if it's like 1 of 80, that's fine.

That's great.

What a good outcome, you know? So I'm excited about like just less mungy work, the things that we all end up having to do. that aren't like giving joy to us.

Totally. Yeah. I think another, another example of this, um, that we talk about internally is, um, I think like on one end of the spectrum, right, we have all these like kind of code completion tools or autocompletion workflows with AI now. And on some level you can think of that as like generation. Um, but to your point, like there's a difference between like, you know, you type just one short sentence and then you hope that it generates the right thing and understood everything in your head. Versus like it's trying to adapt what it's generating based on what you've already done. But I think on like a more fundamental level, like the, the whole like autocomplete process is also a form of search. And I think like we all take it for granted how often we search for things, right? Like we're either searching for documentation or in Figma searching for an existing component or an existing mock of a screen. And so I think we're, we're like equally excited about like these, these new opportunities from the perspective of like, you know, how magical they can look. But also like, if you just look at it, like, uh, autocompletion is just a form of like improved search where you're surfacing the right content at the right time to remove a lot of the tedious aspects of the workflow. And so, um, I think, I think, yeah, sometimes we get so fixated on like kind of the, the, the Twitter-worthy demo that we kind of forget about a lot of the, the more basic things that we can do with these technologies that aren't as threatening to what we love about what we do.

Yeah, speaking about shipping things other than tech demos, uh, before we move on to the future question, I just want to ask one question about how you guys deploy AI. Like, are you guys doing things in the cloud or are you relying on the browser?

Yeah, it's a good question. Uh, we do it largely in the cloud. Um, although we, we are exploring like ways to run models locally too, where appropriate, but right now it's in the cloud.

For sure. Okay. So looking to the future, uh, like what is next? For Figma? What are you guys building towards? Like, what's the next big release? How do you want to make our lives easier?

Yeah, well, we've done a few things recently that people might not have caught. So we did just release a new product, Figma Slides, which we're super excited about. I think it's, uh, it's like first and foremost, it's just like a familiar medium that we all have used in our jobs to build alignment and kind of bring people along. Um, and I think that's a big part of what we do, right? We're trying to help teams like envision the future of the experiences they're creating and build consensus and conviction about where they want to take their products and then move forward as quickly and efficiently as possible to bring the best ideas to life. And I'm just like really excited that we've actually seen people talk about Figma, not just as a tool, but as like a, kind of like changing the way that teams work. Like you kind of like hear people talk about like the new suite of tools they use. And oftentimes it's like Figma plus some other, you know, new tool like Linear or something like that. And it's cool to be a part of that. But I think there's just so much more that we can do to actually embrace the fact that design happens within our tools and outside of the traditional design tool. And I think everyone in a company is ultimately a part of the design process. And I think there's a lot more that we're going to be doing and can be doing to really make that more visceral and more powerful inside of the organizations that are adopting Figma. Figma. So dev mode is the start of that and there's just so much more I think we need to do there. But there's a lot of other stuff we have in the works as well.

Yeah, I'm excited to see what you guys come up with. I'm a believer that good primitives yield very interesting results when mixed. I think FigJam is a great example of that. Slides is another one. So having dev mode in there as a primitive and building off of that, I think will yield some pretty cool results.

Awesome. Thanks.

Sweet. That wraps our questions up for the week. Thanks for coming on the podcast, Kris. This was a very fun dive into how Figma works and what you guys are working on. So thanks for coming on.

Yeah, thank you for having me. It was great meeting you both and spending the time talking to you.

Yeah, thanks, Kris. Figma is huge. It's really changed our industry and it's a delight to use. And yeah, keep up the good work.

Thank you. All right.