How to Build an AI-Ready Design System (Figma MCP + Claude Code)

Who are we? So we're Headway. We build AI-ready design systems, launch new products, and modernize legacy products, uh, really end-to-end. So strategy, design, development. And I always tell people when we talk about Headway, we're very much business and problem focused in that even in the early days of design systems, like nobody wanted to create another button, right? Nobody got excited about doing UI work over and over again and recreating the wheel. And so we just kind of stumbled into it as we moved I would say later stage Sketch into Figma. That started, you know, opening up with components and libraries and design systems and that sort of thing. And really over the years, you know, we turn 11 here in September, which is really wild to think about that it's been that long. But we have hundreds of thousands of people using our templates, training, and courses. If you haven't seen those, those are on Figma, those are on our website, and really love to share what we're learning and have those sort of conversations. And we've launched over 150 products in that time. And one of the things that I'm most proud of here, really, as the, the CEO and partner— I mean, I used to be more hands-on in design with Billy and team— but that 90% of our clients return and continue. So when we start working with them, they really start to see the value, and, you know, we help them do big things. And so that's probably one of them, one of the things that I'm most excited about. But really really eager to kind of dig into more of what that looks like. And, you know, from our perspective, we worked a lot in early stage when it comes to innovation teams, but then also large-scale enterprise where we're rolling out these systems across lots of teams. So with that, I'll really move it into introductions for the team. So I'll pass it over to Tim and he'll tell you a little bit more about his role.

Yeah, yeah. Thanks, Andrew. Thanks everybody for tuning in today. So yeah, I'm Tim Greenmore. I've been with Headway for a few years now and been able to work across a variety of projects and industries and technologies. And it's good to be able to talk about design systems because I've been working in projects that have been without a design system and those that are with a design system, and there's a pretty distinct difference in the quality and velocity of the product development when there's a design system present. So it's nice to be able to talk about now design systems with the help of an agent and be able to share a bit about what we've learned from an engineering perspective. We'll get into that in a bit here, but we'll start more from the design side, and I'll pass over to Billy for his intro.

