Design Systems in the Age of AI Agents

If things are not set up correctly or labeled correctly, when the AI goes to actually build with those components, there will be errors that occur or it will just backfill whatever it finds, essentially, to put in those spaces. If you were to even go through and audit that, that editing process is going to be a lot more time-consuming than making sure that all of that work is done upfront.

Welcome to Intendcraft, a product design podcast where we dig into design systems, AI in the design process, and what it really takes to scale design for software. In this episode, we talk about what makes design systems actually work in production versus what just looks good in a Figma file. We also talk about getting your system ready for AI and agentic workflows. We dig into the gaps we see when auditing design systems from token drift to Figma and code parity and explore new AI tools like Figma Make that are already changing the way product teams collaborate and prototype together. Now let's get into it. When we first engage with a company to really take a look at their design system, what is something like when we open up maybe their Figma file for the first time and we're auditing their design system that tells us maybe in that first 10 minutes or so whether they're in a healthy spot or in trouble?

Well, I think if I just receive a design system file as a Figma file, that's kind of my first red flag. I think there should be, you should have a contact person. There should be some sort of process documented, even outside of Figma for the wider organization, to understand the design system. That's the first thing I look for, not just the components itself, but the whole ecosystem that keeps it afloat, make sure that it's fresh. And that if I have any questions or if anyone on the team has any questions, there's a dedicated person for me to reach out to, contact, and yeah, just get a full understanding of how the, the whole system works.

Yeah, absolutely. Yeah. It's one of those things where if you only get a Figma library, you're like, well, you might not actually have a design system. We might just have a component library here.

Yeah.

And we need to dive in just, just a little bit deeper. I know one of the things that I think is really important now is really like seeing the drift in maybe their token system and token structure. I know we've usually can see a standard that might get set, but then you start to see little one-offs show up here that don't maybe go back into the system or the pattern that they've set up, or they'll have like special tokens set aside for some new thing that got, got added. And I know like early on, you know, you set your token structure, you set your token standards, you might not know everything. In the beginning there, but like not that really kind of shows that maybe they don't have the time to like evolve their system the way they should and kind of review that and a good maturing process. But we've seen that a little bit where there's a lot of one-off tokens here and there and they're kind of all over the place. And that's usually a big indicator that they've been moving really fast and there hasn't been a consistent process there to update that. Manage that effectively.

I think to add on a little bit, one of the, the key pieces with understanding a design system and its efficiency is that we've seen some teams come to us with just a Figma file and there's not a ton of representation of that work happening in development. And those development components are really, I think, like what unlocks a design system because then your dev team and your design team can really playing with the same Lego blocks and making sure that everyone's on the same page there. So seeing not only the Figma file for your components, your tokens in those, again, like Lego blocks that you're building with is important so that you're checking to make sure your designers are in alignment, but also interfacing with the engineering side and seeing if they have a Storybook and then kind of comparing and contrasting what those two environments look like and making sure that things are quite literally pixel perfect.

Yeah, for sure. And it's interesting too, cuz like sometimes when we audit a Storybook or we take a look at Storybook and we've had this happen to us where like you start building components in Figma that are super useful for designers, but then we never have that code parity in Storybook, or it doesn't make sense for it to exist in Storybook and you almost have to like pull back a little bit because you're like, well, if this doesn't exist in Storybook, then it probably shouldn't exist in my Figma library either. And I know that can be a, a, an issue, create a lot of drift and a lot of complications in the end when developers need to deliver specific things and they don't have access to that. Everyone's using AI stuff now, and I know AI has been driving a lot in the design system space in a lot of conversations around agentic AI, how do we implement a design system that like a human designer and maybe an AI coding agent both can use reliably? What are some things that we change with our design systems or, or think we should be changing so both of those customers can use them effectively?

I think one of the things we've been taking a look at, not only like within the design system space, but elsewhere, is just the skill files. And how we can get an agentic skill file to almost imbue the human perspective that we would apply into the skill file into that process. So I think that's really interesting and something that we've been trying out a little bit. The other piece that I think is important is making sure that things like variables, tokens, all of that can be properly ingested by the AI because if they are not set up correctly or labeled correctly, when the AI goes to actually build with those components, there will be errors that occur or it will just backfill whatever it, it finds essentially to, to put in those spaces. And that's really going to end up with, if you were to roll that out, it would give you some tech debt, but kind of if you were to even go through and audit that, that editing process is going to be a lot more time-consuming than making sure that all of that work is, is done upfront and that it's kind of like the dotting your i's and crossing your t's of setting up that process.

