The Changelog: Software Development, Open Source - Bringing Dev Mode to Figma (Interview)

Episode Date: November 22, 2023

This week on we're joined by Emil Sjölander from Figma — talking about bringing Dev Mode to Figma. Dev Mode is their new workspace in Figma that's designed to bring developers and design to the same tool. The question they're trying to answer is "How do you create a home for developers in a design tool?" We go way back to Emil's startup that was acquired by Figma called Visly, how we iterated to here from 20 years ago (think PSD > HTML days), what they did to build Dev Mode, what they're doing around codegen, the popularity of design systems, and what it takes to go from zero to Dev Mode.

This week on The Change Lab, we're joined by Emile Shalander from Figma. Talking about bringing Dev Mode to Figma. This is their new workspace in Figma that's designed to bring developers and designers to the same tool. And the question they're trying to answer is, how do you create a home for developers in a design tool? We go way back to a male startup that was acquired by Figma called Visley. How we iterated to here from 20 years ago. Think back to PSDs to HTML. What they did to build dev mode.

What they're doing around Cogen. The popularity of design systems. And what it takes to go from zero to dev mode, what they're doing around Cogen, the popularity of design systems, and what it takes to go from zero to dev mode. A big thank you to our friends and our partners at Fastly and Fly. This podcast got you fast because Fastly is super fast globally. Check them out at Fastly.com. And our friends at Fly will help you put your app in your database, close your users all over the world.

Check them out at fly.io what's up friends this episode is brought to you by our friends at Neon. Serverless Postgres is exciting and we're excited. And I'm here with Nikita Shamganov, co-founder and CEO of Neon. So Nikita, one thing I'm a firm believer in is when you make a product, give them what they want. And one thing I know is developers want Postgres, they want it managed and they want it serverless.

So you're on the front lines. Tell me what you're hearing from developers. What are you hearing from developers about Postgres managed and being want it serverless. So you're on the front lines. Tell me what you're hearing from developers. What are you hearing from developers about Postgres managed and being serverless? So what we hear from developers is the first part resonates. Absolutely. They want Postgres. They want it managed. The serverless bit is 100% resonating with what people want. They sometimes are skeptical. Like, is my workload going to run well on your serverless offering? Are you going to charge me 10 times as much for serverless that I'm getting for provision? Those are like the skepticism that we're seeing. And then people are trying,

and they're seeing that the bill arriving at the end of the month. And like, well, this is strictly better. The other thing that is resonating incredibly well is participating in the software development lifecycle. What that means is you use databases in two modes. One mode is you're running your app, and the other mode is you're building your app. And then you go and switch between the two all the time, because you're deploying all the time. And there is a specific, you know, part when you just like building out the You're creating a branch, and then you're developing your feature, and then you're sending a PR. And then that goes through a pipeline, and then you run GitHub Actions, or you're running GitLab for CICD, and eventually this whole thing drops into a deploy into production. So databases are terrible at this today. And Nian is charging full speed into participating in the software development lifecycle world. What mean by proprietary is built in-house.

You know, the technology is actually open source, but it's built in-house to support copy and write branching for the Postgres database. And we run and manage that storage subsystem ourselves in the cloud. Anybody can read it. You know, it's all in GitHub under Neon Database repo. And it's quite popular. There are like over 10,000 stars on it and stuff

like that. This is the enabling technology. It supports branches. The moment it supports branches, it's trivial to take your production environment and clone it. And now you have a developer environment. And because it's serverless, you're not cloning something that costs you a lot of money. And imagining for a second that every developer cloned something that costs you a lot of money in a large team, that is unthinkable, right? Because you will have 100 copies of a very expensive production database. But because it is copy and write and compute is scalable, so now 100 copies that you're not using, you're only using them for development, they actually don't cost you that much. And so now you can arrive into the world where your database participates

in the software development lifecycle. And every developer can have a copy of your production environment for their testing for their feature development, people want to merge this data, or at least schema back in into production, people want to mask PII data, people want to reset branches to a particular point in time of the parent branch or the production branch or the current point in time, like against the head of that branch. All our top customers use branches every day. I think it's what makes Neon modern. It turns a database into a URL and it turns that URL to a similar URL to that of GitHub. You can send this URL to a friend.

You can branch it. You can create a preview environment. You can send this URL to a friend, you can branch it, you can create a preview environment, you can have dev test staging, and you live in this iterative mode of building applications. Okay, go to neon.tech to learn more and get started. Get on-demand scalability,

bottomless storage, and data branching. One more time, that's neon.tech. All right, we're here with Emil from Figma. Hey, welcome to the show. Thank you so much. Thank you. Happy to be here. Emil from Figma. Hey, welcome to the show. Thank you so much. Thank you. Happy to be here. Happy to have you.

Pretty cool stuff you've been working on over there. Dev Mode, which is, maybe it's a new product from Figma. Maybe it's a new direction. We'll dig into all of that. But you didn't start there. You started as Visley and ended up as Dev Mode. Do you want to give us a brief rundown of the history of your company and joining the Figma team?

Yeah, sure. I can rewind it before Visley as well. I think that's interesting. For context, I started a company, Visley. We were maxed out at nine folks, went through Y Combinator, tried to build a design tool specifically for developers for a while and and eventually joined Figma a couple years ago and have been working on dev mode since and I've launched that since then um so that's kind of the very very short kind of gist of it but stepping back a bit like really ever since I like started

coding or started getting into software which was late late compared to a lot of folks. I really got into it when I was 20 or whatever, 1920. I wasn't one of those 13-year-old script kiddies. So I have had a long background, or I guess not that long, but my whole time being involved in software, I've always been really focused on the design, how things are built, why things are built, and really jumping between design and engineering, software engineering on a daily basis and comes from kind of all the way back from university. And really every kind of thing I've worked on since then has been really focused on bridging this gap between design and development in various ways.

And I have had experiences working on product teams where the designers and the developers took this fluid shape where it was really kind of worked as one cohesive unit, as opposed to kind of two siloed teams or whatever. And that's really where my background comes from. So after having been at a few places, but most recently at Meta for three years, mostly working on open source, like layout engines and mobile infrastructure, things like that, as well as developer tooling. I felt like I wanted to take kind of the next step. And I thought back to this thing that I've been thinking about for ages, which is really getting designers and developers to work more closely together and work as one cohesive unit. Because I think that has always, in my experience, led to just the best products being built,

the most thoughtful products, the teams that have executed most quickly. They've kind of been these teams that work as one cohesive unit. And I wanted to build software to enable more teams to more easily work as such. So that's really where Vistly started trying to enable this. So started this company with a friend of mine at the time. That friend is also still at Figma. And yeah, we spent a few years basically trying to re-envision what a design tool would look like if it was built for developers from the ground up. So really kind of a React-based design tool that everything, every object, every layer, every pixel was a React component behind the scenes. Or rather, we even, we had