Yeah, thank you, Tim. Uh, name is Billy Sweetman, head of design here at Headway. I've been doing design system work for, for quite a bit even way back when we used to do smart objects in Adobe Photoshop, uh, and it was kind of a nightmare to manage. Uh, so excited to talk about the evolution of design systems. Um, really it's cool to see that we have a lot of folks who are early on in their design system journey or doing rebuilds. Uh, I think that's a really cool angle, and a lot of this stuff you can get into the ground level, uh, that we'll kind of chat through. Like we said, the focus is really for teams to prepare to help their design system thrive in this new agentic workflow, uh, that's being kind of applied throughout the industry all over the place. Um, and really the audience here, like I said, I'm gonna talk a little bit about things that we're doing on the design side, uh, and on sort of the design system management side, and then we'll dive into the dev bit as well and talk a little bit about dev stuff. So, uh, should be some good stuff for everybody. Uh, the first thing that we're going to talk about is like, why does this matter now? Um, and this might be old news for just about everyone, but you know, AI is really revolutionizing how digital products are being designed and built. Uh, things are moving faster, being able to generate code screens and then flows at increased rate. Um, spending a lot of time prompting things and, uh, reprompting things and waiting for things to kind of finish and then getting in there in the little minutia, uh, and that really makes the product quality and clarity becomes like the bottleneck now. Time to deliver is, is shrunk, and so the quality and clarity, if that's not good, that's removing all our productivity gains, right? And the tools are changing, frankly, very quickly, right? AI models, uh, continue to evolve, but we really need to establish patterns that are sort of tool or AI model or service provider agnostic so we can ensure continued future success. We don't want to build something that's only going to work one way and then all of a sudden we have a new model show up and then now everything kind of implodes on us. With this acceleration, like we said, it's— our output is increased dramatically. But, you know, if our systems don't have the strong definitions, it can start to cause drift, and we can see that in our products, right? The AI compounding the amount of output, but as it starts to drift, hallucinate, grab the wrong thing, and then it'll start referencing that, and then we start to create these like bigger problems at the end. And it's even worse if we have multiple products that are being built at the same time, so that's even another multiplier of drift that can happen. So we need to make sure that our design systems, which this has been true from design systems from the get-go, but they still need to be able to reinforce those brand standards through consistency across all of our screens and products that we're delivering, right? We need to improve that efficiency through reuse. We need to align our design and engineering teams still, especially as those roles get a little bit muddier and folks are building out, designers are helping deliver front-end code, engineers are also helping deliver mockups, things like that. Product owners are delivering mockups as well. And we need to continue to reduce decision fatigue, right? And really support that scale across the teams. And that's where we get into, you know, becoming agent-ready and make sure our design system thrives in that space. We can see some of the pain points already that are manifesting with clients of ours and other design system practitioners that we've talked to. As agentic adoption is happening, right? We might have teams that are bypassing AI because, or bypassing the design system because AI is fast at reproducing things that look like it's part of the design system. They might not even know either, right? If they're not a developer or have a development background, they might not know that what they're seeing on the screen isn't part of the design system, right? We start to see product patterns diverge. Because the design system isn't being referenced, right? We might be seeing documentation that's not being used in the workflow or referenced in the workflow, so things might be forgotten, decisions might no longer be referenced as we go through. We might have new tools that are being used to ship products, like I said before, that are not representing the brand well because it looks close, but it's not exactly what we want. And then the productivity is not being demonstrated in the roadmaps with these enhanced capabilities because we end up doing a lot of rework or a lot of sort of a big push at the end as we're delivering things. So now design systems need to support humans and machines, right? That's the thing that we, we need to do. It's not that design systems don't matter more. In fact, they probably matter more now than anything else. We just need to add more context to our design system so machines and AI agents can reference them and use them efficiently. Um, some of this is our composition libraries and docs might be too interpretive and they're not clearly laid out in a way that's efficient for an AI agent to look at it. Um, right, we might have a lack of naming rules or composition logic. Um, a lot of context, uh, gets sort of maintained in the heads of the team because they've built multiple, multiple flows, multiple product features, and they understand that and they remember that. But the agent has no context of that, so it might make up new things and doesn't know what to do, right? Uh, it might not be delivering what developers need, uh, where they're at. So we might not be delivering the right, uh, components or the right tokens right in their environment. Which may cause them to bypass the system or use something else. And traditionally, a designer or developer, especially developer, could pick up the slack if a designer delivered something that maybe was close enough, but didn't necessarily use every single token that should be there, or didn't use every color value that's in the system. A developer could then pick up the slack and kind of correct that as you're going through. And then the visual models are still very interpretive, right? So the visual models might struggle with some of the details in a screen mockup, especially if it's a static screen, we're not— if you're not giving it an actual Figma frame, they have a hard time kind of pulling out that, that information. So this is all stuff that we need to sort of clearly identify and fix in our design system so our agents have a better job of going through that. And so for us, the big thing is kind of understanding where is your design system today and where do we fit in that path, right? Might be early on and sort of have this ad hoc file. Might, you know, we might have a Figma file, things are being copied and pasted out of it. We kind of maybe have a catalog, this is like level 2, where we do have a library exists, the components aren't necessarily composable, we might have some tokens, code might be disconnected. Or we're kind of in the level 3 area where we're structured, we're having Figma and code alignment, maybe we're using Code Connect, token architecture is in place, we might have some governance, so humans are shipping consistently. Then level 4 is like validated, right? We have rules, rules that fail CI, not just reviews. We have schema-driven documentation, and here we're starting to have agents produce usable output. And if there is drift, it's being caught early. And then we really want to get into the agentic space, right? We want AI to produce shippable UI, humans to review exceptions, and we want to see that increased feature velocity in our workflows. One of the things that we did for teams, and this will be included in the emails, we kind of put a little checklist together so you guys can self-audit and kind of see where you are with your system and give you some of these steps to enhance that. But most teams, and I think specifically in the case today, identifying this level 2 space where they're starting to get their system going, they're starting to build some of that infrastructure in, or they're in that level 3 and they're starting to lean into the more structured side of things. So we, like I said, we'll email this out with the follow-up email, but this is a kind of a summary of things that you might be experiencing, things that you can do to move into the next level, in your design system, and specific callouts on things that you want to start to think about and implement to start leading you into that agentic system. Now, a lot of this stuff that AI— to build our system to be more agentic and more usable by AI, it's really going to touch every layer of our design system. You know, we might think of it as one little part that needs to be enhanced or be used, but there's like multiple areas of the design system that, that need to be adjusted, right? We might have some additional tooling like a Design MD file that's going to help make sure that our brand is consistent, a single source of truth of values for generative tools and for maybe our coded design library. We're going to maybe have a linter or an MCP server to help finalize and make sure that a design system is using all the right pieces, whether that is something that's checking, before a PR is merged in, or also in Figma. I know Figma just released their design checker tool, which is a really good way for designers to make sure that their Figma files are using all the components, um, and using all the tokens they could. Um, things like Agents MD file to help direct you when to use the MCP and things like that, right? So there's different tools that are gonna be implemented or adjusted or modified at every sort of layer of the design system here. One of the things that we leverage to really start— that's on the design side— on how to build out our components to be more helpful for agents is this agent-ready audit framework. And so this helps us build a roadmap to really evolve our system and take a look— it takes a look through our composition library, which most of the time is Figma, so it is here towards Figma, um, in Storybook. And we go through and we review things like, uh, what do the tokens look like? What does our semantic layers look like? Uh, do we have opinions in there? Are things structured? Uh, do we have, um, composition rules? Um, so we'll kind of go into each one of those and then we'll kind of show you an example of what that output looks like. And this is a skill file that we're putting together that we're gonna, uh, email out as well. So you guys could run this in, in your Figma libraries and in your Storybooks, uh, and get some of that information. Right, so one of the things we check off right away is, you know, pretty straightforward, but do our components use tokenized values for every color, spacing, type, radius decision? Are those tokens tiered in a primitive to component level? Are there any, uh, unique nuances there? Um, are we making sure that those are also semantically named? Uh, an agent doesn't do well with ambiguity, so we need to make sure that things are named in a way of how they're being used. And this goes for token styles, any variance? Are we encoding that purpose context in the states within it? We're also going to check through our composition rules. Do our components have rules, states, and conditions that trigger those states or those rules? Are there group-level behaviors that control maybe atomic components that might be nested within? We use the button group as an example. A good one here is like, does the button group have a minimum amount of buttons that are allowed to be in that group and a maximum amount clearly defined? In its definition so that when it gets used, it knows exactly when it can and can't use this. Have we put decision logic in there? You know, slots with component constraints, if we're using slots in our components, character limits declared, min and max counts, and specific nesting rules, what might be able to be nested in a slot or not. Do we have opinionated defaults? Do our components tell an agent when to use it, when not to use it? And then if it can't use it, what should it be using instead? Uh, you know, so for example, uh, do your tabs and your button group clearly define when they shouldn't be used and maybe reference each other when they use something else instead? Do we have a structured decision tree like default fallback values? Do we have conditions written logically to justify deviating from those default values? Um, are we telling an agent when it's free to make something new or, or to, to to go grasp for, uh, something else. Um, and the last one is, do our components map cleanly to our engineering patterns? Do we have the responsive rules and theme switching mechanics all clearly defined? So our audit framework takes a look at all of these aspects in our Figma components and in our Storybook components. Um, and we'll kind of show now what that kind of looks like. So like I said, uh, here we're gonna take a look at the button group. We're gonna look at the Figma component for this. Um, and when we run the, when we run the skill file, it'll grab a handful of components to look at because if we grab all of them, probably burn through all the tokens and take an entire day to do. But it gives you a good snapshot of, of things that need to be fixed on all of those. So when we ran the live audit on this, some of the things that it caught right away, it was there's no min/max character counts on anything, we had no max count of buttons inside of it, we were using reserve variable type, there's no state trigger, in here telling when it should switch to anything else. And this then helped us build out the roadmap. So we scored a 9 out of 18 in here. And then we use that to build out and kind of think through like, what are the things that we need to fix? A couple of things that we saw right off the bat is definitely making sure that we gave more information in the component configuration description. What type of component is it? What might it be called by if somebody, you know, other names in there, a little description of what it is. Some use cases for this component, dos and don'ts, things like that. And this is an agent-readable description, so we're building this out so the agent can read it. So when you're using maybe an agent inside of Figma to build something, or you're delivering your frame out to something like Claude Code, it's reading this and understands what component is being used. And then we also redefine the properties to align with our standards, and then we communicate those standards to an agent through like a design system properties.md file that has all the definitions of what those properties are, what they can and can't do, things like that. After those enhancements, we ran the live audit again. And so we defined those composition rules, we defined some trigger rules, we defined what to use instead, and we got a 7-point increase. So now with these enhanced components, we can look at increased consistent, uh, since increased consistent placement through additional tooling like maybe our MCP or pulling it in through Cloud Code and the agent picking the right component and configuring it correctly more often than if we didn't have any of these definitions or any of these details before. So I'm going to kick it over to Tim to talk a little bit about the dev side of building an agentic design system as well.