Yeah, absolutely. I know one thing that we've been doing right now is like thinking about how our documentation changes a little bit for the design system and, and how do we create not only a good template for, you know, designers and developers to read, but also How do we create those additional documentation bits that, that maybe an AI agent or an AI model can go through and check out? I know I've been playing with the USpec plugin or the USpec plugin, which is through the Figma Console MCP to see how it's generating documentation. And then how it's, you know, this will actually generate documentation for you, kind of like seeing how they're doing different things and different elements that they call out in there specifically. And then trying to see how that will help with some of the agentic stuff that we're doing and what are some of the differences that they've been, you know, in the way they put their documentation together from what we've normally put together. It's been okay at generating out documentation for our use. I still have to go in and correct a bunch of stuff and maybe the prompt that I'm putting in there isn't as good as it should be, but it is interesting to see how their system and their skill files go through. And unpack your design file and then read that out into documentation. And it gives me a little bit of a window of like, okay, if I needed to do an AI to ingest this, how might I document that the other way around? So it's, it was pretty cool. It was pretty easy to get set up with the Figma Console MCP and allows you to do, do quite a bit of stuff.

So Billy, I have a follow-on question with that use case. You mentioned you're prompting it and You have some thoughts around the prompt setup. What would you say are important pieces of the prompt to make sure that you're thinking about? And then kind of with your experience up to this point, is there anything you would change?

Yeah, there's so, and they kind of call this out in their documentation because you can ask it to like create anatomy and it'll go through, it'll crawl through the Figma component and it'll start to put the anatomy bits and pieces out there, but if it can't infer it from the actual component itself, it's not really gonna do a good job of catching that stuff. So you have to give it the same way if you showed somebody your design system documentation and, you know, you assume these things are, are there because we're all designers and we've done all this before and we just know how those things work. It's not gonna always know that stuff. So you have to kind of like add those additional pieces to, to the, um, to the prompt. So we do a lot of subcomponents in our components to drive structure. And so I would always have to tell it, hey, you need to at least go one level deeper when you're running your anatomy check. Um, because a lot of the properties are in that second layer, it wouldn't actually check those things out. And then where we use like replace me components, cuz we don't have, well, we have access to the slot now. I would tell it like, hey, make sure you're correlating these to a slot component in development so that even though in Figma we're calling it a replace me, we know in our Storybook it's a slot and making sure that it draws those comparisons there. So it's just trying to give it that extra bit of context that might not be inherently like discoverable on the on the page itself because it's not reading any of the documentation in your, in your Figma file. So you're kind of adding that as it's generating out the documentation.

Cool. I think that's a good way to think about it. And I think especially within the space of, you're like talking about the USpec prompt as the same space of like, if you were to give somebody who's never seen your design system before the documentation and like maybe they're new to design systems, like explaining it in that way so that the system understands the level of detail it needs to have. And I think that's even something that I've run into just prompting with other types of work that we're doing at Headway, the specificity that's inherent within the prompt. I think sometimes I've made assumptions about how much I need to say or how much I need to, or like leave out essentially. So I think that's definitely a balance that is important to Stripe is like letting the system build on its own, but also being super specific about the parts that need to be very detail-oriented.

Yeah. And I think like Sam and myself, we've been doing a lot with some of the design system work we're doing now to really ensure that everything that's in Figma is one-to-one with what's in the coded environment for obviously property names, things like that, and trying to build a good templated structure all the way through so that when we do have agentic tools running through maybe a Figma file and creating out a screen, it knows exactly what the component is, what the properties are turned on, and it can correlate those all with the developed component that it needs to, it needs to compose in that correct form. And so there's a lot of like making sure everything is exactly as close as possible to the exact same things in both environments, which sometimes can be a tricky cuz sometimes you can't do things in Figma that you have the freedom to do in development side.

Yeah, the property naming, that was a big kind of learning experience for us cuz yeah, like we would set things up with like, you know, within Figma where it would make sense for designers to, to pull in. But yeah, I know that being one of the things that we had to align with the dev team was to make sure that, yeah, the way we're setting those properties up and how we were naming those was, was more of a, a one-to-one to help mitigate some of that.

Awesome. This is kind of going back to a little bit, kind of the first question we had is like, so what's the difference between a design system that looks complete and one that actually works in production? And where do we normally see the gaps in one that may look complete versus one that works in production?