big ambitions, which I think is always good. So it wasn't actually even a React component behind the scenes. It was this kind of abstract notion of a renderable object that initially translated to React. But we'd also built a cross-platform kind of high-performance Flexbox engine. So we could translate this stuff to iOS and Android and what have you in the future as well. But really kind of at the core was a design tool where every kind of interaction or action you took translated to a line of code. I think it's interesting to see this world of development that as I hear you share your story,

I just think of like, we're trying to build products, right? We're trying to be front-enders. We're trying to be engineers and work together. But then we're also building the tooling that allows us to build along the way. And I come from a generation where CSS was brand new, basically. We were still designing inside of Photoshop. We were still doing sliding doors to do different things with tabs and CSS. We did not have rounded things.

We did not have all these cool things that are out there in web standards. Now it's interesting to see how the iteration has taken place to get to this dev mode world where finally we have a design tool that does have dev friendly enablements and it may not still be perfect, but it's so much better than what we were, right? Like every iteration there is sort of like very, very iterative because we're building products but also inventing and re-establishing and iterating on the standards that get us there and the tooling and products like yours and figma have allowed designers and devs to play very well together yeah i mean i think it's interesting thinking about this like you said kind of in a historical

context because i think these the idea of visual tools to kind of in a historical context, because I think these, the idea of visual tools to kind of argument front-end development has been around forever. I think since we built graphical user interfaces, the notion of kind of a graphical user interface to help you build graphical user interfaces has been a thing, whether it's kind of like Interface Builder in the 80s from Next and then later or tools from Adobe, or what have you, right? Like, this has always been a thing. And I mean, it's in one way, it's pretty obvious, like, it's easier to build a visual thing visually, for the most part. But this is actually gone, I think, harder to execute on over time, because the requirements have changed right so let's say

like looking back adam like you were talking about like css is like just kind of becoming a thing like back in those days like responsive design wasn't a thing it was like no it's 960 pixels or whatever 720 that's right and that's it and actually like you wouldn't have any css for styling right you use like jpegs as backgrounds and if a hover effect was like switching to a different jpeg if you even had a hover effect right so in a way it was very much like with the technology and the requirements at the time it was actually much much easier to go straight from like design to functioning application back in that day, because it's literally just like JPEGs on a webpage, like roughly laid out with a fixed kind of design. So I think like, we still believe heavily in this

kind of notion of like, I think like, as front end developers building graphical software, like working with a graphical tool to help us build graphical software is an abstract notion. It's really helpful. But we can't emulate what we had 20 years ago because that was just built for a different time. And now we have to think about the constraints we have now and build

different kind of software that helps modern front-end development. Even though we sometimes think back to, I wish it was 20 years ago. In many ways, simpler times, but things are better now, I think. Simpler, yes, I suppose. I mean, even like PSD to HTML, like that terminology, right?

Like that's comical, right? Like there was companies that were born to do that. Yeah, whole industries. Right. And you would slice inside of Photoshop, or I think even at the time, there was a whole different tool that was not photoshop that was acquired by macromedia or adobe acquired macromedia and had this other tool that was i forget what it's called even that's been that

long ago and i remember having debates with somebody when css came out like don't use css it's stupid you could do that with tables why would would I do that with CSS? You know what I mean? You have this pushback of the new thing and the change. But it was simpler in some ways. In some ways, yeah. But it still boggles my mind that we would. And I did this, but not for web, but for iOS. But it boggles my mind that we used to use a tool for retouching photography to design UI, right? Right. It reminds me of how people use Excel for literally everything.

Every Excel feature is like a startup itself. I don't know. I feel like it's by any means necessary. Yeah, for sure. It's kind of like the by any means necessary aspect. I think that's the unleashed. We wanted to do this new thing on the web so badly that we use tools that were not designed for the job and still got the job done.

And we forced the tool to change. And I guess ultimately, you know, the merger of the worlds of Adobe and Figma even happened. I mean, like that long transcendence of a timeline is just, you couldn't have predicted it necessarily, but we forced it by means of just using the tools that we had. So a long time ago, I helped Grooveshark, which was an old music streaming app slash service, rewrite their Flash app in HTML5. This was when HTML5 was like burgeoning. And they always had great design. I mean, that was one of their things. Like the design was slick and nice. And I met the lead designer of Grooveshark

and very talented guy. He did all of his design work. I mean, literally all of it in Keynote, Apple Keynote. I mean, Apple used to design their stuff in Apple Keynote. I asked him like, isn't this like a PowerPoint replacement, like slideshow thing? He's like, yeah, but it's a great design tool.

And so he took Keynote and he handed me Keynote, and I was supposed to implement that from there. It actually was just as easy or painful as Photoshop. I had Keynote installed already, so at least I had that going for me. A lot of developers have Photoshop licenses or not.

At least it was vector-based. Yeah, exactly. It was vector-based. But it speaks to this real inefficiency that exists in the world of the collaboration bit, which you guys are very much building tools right in that area where you can lose so much time and money in those handoffs, if they even are handoffs. So there's many different ways of doing it. If you think about a software product, you have kind of the product owner, right? This is the person who decides the direction, the features, et cetera. You have the designer and you have the developer, these as roles. Historically, I think the most successful and quickest moving orgs are when those three things work very well together or sometimes are inhabited by a single person.

The one person unicorn who can think it up, design it, develop it. Very successful. But when you have teams doing those things, there's so many different ways of managing the collaboration between the three. And there's so many bad ways to do it. In fact, we can reminisce about some of the bad ways. When you had to go hire a company to take your PSD and turn it into HTML, and then you got to go hire a different company to take your HTML and turn it into a working web application, it really struggles to be able to iterate when you have silo, silo, silo, and then knowledge transfer fails. And so the person actually said this color, but the developer thought they said that color. Yeah, and I think that's fundamental to Figma as a company and as a product, but also to how we, when we started

developing DevMode, we really wanted to think through DevMode from first principles. So everything was on the table. Should DevMode be a totally separate product? Or should it be kind of a new file within Figma? Or should it be like a mode, which is what we eventually landed on, right? But what we thought through with all of this was really back to this,

like piece of communication and collaboration, right? We know that what really matters for companies to build better products and build those products faster while also maintaining a high quality bar was really about communication and latency and communication, fidelity of communication. So for us, it was really obvious that no, developers, designers, PMs, or even lawyers, be in the same spot and collaborate live in real time together. Because otherwise you get asymmetry in information or miscommunication, or you get things where somebody doesn't learn

about information until like three days before launch. And then you either need to scramble or most likely you're delaying launch by like a quarter or whatever. So making sure like everybody's on the same page is looking at the same thing, and knows the same information is really key to great collaboration and building great products quickly. And I don't think it can be overstated just how much time and money you can save by greasing those skids, because so much of the fails in software development process is simply inefficiencies