Yeah, thanks, Billy. So yeah, I just want to talk a bit about then what is the experience like for engineers? How do we leverage design systems? How do we leverage a design system in a way that is, you know, useful for an agent and in the end productive for us in our team? So So let's take a look here. There's two main ingredients that I'll use as part of this explanation. There's, there's one that you've likely heard of or, or actively have used, Figma's own MCP. And so we, we leverage Figma's MCP to help extract design specification from the design in, in Figma itself, and we give that that context, that design specification to the agent, right? And then the other part, which is, uh, which is unique, that is, is closes a pretty big gap in this overall experience, that's a custom design system MCP. And so we'll, I'll demonstrate why that second ingredient is necessary, why it's not sufficient to just use Figma's MCP here in a bit. And, um, the, the— to fast forward a little bit, one of the main reasons why Bing My MCP by itself is not sufficient is the agent is going to answer the question that it's given, but it's going to invent what it needs to. It's going to duplicate whatever it has at the ready in order to answer the question that, again, that it's been asked. And so if we ask the agent to implement a specific design, well, it's going to use a hardcoded hex value. It's going to invent prop names for your React component. It's possibly going to use the wrong component altogether in a way that would mean the resulting application is inaccessible. And so each of those very specific decisions the agent makes aesthetically will look right to you, but it— at some point it will have diverged from your design system and more importantly the brand in the organization that the design system represents. So, so the custom MCP— well, the custom MCP actually isn't enough by itself either. It's not as though we could replace just Figma MCP with our own MCP. Again, we need both, both ingredients to make this work. The custom MCP helps tell the agent, okay, don't just, don't use a plain hex value, use our design token, and the token name is background primary, for example. Don't use a hard-coded type, font family name, font size, use our heading, our main heading token from our design system, right? So there's the, the custom MCP fills the gap for the agent to tell the agent, here's what you should use from our design system. Please don't just invent or, or generate the hard-coded value that you otherwise would to fulfill the prompt. Okay, so if we dig down a bit deeper now into what does a custom MCP need to provide. Specifically, how would we architect that custom MCP to then give the agent the type of information that I'm describing? Um, we, we sort of boil it down to these 4 main tools. Like, we want to tell the agent, well, what packages does my design system UI kit provide? Um, within any one of those packages, What is the component API? How do I— the agent is going to need to know how to map the information that it gets from Figma's MCP to any one of those packages that our UI kit provides. Um, even going deeper, then we need to, after finding the component, right, how do we map specifically to the, the prop or the or the, the, the specific variant of our component. There's, there's so much knowledge baked into a single component from our design system, and each, each one of those decisions that gets baked into the component, again, the agent needs to be able to understand and properly apply. And so the last, the last, last but not least would be when I have a component in my UI kit that is meant to be used from my design specification based in Figma, when that component is being used in a way that's not the default out-of-the-box experience, I need to apply a design token in order to get that custom instance in its proper place and use within the app. The fourth tool that I just want to call out would be getting the design token. So what are the design tokens that the system provides and, and when are they to be used and what is the purpose for them. And so that custom MCP answers all of those types of questions and primarily through these 4 MCP tools.