I think a dedicated design system team, or at least one person dedicated to maintaining the design system. Is really critical to, like, its success. Someone who's able to kind of field questions, take in new requests, be able to communicate between the development team and the designers using the design system, any issues that are coming up with their components and, and how they're trying to use them within the screens that they're trying to solve. That's kind of the key for me of that collaboration piece, making sure that there's someone there to make sure that things are being communicated both ways. And it can include dedicated Slack channels, making sure that they're being managed properly. Any changes that are coming from the design system are being communicated to the team, or open office hours, places where folks can go and, and ask questions. Those are kind of the pieces that need to be in place to make sure that it's, it's successful and, and being used properly.

Yeah, it's one of those things where at least the most success we've had is if, if everyone assumes somebody is doing it, that probably means nobody's doing it. So having somebody dedicated to, to kind of tackling that and, and making sure that it, all the things are happening in the correct, the correct ways, or at least there to facilitate that process, this is gonna be more successful than sort of this abstract who's doing this? I don't know. Maybe it's Jeff.

Today's episode is brought to you by Headway. Do you need to design and build a world-class user experience for your software, but feeling like you just can't get there on your own? That's where Headway comes in. We're the folks who help ambitious startups and enterprise teams bring their product ideas to life through design, development, and product strategy. We don't just give you user interface designs. And leave you to figure out the rest. We work with you and your target customers to create beautiful user experiences, build scalable design systems, and provide Silicon Valley-level talent to get it done right the first time. Whether you're launching a new software or just looking to add features, we've got your back. We've worked with startups in industries like logistics, healthcare, fintech, and edtech, helping them solve their biggest software challenges. And here's the thing. No matter how complex your product is, we can help you gain clarity and get the job done together. We're so confident that we'll be the right fit that we offer a 50% money-back guarantee if you don't think we're working out within the first 45 days. Ready to see how we can help you and your team? Just head over to headway.io and book a free consultation today.

I have a follow on for you guys with regard to like having that dedicated person. So like imagine you were a new design leader at an organization and you don't have a dedicated design system hire. What is the best way to handle that if you have just a team of designers, but you have a design system? Like how, how would you go about like breaking out that work?

Yeah, I think the thing there, and we see this a lot. In the design system space is even as a small startup that maybe only has like a design team of 2 or 3 people, like they're still building a design system. You know, it might be small. It might just have a tiny bit of components and functionality. It could be mostly in the design area, maybe not quite in dev yet. Maybe they're building on top of a library already. They're already doing those things. So I think finding that person who's eager to do that and just know that they're not going to get everything done all the time. As fast as we might expect them, but that help maintain that system because the system really is becoming the linchpin for everything, right? AI's generating more code and we don't want things to drift from the brand and we want things to make sure they stay in aligned with our patterns and things that we've established. Like we need to have that stuff ironed out, otherwise we're gonna start to get that design system drift to happen. And so having an individual who's doing some of it, Maybe not doing it to a full depth of a whole team dedicated to it, but I think some of it is gonna be better than nobody doing any of it. And I think a lot of designers are, enjoy doing that work and they enjoy having that reusable library of stuff when they're doing their work. And I, devs, I believe too, are eager to do that work.

Yeah, it's about carving time. So whether that's quarterly, if you're a small team and you have lots of irons in the fire, making sure that you carve out that time to take a look at your design system, check that it's healthy, that any updates that have come through Figma are kind of being used to its fullest potential, making sure that you are getting what you already invested in starting to, to build it together. Kind of lose all that great work, all that groundwork that you've set when you set it up. If you're not constantly going back, maintaining it, making sure that it's healthy and actually being used properly within your team.

Yeah. And I think on the flip side of that, I know we talked a little bit about like smaller teams. I think on the flip side of that, for like teams with 10 or more designers maybe living and breathing across multiple products, there's a different challenge for how do we build a system that scales for teams that large? Or larger, that doesn't become a bottleneck for them. You might have the resources to build everything that you need, but then it's like, how do we manage that governance and how do we manage those teams so we can effectively deliver what, what's needed for them? I think one of the biggest things that we've dealt with those bigger teams is thinking through, like, you get a lot of requests, you get a lot of component requests, a lot of products. Maybe multi-brand, a lot of changes that need to come in, really leaning into like an effective contribution model is very helpful. And really understanding like what are the different layers of contribution to the design system. I think everyone has this like gold star vision that contribution is I designed a thing, built the thing, and committed it all the way through the system. But not every team has the time to do that. And so I think contribution for one team could be, here's a mockup of what we would like, and here's some documentation written up on, on what we think we would need this to do for their specific product. And they're not going to have time to maybe do the end-to-end testing and everything for that. And then other teams, it might be like, hey, here's a first draft at a coded component, can you guys bring it to the end? And then teams that do have a little bit more time and availability, you know, they could really flesh something out and push a PR all the way through the system that our— that design system team maybe reviews.