in our collaboration practices. And a lot of times we're trying to just make it up on our own. I mean, I've done a lot of small contract work where I'm working with different teams, different clients. And so I had like iterations on how many different ways you can collaborate around a software project. And so many of us are just making it up as we go along. And if you're not familiar with that one, there's just so many ways that you can waste time, waste money, waste effort on stuff that doesn't matter. And so yeah, if you can bring everybody to the table at the same place and get them collaborating there and provide tooling and resources for that to be effective for everybody, then that's a big win. So when you started DevMode, so you joined Figma to build DevMode?

Is that fair to say? Visley was already building kind of a thing? Tell us how that worked out. Yeah, so just finishing up with a thought on the communication front, which I think kind of segues into the next thing you're asking. This is something F figma has been thinking about since day one right this is the reason figma is a url in a web app because yes you can get your whole design team to like install some design software or even that is like hard sometimes but

let's imagine you can do that it's really hard to get, a random stakeholder or engineer on the team to install this big design software and create an account or whatever, just to kind of quickly view a prototype, right? So having that as a URL where anybody can just load it up quickly and see what they need to see, that's really the foundation of what Figma was started for. Because we always knew that, I say we, like Dylan and folks who started Figma way before I joined, always knew that design is a process that really involves more than designers, right? Everybody needs to be part of it, whether you're a PM, engineer, or marketing, or really anybody who even touches any aspect of the product needs to be part of that design process. And we want to make that, encourage as many people as possible to as easily as possible come in there. So the notion of design needs to accommodate for developers, developer handoff, engineering collaboration, that's something that Figma has really been thinking about since day one. So the reason we joined Figma is really to deepen the investment in this

rather than start it up from scratch. It's really to deepen that investment in developer collaboration. So, I mean, realistically, like we'd been running Visley for, I want to say two years, two and a half. I can't remember at this point. It's been a while, something like that.

And yeah, we had a product. We had it in beta. We had, we didn't have a lot of we had sub 100 users but like enough to get feedback but the feedback we were getting was like really good but from like indie developers right the developers who did both design and development and they really liked it but we just like basically was impossible for us to get into any any larger team because you know, designers didn't like the tool, which is like fair enough. We really set up to build kind of a great design tool for engineers. And that is what we built.

But at larger companies, like you need to bring design into it as well. Right. And to a degree, kind of Figma was kind of in the same spot, but the opposite spot. Really? Right. And we were using Figma at MISLI, so we knew about Figma, we loved Figma. But Figma was a tool just like absolutely loved by designers, right? But engineers were like, I mean, it's better than Photoshop for like, I don't need

to install Photoshop, right? So it's better than that, but they weren't in love with it. And they didn't see it as a daily use tool necessarily. So that's the audience we were really trying to serve. And, and again, Figma had been investing in developer kind of developers as, as a cohort, but, but I started talking to Dylan and like, really we wanted the same end goal, right? So it just felt natural to come in and boost their investment and kind of this space. And that's what we've been doing. So we came in, we tried to figure out how to best really serve this audience. We actually started with something that's not DevMode at all.

The first project we took on coming in was, we called it AutoLayout v4.3. I don't know, one of the versions. The next version of AutoLayout layout which is figma's kind of flex box in in the design tool because we knew from talking to users are also just like knowing from ourselves that i mean if you get handed a design and it's all absolutely positioned it's going to take you a lot longer to translate that to code uh than if it's using something you can relate to like flex box and the fact isLayout was loved by a lot of designers, but it had a high barrier of entry.

So it was like hard to like start using. And there were just a lot of cases it couldn't handle where you had to like opt out and just absolutely position stuff. So all of this led to, relatively speaking, low usage of AutoLayout. So we really want to solve this problem for designers so that they were excited and could use auto layout for more things and thus kind of improve the developer end of things. So kind of a second order impact on developers. And once we completed that, we shifted over to building this entirely separate space, a dedicated space within Figma for developers we

call DevMode. And it's ended up actually not being a separate tool or anything necessarily. It's more like a different tool set. So you're viewing the same content, the same canvas in Figma, but you're viewing it from a lens of a developer. So we change out the whole tool set. We change out the left and right panels. We make everything like optimized for a developer as a user, which hadn't existed in Figma before and allowed us to really make different trade-offs and optimizations where previously we might say, oh, that's a developer tool, so let's put it behind the sub menu.

We now had an interface where we could say, no, let's make it like the biggest thing on the screen, right? Which is a big difference for our users. What's up, friends? I'm here with one of our good friends, Firas Aboukadej. Firas is the founder and CEO of Socket. You can find them at socket.dev. Secure your supply chain, ship with confidence. But Firas, I have a question for you. What's the problem? What security concerns do developers face when consuming open source dependencies? What does Socket do to solve these problems? So the problem that Socket

solves is when a developer is choosing a package, there's so much potential information they could look at, right? I mean, at the end of the day, they're trying to get a job done, right? There's a feature they want to implement. They want to solve a problem. So they go and find a package that looks like it might be a promising solution. Maybe they check to see that it has an open source license, that it has good docs. Maybe they check the number of downloads or GitHub stars. But most developers don't really go beyond that. And if you think about what it means to use a good package, to find it, to use a good open source dependency, we care about a lot of other things too, right? We care about who is the maintainer? Is this thing well maintained? From a security perspective, we care about does this

thing have known vulnerabilities? Does it do weird things? Maybe it takes your environment variables and it sends them off to the network, you know, meaning it's going to take your API keys, your tokens, like that would be bad. The unfortunate thing is that today, most developers who are choosing packages and going about their day, they're not looking for that type of stuff. It's not really reasonable to expect a developer to go and open up every single one of their dependencies and read every line of code, not to mention that the average NPM package has 79 additional dependencies that it brings in. So you're talking about just, you know, thousands and thousands of lines of code. And so we do that work for the developer. So we go out and we fully analyze every piece of their dependencies, you

know, every one of those lines of code. And we look for strange things, we look for those risks that they're not going to have time to look for. So we'll find, you know, we detect all kinds of attacks and kinds of malware and vulnerabilities in those dependencies. And we bring them to the developer and help them when they're at that moment of choosing a package. Okay, that's good. So what's the install process? What's the getting started? Socket's super easy to get started with. So we're, you know, our whole team is made up of developers. And so it's super developer friendly. We got tired of using security tools that send a ton of alerts, and we're hard to configure and just kind of noisy. And so we built socket to fix all those problems. So we have all the typical integrations, you'd expect a CLI, a GitHub app,

an API, all that good stuff. But most of our users use socket through the GitHub app. And it's a really fast install a couple clicks, you get it app, and it's a really fast install. A couple clicks, you get it going, and it monitors all your pull requests. And you can get an accurate and kind of in-depth analysis of all your dependencies. Really high signal to noise. You know, it doesn't just cover vulnerabilities. It's actually about the full picture of dependency risk and quality. So we help you make better decisions about dependencies that you're using directly in the pull request workflow, directly where you're spending your time as a developer.