Real quick, Tim, we had a question come in here from Justin and I'll upload it here, but have you looked at the reverse direction, generating Figma from code instead of code from Figma? It seems like a lot of these failure modes— invented props, hardcoded hex, wrong component— Come from trying to extract semantics Figma never had in the first place rather than pushing semantics you already have in code outward?

So that's a— yeah, that's a really good question. And I would say that typically your design system is going to start with— there's a schema, there's naming, there's guidelines. There's documentation, generally speaking, that exists before the UI kit. And so at the new birth of a design system, you're typically starting from design, and I'll just use Figma as the tool for that. You're starting from Figma and you're flowing into engineering, into the development of components and a UI kit. Typically that's what happens, but once you have that UI kit established, we— Billy and I and Andrew and others have been exploring what then, to your question, like what does it mean then if I want to improve this component definition that doesn't yet have representation in Figma? We've been exploring ways to empower designers to help bring some of that concept from code back into Figma. But in the end, that creates a two-way street. It creates the second of a two-way street. We haven't started, and we have— to be honest, I think we'd have a hard time imagining starting from code and then establishing the design system and all the definition with that design system in Figma. We just typically start again from design and flow into engineering, if, if that helps.

Yeah. And for, for context, Justin, you know, a lot of this, you know, is kind of these approaches really hold true inside of larger enterprise teams, product teams of 20, 30, 50, right? We also have greenfield projects that, that Tim mentioned where we still will start with the Figma design system that we've created called Shipwright. You could, you could learn more about that on the Shipwright store, but we'll start there and define it out to kit for designers to use and then push into code, but really is that foundational layer. But I would say if you're a small team of one or you have two people and one of them's design engineer or front end, I mean, you may not have to be in Figma. I think that's the discussion that's up. Up for grabs is, hey, what does the future look like, you know, a year from now? Even for small teams now, do you need Figma? Well, not really, no. So it kind of depends on where Figma sits in your workflow of approvals, of decision-making, and of product strategy. And that's kind of the core of, do we need Figma or not? Or can we go— can we create something in code and push backward? And in that case, you're probably using it a little bit different than how we're seeing teams use it in these larger contexts across multiple products or platforms or things like that. But hopefully that's, hopefully that's helpful. And there's a couple more questions here for Alexander. You have one. I think we'll get to that here. So we'll hold that for kind of after, but we'll let Tim kind of continue and then we'll pick up with the questions. So thanks for asking them. Definitely keep them coming.