Yeah, I have a little bit of personal experience in our, our last engagement of being on a smaller team that was using a larger design system. We were building for, for iPad, which is very unique, has its own kind of quirks that not all, every larger design system takes into account. So what we did to kind of help keep us agile was create a product library, very much informed by the larger design system to put together those smaller pieces of screens. And then once we found something or a pattern that really worked for us, having that communication back to the larger design system team. And seeing if that's something that can be incorporated into the larger design system. So not being afraid to peel away in a sense, but you don't want to be siloed. So having those, like I mentioned, touch points, those channels, that dedicated person to have constant communication back, um, that we've uncovered something and, and we want to contribute back to the design system for the wider team to use, but still being flexible enough that we can kind of go ahead and and build something on our own.

Yeah. And I think for those teams, just that, that contribution model is so important. And we always, we always have those like huge, ultra huge diagrams of what contribution looks like. And it's got a million layers and a million loops. And on one engagement, someone had asked us like, just give it to me simple. Give me the simplest, rawest form of contribution, what that looks like. We did put this diagram together that we were like, oh, it's maybe like the 4 Ds of design system contribution, right? So like, how do we empower teams to make decisions? Does it belong in the system? Does it not? Like, can they design that thing out for us? Then development, like, are we building it? It's gonna get kicked off from the backlog. It's gonna take a little time for us to get to it. Can it be faster? Well, yeah, it can be faster. but then your team maybe builds that out. And then the slowest part for a lot of us is like the documentation parts. And that's one thing where I'm kind of eager with some of this AI documentation thing. How do we speed that up a little bit? Because we try not to release anything without having the design and dev hand in hand with all the documentation, as many of the edge cases covered, because we've had bad experiences releasing things too early. Then things get outta sync or issues that we just didn't consider come up and then we got to patch things and, and that always becomes kind of a nightmare.

I think that's important to strike a balance between like too many cooks in the kitchen type of situation, but also allowing people to contribute that want to contribute, but having a process around it. At the same time, that balance is between your hitting those important deadlines and then understanding when it's important to add something to the backlog and it's like not the right time to actually do the work to get that component into the system.

And I'm really eager to see, like, we've been talking a lot about how can we automate all the checks and balances through building out components. Like, um, how can we essentially create a design system linting tool that can check through a component to make sure it has all the bits and pieces that we need in the design space? You know, how can we check to make sure that we've covered all the documentation bits, all the accessibility documentation, are those things that we can, we can automate to help us get those things done quicker and more thoroughly. So I feel there's a lot of opportunities there and we're exploring some stuff that's, that's helping us deliver components faster and also helping people to have designs that are more compliant with the system as well. So I think all those things are beneficial to, to teams that, have these large, or large teams that are using, using systems across various projects. Anything else that we'd like larger teams or larger enterprises struggle with, with design systems that we've experienced in the past?

One thing that we've experienced, I think, with a couple of different engagements is when we have folks who have never used a design system before and an enterprise is rolling it out for the first time, or we have an existing design system that we've just stood up and we have folks who are new to design systems and they're just onboarding to the organization and making sure that there's the right processes in place so that those people don't get left behind in their functional product teams or just as individuals. I think that's really important that if you do have the fortunate situation where you have budget to have a dedicated unit that's responsible for design system, making sure that unit is running educational opportunities for either, again, if you're in the scenario where it's your organization is just adding a design system in for the first time, or you're making upgrades to it, or you have folks either on engineering or design who have just joined the team and they're not familiar with the design system. Um, setting up things like office hours so folks can go with questions, setting of learning opportunities. I know we've done almost like quizzes for folks where they'll come to sessions and learn different things and then they'll have to take like a mini assessment at the end. And it's, it's really like a, a good way to, to test that you've understood the curriculum, so to speak, and that you can then take it and apply it to like a real world scenario. So I think those pieces are really important because I think especially at the enterprise level, making the decision to invest in a design system is a really big step that does lead to a lot of efficiency, but you need to make sure that every member of the team understands that process completely in order for it to take full effect.