Whether you're managing a small project or a large application with thousands of dependencies, Socket has you covered and it's pretty simple to use. It's really not a complicated tool. Very cool. The next step is to go to socket.dev, install theub app or book a demo either works for us again socket.dev that's s-o-c-k-e-t.dev so bring us from there to dev mode as it exists today so you have this blog post out how we built dev mode there was a lot of user research there was a lot of conversations this seems like maybe a not so hard problem to solve in the small, but when you try to solve it for disparate teams around the world working in different ways, different organization sizes, all of a sudden I get very overwhelmed just thinking about the task in front of you.

So you landed on this mode, which is a way of thinking, but that wasn't where you started. Can you take us a little bit on the journey, some of the conversations, and how you ended up landing on what you've landed on so far? Yeah, it's a great question. And I can spend hours on this, so I'll try not to. But I think this is the crux of it. I think, first of all, we're really happy where we've landed with DevMode.

We're hearing from customers. They're also really happy with it. It's really kind of accelerating teams in the way we want to accelerate them. That being said, there's also like so much left to do. And there's definitely parts of it that I'm still embarrassed of, but that's because kind of perfectionist at heart and we're working hard to kind of make it even better as we go along. Right. But the thing that makes designing for DevMode hard is that we're designing a new product at a large scale. So we're designing it for all of Figma's existing users. And they have very different ways of working.

You're like large employee-based bank versus like two-person fintech startup. To nobody's surprise, they work differently. Because they need to work differently. They have different processes. They have just different resources and so forth. So designing a product from scratch that works for this breadth of people is really hard. Most products are not designed like that, right? As a startup, you don't have any users. So you start with designing for kind of one small cohort, right? And make it great for them. And then you build up over time and over time that complexity grows with the product and you can serve more and more users. But for us, we, we really had to serve all our users day one.

So we had to take an approach, which scaled between like to all those different kinds of customers. So that's how we landed or like that, that was in the back of our heads as we were designing dev mode. So that's why we have such a strong focus on like customizability. Extensions and plugins is a huge part of dev mode where any user can go in and say that, no, I'm like an iOS developer who still writes Objective-C and I want to see like code hints for that. I mean, like you can get that, I think. There's a lot of plugins, so I think that exists.

But basically, you can customize it to show you the kind of information you want to show, you can show the documentation you want to show for whatever design system you're using, and so forth. So customizability was really kind of a main angle. And another thing we kept thinking about was this kind of concept main angle. And another thing we kept thinking about was this kind of concept of making DevMed really feel like a home for developers, making it feel like this was built for me as a developer

and not like a developer feature slapped onto a tool for designers, right? We really want to encourage developers to really spend time here and really really not just to spend time to like boost metrics right in many ways we actually want developers like get out of figma as quickly as possible and get back to coding that's like a goal of ours but we want the time they spend in figma to be productive rather than being kind of you know just searching and hunting for the right values. So this is kind of some of the, I guess, some of the thinking behind the design of DevMed. And the path we took to get to where

we are today is, I mean, long, it's circular, it's winding. We went back and forth many, many times, right? But the highlights I would say is that it it started with a huge focus on translating designs automatically to code this was a big focus in the beginning or a big hypothesis in the beginning i would say uh which we kind of quickly built out it was it's actually really cool uh we can talk about why it didn't work, but it was really cool. It looked like, imagine Chrome DevTools. You basically had like a code split screen, like half of it was code, half of it was design. It was like, you're inspecting the design and like seeing the HTML for it, right? Super cool from a UI perspective. When we actually put it in front of customers,

it didn't work at all, right. Because that code is, I mean, it's just like not what they, the code they needed to write, uh, you know, designers are not spending time getting the light right layer structure or like div structure for their designs. Right. It's not necessarily use using the correct abstractions you want, or there's a million problems here that, that make this just like not work well. And in many ways also like go too deep on the design and it easily lifted out, I would say properties of the design that were unintentional, right? So the beauty with kind of design is just kind of a picture that you can click on is that like you don't see the unnecessary details.

Like if a thing is wrapped in like seven empty groups or whatever, like, you know, you don't notice that you don't see the unnecessary details. Like if a thing is wrapped in like seven empty groups or whatever, like you don't notice and you don't care really. But if you're like really exposed to the underlying what that would translate to in code, now it starts exposing those kinds of details and makes them look important in a way that they definitely aren't

and actually distracts you from the most important aspects of the design and the intentionality there. So for all those reasons, like it didn't actually work. So we pivoted away from that and tried a number of different other things. And throughout this, like constantly just talk to users and across all sizes of companies and just to figure out kind of what the most important aspects were. The larger problem statement we landed on was like, and this is going to sound silly, but everybody we talked to wanted to build better products faster.

But like, this is hard. And especially like at a scale in companies, really hard to keep velocity high and quality high. So what we really just did was we talked to a lot of these customers, especially kind of post 100 employees. Because before then, like if you're like three people, quality and velocity is pretty high and it's easy to keep high. But as you grow, it can get harder. And the things we noticed were, I'd say, three buckets that I like to think about.

One is, I kind of touched on this with the collaboration piece earlier, but the first is like why you can't build great products fast is typically like organizational alignment problems. And this can be just like, you know, people have different opinions, but it can be also just purely kind of informational problems, which we see a lot,

which is, I mean, one really simple example is designers and developers would have a different tool, right? You design in one place and you like hand off in another place. And because there's this silo of information, now you have like duplicated information at two places. Developers would sometimes, you know, build the wrong thing because a designer forgot to export the latest version and you have designer developer think they're building the same thing but they don't notice it until like two days before it's gonna ship yeah and then people get stressed right or another classic example is

engineers are working off of jira or some other tool right it has nothing to do with jira and some pm or designer engineer has basically created a bunch of Jira issues that spec out the product and included screenshots of everything to build. But nobody thinks to update those screenshots or those tasks when the designs change, right? And again, people will be building different things

because you've siloed the information and you basically forked the information, right? So that's really something we want to resolve. The second bucket of problems, again, hindering folks from moving fast and building great products, was more around just maintaining product quality as an organization grows and scales. And that it can be really hard to stay on top of this. And our favorite and best tool for this is really design systems. We think that's kind of the tool most companies employ to kind of scale quality. But the problem we heard from a lot of customers is like,

yes, they have a robust design system, but nobody uses it. Or people use it wrong or all these things, right? So we really wanted to make sure that these companies who've invested in design systems actually like you know that that investment is worth it and we want to really um make sure that that really helps them you know increase that product quality and and the third bucket which we heard from companies that again wanted to like everybody else ship better products faster was that dev efficiency was just hard to keep high as as they scaled and this mostly came down to just a lot of like small