Yeah. Yeah, that's good. Thanks, Andrew, for helping me catch that question. Um, and maybe just to add too, we've done a little bit of exploration with pencil.dev, like another tool. And, and I, I've done not, uh, more for exploratory work, something that, um, has been less, less important, but just how do I go from something that me as an engineer prototyped in pencil.dev, in Pencil, then move that to Figma. And it It can be done, it just again organizationally, contextually, like Andrew said, it's somewhat contingent on your circumstance as to whether or not that's necessary, but in an ideal state we would flow from design through to dev. Okay, so I just want to further illustrate what these two ingredients being Figma and a custom design system MCP, what do they give us? And so if I just used Figma's MCP, if I use this U Sports management app concept that you see in the screenshot, and I ask the agent, hey, like, you know, implement this design, it's aesthetically going to do, like, an incredible job. It's going to give me what I want, again, aesthetically. But missing from that is really my design system. If I look at the implementation on the right, I see hardcoded hex values again. I see just generic buttons and divs, text that is, is again hardcoded. So you likely get the point that it's implementing and fulfilling the request, what it's been asked to do, but it's not using my design system, and that makes for problems down the road. It creates a pretty big opportunity for drift, and maintenance is troublesome, and I'm not really getting the full implementation. It doesn't have— there's no nod to accessibility in this. There's no responsiveness in this. There's just some problems with it that my design system should otherwise answer. And so now if I have custom MCP in play in addition to Vigma MCP, I get the same, the same aesthetically accurate representation, but you can see how concise the implementation is. It's using my container from my UI kit, it's using my text element again from my UI kit, it's using button, and then it's using design tokens that are specific to my design system. I don't— there's no hardcoded hex values, there's no specific font sizes or padding or margin, right? So you, you get, you get something that is design system informed versus, versus invented in response to your prompt. Okay, so a little bit more in by way of actually making sure your agent leverages your your MCP. So your agent will have access to these two MCPs and it's going to— it's somewhat going to use them at will. It's just your agent, right? But it's going to use them in a way that it— when it needs to in order to try to answer the question. And so we want to say, agent, like, use my design system MCP under these circumstances. And so in addition to having those two MCPs enabled, adding some guidelines to your agent MD file to tell your agent, use my design system MCP under these conditions, will help form a contract. It's still not 100%, but it will help form a contract between your MCP and your agent so that it leverages that information. Now, if you don't If you didn't do this, if you skipped this step, your agent's going to start to scour your code base at times. It's going to look for ways, again, to answer the question. It's going to look for patterns, which is fine, but it's very inefficient. And in time, it's again potentially going to lead to some drift because if it finds something that is similar somewhat answers the question, but that something might not be correct, it might be a bug. Well, you don't want the agent using it, so you always— ideally, you want your agent to go to your MCP, and that's why AgentMD with some guidelines is, is an important step in this setup. So here's, here's sort of a high level how we like to think about from the engineering side, how do these pieces fit together? So we've been adopting Google's open source Design MD solution, and we have moved as much of our source of truth from Figma, and, and that is in the form of guidelines for when to use this element of the design system or that element of the design system It's in the form of design tokens and actual values that those tokens represent. There's component guidelines within the Design MD that can be leveraged. And so we've moved as much of our source of truth into Design MD as we can. And then from there, we use that Design MD to help build up our custom MCP. So the custom MCP then can reference Design MD to know what are the tokens and what are the values, etc. So that helps us again, to keep the design system in a single place as much as possible. And now when we interact with an agent, you know, those two tools, DesignMD and Custom MCP, pair well together to create the context needed for efficient development with, with an agent. And then we typically are, are developing React for the web, React Native projects, Android native, iOS native, um, like even Ruby on Rails or Phoenix and Elixir as front-end tools in their respective frameworks. We've used this stack, DesignMD Custom MCP, to help drive development in any of those frameworks and stacks. So it's helpful to see— in our experience, it's been helpful to see the effect of this setup be productive not only in web, not only in React Native, but in both serving the same client and the same product. That is, it's a productive solution for for cross-platform development. What good looks like in the, in the agentic era. What we want to do is we want to make sure that we're minimizing the amount of ambiguity. We want to lessen that. We want to set realistic goals. I'm not saying eliminate it altogether. We want to lessen the ambiguity. Want to give designers confidence that they can leverage an agent to help speed up their efforts, and not only that, but improve the quality of their efforts. Developers, again, should be able to work with an agent in a reliable way, in a predictable way. I want to make sure that AI outputs are, are again reliable. They don't just lead to us having to undo and then fix and redo, but they lead to engineers being able to verify and then ship ideally. So teams scaling without creating fragmentation, right? So how do we bring more people onto our team, or perhaps team members move from one team to another, right? There's a lot of context that comes and goes in those changes to a given team. And so this helps minimize the risk in changing the dynamics of your team. We want to provide stakeholders, leadership, right, with some metrics, some insight into how is my product team doing, what is the speed that they're operating at, how is the quality of the output they're producing, are they happy with the work they're doing, right? So we want to leadership the ability to see that this design system is actually being effectual in what it's being used to do, which is produce a better product. And so, yeah, so the system becomes a multiplier, not a maintenance burden in the end. It's beneficial to everybody, not just some.

