From Figma to Claude Code and back | Gui Seiz & Alex Kern (Figma)

The energy that we've rediscovered around those spikes, where we're all just prototyping and throwing it all into the same place, momentum begets momentum. And so having the team together riffing and yes-anding and trying this stuff out is really great. This feels like pair programming for designers and engineers. And you can work very quickly back and forth using the MCP as a connector here. Oftentimes, the code base gets way ahead of where the actual design file is. And there are states or workflows that just don't exist at all within the design file. So what I can do is say, send all five states of the sign-up flow to Figma. Now what the agent's going to do is read my code base, understand what I'm referring to when I say those five states. And for each one of those, it's going to individually import that one by one into Figma, such that the Figma document will then have all of those states laid out all side by side so that my design partner can work against it. It's definitely changed our workflows in a way that it's kind of really blown up what a workflow even is. Before, for the majority of our careers, we've had a very linear, agreed-upon workflow where you increase fidelity as you go on. Because it's really expensive to work in code, and it's really cheap just to trade ideas and sketch them out. But AI basically collapsed that. And it's just as cheap to riff in code as it is to riff in design. And so a lot of times where we used to mock up these kind of grayscale wireframes to point at what things should be, we can get functional wireframes straight away. And a lot of times what we treat these kind of vibe-coded outputs is like, let me get to something that I can just is more malleable, I can play with, and then let me kind of work into it. Let me bring my team in. And we're still, like many companies right now, trying to figure out what is the best kind of step process. And to Alex's point, it depends. It really depends on the scale of the feature, whether it's a feature or a bug or product, like what are we trying to get to? We find ourselves reinventing a workflow almost every day, multiple times a day, depending on the case that we have to solve for. What I like about what you said is a couple of things. One, I do think up until this point, both design and engineering felt very scarce and expensive resources. And so you were always trying to reduce effort in design by doing things like wireframes. And I tell the young people today, they don't know how spoiled they are. You don't know what balsamic is or those old mock-ups used to be. You don't know what we used to have to do with wireframes. So I think we were always trying to figure out that. And then we were always scarcely protecting engineering resources. And part of that meant more work fell on the design team to make lots of very specific decisions about design implementation so that you didn't waste engineering's time trying to figure out is this supposed to be a rounded corner? What's the hover effect? What's the error state? All this kind of stuff. And what I do appreciate about AI is now the cost of generating really high-quality stuff has gone down, which means you can invest more in the pieces that really matter. And then more people can contribute to the ultimate experience in design. And Alex, I'm sure you feel like you can contribute more. And so I think that's an interesting change to how we had historically been doing more of a waterfall-style product development process. And to add to that, you also have more exploration capacity because you're not spending so long on one idea de-risking that one idea through meetings and prototypes, et cetera. If you can shortcut to that, you're going to explore more ideas. You have more divergence potential. And I think that's really interesting as well. I think we got to like going deep on quality. We can also go wide as well. Yeah. I find that I'm spending a lot less time doing like the mechanistic, even on the engineering side, the mechanistic, like, you know, changing of syntax and, you know, trying to thread data through different call sites and more focused on the problem-solving aspects. And I feel like that same, you know, focus on like problem-solving as opposed to the mechanical work is really what AI is enabling on engineering as well as like design teams. Awesome. Well, we're going to actually dive in and show some of this not in theory, but in practice. And we're going to see design starting in codex, which is not what I expected when I dialed into this call today that you all were going to say, Hey, we're going to start over in codex, but that's what we're going to do. So do you want to share your screen and show us what I'm going to call the sandwich of code, which is going to be code design code, I think is the process. Love it. Yeah. Let's do it. So, yeah, we thought we'd start with codex because we've just recently launched this as well. We had a launch for Claude. We've just launched on codex and we're bringing this kind of MCP functionality to a bunch of stuff. Let me see if I can just go open my localhost for this project. Something that happens a lot is uh the sources of truth diverge between design and code. So sometimes some things only really exist in a state in code, uh, or you start working with a developer and you really like elevate what the thing was, the artifact that you originally supplied. Or sometimes like that just doesn't exist in code. You've inherited someone else's project from forever, forever ago. And so what's really interesting here is that I can just open up a local page. So, so now we've been working on as a, as a demo app, Alex and I put something together just to show you the power of this. Let's imagine I am working on a thing that there isn't really a coherent source of truth for. It's just a financial tracking app. And I really want to do some editing in here. And the, the case that usually comes up is that, yes, I could prompt it for these things, but it's kind of a, a wish and a hope that it gets it, or I have to be super specific, or I have to do install a bunch of tools that help me kind of manipulate closer to the material. But what I really want to do here is just ask codex to send the budget allocation page to Figma. Got it. So what, what we're seeing here, and I think the problem we were setting up, which I can empathize with, which is no one ever keeps their Figma up to date with what's the latest in prod. And prod rarely has the hopes and dreams of what has been designed in Figma. And you know, a lot of times, even I do this at Chatopurity, we've created like a Figma page with a bunch of screenshots and they always go out of date. And so even for using recent designs in things like marketing assets, not even just the software development process. It's really hard to keep these things in sync because code and design are moving in parallel tracks and there's not a common substrate between them yet, I would say that can keep them sort of up to date on both sides. Exactly. Exactly. That's exactly right. Great. So then what you're using here, if I can, if I tell me if I'm wrong, which is you have the Figma MCP connected to codex. So that's a hosted MCP that you've connected. Do you have the Figma skill also installed here in codex? Because I know codex has made a big deal about skills. And so I'm wondering if you're using those two together. Honestly, at some point I installed all the skills. So I have no doubt that at some point I'm using it. We also have, uh, you know, we're, yeah, we're, we're exploring kind of how we improve those. Alex can talk more to those for sure. Yeah, you can use the skills in order to do this, but you could also just ask the MCP directly and it seems to pretty reliably get you to a. You got a Claire vote. Ooh, uh, this is really good. So if you actually, I mean, if you look at the, the page and you look at the comparison kind of side by side, now I have all of this in Figma. And so not only can I do more intense kind of direct manipulation, I can go in here and I can like move stuff around in a way that's much more freeform that perhaps I would have had to like really express with words and it should be really burdensome and laborious to explain which bits I want to move where and et cetera. But my whole team can also jump in and now we can just exponentially scale this work versus me solo having to do everything. And when you work in a team, it's like really helpful to leverage that. So for those that are listening and maybe not watching the screen share, what we just saw is taking a locally hosted web app and code base, and then using the Figma MCP to then pull the whole design of a page or component into Figma, into a frame. And then you can just edit that frame. And a benefit that I didn't really think about, which is really useful is it's really, you know, Figma is really built for multi-person collaboration, multiplayer collaboration in a way that prompting code in something like a codex or a cursor or cloud code really isn't built for. And so that broad exploration is very, very hard to do. The other thing that I want to say for people is, look, I, I'm a true believer every designer should be in, in their IDE plan with GitHub, all that kind of stuff. And also there are some orgs that just to get like a pixel-perfect version of whatever somebody had mocked up. And I mean, we didn't even have Figma that I was doing things. I was making Photoshop PSDs for the real olds out there. And just the ability to, like, pull in what's the size of this? How's it supposed to look? What's the alignment? All through just typing still to this day blows my mind out. So I'm curious how this has just changed your relationship with what your job is as a software engineer. I know you said, like, the mechanistic pieces have gone away, but what does this do for you from like a time, like how you spend your time perspective? Yeah, I mean, I spend quite a lot of my time just sitting here inside of my terminal now. I do so much less. I think of the, like, what I used to have to do where I had to have a browser window open at the same time as having my code window open. There are times where I need to check those types of, you know, product-oriented flows, but there's actually quite a few changes, especially when they're kind of mechanistic in nature like this, where I don't even necessarily have to have, you know, the visual in order to get the work done. So I often have two, three, up to five, maybe, Claude code instances running all at the same time, working on different aspects of the work that I'm tracking. So some of them might be doing things that are just reconciling the design file with the code base, but other ones might be working on exploratory things, answering questions that I have about the code base, writing specs and documentation that we've talked about in a little bit, and kind of my workflow around grounding technical specifications inside of code bases. I'm just going to allow Claude to progress here. So it was able to find what those differences were between the design file and the code base. And it's actually going ahead and applying them. And what's amazing to me, and I think people don't articulate enough about, let's call it a multimodal AI or, you know, computer vision, all this stuff is it doesn't have to be you dragging a PNG of the file into Claude Code, it reading that through a vision model and then making some inferences about it and designing it. You're actually doing this like sort of pseudo structured data to pseudo structured data translation through the MCP, which has to have much higher accuracy, but it's translating functionally visual information, which I think is just so nifty. I love it. Has this changed kind of your mental model of what does, I mean, I think Figma in general has pushed forward everybody's mental model of like how you encode design into data. But I'm curious, how are you all evolving your thinking when you have all these multimodal models at your fingertips, when you can do kind of structured data to other structure data translations? Has that inspired any ideas internally about what the future of design looks like? What's really interesting about like our role with all of this is kind of really moved upstream. And we're in this really, I find it almost decadent moment in time where before we'd have to be so conditioned on really sharp product decision-making skill that would have to happen like almost immediately and being able to like quickly reason with stuff and quickly get to really good craft because the bulk of the time was spent building. And so the longer you ate into that, the more P0s became P1s and P2s. And so now we're kind of actually at this point where more of the priorities can make it above the cut line. And also we can spend a lot more time in the planning stage. You asked me like, does it start with design or with code? Actually, I start a lot of it with planning and just like really riffing and allowing myself and indulging in the possibilities and then kind of riffing in something that, you know, if I need it to be something that can only exist in code, it'll be code. If otherwise I will diverge in design. But I see design as much more at this kind of like, what should we be building stage of the conversation, which we were before, but it was like a very rushed moment there. And now we can spend a lot more time in it because we know that actually the building will happen a lot quicker. And so we do that. And then on the other side, we spend a lot more time in the craft because we can, because we can reach higher for ideas because before we're like, well, I don't know, hopefully an engineer will get my intention. Now I can spend a lot, a lot longer in that moment. I love that you call this a decadent moment because it was two years ago at Config, actually, I gave a talk on the future of product management. And I said, this is the era of yes. Like this idea of the cut line has to disappear. And how many planning meetings have we all been in where we look at a design and an engineer goes, oh, well, that's just going to add scope. Like we got to cut scope. Or we look at a priority planning meeting and we say, oh, that little fix that everybody hates in our app. I know that everybody hates it, but it's not a P0 priority, so it's got to, you know, go, go next year. And I do think this idea that you can really have an abundance, a feature level abundance mindset is, and the craft level abundance mindset where you can put the polish and all the things that make these experiences nice are one of the benefits of working with AI right now. So it's done here. It's applied the patch. And now you can actually see that the app has been updated. And it looks exactly like what the Figma design looked like, but has been applied entirely within code. And so the benefit we got here, just to reiterate for folks that are not watching, is taking an existing app that had drifted very far from the original file in Figma. Happens to the best of us. We programmatically pulled it into Figma. We used our beautiful, fine-tuned, opposable thumbs and fingers to actually drag and create the perfect design that we wanted in Figma. And then that's very easily pulled in by an engineer like Alex. Claude code, whatever your code is, built the code, didn't even look. I mean, you did look, but like didn't have to look at the design. And now it can be deployed pixel perfect. Everybody's happy. That's how it works. That's how it works. Okay, now we're just hitting the rubber wall and we're going the other direction. So you're going to show me how we can start with no design, go from Claude code into a design, and then I'm presuming back to Codex. And this episode is just going to be a ping pong back and forth. So Alex, how would you, as a engineer, no design setup, actually start designing something in Figma? Oftentimes, like the code base gets way ahead of where the actual design file is and there are states or workflows that just don't exist at all within the design file. And I want to show you a little demo of like how you can actually take all of those states that don't exist within your design file, but exist within your code base, bring them into a Figma design file so that your design collaborators can work directly off of those. Here, I've been working on a signup flow for a new app that I've been working on. And there's a few different states of the signup flow, but not all of those states exist within my design file. And so what I can do is say, send all five states of the signup flow to Figma. Now the agent's going to do is read my code base, understand what I'm referring to when I say those five states. And for each one of those, it's going to individually import that one by one into Figma, such that the Figma document will then have all of those states laid out all side-by-side so that Guy, my design partner, can work against it. Yeah, again, I'm just going to go back to how it was before. And I'm having flashbacks to these design packages that I used to send over to engineering where every single error state, every bit of copy, every this slash is yellow, this slash is red, this has orange, this is the hover state, was documented, designed, lovingly crafted pixel by pixel. And the ability here, again, I think for a designer, even to say like, can you remind me what happens when you have a correct email, but an incorrect password on this sign-in flow? And like, what is our error state without having to go into the code and without having to replicate that in production is pretty powerful. And then you layer on top of that, oh, cool, it's actually in a Figma component. So I can go in and edit it. It's not just a screenshot is quite nice. And so right here, is this in Figma? These are all the browser windows that I'd opened up, but here is now the Figma document that has all of those states laid out side by side. And you can see that each one of them was imported as part of this like exact flow all into the same Figma file. And I can now send this link over to my design partner so that while I'm working on my side of the code base, they can actually get started on riffing on this, experimenting with different colors, patterns, et cetera, all while I'm doing my normal development work. This feels like pair programming for designers and engineers together. It's such an interesting new way, you know, Guy, as you said at the beginning, like a new workflow to think about where you're both in different expressions of the same part of the app. And you can work very quickly back and forth using the MCP as a connector here. Do you find yourself doing more inside of my repository or it commits credentials or things like that. But I use this skill pretty much all the time in my dev loop as a way, once I've like hit a good state where I think that this is ready to go and should be like, you know, pushed to our repository, I do slash ship and then walk away from my laptop and it usually takes it from there. So one thing I want to call out, this is giving me such inspiration, which is every engineering org that I've ever run has an internal wiki that has that page, which is, this is what you do before you push a PR and you get in everybody's way in the deploy pipeline. And every engineering team should go through their onboarding wiki and pull every page out, every, this is what you should do into a skill and then give access to that to their entire team. And so I think we're really shifted from this idea of like an SOP into a skill or a doc into a skill. And I know so many folks that have this buried in GitHub, in Confluence, and you can just give somebody the job for a week to take all that stuff and make it a skill, push it in your repo and then let everybody benefit from a systematic way to roll out those best practices. Absolutely. Yeah. Awesome. It turns like a lot of these like processes that would otherwise just be, you know, based on best intentions and whenever people remember into something that can be fully automated and brought into people's workflows by default. Amazing. Okay, well, this has been great. Just to recap what we saw, we saw Codex to Figma to Claude code to Figma, basically just calling out, you don't have to think about your designs as a static asset anymore. You don't have to think about building components in code only or in design only. These things can interact together. Calling out the benefits of just being able to touch the design with your cursor and collaborate live with your colleagues and then encoding some of your best practices into things like skills, encoding some of your capabilities into things like MTPs. So then everybody can access stuff. So I'm going to ask you a couple lightning round questions. You both have to answer their clear rules. So you cannot say it depends. I'm going to start with the one that I started this episode with, with which is Guy, code first or design first. If you had to pick one. Design first. I love it. And Alex. I'd probably pick code first and I think that makes me. Breaking the mold here. And this is why Figma had to make this MCV because there will never be, never be agreement here. You know, my second question for you all, and Guy, I'm interested in your opinion, is are there any things around AI, not let's put software and, you know, design systems, all this stuff aside, that you're really excited about as a creative, as a designer, that you hope people are going to start using more talking about more. Honestly, it's just been a, a. Like a platform for me to just learn more about something that I was always curious about, and I hope the people like see the educational and the upskilling aspect of it and not just outsourcing any potential capability because it happens across everything. Anything you wanted to get a little bit deeper on, you can now do it without having to troll through links. Like it just, it's just there at whatever moment you need it. And I think I've been diving deep into getting deeper into shaders, which before was just pure mathematics that I had no business playing in. And now it's like, oh wait, I can talk about it in natural language and I can learn more about the specifics that I want to learn about. Alex, what about you? Yeah, I, I mean, I love going really deep. We have a massive code base at Figma. And so I love asking all of the like crazy questions that I had always like wondered about. We have an internal service, for example, that I didn't know the origin of its name. And so I asked Claude to go and figure out based on the commit history what the origin was and it came back with a really good story about like how that came to be. It got renamed multiple times that, you know, contributor has since left the company many years ago. So this was kind of lost in the ether. But now, now all of this lore, honestly, from the company is actually like embedded inside of the code base and I can, I can find it now. I'm going to bridge both of your excitement, which is, I think it's such a fun thing to learn by querying open source libraries. And so the example of this recently is, you know, OpenClaw, now named OpenClaw, came out and everybody's like so mystified. They're like, it's working overnight and it's doing all this stuff for me. And I was like, I'm just going to go into this thing and figure out how it's architected and how it actually does the thing it does. And it was such an interesting learning experience just to decompose how you would design an agent and what were some of the kind of new things that it had built. And so that's another thing that I recommend either going deep in your own code base or going deep in an open source code base to learn something is something that was so inaccessible before. And now you can do basically on any open source library out there, which I think is really cool. Okay, last question. Alex, I'm going to start with you first because you, you know, we had a tiny bit of friction with Claude code. I saw you sweat a little bit. When AI is not replying how you want, it's not doing what you want, what is your prompting technique? Do you like just slash clear and kill it? Like what do you do? That that can work, but I find that the more successful one is, is, it's either cursing a little bit in the prompt. I, I, you know, I'm somewhat ashamed to admit that that's extremely effective, but the more common one I use now is that my boss is mad at me and it seems to work pretty well. It, it kind of sympathizes with you and it's, it's, it's kind of cute. You know, I sometimes say about this, about parenting. I tell my kids, I only yell at you because it works. Like, look, I don't want to yell at you, but sometimes it's the only thing that you guys listen to. Guy, what about, what about you? Are you also, do you also? I have to take the gentle parenting route. I'm terrified of the robots taking over and reading through my prompt history. I'm still on the make no mistakes camp. Oh make, make no mistakes. I am very polite. I, I kind of go with like, no, like I sound really like sad. I'm like, no. Or I do sort of growth mindset parenting where I say, I believe you can do it and I believe you're capable of solving this problem. You just apply yourself. You can do all things. Alex, Guy, this was so great. Where can we find you both and how can we be helpful to you? You can find me on X. I'm on X as KernIO. Amazing. And you can find me on any social media platform as Guy Seiz, G-U-I-S-E-I-Z and just generally if you at Figma, chances are I'll probably be reading it. Amazing. Well, it was so great to have you. I am so excited. I've got, I've been very inspired about how we can manage our YouTube thumbnails through code and Figma. So I'm going to go experiment with that. And I appreciate you all joining How AI. Thank you for having us. Thanks so much for watching. If you enjoyed the show, please like and subscribe here on YouTube or even better, leave us a comment with your thoughts. You can also find this podcast on Apple Podcasts, Spotify, or your favorite podcast app. Please consider leaving us a rating and review, which will help others find the show. You can see all our episodes and learn more about the show at HowIAIPod.com. See you next time.