day-to-day paper cuts everything from like compile times to what have you that would just make their engineering orgs like move slowly and in the context of figma we would hear things like it talked about like oh figma is like complex to learn as a first time user because it's like, especially as a developer, because it's kind of been designed for designers. Or a really classic one is that developers would get like a version two or version three of a design. And they would literally spend a day just like playing the old game of like find five differences between two pictures it's like wait what has changed here and try to like construct a change log manually and then like transfer that to a task tool or whatever all this like kind of repetitive work that just like slowed engineers down day to day so those were kind of the three buckets of problems we saw hindering

companies to build better products fast and that's what we kept top of mind as we were building dev mode really and again this goes back to the conversation we had earlier of like for that org alignment piece it really starts with getting everybody to just talk and like use the same tool and be in the same space and that's why we built dev mode as as a mode within figma design right and we also knew we needed to build tools within dev mode for like clearer communication as well to like have those clearer specs be aligned on like what to build so you're actually building the same thing and that's where we have things like where designers can mark things as ready for dev or they can like annotate details of the design and really spec it out.

And then that last piece was like really about making sure the information is in sync between kind of all the different silos of information. And that's where like our partnership with, I'll point out like Atlassian here, because we have a really deep partnership with them, but also working with like Linear and Storybook and other companies but we really make sure to like with the Atlassian partnership make sure that like Jira is up to date with dev mode so you can like create Jira tickets within dev mode and that automatically like connects them via a link and now you don't need to like think about like having information in two places

and worry about that you can work wherever you you need to work and and get the information you want to make and and that's ensured to be up to date basically so that's really like how we've been thinking about devmed and happy to talk about the product quality piece and the dev efficiency piece as well but that's generally how i see kind of the the problems that we're trying to solve i just can't believe how much uh how much thinking goes into like building such a tool you can't just make a code gen and make it work you can't just push the magic i mean i guess in the way you can't push the magic button it's kind of what you've done in a way but all the iteration it takes to make this work oh and, and I'll tell you, while we can't build Cogen and it just works,

we also can't remove Cogen and it just works. Because our customers love the Cogen we have. And then others find it less useful. We have to find a way to balance that in a good way. Yeah. It is smart, though, to do the toggle back and forth between this. Because you could have made it a whole different product as you mentioned like but making it in the figma world and not making it some sort of bifurcated over here thing it's really the great invitation like

you mentioned before the day one of figma and i don't want to go back to the beginning necessarily but to being a url it's the great invitation and now this is still the same great invitation that figma was because you didn't have to install something. You didn't have to do all this setup like a developer might do to build out their dev environment. It's not like that at all. It's not a design environment. It's just go here.

And if you're in the engineering or dev spaces, you can flip between the modes and really just enjoy the direction that Figma's taking, what it means to design and to develop for the web. Yeah, for sure. And I mean, I'm excited about the directions we're also taking this to make it feel even better and more seamless for developers.

And this is early days, but we've in the past six months integrated with Visual Studio Code as well, where you can actually bring up dev mode specifically in VS Code and have your designs and code side by side. And it's not like, I think that's interesting and it like limits context switching, but the really, really exciting part, and we're just like starting to touch on the possibilities here, but is how Figma for VS Code actually interacts between the code and the Figma file,

where you can do things like you're in a React component and you're looking at a design for that component, and you can link those together. So later on, if you're browsing the code and you see a component and you're wondering, is this design correct? You can like not command click on it, but basically you can click in the gutter and it opens up the exact Figma design source of truth

for that from your designer. You can double check that. Yep, okay, this looks correct. Or if you have a new design for something new up, we actually integrate with the like auto-complete of VS Code. So if you start writing CSS, instead of like co-pilot suggesting random colors, right? We'll actually suggest colors and spacing values that come from your design file. So it's like

it feels like a super smart Copilot that knows exactly about your design. And still early days, but I'm really excited about the potential there. That's awesome. Going back to the CodeGen bit, it seems like people love it, people hate it. Sometimes it delivers, sometimes it doesn't because of the intricacies that you described earlier where the designer is just thinking visually and they're just doing what they need to do

in order to get things to group, et cetera. And now we have these layers and layers and et cetera. And sometimes the code isn't just there good enough. Are you continuing down that path though? Because I imagine as a developer, if I did have the button that says, take this and turn it into code that I would write, that for me is sort of, would be the end goal.

I mean, obviously the other stuff is nice as well, but if I could get that and not have, let's just say like misaligned code, code that I would actually write, then you guys would be like, just printing money for lack of a better word actually write then you guys would be like just printing money for lack of a better word like wouldn't that be like everybody would sign up at that point so are you still are you doing both like okay we need we need alignment tools we need

efficiency tools we need to make sure people are using the design system and stuff so integrating in developers workflows all that stuff needs to continue with dev mode but if the code gen could just be so smart that it could like you know realize that these extra components are worthless and just throw them out right and grab them the way i would in the first place then that could be that could be the solution like the end game are you still going down that path as well? Yeah, I agree. Like that as an end state is super interesting. We'll see when slash if we can get there, right? Or is it, it's probably a when than an if, right? Like if you a hundred years, whatever, I don't know.

Or two years, who knows? How far? Well, how far does it feel more like a hundred than two? Like, cause you've been working on it. So you would know better. I think there's a lot of, there's a lot of problems with getting it correct, right? But I think it's very doable for us to make it a lot better than what it is today. So instead of kind of guessing at when we'll have this perfect solution, because I don't know.

But I'll talk a bit more about how we're thinking about the next steps here. So what we have today is, I mean, out of the box, you can choose if you want to get some code for like CSS, SwiftUI, or Jetpack Compose for Android. And that gives you, I think, a reasonable hint at how to influence stuff. Personally, I use it a ton for box shadows because I never remember the syntax for box shadow, right? Or gradients or,

or whatever, right? It's super nice to like quickly get started. And it's like, yes, I'm not going to commit it directly to GitHub. Like that's not the point. And then there's like great plugins that can give you like tailwind code or give you like full on like react code for the whole design. Again, like don't commit it straight away, but this is like a great starting point to like get you started quicker, right? I think what we're interested in next building, and we're just starting to think about this, but it's really a focus on design systems. So if you are using design systems, which a lot of customers and our customers or companies in general are doing today across both code and Figma, to be clear, then if you click on a button, you don't want it to say div and a class name, right? You want it to

use my button component imported from my design system, right? So we want to make that work. And we think we have a path to get there in the near term. And we're exploring a few ideas. And I don't have anything specific to share there. But I can say the early explorations here are really exciting. And that's a place we can get to fairly soon. And then I think it becomes more problematic if it's like, here's a net new design for a website. Please code it up like I would have coded it up. I think that's much further off, although that's also much less common. Usually it's like, build this thing

using components we already have. And developers just kind of want to be pointed at what components to use, where they exist in the code base, where to import them from. And maybe some sample code for like, this is how you should use the component. Like that's, that's really what, what most people are asking for. And that, that is not far off.