Awesome. Thanks, Tim and Billy. Yeah, I appreciate you guys walking through that. We've got a group of questions and obviously, you know, some folks kind of talking about what they're seeing in their orgs. And I think a lot of maybe additional context for us is like a lot of what we're seeing this still be definitely a need is multi-products, multi-platform, larger teams, right? Like if you have one product, it probably looks a little bit different. You know, if you got one product, even if you have a larger team kind of servicing that across different either customers or use cases, like it probably can be chopped up a little bit different. Where we're really kind of seeing a lot of this, the need for, you know, custom MCP and things like that, we still need Figma, we still is really, you know, large enterprise context where there's still decision makers, there's still iteration, especially, you know, before things get to a production or a staging environment. But if you can, like, why, you know, everything, I always say this, like, everything to this point has been a simulation. Hey, we got really good at wireframes while we're simulating something. We got really good at high-fidelity design while we're another step in the simulation. Hey, we're getting really good at prototypes, another step in the simulation. And now really we can get to a clickable thing that looks and feels real, that maybe is also saving to a mock database or SQL or something and run those, you know, true, true simulations. So definitely caveats and it's no one-size-fits-all for sure. With that said, I guess we'll kind of hop to, to Orna here had a question. How do you implement large design systems that are divided into separate Figma files as a whole system to cloud code, for instance?

Yeah, I mean, I, I'd say our design systems, a lot of the ones that we've worked on They do get broken out into separate files, uh, especially when we start adding product-specific patterns or product team-specific patterns, um, into those. Um, and a lot of that's driven through, uh, all the Storybook definitions and making sure that all the components are, are coded out in that direction. So the Figma files become a little bit less important of where that stuff exists necessarily. Um, just as long as those definitions in, in Figma is correct and matches up with those coded libraries. And so then when we're running cloud code, and like Tim was saying, with Figma's MCP or the, uh, and the custom MCP, it's able to discern what's pulled out in that final composition frame that's being delivered, uh, and match it up with the, with what's actually being implemented in, in code. So, um, So hopefully that kind of answers your, your question there, because, um, yeah, a lot of ours are broken up into separate files and it doesn't seem to be much of an issue when we get into building in Cloud Code. Tim, I don't know if you've got any extra insights on that as well.

Yeah, um, it's in the sense that Figma's MCP will use whatever link you— whatever frame link you send it. So as long as you— your account has access to the file, well The agent's going to be able to get at that. But I think it's— yeah, it's probably more of a design question. Like, how do I organize my Figma files in a way that can be more maintainable? And I think, Billy, what we've come up with in having those design tokens, those variables central in a file and then bringing them into product files has proven to be scalable and maintainable.

Yeah, and it's, and it's been nice even on our internal team. We've been having even some of the designers build out the components themselves. So as they might build a new component definition inside of a Figma file for a specific product, but then they're also building out the coded definition as well and running through that workflow as well. So it's a little bit easier on the governance side too. So it doesn't have to be a single team managing all of that. So as folks need things, they can build those out and make sure they define all that correctly, and then they can publish the live component as well.

Awesome, thanks. Hopefully that was helpful. Orna, if you have more details or context to share, specifics, definitely drop those in there or, or reach out and we can chat some more. Another one here from Corey, Vickery. Any visual examples you can share, like we did X things to improve Y thing and here are the Z results value, maybe before and after. Maybe you joined late. We kind of went through a couple design examples. So this recording will be up, Corey, for, for some of that. And those are, I think, good, a good test. So we did a before and after of what happened in the Figma file to the components that were designed there. And then Tim kind of shared a little bit more about the difference between using just Figma MCP and a custom MCP that adds in the context of the codebase and variables and all of those things. And if you did see those already, drop a comment in here if there's others. I don't know if there's any we could pull up right now and share from any of the enterprise projects we're working on. But—

well, and I think the funny thing is, is a lot of the stuff that we're— know, or that we've experienced is like The documentation is really the thing that's probably the most important. So even in that update to that button group, we didn't actually do anything visually to the component itself. It was all documentation, how to use it, when to use it, property alignment, things like that. And that's the, that's the, the crux that made it usable.

Hopefully that was helpful, Corey. If not, drop a comment. Some of the other things coming up here, Jasmine Huang says, what's your approach to handling multi-product themes within a design system? How are themes organized in the repo and consumed by different products?

Yeah, that's, that's a good question. I mean, there's probably a design answer to this too, but I can start with the dev side. So what we've done is we've, we we'd recommend this too. We enjoy working this way, but we've leveraged Tailwind. And so the design system, when we would, when we would build a design system, even if web is the primary target, or let's say native is the primary target, we, we build it in a way that would be able to be consumed by both platforms. And so we would use Tailwind, and then Tailwind with the help of a library like NativeWind or UniWind gives us the ability to apply those Tailwind classes and styles to both, both platforms. And so we don't end up with two copies of a theme file. We have a single, a single theme, a single theme package that then product teams can ingest. And that theme is what is a dependency of all the components and other packages that our design system UI Kit exposes. And so with the help again of a tool like NativeWind or UniWind, we then have the advantage of using Tailwind cross-platform. And that's been, been a very good solution. And there's, there's other solutions for sure, but we, we found this to be pretty stable and productive and one we'll likely stick with for the foreseeable future.