Yeah, for sure. It's like, it's like a way of working and, and, you know, we've been part of training teams. Sam and Melissa, do you have any experience, cuz you've been embedded with teams where we've been rolling out a design system and then you're on the, on the product team helping designers who, who might have never used a design system before. Anything that— words of wisdom that you might have for rolling out design systems to those product designers who are new to design systems?

I mean, I think it's important to really read through the documentation, see what all components have been created and their states, because I know I can fall into the, well, I'll just use a list item for absolutely everything, and maybe that's not the correct component to be using, or, you know, I'm not using the heading correctly. So going through, seeing what is available to you at the time and, and how it works within, within a screen, and just experimenting before you start putting things together is a good way to kind of get your feet wet and have a better understanding before deadlines are, are looming over your head and now you have to put something together quickly.

Yeah, absolutely. Pesky documentation.

Yeah. Yeah.

I would say it, it is interesting cuz a lot of the questions that I get, like you were saying, Melissa, just like understanding the documentation or what components are available. Some of the systems that we work on are you know, are pretty large and I think it's just the familiarity with what components to use where and, and even just like how to manage those to, to access the different variants within a component set and how to, how to get them to work for your specific use case. So yeah, a lot of it. Yeah, just going through the documentation and putting things together and, and, uh, and then having, you know, bringing in some of those questions that you might have to like the open office hours, the things that we provide to help just check those things to make sure everyone's using things properly and in, in the right way.

Yeah, absolutely. I know we've all been playing around with, uh, various new design tools that are coming out. Google Stitch is out. We've messed around with Paper and Pencil, interesting names, as different tools. We've all done a lot of Figma Make experiments and used Cursor and QuadCode, things like that. And the design tools are are really starting to leverage AI more or their natively built AI design tools. What kind of experience do y'all have having that solid design system in place with those different parts of the process with those new AI tools? And like, what are some of the impacts that we're seeing or speed and effectiveness of a designer within a team or even yourselves on some of the projects?

I like leveraging those tools for prototyping and being able to come up with something that is super accurate to what is ultimately going to be developed. I know there's workflows where you can essentially go straight into development and publish, but even just using it as a communication tool to get buy-in, to help people get on board with your vision instead of just kind of showing them some strung together JPEGs and hoping that they get it, having them be able to interact with it in a meaningful way and see how data actually interacts instead of having that lorem ipsum where we have the same kind of card in every screen and, and hoping that they understand this is going to be live and dynamic and all the cool things that it can do. You're able as a designer to bring that to life and get people to understand like what the vision is. And it wasn't super readily available, or it would be a real time suck to not leverage those, those AI tools to do that.

One thing that I'm kind of excited for is like, we've done a couple of prototypes in Figma Make, and if you got a multi-theme design system, sometimes it doesn't pick the right theme. So there's a little bit, sometimes there's some issues in there. Sometimes it, cuz it's recreating all of those components. That it's pulling in from the design system, but they now have it so you can actually pull in your own npm packages. So you're actually using the actual coded components, which is really nice. 'Cause I think that's just gonna make things go faster. You're not gonna have to like say, hey, no, please use the hover state that I originally had in there as it kind of inferred its own. Because we saw some real unlocks when we were on site with a client where we were sitting with product people. And we were able to just explore a whole bunch of ideas really quickly by having a couple Figma Make instances up and running. We're like, well, what if we did this? And what if we asked you to do this? And, and just try out all these different ideas. And, and at the end we were like, we could probably run these past customers, A/B test which one's the best one. Yeah, they don't look 100% right, but at least that'll give us a sentiment of where to go. And then we can bring it back into design and be like, okay, Now let's refine it. Let's make sure we have all the edge cases. And I think that's like a new workflow that really is like more collaborative for these larger enterprise customers where maybe it's a little less collaborative now, where it's a little bit more waterfall. Product makes a PRD, design gets to go do some design, maybe a research, then it gets handed off to dev, where now product and design can explore together and really create a PRD in the form of like a prototype that they actually validated and tested.