And I'm excited to kind of see where we can deliver on that over the coming, uh, coming year. This is not production code, right? This is still something we might ship to production, right? In this scenario uh no i mean i think it depends we'll see how it turns out but i can think of yeah it depends right currently it's not there though right it's going to be there oh yeah i mean currently this is like we see code gen very much as as it's kind of a starting point kind of

a unblock your writer's block kind of thing and And, and, uh, you know, tell you how to do that box shadow or, or filter or linear gradient and CSS. Like it's great for that. Right. So it's some way like unblock writer's block and documentation almost. Right. But then we want to, you know, bring your design system into this as well. So that when you click on button, it says import my button from library.

And this is the, I don't know, this is some sample code of how you can use that my button to achieve what you want. Like that, that is, that is where, where, uh, where we want to get to. What's up, friends? AI continues to be integrated into every facet of our lives. And that remains true because you can now index your database with AI. You can write more code, become that 10Xer you always wanted to be. And you can even draft a letter for a lease on an apartment or a new property. AI is everywhere.

And it might be time for us to start questioning, is AI our friend or our worst enemy? And that's the focus of the three-part season opener of the award-winning podcast called Trace Route Podcast. You can listen and follow the new season of Trace Route starting November 2nd on Apple, Spotify, or wherever you get your podcasts. And this show is all about the humanity

and the hardware that shapes our digital world. In every episode of Traceroute, a team of technologists seeks to untangle the complex question, who shapes the internet? Seasons one and two gave us a crucial understanding of the inner workings of technology while revealing the human element behind tech. And season three tackles not just AI questions,

but also how can we use technology to preserve the earth? Who influences the technology that gets made? And what happened to the flying cars we were promised? I think it's safe to say that the future of AI is both exciting and terrifying. So it's interesting to hear the perspectives of experts in the field. Listen and follow this new season of TraceRoute starting November 2nd on Apple, Spotify, or wherever you get your podcasts. How many orgs have design systems? It seems like I tend to have a very indie lens, so I'm always scaling up to larger.

But I know that design systems are things that we talk about a lot on podcasts and there's people who like go and teach how to have a design system. But I feel like this is something that like high quality, well-invested orgs have, but most of us don't have. I see a lot of startups with design systems as well. It depends on what you define as design systems, right? Like, oh yeah. What do you define? Material design is a design system used by like thousands of companies, right? Or you have ant design or these open source design systems, right? I would still count that as the company having a design system, even though they didn't build it. They're using a design system.

If you think about it like that, the vast majority are using some kind of design system. That's not an official stat. It's just like, that's the feeling I get. Sure, that's fair. I just think that to a certain extent, it is a barrier to getting started. But maybe because of open source

and because of the proliferation of at least low cost available design systems, you could get started relatively easy. Maybe like the steps, two or three of startup is like business idea, some sort of feature list or go-to-market strategy. And then like some kind of a design system so that you can start building that thing.

Yeah, but also design systems aren't a binary thing. It's not like you either have or you don't have one even like you know week one as a startup you'll probably be like what color should we use for our logo what font should we use like those are the first decisions you're starting to make as your design system right uh or like how should our buttons look right like it's a decision you have to make and probably you want kind of your your styling of your various elements to kind of have a consistent look and feel whether you're using an open source system or not and this is building up a design system now it might not be like formally a design system so to speak but sure but i would still like that that's the starting point of a very good design system.

What color should we use for our logo? And then the answer is always blue or purple, right? Like everybody's always picking blue or purple. I want more to pick orange, but I'm a fan of orange as well. Adam? Green. Blue? Purple? Green. Green! Hacker green, bro. You know?

Hacker for life. Dev mode is green. Heck yeah, man. That's where the terminal prompt lives in Greenland. This is being designed initially for those that appreciate whether they do it themselves or inherit it or adopt it a design system first, because that's a good place to begin. Right? I would say yes and no. Yeah.

Yes and no. I would say that is our core focus now i would say for those that don't have a design system dev mode works great i would say if you are super invested in design systems there's just like a lot more we can do like i think demo works great if you have a design system today as well it's just i think there's just more opportunity to provide even more value once you have a design system versus if you don't have a design system like in a way there's just like a cap for like how much we how much value we can bring to you by knowing that system we can like

infer a lot of things we can we can uh yeah build upon that and just provide a lot more value so that's where our focus is. We think for those without design systems, DevMode is, I wouldn't say done, it's never done, but we think it solves for them pretty well today. And it does, again, it does support those with design systems as well. There's just like infinite kind of runway to do more, I think. Okay.

Is it challenging to give us a zero to DevMode scenario to go from not a Figma user to Figma user to enjoying what dev mode is? Whether let's just say I'm a startup who, you know, adopted material as an example, you, you did, we didn't build it. We, we inherited it. We adopted it. We appreciate it. But how do I go from zero to appreciate what dev mode offers my team? Yeah, that's a great question. I think with something like material design, like using a design system like that,

one, it's like a really big design system. It's like pretty complicated once you get into it. There's a lot of options. There's a million components. And what DevMode offers is really a way to really move faster as a developer here. You can get those mock-ups. You can quickly, like, whatever you're clicking, it'll actually tell you, like, oh, this is the documentation for that specific component. This is what you should be using in code.

And that's, like, linked to if you're using, like, MUI or whatever, like an implementation material design in code. You quickly know, like, exactly what components to use. So you're not trying to like, for every, like every step in the design, trying to figure out, read the docs, figure out kind of what to do. You can much more quickly translate this over. And that's kind of one of the things that DevMode gives you to like move really quickly. And I think, especially if you're using a DevMode within VS Code, you can be like really heads down in the flow, focus on coding and always be easily referencing

kind of those components you need to use to reliably kind of recreate what the designer has done. But especially in like, let's say like, this is a smaller team that's like really quick moving. I think things like our compare changes feature is super powerful here, where when something's changing, go into dev mode, and just hit a button. And instead of like, asking your designer to, you know, write up a change log, and we're only human, so they're gonna forget like 60% of the

things they changed, right? Where you can just ask the computer, like what actually changed here? What should I be updating? What values or what components should be changing to really stay in sync with what my designer wants me to do here right and this in the end one it goes faster you're more like autonomous because you don't need to rely on like waiting for designer to respond and three like you're going to build a higher quality product because you're not going to miss something that you would have naturally missed otherwise. There's many more examples of this. But yeah, whether you're a small team or tens of thousands, hundreds of thousands person organization, you can take advantage of various features of DevMed

to really help you, again, build better products faster. I like that. I'm going to keep using that too. It's pretty solid. What are you going to use it for? Build better products faster. Anything. To describe all the things I'm doing. Yeah, just helping you build better products faster.

It's like cliche. If you're a Silicon Valley fan, they say that often in season one. So I got to mention that. Wait, do they? Yeah. Maybe that's where I've gotten it from. Maybe that's where we got it from. Listen, I don't want to be cliche here, but we're making the world a better place. We're building better products faster. I don't think they say exactly that. Not like that. I'm