Yeah, and on the Design MD side of that as well, like, we're— we've already sort of modified from the, from the straight Google framework and recommendations for like light and dark mode because they don't have mode management in there. Uh, so we found a pattern that other folks were using that seemed to work really well. Uh, multi-theme as of right now is two different files. Um, so when we manage those, they are two different files across the board. We're still trying to figure out what is the best way to do that. That's what we found to be the most effective, effective way to deliver those to the teams who need those.

So thanks, Jasmine, for the question, and thanks for the answers, Bailey and Tim. A couple more here. I think Justin has one. Agents.md sits at the top of the pyramid as, as context. Once a team there, team's there, who's responsible for keeping that file accurate as the system evolves? Is that a person's ongoing job? Does it get validated, generated automatically?

Yeah, you know, again, on the engineering side, we, we would try to build, and we, we do the design system in a way that empowers product teams, that they can work the way they want to work. And so this is somewhat of a how to work question. And so if you, if your design system is serving multiple product teams, we would provide those product teams with an easy way to add design system context to their agents.md file, but that's where we would stop and we would say, here's a quick way to do this, but if you have a different way to do this, if you manage your agents.md in a way that's somehow unique but fits your team, it's really your choice to make as to how you do that, but we want to give them, you know, as much of a frictionless way to adopt design system context as we can. Now, if your design system is serving maybe a single product, it's just a smaller scope maybe than what, what I was describing just now. Then, then it's more of a discussion, right? Who owns that? I would still say that it's the product team and less of the design system team. Only because the design system team is, is a portion of that agent's MD, it's not the primary piece of the agency. It's still just a subset of the whole. And so the whole would be the product team who, who need to use the design system, not the design system being the primary umbrella under which the product team works, if you will.

Mm-hmm.

Do you agree with that, Billy?

Yeah, I would agree. I'd agree with that. And a lot of the stuff that even that we, we deliver out for teams. Like, for example, just to go back to like our Design MD libraries and, or markdown files and things that we put out there. We try to keep the same contribution model that we do for components. And if folks have something that they feel needs to go in there, or they made a local version that pulled down and made some adjustments and edits, we really want teams to push that back to us. Because we can't be everywhere. Catching everything all the time. And sometimes we'll put something in there that, that worked well for us, but then somebody will find a way to enhance it and it just works 10 times better. And so we want to make sure that we have that as well.

All right, couple, couple more real quick. Vitaly, during AI implementation, we've encountered a problem. The more information we ask the AI to analyze, the more credits it consumes. In the end the outcome looks the way we want, but it took a lot of credits. Have you tried to optimize the cost? And I think, Tim, you can— I know the answer to this, but you could talk a little bit more about that kind of journey with the MCP.

And yeah, yeah, so we— it's a good question. I mean, everybody's facing that now, or will be shortly, as they, as they realize that, oh, there's, there is a cost associated with this. And so when we when we've designed a custom MCP in the past, and when we will in the future too, it's something that runs locally. So we don't— with this in mind, the context for the design system that an agent needs is not so big that it needs to be hosted somewhere, or it's counterproductive to have your local machine download that MCP. It's relatively small. And so we've developed it as a— our custom MCP is a simple npm package that can be installed that just again runs locally. It's not something that is hosted or just leads to more consumption of tokens. And if the agent has that context at the ready and your machine doesn't need to— your computer doesn't need to do a whole bunch of processing to figure out what the answer is given the context in that MCP. If it's just looking up basically like the equivalent of looking up in a dictionary, here's the answer to the question, well, it's, it's faster time-wise. It's less of a spend because the agent's not churning through tokens. Um, it's— you're not dealing with authentication challenges because it has to go out to a hosted solution. There's so many advantages to that, and so that's what we'd recommend is make it make it local, and you'll get the same quality result, maybe even a better result, while keeping costs as low as it could be, both in time and dollars.

Yeah, I think the other thing too is it goes beyond design systems, right? Even just using deterministic traditional ML with algorithms and then using AI where you need to. I mean, I think that's what we've seen as the biggest combination, especially when you're dealing with B2B software and things that are more deterministic, you know, if you think about workflows and other things, um, those two together.

Well, and I would— I saw there's a lot of, uh, there's a lot of buzz around Headroom as well, uh, which is a way to compress token usage as well, just for general, um, general AI usage. So something to look, look into if you haven't yet.

Yeah.

Yeah.

Good call.