Yeah, I think it's kind of interesting. The tools are becoming more collaborative in the sense of the, I think previously in product design, it was very much like each segment, so product design and development all had their own lane and you just kind of had to stay in your lane, whereas now it's just like one river that everybody's swimming in together. And as a designer, you can take things in Figma and actually get code and then share it with the developer. And if all of that is backed by a product owner and you've collaborated on that as a group of those three disciplines, I think that really unlocks a lot because then you're going to skip the process of having to iterate of like, okay, product owner is going to give the brief to design and then design is going to iterate with product. And then once you reach a certain point, you're going to go over to engineering and then you're going to iterate more. But if you're able to use something like that NPM package, you can iterate a lot faster, but then you can also bring something to engineering that feels like it has legs. And they can really understand what it is. It's using the same components that they're using in Storybook. And it, again, Billy, to your point, it might not be perfect, but we're a lot closer than we were with our previous process. And I think that'll just allow for more experimentation. But there's, there's a lot of opportunity, I think, for really interesting experiences. Whereas I think now there is sort of like a tax of Lego, we can only do so much with the current process. I think AI is going to unlock a lot, a lot of opportunity with, with experimenting that we may not have had access to previously.

Yeah, absolutely. How do you guys feel about— we talk a lot about prototyping and being able to leverage, leverage prototypes. Personally, I'm really eager for this sort of future where we're kind of building UI and we're actually using the real UI components, not like the sim— I don't know, I always call it the simulation. Right? We're building a simulation so someone else can build the real thing. And I've been really interested in, in Paper and how they're really, I don't, I still think it's a little bit of code on both sides, not necessarily using the actual bits and pieces from your system, but this is kind of doing what Figma is doing with Cloud Code now, where you're able to pull in your actual screens, customize within there, and then push those back out to code. But how eager or how excited or how non-excited are all you to dive into the actual code and work on the actual interface?

I think it is both exciting and nerve-wracking. As someone who used to write HTML and CSS for a lot of my day, I don't miss it. I'm going to be honest. I do really enjoy the creative aspect of product design. However, I think that having that experience, I think knowing some code is really powerful and it does unlock this level of empowerment within the designer. And it also allows you to have better communication with your engineers, which is really important, I think, for both disciplines to speak some of the language of the other side. And the thing I can equate it to from Just like design in pa— like in the past, I guess it's like this probably going back like 15 years, maybe more is like Dreamweaver when you had like the WYSIWYG and you had the code up on one side, but then you had your actual design on the other side and you were kind of making changes or the code, but then you could see what was happening and designing in that way is very interesting. I think Dreamweaver as a product was definitely an interesting space. I used it a ton. It wasn't the best, but it was a thing. And we all used it for emails and web pages and things like that. But if we could get like a better version of that, and I don't know, like having trust in the dev side as well for us to like actually get in there and make changes and branch things and like merge it back in if it looks good and having like an auditing process for code reviews. For designers to merge things. And again, I think that unlocks a lot of speed and efficiency, but it's just like making sure that the right level of comfort is there for the designers to make the changes, but also for developers to be like, oh no, the designers are in our space, that type of a, like, level of fear. So, like, they're going to break everything. So I think there's, like, definitely a, like, communication and collaboration branch that has to happen for that to really work well. But it's definitely exciting.

Yeah, my hope is that it does make a developer's life easier and not harder. The front end is really only half the story. There's a lot happening, a lot of data that has to get sorted and understood, and a lot of connections that have to be made in order to even display an image, for example, or to display the correct data point. So if we're able to make their lives a little bit easier by caring about The roundedness of the corners that we care about. I mean, I think that's exciting to see, and exciting to like at least try. And it's the digital era, so if we don't like it, we can change it. We'll pivot, we'll find something new, we'll experiment. And I think that's what's exciting.

Yeah, I'm just, I'm eager. Like currently the workflow is, hey, we need to add a new state to this component. I'll mock it up in Figma, send it over to a developer. They might code it up. We're going to do some testing, we're going to verify together to make sure it's right, and then we're going to send it. And it would be great if I was like, hey developer, can you just make sure I didn't mess this up? And then we could just send it. I've seen a couple of folks doing that, and I think that's, that's a part where I would like to have a little bit more control. Like, yeah, I'm not going to be diving into the backend or worried about API connections or anything like that, but I definitely would like to have, hey, just let me rip out this new state real quick and we'll call it good. All right. Well, awesome everyone. Episode 2 down. Thanks for watching Intent and Craft. Wanna support the show? Subscribe and turn on notifications so you never miss an episode. You can also share it with your team or leave a rating and review to help other designers and product leaders find us. We'll see you next time.