being very caricature, but yeah, it's a thing. Well, art imitates life and life imitates art. Let me ask you this, Emil. Did you use dev mode to build dev mode? I mean, not in the beginning. Dev mode didn't exist. Well, when did it become self-hosted? I mean, not in the beginning. DevMode didn't exist. When did it become self-hosted? Yeah, exactly. We quickly started, both as a company and as a team. The DevMode team is pretty small within Figma. It's growing, but pretty small.

We use DevMode, and the engineers and designers use DevMode. The rest of the company does as well. The beauty of that is we never forced anybody to use it, right? I think that's the kind of the worst kind of dog fooding if you force people to use it because then you don't learn why they choose not to use it, right? So in the beginning, people chose not to use it, right? And we learned really much from that internally as we iterated on the product. And we got to a place where really the majority of developers internally were using it.

And I mean, not everybody, and you would not expect that, right right but we got to a place where more and more started to use it and that's when we kind of were starting to starting to move to more external testing at that point so yeah we use it and we um the features we we love to rely on as a team are like really this um i mean a lot of the design system features I've talked about, but also this kind of these tools for clearer communication. So specifically the ready for dev stuff, because our designers do like 700 mock-ups, which is like great. And we get a lot of exploration, but it can be really unclear about,

wait, which one did we land on in the end? And ready for dev and dev mode really allows us to really get everybody on the same page there and same using annotations to really annotate every little detail and annotations is um for those listening and not a feature yet of dev mode but it's coming really soon and we're we couldn't be more excited about it it's a way for you to annotate every like little measurement or, or, or add little notes or annotate, like, this should be 12 pixel font size, really like spec out all the details in a way that you could always do before, like manually, but now it's like 10 X faster,

which, which really makes sure like your designer is actually going to like enjoy specking up the spec, which also leads to, you know, if they're going to lead to basically like you being on the same page. Right. So, so we're using that, uh, that a ton as well. That's a great medium for, you know, us designers to take out our passive aggressive moves, you know, like put the note on there. It's 12 pixels wide, Carl you know stuff like that yeah and like

you'll see teams using it like i don't love this but you'll see teams uh sometimes using it as a way to like cover their own ass right like oh well if i if i annotated it then it's not my fault it's not in there right um right i i don't think that's the best culture to have, but that's not how we use it. Well, it's a tool, and humans use tools as humans use tools. So annotations coming soon. Very cool. Anything else about the process, the creation process for you all internally?

Are there any bits of Visley that are left in here as assets, or is that just ancient history and this is a fresh start? Everything's Figma 100% code-based? Yeah, it's Figma 100% from a code-based perspective. We really came in as people who had thought about this a lot, more so than people with a large code base. And in terms of process, I think there's a ton of talk about there. I think the thing to keep in mind and that I love about working at Figma is

and it kind of what is instilled in DevMid as well is that building this product has been really collaborative, right? We've had, you know, our designers and our fantastic like product managers thinking about this, but also the whole engineering team and giving feedback constantly as well because it's a developer tool, but developers at Figma give feedback all the time on designer tools as well.

So that's fine. But it's like a super collaborative process. And yes, we've gone in circles a couple of times and back and forth to make sure we land on the correct thing, but it's really been developed as a really collaborative product, and it's been developed collaboratively as well in a way that we couldn't have gone to the same quality product if we hadn't gotten kind of all those opinions in the room while we were designing it and building it out. I'm just glad we're here.

You know, the PSD to HTML days are just whatever, man, PTSD, PTSD to OMG, you know, forget that stuff scenario. I'm just glad we're here. I'm glad we have people like you just,

I mean, what an amount of effort it must've taken. Like, I know you even struggled for, well, iterated for over a year and a half on just like how to get there, like how to go to that magic, but at Like, I know you even struggled for, well, iterated for over a year and a half on just like how to get there, like how to go to that magic button moment, you know?

And it's hard to appreciate those moments, you know? It's hard to appreciate all that goes into the details to make the future possible. For sure. And it's so fun now that we've launched DevMed and in beta since, what what was it mid-june i keep forgetting dates for mid-june let's call it don't ask us and uh yeah i'd config in mid-june and um it's been so fun not just to see people use it but it's entirely changed how we develop

the product in a really good way where you know when it's secret in the in the beginning also before launching it's you know you talk to some customers you ask them to sign an NDA and it's like over a zoom and it is what it is and you get some feedback but since launching it we've been able to really talk to users in a an entirely different way and that's really led us to really be able to accelerate you know development on dev mode in an entirely different way. And that's really led us to really be able to accelerate, you know, development on DevMed in a very different way as well. Like we launched it mid-June, we launched it with a big, like, give us feedback button up top. And the interesting thing is like a lot of people that like have written in to us, like, oh, I don't think anybody will read this. It's like, we read every single one.

We connected it to our Slack. So we get a ping notification for every single feedback request. And in the beginning, this was thousands per day. So it was overwhelming. I might've missed one or two, but we read most of them.

That's awesome. And not just like me read it or like, you know, my boss or whatever, but every single engineer and designer on the team That's awesome. 200 issues of varying sizes sure but added features resolved issues and just like worked super closely with everybody and we're continuing to do that uh since then as well but the team was just like operating at at a totally different velocity than before in terms of like those sorts fixing those sorts of issues because we we had uh. So we saw these issues that we couldn't possibly see before. And we had like a fire hose directly kind of injected into the team that they could see and get pinged on every single day.

And I still get at this point, I don't know the number, less than a thousand per day, but still get like many times per day pinged by this Slack bot, which is like, here's feedback, here's feedback, here's feedback. So we're seeing it all in real time. and that's how we like to build products. Very cool, Emil. Well, the blog post is out there on the Figma blog if you want to read more. Of course, we have the deep dive here. Anything left unsaid?

Anything we didn't ask you about that you've been itching to say before we called a show? One thing that we haven't talked about, this being like there's a lot of developers listening in here i think it's worth maybe just like chatting a bit about the developer platform that is figma as well like we have this we've had this really robust rest api for a long time now and and also like a really robust plugin api for a long time and both And also like a really robust plugin API for a long time. And both these, I mean, they play into Figma as a whole, but also especially DevMode. And I think it's such a fun kind of visual platform

to develop for. And in many ways, it's, I mean, it's been around for a while, but I mean, it's not the iOS app store. Like there's definitely a lot of space for innovation here and a ton of like untouched um untouched ground so what kind of stuff can you build can you paint a picture for folks like give us an idea of what kind of stuff we could build yeah so i mean generally speaking the api gives you access to everything in a figma file with like high