Awesome. Well, we're getting close to time here, so if you have other questions, definitely hit us up, shoot us an email. We've got it, ahoy@headway.io. We'll reach our whole team here and be able to hop on and, and kind of chat a little bit more about your specific roles. I think the biggest thing as we look at next steps is, you know, where do we go from here? I think, you know, each, each one of us is at a different spot with our design system. And so I think the biggest thing is just realizing where you're at. Hey, if you're brand new, what can you adopt? What are the standards you could do out of the box? A good example is, you know, Meta just came out with their Asterisk open source system. You know, it's well documented, like looking at some of those things where you're not reinventing these if you're a one-person team or if you're, you know, an established team, obviously, like there's challenges and just ripping out what you have. And so I think a big part of that, Billy, if you want to go to the next slide here, um, is just figuring out, hey, where do we upgrade? Where do we enable our team with those sorts of things? And a big, big part of that is, you know, we have Shipwright UI that's free. That's, that's a Figma library right now, um, but that's really what we base all of our coded components off of when we start new projects, um, and those sorts of things. And design system roadmap is the other the other side of that. And I, I think, you know, if anyone here is looking for help, kind of where we help really is, you know, in this enterprise large team context, like consulting. Hey, anyone here who joined us, happy to hop on a call, do a consulting for free, go deep, you know, in a, in a private environment on your specific cases and, and give you some very specific advice.

Definitely.

Like, as I mentioned before, we're passionate about design systems and have been an adopter for 7, 8 years of, of using them really ruthlessly on our projects. And the other side of that is, hey, if you're looking to figure out how to go from where you are closer to an AI-ready and, and even agentic system, we can help create the plan and really run the rubric that Billy ran, run what Tim ran on some of your components, and really identify like what are the, the grassroots design system level things that you can do to improve your product. For the team. And then beyond that really is really looking at, you know, this building a custom MCP. As Tim mentioned, it runs locally, it's available to your team. That's something you guys wholly own, but we really custom code that to you and the environment, how you're using Figma, how you're leveraging different things within your code base, and make sure that it's tailored to you. And a big part of that custom MCP process is the roadmap is kind of step And I think, you know, for a lot of teams that we've been looking at doing this for is like, if we get to the end of the roadmap and realize you're not ready, obviously we can't build an MCP to automate. There's more things that either your team can do or if you want us to do, you know, we can fill the gaps there. But I think options that really help you move. And as we talked about, like if you're a one-person team, not a great fit, like there's probably not a whole lot of value in kind of hiring an outside team like Headway. But if you're a larger team growth stage SaaS is a lot of companies we work with, enterprise teams. There's a lot of value that can be had here. And one of the questions that maybe that Jesse asked, which I think we can kind of end this with, I think it'd be a good bow on, on everything, is just do you track and measure business outcomes and impact your design systems are able to achieve? If so, do you have some examples of outcomes you've been able to achieve? And really, I kind of let, let you guys talk a little bit about that, but we definitely have value calculations and estimates for Hey, what's the impact of the design team using these? What's the impact of dev? And then what's the overall impact cycle time-wise? We can't share any of those specific numbers, but we can share kind of how we think about it.

Yeah, I think a lot of this depends on, well, like baseline metrics that you might already have at your team. And we try to do things in isolation to prove the value that we're proposing. Because sometimes it's hard, we try to get rid of, you know, you might have a team that's doing a lot of back and forth, and then, you know, they might be iterating through things, and then it's hard to measure. So we try to take things into small little bite-sized experiments, run some value calculations that way, run some assessments that way. We also, we like to measure, at least for the design system across the board, we like to measure engagement. Along with adoption. So we've put a blog post together on what that means. And, and we feel that's a better signal of like, hey, folks have used the design system or they have it, but are they actually engaging with the whole breadth of it? And, and that's been really valuable for a lot of stakeholders because they see adoption metric, they're like, great, everyone's using it. And we're like, yeah, they are using it, but then this team's not really engaging with it. So what's going on there and allows us to dive into that a little bit deeper. Yeah, anything else, Tim, that maybe I missed there?

No, that about covers it. I just point out that what we've seen is that when somebody takes a step to contribute to the design system, they conclude like, oh, that wasn't so bad. Like, oh, I can do this, right? And so then the second, third, fourth, those contributions start to happen way more readily. And you can see then the effectiveness, effectiveness of the design system, the value of it start to spread and starts to become more, more known. But some getting that first contribution or that first engagement, that can be the bigger challenge. But after that, we've found it to be, to be a pretty reliable element of the overall plan.

Mm-hmm. Yeah, absolutely.

Awesome. Well, thank you everybody for joining us. Thanks for the questions. Like I said, let's stay connected. And thanks to, to Billy and Tim for sharing what they've been learning on the ground and how we're really thinking about approaching and are approaching these product, these problems in the market, which they'll continue to evolve. As we say, like, there's no absolute truth in design systems and what's right, you know, as we saw here, even in the comments, like, everyone's at a different spot and what makes sense for one organization doesn't make sense for the other. And I think that's where you really need to look at it with, hey, where, where are things at and what do you need in order to move forward? And it's an exciting time to be in software and excited to see where it goes. But thanks again, everybody, for joining us.

Thank you all.

Bye, everyone.