fidelity down to like uh individual vector paths for all the drawings, images, fonts, etc. It also gives you access if you're building plugins in Figma design, gives you access to also add any design object to the canvas. In dev mode, you can't edit the canvas. Because again, this is something we heard from developers, they didn't want to accidentally edit the canvas. So we restrict plugins from editing. But in yeah, plugins in dev mode like we have again you'll have like simpler things but still really powerful like our integration with uh grn atlassian and a partnership there where you can click on any part of the design and like new issue and it'll link it together with exactly that part of the design and similar like Storybook has built an integration

so you can connect your chromatic Storybook instance to dev mode. And you can say this component in Figma is this component in my Storybook and you can like link this together. And once you've done that once, any developer going in later can run that plugin and see and interact with like the code version

of the component and the Figma component at the same time and spot differences or, you know, know the API, learn the API and so forth. So it's super powerful. We've seen plugins that allow you to export assets in like formats that like we Figma just haven't gone to supporting yet. And then there's, I think at this point

over a hundred different code gen plugins for like Tailwind, Flutter, React Native, React, like Swift react application or even like view and a couple of other frameworks for you to like get a really strong starting point, I would say on, on your development. So highly encouraged looking into these plugins, but as a developer, it's, there's just a lot you can do here. And I'm excited to just like see people innovate. I don't want to like say, these are the things you could build because honestly, like I'm excited to just like see people innovate. I don't want to like say these are the things you could build because honestly like I'm excited to see what people think about when when they kind of read up on this more and check out what's already existing but you can really do anything you want with the visual content in Figma. It's super cool. Another and that's like the plugin

API in Figma then like people are building on top the REST API, things like a designer changes a design token or we call them variables in Figma that automatically like pushes a GitHub PR to your repo with CSS versions of that definition. So if you update a color in Figma, you can accept a pull request in GitHub for that new color, which is also like super cool.

There you go. That's there now? Yeah, I mean, the REST API is there. I can't point to a specific implementation of the GitHub syncing, but I know there's some open source things there. What I asked you before is this production around dev mode. The question I really was getting there was less specifically to dev mode in particular, but more the platform of Figma.

You're eventually going to become where production happens. You're going to be experimenting in production to some degree with design even too, where it's still pull requests, it's still code changes, it's still Git-based like all workflows are it's still going to have ci in there but at some point you're literally going to be you know iterating on the exact thing that is the production artifact that's working that has ab tests and you won't have this you know dev production silo it'll just be this is what it is. I think partially. I mean, our mission with DevMed is really to help developers go from design to production as quickly as possible and with as high quality as possible. And I think the help developers there is a really important piece of it. We're really not trying to replace developers here we're really trying to help them and i think where we can go like directly right from like tool to get and like bypass the

developer is in very specific scenarios and it's the specific scenarios i think engineers hate doing which is like a color got updated in figva please update the hex code corresponding to that in code is like very like machine translatable or like this icon got a new vector in it please re-export it and reuse that thing and all the places it's already used it's like a computer should be able to do this for me right let's like find and replace with the same asset just an updated asset those are the things we're thinking about when it comes to like pipelining from design to like not production necessarily,

but to get, let's call it directly. But for everything else, we're just really trying to give developers like the support they need to go as quickly as possible while maintaining high quality from design to production. Maybe one last question on that front, we can call it a show, but when they get

to production, does this tool go away? Because if it's so influential and so transformative to get there faster, I would just want to stay there faster, more efficient, better, et cetera. It's a great question. I don't think it has to end. It does today uh or in a way it does today like i would say it doesn't end there's a gap right because i think all uh all product development is like a cycle where like it will go back and design updates will be made and those will eventually go through dev mode and reach production again but there's a gap there between kind of you know it goes to production and then dev mode stops starts being used until new designs and then starts being used again. Like you could imagine like us in the future helping you like assess your production environments, like how close it is to the designs to spot bugs maybe or spot things that should be tweaked or maybe there's a way for you to

i'm very much just spitballing on ideas here that are kind of in the back of my head but maybe there's ways for you to like on your production site maybe add a note to be like uh you know in our next redesign maybe we should fix this right things like that and that's like somehow connected back to your designs or to complete that loop. I think there's potential for interesting things there in the future. It's not something we're necessarily working on now, but like, I think it's interesting to think about

how we can really acknowledge that this is a cycle, right? And it's a cycle of iteration and not just a one-time pass. And that's really how we're thinking about all of Figma and especially dev mode all the time is like, it's not necessarily like, how can we finish the process faster? It's like, how can we squeeze out five more iteration cycles? That's how we're thinking about things, right? Because we know that like twice the iteration cycles, like twice the product quality uh twice the code quality whatever right so we're not necessarily trying to get you to finish the

project faster although you can choose to use it in that way but we're more thinking about it as like squeezing out more iteration and you can choose you know how to you can save five hours and use five hours for our duration you can can split that time however you want, right? Well, yeah, again, I appreciate you being on the mission because somebody needs to be. And this is the future because it's what's being used. The most widely adopted design tool. I know we use it internally for various different things and it's the future. So don't sleep on it.

Use it. Check it out. What's left? Anything else? And it's the future, so don't sleep on it. Use it. Check it out. What's left? Anything else? It's 2023 and we haven't talked about AI, but I feel like that's a whole thing. We should not. We should stop before we talk about it. The only thing I'll say is that I'm excited.

Can't talk about much, but there's definitely exciting things coming down. Very cool. We'll have to use that as a tease for some future content. The future. Yeah. Well, thanks, Emil. It was awesome.

It was great chatting with the both of you. Yeah, you too. Okay, let's do an unofficial poll right here at the tail end of the podcast. I want to know. Raise your hand. Hop in Slack. Go on Twitter. Wherever you want. Let us

know. Do you recall the PSD to HTML era? That's one. Are you using any CodeGen tools, literally helping you write your code or tooling like CodeGen from Figma that helps you generate your code from some sort of visual tool? That's two. And I guess last, are you using a design system? Either one you made, i.e. your team, your org, or something that was made out there in open source that you've adopted. That's three. Let us know.

Again, hop in Slack. And I said Twitter before, but I guess I meant X. My bad. Still can't get that right. And hey, by the way, we have a bonus six minutes for our Plus Plus subscribers. You can go to changelog.com slash plus plus to learn more. It's better. It is better.

Ten bucks a month. A hundred bucks a year. Directly support us. Drop the ads. Get bonus content. And I guess a little bit more love because you're closer to that cool ChangeLog medal. And that's where you want to be. Again, changelog.com slash plus plus.

Okay, one more shout out to our friends and partners at Fastly, our partners at Fly, and of course, our search partner, typesense.org. Much love. And of course, to the beat freak in residence break master cylinder for bringing those beats every single week so so good okay so it's thanksgiving one thank you so much of course we love you and two that means we're going to take the week off for change logging friends so if you're looking forward to friday look forward to next friday instead we're talking to gare gay oros have no idea what we're talking about but i'm sure we'll talk about a lot of fun stuff happening in the ever-changing dev engineering tech landscape it's crazy out there okay see you

next week