Why Your Design System Needs an AI Strategy

We're excited to get started here in this month's installment of Optimizing Design Systems for Humans and Agents. I'm Andrew Verbenkour, one of the partners here at Headway, CEO. I spent all my time really coming up in the early days of Headway in design and really partnered with Billy on design systems as those started to become a thing beyond UI kits in the early days of Sketch and really moving into Figma. Where we're at a lot of times is how do we add value to the business and not necessarily create another button, right? No one on our team wants to create another button. And so a lot of it has been how do we continue to build kits and things like that? I think in maybe it was 2018, Billy, we started Shipwright initially, which is our UI kit, and really figured out like, hey, how do we not do this again? Because no one likes to do it. It's all busy work. How do we focus on business value on customers? And coincidentally, those start to overlap with what we're talking about today, which is it's not just humans using them, it's, it's agents. So how do we start to position everything from that. But so, you know, from a Headway standpoint, we build agentic design systems that accelerate the launch of new products and digital transformations. And so really design systems is core to that. And we're seeing that faster than ever with everything going on in the space where if you can make these decisions, you know, one decision that makes a thousand sort of mentality and get the right infrastructure in place, you can really start to advance the business quickly in new products. and new opportunities and ultimately transforming much faster than you could before with a smaller team. So for those that aren't familiar with Headway, we have been in business since 2015. We have tons of templates and training and courses available. Maybe some of you have come in from those or, or have seen those, but we've trained hundreds of thousands of folks, designers, developers, strategists with that stuff. And we've launched over 150 products in the last 10 or 11 years. And really a big thing that I'm most proud of as, as our CEO here is that 90% of our clients return and continue. And that's kind of a testament to our work and, and the value that we can help bring. And so we've worked with a lot of large companies to really help figure out how do we do innovation at scale? How do we build design systems and really start to level up our team from that perspective? So excited to get started here.

Yeah. Hi everybody. Welcome. My name is Tim Greenmore. I'm a development lead with Headway. And I get the pleasure of working with clients as an engineer, as a developer to help build out the design system in the form of a UI kit, or in this case, help identify how to get an agent well-informed of what the design system is. So your agent's doing productive work and not creating more problems for you than it solves. And so looking forward to talking about that more with you here in a bit. And with that, I'll hand it over to Billy.

Awesome. Thank you. I'm Billy Sweetman, head of design here at Headway. Partner Tim on a lot of design systems, mostly on the design and operation side and working on adoption, things like that. Today we're gonna mostly talk about really how do we help design system teams understand how we can prepare our design systems for these like new and emerging agentic workflows. And really everyone's trying to solve the same problem right now, and this is kind of our unique view on how we, we think that problem is solved. Really everyone here, this really core focus is for like design system teams, product managers who maybe have a design system or maybe if you're just starting one out. I know we got a pretty good mix of folks who are scaling and on the mature side. So you're definitely knee deep in this. At least everyone that we've talked to is for sure working through these same issues right now. So I'm gonna set a little bit of the groundwork of where we are in the design system world. I'll talk a little bit about some of the stuff we're doing on the design side. To help the agents handle our design systems better and use them more effectively. And then Tim will kind of round us out with some of the dev stuff that we're doing and kind of show you some of that, how these things all interconnect. But sort of why does this matter now, right? AI is revolutionizing how we build digital products. We're all seeing it, whether it's AI mandates at your team or just like the speed at which we can do things, right? We can move faster. We're generating code and screens and flows at really increased rates. And so the, the time to get things done and complete is shrinking. But now, really, the big bottleneck is like the product quality and clarity. We want to make sure, you know, that everything is right, correct, feels good, is following our design philosophies, following our product philosophies. And that's our bottleneck. And if we're constantly iterating there, we're losing all of those gains that we got from establishing AI workflows and ingentic workflows, right? And then the other thing is that tools are changing, right? AI models continually evolve, but we need to establish patterns now that are sort of agent or model agnostic that can ensure that future success. So as we change between different models or different services, or we eventually have our own, we've built out a foundation of knowledge and a foundation of tooling that can help us do that. One of the big things with the increased output is, you know, that output is increasing rapidly. AI is moving us very quickly, but if our system doesn't have a strong definition, it starts to cause drift. And this is something that we can see a lot. Things might look right, but they're not technically correct. Mostly right ends up causing us a lot of rework, right? Fragmentation could tarnish our brand. And if this is a single product that you're working on and your design system is managing all of that. That drift can definitely compound in that single product. If we have multiple products, it even gets worse, right? Now we have multiple products, multiple things that we, that are gonna cause drift. And so we really need to ensure that our design system is doing the things that design systems should do, right? Reinforcing brand standards through consistency across all of our screens and products. We wanna improve the efficiency through that reuse, align all the design engineering practices and reduce that decision fatigue, and then support scale across those teams. But we need to make sure that it's agent ready because an agent is helping us do that work. And sometimes it doesn't know the correct things that we might know. Right. And we're seeing those pain points now as we're working on teams, right? They're manifesting with the agentic adoption across all, all companies and they're adding to that drift. Some of it can be team-led, right? Teams are, teams may be bypassing the design system because AI is really fast at producing results that looks good enough or close enough, right? We might have product patterns that are diverging because it's just bringing inconsistent implementation across the, across all of the development. We might have documentation that's not being used in the actual workflow, right? We've written really verbose prose and documentation for humans to read, but the agents aren't referencing it at all. So they're kind of going off on their own. We're gonna have new tools that aren't representing the brand well. These could be you're adopting generative tools and they might not be using your existing design system components. We still wanna make sure design system— Right. And the worst symptom is like the productivity isn't being demonstrated in the roadmap. So we can't release things faster. We can't, cuz we're doing a rework and a lot of churn. So it's not that design systems don't matter anymore. It's just that we need to add another layer so really agents can find their way, right? So we need to make sure that our composition libraries and documents, they're, which tend to be a little bit interpretive or, and not clearly laid out, are very clearly laid out and written in a way that agents can understand, right? We might not be following, maybe our naming and composition logic isn't as explicit as it needs to be. We might have lack of naming rules that isn't— that when agents look at things, they don't really understand how to use those, those different elements. We might have things that we can retain easily because we can remember things, you know, for a long time, but an agent is going to lose that context all the way through the different various working sessions and different resets. Right. We might be not delivering exactly what developers need, you know, where they're at, causing them to bypass the system. Like, how do we deliver everything that they need in the tools that they're already using so they don't have to pick up another tool? Or go somewhere else to go get that. Another symptom is we might be picking up or generating things that look right, but it lacks that system integrity, right? A developer could pick up the slack if a designer designed something maybe a little bit incorrectly. They can interpret that easily. But an agent might take it as, as verbatim and produce more hallucinations down the line because it took that all the way through. And then the visual models that we currently have are a little bit interpretive and they're gonna cause some drift through there because they might not be using our our exact tokens because they don't understand the actual spacing methodology that we put in there. So these might be all symptoms that we're feeling as we're kind of working through our agentic workflows and leveraging design systems right now. And so we wanna kind of take a look at where your system is and kind of where we feel, you know, your system kind of starts out, right? We have these early ad hoc systems where it might be a little copy and paste components. It doesn't sound like a whole bunch of folks are in this early phase, right? A lot of engineers might be building from scratch. Scratch. And then we kind of have like the catalog system here. We have maybe a Figma library that exists. Components might not be super composable. We might have some variables and tokens established. Code might be a little disconnected, right? We might not be leveraging things like Code Connect, or they might not be in parity, like property names might not be in parity, things like that. We might be on the structured side where Figma and code is aligned. The token architecture is in place. We've got some basic governance. Humans are shipping consistently. Then we have kind of level 4, which is the validated, where rules, rules fail, CI, it's not just reviews. We have schema-driven documentation. Agents are able to produce a usable output and we're able to catch that drift. And the final stage is really like that full, full agentic where we have full JSON schema coverage. AI is providing shippable UI.

Mm-hmm.

Humans really reviewing, reviewing the work and really maybe even as reviewing just really high, you know, high priority work and not everything, you know, maybe there's lower priority work that's being shipped just automatically. Most teams kind of identify in this cataloged or structured, I'd say based on the poll that we had, everyone's probably like level 3, maybe starting to move into level 4. And, and so this is where we end up talking to a lot of teams and kind of where where they are in the current, in the current process. Now with AI kind of touching everything, there's really this part of a new— the, the newer design system is this additional tooling that really helps us connect these automated dots, right? And it's happening at every layer across our, our design system, right? All the way down to the primitive level where we might have like a DesignMD that's helping us generate or helping us maintain the context of tokens across various different tools. You know, we might have, we're definitely gonna have, or we're definitely gonna have updates to our agents.md file that's gonna help with routing and choosing the right things. We might have some linter tools that's gonna help design files become foundational structured elements that catch any mistakes in the design file before we hand that over. So really there's a lot of things that are being touched in the design system. that really builds up this agentic workflow. Now, where we leverage, where we kind of take a look at design systems is we kind of take this frame of the agent-ready audit framework and we kind of look through a design system and try to see, to see how ready is it for agentic workflows, right? You know, and the idea here is that we're gonna take an audit of a design system and really build out a roadmap so we can evolve that system. Take a look at through composition libraries and Storybook book, and by reviewing each one of these things to make sure that they're written in such a way and that they're structured in such a way that an AI or an agent can easily read it, understand it, utilize it effectively. So one of the first things we do is, you know, tokens, they're not just the foundation anymore, right? They're the vocabulary for AI, right? Do our components use tokenized values for every color, spacing, type, radius decision? Are those tokens tiered from a primitive to a component level? And then next, are they written in a semantic way so that they, an agent knows when something is being used? Like blue-100 is no longer very useful. We want to give some intent behind that. Just like we would do with our styles and variants, we want to encode that purpose and context into the naming of everything, right? No ambiguity because an agent can't get the right thing. if it doesn't understand what the names are. We have to add extra routing if that's the case. But we also wanna make sure that we have composition rules that are explicit in our, in our tooling, right? So do our components have composition rules in themselves? Do we have conditions that trigger those specific composition states? For example, are there group level behaviors that control atomic components underneath that if we have something linked together? And do we have that clearly written so that an agent can see that, understand that, and then be able to configure that correctly. Do we have decision logic built into our components, right? Do we have slots with component constraints, character limits, declared min-max counts, and all those nesting rules kind of written into the instructions that we're, we're giving our agents? Do these live in not only our maybe design representation of our components, but do they also live in the code representation of our components? Or do they live somewhere in a happy medium where they can be referenced both ways? Do our components and instructions tell an agent when to use that specific component or when not to use it? And when it says don't use this, does it tell it what to use instead?

Can—

do we have some of those opinionated defaults written into our component instructions for agents in our, in our documentation? Then the next one is like structured decision trees, right? Do we have default fallback values? Do we have conditions written to justify when we want —deviate from the default? Do we tell an agent it should make something new instead of using something that we already have? And then the last one is, do our components map cleanly to our engineering patterns and responsive rules, theme switching mechanics? If we do have information in two spots, is there parity for that? If we're referencing a single spot, does that match up across all the different tools? So these are kind of the things that we look at when we audit design systems, so we can then build out a, a rubric and give us some idea of what are the things that need to change, and what are the things that need to be updated. So we'll show a little bit of what that audit looks like. So this is the Figma portion of the audit where we're taking a button group component that we built a while back and running it through the audit process. And we're gonna look through all those different things so that we can ensure that if an agent sees this button group in a design or we're referencing it in documentation, it can pull the right information that it needs. So when we initially did the audit, we scored pretty low, say 9 out of 16, and we have different categories that match up to, to the framework and different things that we're looking at. Some of the things that it flagged us for is we didn't have information about the character counts. We didn't have a max count for the button group informed in here. We were using a reserve variable type, and there's also no state triggering logic written in the component itself. All of this stuff probably lives in our document site somewhere. But to have our agent find a component, then route all the way to the document site, then come back and then decide how it should do that is not only— seems a little bit wasteful, but also takes a long time. It's a lot of context to build into it. So what are some ways that we can build this and put this better into the system? So we use this information to build out the change list that we would do to this component. And really built out the roadmap for updating this single component. Some of the things that we did is we obviously redefined all the properties to make sure that they aligned with the standard that we set. And then we also communicate that standard to an agent through things like a design system properties file, MD file. This could be something that we've been using a little bit as a design MD file too. So making sure that some of those things are written in there when we're composing those things. And then the other thing is making sure that we had an agentic readable description and really trying to embed some metadata into the component, what type of component it is so that matches up with our component, uh, listing structure, what tags are available, what do we have use cases for this for, when should we use something else, right? And so we go through and we update these components, we make these changes, and we've added in these additional details. And then when we run our scan again, we got about a 7-point increase, right? We defined some composition rules for this component. We defined some trigger rules for it. We find what to use instead with some metadata along with some of those properties increase, and we got about 7 points out of that. Now with these enhancements, our component, you know, we can look at increased consistent placement and usage through additional tooling. For example, like additional tooling through a custom MCP, which I will hand over to Tim to talk through on the dev side.

All right. So yeah, so like Billy's explaining, we've worked on creating some tooling to help automate and, and just overall improve the experience in working with an agent. Um, I just noticed in, in chat there's a question about tooling, right? How do you, how do you generate some of the content that the tools you're creating are, uh, can use? And, and the answer is yes. I'll, before I get into the back into the deck to answer the question. The answer is yes, but you also have— you likely have guidelines and design system specification somewhere else. And so you, you have a little bit of a chicken or the egg problem where you need to get that context potentially from Figma. Maybe that is where your guidelines and design system specification lives. You need to get that into your agent before your agent could actually generate the context for your tools. And so, so it's a good question. I think we can potentially come back to that a bit. Unless, Andrew, you have some thoughts?

Yeah, I'm sure we can chat a little bit more about it. But I think the biggest thing is that there's a, you know, we always talk about like what's good for humans is good for agents, right? Even before agents came into the picture, having these things documented and guideline is really important because you really need someone to make those decisions and you can have some good defaults, but based on what's out there in the market, but each business is gonna be a little bit different in how you apply some of these rules and logic and exceptions, as Billy mentioned. And so I think getting to the point where you have somebody who's reviewing this, getting that alignment really early on, even if you are using AI to generate them and, you know, making sure you're being intentional about those decisions, I think will help avoid, you know, a lot of tech debt and other debt that happens, you know, because of, maybe the oversight of, hey, generating all this really quickly and moving on to generating UI and generating, you know, flows and stuff without really thinking through the implications of it. There could be— this is kind of the one decision that makes a thousand as you start to empower your team depending on how, how big they are. But I'll, I'll kind of drop, let Tim go through the deck here and if there's more questions around this, we can definitely, definitely chat more.

Yeah. Yeah. Thanks, Andrew. Yeah. So Billy, if you wouldn't mind navigating ahead, there's sort of two ingredients that we'll talk through as part of the development side of agentic, agentic-driven design system work. The first on, on the left there, Figma MCP. So you're, you're likely familiar with Figma MCP. You've probably used it. We'll talk a bit about why that alone isn't sufficient. And what are the shortcomings of it when just, again, used by itself. And then the second being a key ingredient that we found is helps close the gap to what those deficiencies are from Figma MCP-only approach to engineering. So if we looked at why Figma MCP, why that is not sufficient by itself, if, as Billy had, had spoken to If we ask our agent to implement a given design and we hand the agent a URL to a Figma frame and the agent is connected to Figma MCP, it's gonna get the design specification from Figma, but it's not gonna have the information your design system has. It's not gonna have guidelines, it's not gonna have tokens, it's not gonna have component APIs. All that information is gonna be missing. And so what is it gonna do? Well, it's going to implement ad hoc solution to the, the request, which is, you know, build out this design. And that by itself is, is gonna give you a very aesthetically accurate solution. But that's not ultimately what we want. What we want is an implementation that leverages the, leverages the design system. So So if we jump to the next step, so why not just then a custom MCP? Why, what role does the Figma MCP have? Well, Figma MCP is, like I said, is giving the design specification. So it's telling us how to lay out components, it's telling us the copy of the text that we're putting on the screen, it's telling us spacing, it's giving us the design specification. And so It's just important that we start with this, this ground, which is we need both of these tools in order to get an agentic-generated design using our design system. So, all right, so if we look ahead, Billy, at the next slide, the MCP tool that we've, we've been building out generally starts with these four tools that helps our agent achieve the design spec that it's given. And so, when we think about what Figma MCP provides, it, again, it provides a design spec with spacing specification, color specification, type specification. And then if you begin to think atomically, those, those primitives start to build up into things like a card component or a button or, or an accordion. And so if you think of your design system, you likely have a list of UI, a list of packages, oftentimes a React package that represents those individual components that you see in Figma that are being used in Figma. So our MCP tool that we've built out for clients and, and for ourselves with our Shipwright product is gonna have a list of packages that the agent can reach into. So that list the agent can provide will help the agent then discern what it sees from Figma MCP, what it sees there, what is the actual package that might represent that specification. And once it identifies the package, and if we just stuck with, let's say it's a button package, The agent determines it needs a button, it finds the corresponding package, then it can look at a map component tool from the MCP definition. And the map component then will say, okay, now that I've got the package and I've got the specification, now I can begin to wire up with the help of the get component definition, the API to what those specs are from Figma. And then last but not least, if you look at the, the fourth tool, the get design tokens tool, that helps, that will help if, if the component instance that the agent sees in Figma has diverged at all from the default. If there's custom color, if there's a custom size, if there's a custom interaction to it, it can take that customization, that custom spec. And then search through your design tokens to get the equivalent in order to override what would otherwise be a default package instance in your, in your app. So, okay, so those, those 4 tools sort of provide a foundation for what we found to be a helpful MCP definition for our agents. So if we jump to the next one, Billy, there's The way that we've helped firm up this, this recipe, if you will, is we've, we've taken a somewhat simple design that you see on the left there. That's just a simple screenshot from Figma of a youth sports management app, a registration screen. And if we only used Figma MCP, and you look on the right side, what you get from your agent is Again, it's a custom implementation. It's hardcoded color values. It's HTML primitives, or if you're using— if it's in React Native, it's React Native primitives. None of that is really design system, even though aesthetically it looks accurate. It's not your design system implemented app. And so that's really what we want, because now I have this implementation that I would otherwise have to go back and, and basically rewrite. And so the agent didn't help me in this case, even though, again, it gave me an aesthetically accurate solution. So if we jump to the next, the next step for comparison's sake, but we got an MCP that is built around my design system that knows of my design system, the packages, the component APIs, the guidelines. What I get on the right is actual— an implementation that actually uses my design system components. And you can see there's a container component, a text component, button. You can see the class names are not primitive Tailwind classes. They're actual colors and spacing that are coming from our design system. And that information, again, it doesn't— it doesn't get to the agent if the MCP doesn't provide it or isn't there to, to offer it. So next, after— if we, if we think about those two ingredients as being essential to getting your agent to implement a design properly, your agent still is going to do what it can the quickest quickest it can and the path of least resistance, it's going to try to answer the question that you get it, that you, that you feed it. And so if the question is, or the command is, implement this design, your agent might start to reach for other things within the, within your app, within your code base. And it might start to see, oh, I see this pattern over here. Let me, let me try to mimic that pattern. And that might be correct, but it's also sort of like Billy mentioned earlier, it's, it's inefficient. It takes time for the agent to process that context that it came upon and then apply that knowledge to the question at hand. Whereas what we want is for the agent to use the MCP because we know that the MCP is, is an authoritative ingredient to this. We know the MCP will answer the question directly and accurately. We want to just take one more step on top of a custom MCP, and that's just using your existing agents.md file. Within that agents.md file saying, do this and don't do that. Some very simple guidelines will help your agents to avoid combing through your node_modules directory, for example, and instead, do this, use my design system MCP to implement designs. And so that adding to your agents.md file, telling your agent when to use your MCP server, uh, will, will help it to answer questions efficiently and accurately. So it's one other small but important part to this. So when we— so Billy and I can walk through all this, how it all connects together. So Billy, do you want to come back a bit from a high level and describe how custom MCP fits within the big picture?

Yeah, and I think there's a— there's also a question that I saw in the chat about advocating for an MCP, but part of the team is talking about Design MD, and how do those two things kind of interact with with each other. So we can talk about that a little bit in the context of, of this slide here. And this is kind of how we feel the different layers in how we would apply different bits and pieces of information to help build that context to really drive, you know, accurate design system usage by agents. And then also to be able to handle accurate design system representation. We're gonna say representation because it's not our design system components. It the right design system abstracted bits in these new generative tools. So Design MD, we kind of feels like going to become the source of truth. It's going to have, it's going to be where we store all of our composition rules in the prose bit of the MD file. So the top half is like YAML-specific definitions, and that'll be like our tokens and our variables and spacing and things like that. And then the bottom half is going to be where we can have some of those composition rules, do's and don'ts, specific specific mobile responsive breakdown rules and logic. And we can have that decision logic written in there. We can also have the Design MD get some details on like when we should use specific colors and be a little bit more verbose in those areas. And the custom MCP in our design system and our Figma will inherit a lot of those values and then get represented in those as well. So that's kind of how we, we feel that will, or that works together in the stuff that working on now. Those two things will pour together to help deliver that context to the development environment where we'll have specific skill files for specific tooling, right? So here we have like React Web and Native would have its own skill file for things that are unique to that. You might have a mobile. So sometimes we're working on design system that works on mobile, like it's React Native and it also works on web. And so we're gonna have a different skill file for the mobile team to, to, for the things that are unique. Mm-hmm. Unique for them, and those three things paired together will help get an accurate representation of our components in an efficient way in those development environments.

Yeah. Billy, if I, if I could too, it's probably helpful to distinguish, at least it's been for me in the past, think of Design MD as actually being more helpful with generative design. So if you're asking it to, to design something as opposed to build something in code. The building part is where the custom MCP we found to be more useful. DesignMD, generative design, we found to be more useful. And so they're not mutually exclusive by any means. This, this slide helps to communicate that they build on top of one another, and they can serve both your designers and your developers. But it, if you think in those two buckets, it might help to understand why, why they both exist. And why somebody on your team may use one and not the other, or they may use both.

Yeah, exactly. And so like a, a very realistic example for on the design side, using Design MD file, once we had that all defined, was a team we were working on wanted a Figma Make library, but we didn't, didn't have the bandwidth to get all of the actual components from the design system hooked up into the way Figma Make would allow them to be used because it would've take some time. We would have to, there's some refactoring involved. So we need to have the design system represented in a way. So using DesignMD with the component definitions and everything in there, we are able to stand up a Figma Make kit that is identical to the design system by using the DesignMD as the spec for it to follow for every component that it built out. We were actually kind of surprised that even though you give the, you give Figma Make access to your component library, it just it didn't pull in the right tokens and, and values. So using DesignMD, it, it then did pull in everything accurately and represent it in a correct way. And so that's a way that how it can help inform, you know, design system representation in some of these new tools.

Yeah. I, and I, I, I think also the, to a point you made earlier of this, this as an architecture, if you will, is, is agnostic to the agent you're using. Whereas if you're leveraging everything Figma's offering, then you're, you're limiting yourself to what might come in the future from, from different vendors. And so, and it's also maybe limiting your team where somebody may prefer Cloud Code and driving design through maybe Cloud Design versus, uh, another teammate using Figma Make for much of their generative UI, UI work. Mm-hmm. So, yeah.

Awesome. Any more questions about how it all connects here? Otherwise, we'll dig into some questions from the chat from here. But before we do, we'll kind of leave this up. If you do have questions, drop them in about this or anything else we can talk through and how we've been evolving our approach, right? One thing we talk about is like there's no gold standard other than the things that are working today. Like as new tools evolve, as new things come up, we just have to be open to adopting those and then figuring out how do we test if we're getting better results or not. And that's kind of part of the process here is making sure that we're, we're open to evolving it. So this is kind of, as the team mentioned, built upon all the things that we've been doing with mostly with large enterprise teams or late-stage startups and supporting, you know, the design systems and multiple products primarily. So we'll go into a little bit here back to Anu's question. She talked a little bit about how much detail and context to provide an agent, uh, to effectively build a design system. Maybe this is a little bit different than what we were talking about in using the design system. Um, so Anu, maybe you can clarify a little bit more about you don't have one now and you're trying to get AI to create the first version of it, you know, and is that in, in Figma? Is that in code? Is that just in code? Uh, maybe a little bit more detail and we'll come back to that. Um, we'll talk about Joy's question here. Uh, Joy C, thanks for submitting this.

Do you have, uh, does having Storybook help with using AI and Agentic tools?

Well, yeah, it's a good question. We, we use Storybook in, in most, if not all of our builds. It, we, we haven't used Storybook's MCP. And so there, perhaps that's part of your question. And if not, Storybook has an MCP. We have not used it simply because it burns through an awful lot of tokens and we just found it to be inefficient. And we've really got the agent to answer the question we need with our own MCP. So, so that, that part, that part of the Storybook offering, the MCP piece is not of tremendous use, but it potentially could be for you. The, the interesting thing is Storybook at this point is more for humans. It's not— though the agent, we could point our agent at it and the agent would get context and probably get the right context in the needed context. We've just found it inefficient. So whether we use Storybook MCP or we point our agent at our Storybook published instance, all of that context has to be built up. And that again is just the kind of the kind of a very verbose approach to getting an agent to answer the question.

Awesome. From Joel Richardson here, how do you handle asset management from Figma? Images, SVG icons, etc.?

In—

Joel, maybe I'll assume that you're thinking in terms of how do you get an agent to leverage to pull assets from Figma? Is that— I assume that's sort of what— is that the, the base of your question there? We, to be honest, we, we haven't. We've largely added when it comes to icons, for example, that's part of the UI kit that we've built out for the design system. So we're not pulling that asset because it's in an npm package. And then we can reference that icon with a name. We don't need the actual file. That's an icon. Images, different build.

We do have those fallback images that we put into the design system, which are SVGs. But we haven't— that was a manual translation. We didn't automate that translation from the Figma SVG to being available in the design system?

Yeah. Yeah. It's a good— it's a good question. I think it might depend a little bit on your use case. And the use case that I'm describing, having a UI kit with a package and then referencing an icon by name or potentially an image by name, assumes that you have all that information up front, right? And if your circumstance is different, you're building that as you go. Uh, I, I don't have— Figma's MCP will give you some access to screenshots and to some of that asset, but it's not really the same thing as exporting directly from Figma, as an example, into a high-res image or, or otherwise.

Something that is on our roadmap though is even with the the icons is giving an appropriate amount of metadata. One thing that I've noticed is using some of the generative tools, even when they're either, whether it's through Figma Make or even using Figma itself and it pulls out the icons, it doesn't always grab the correct icons. And so, you know, adding some additional metadata, we haven't done this yet. It's on our roadmap, but adding additional metadata to the icons. So hopefully the agents have a better Understanding what icons we're actually referencing and what do we actually want.

Awesome. We'll move on to the next one here from John. How do you view a monolithic design.md versus a composable approach? How do you tackle the debt in transformation? Do you approach building an agentic design system lazily as it comes up or actively? And have a few, a few different ones there. Maybe start at the top and work through that.

Yeah, I can start, Billy. I think you and I probably are thinking the same along the first question, monolithic versus composable. In one instance, at least that we've had, you've got multi-theme and then within themes you've got a light and dark mode. Design MD doesn't yet— the spec itself does not define and give instruction for how to support that. Scenario. And so, if your design system is supporting multiple products with different themes and it's fairly complicated, then what we're— what we're using for now is a single theme would have a single design MD file representing it. And then we've actually diverged a little bit from the Design MD spec when it comes to light and dark mode into— Yeah. Into our own— our own solution. So, it— we're— given the spec is so young and it's evolving quickly, but its momentum continues to build, we're very conscious when we diverge from the spec. But we're also very confident that it's gonna become a key ingredient in the future for most design systems, if not— Yeah. I'll just leave it at most.

So, yeah.

So, we're okay diverging from that knowing we're gonna have to go back at some point and bring it in line with the spec as the spec matures.

Mm-hmm. Yeah. And right now we have for one of the themes that we were working on, we have a massive— I mean, all the components are defined in there. Following that. And that's always a conversation that we're having. Does this make sense to have all those definitions in there? Is this too much context to go through? And we wanna, we plan on taking a look and maybe running some benchmarking to see what's the best approach for that. Cuz it does seem like a lot in a single file, but also so far we haven't had any issues. I, I saw someone asked if we use DesignMD in Cloud Design and yeah, we've used it in Cloud Design. We've used it in Figma Make. We've used it in a couple of different in just Claude code. And we haven't had any issues getting any like bad output from those. I would say it's always like probably 70% of the way there. So it always misses something, but it's, it's a lot better than without.

All right. Let's talk a little bit about the debt in transformation. I guess you talked a little bit about that, Tim, in like coming back, and some of it's acceptable, right? Just like before agents, like, hey, this is an acceptable thing, we're gonna come back and refactor it at some point. But is there anything else to push on there?

Yeah, I mean, I think just like to Billy's point again of like, you know, 70%, say it's 80%, like if the goal is 100% today and you're waiting until you have 100% to to dip your toe in, you're just going to always be waiting. You have to be willing to take the gains that you get from such a system, like with what we're proposing. Take the gains knowing that you're going to have to still work with it and close the 20%, 10% gap at the end of the— at the end of the ticket that you're working on. Mm-hmm. And in the end, we found there's a tremendous amount of value in that approach. Just you have to be aware of that. It's still an agent and it's still non-deterministic. And so same input does not equal same output. And that's okay for now.

And I think on the second half, we're like building it lazily as it comes up or actively. And I think, You know, we can kind of include Josh's question of like, how would you take an existing system and gradually adopting the new agentic design? You know, from the get-go, it, it's really taking a look at where you're at and what your roadmap looks like. And for us, it's starting to find those opportunities to start adding those little bits and pieces to it to help gradually build into an agentic design system. So for us early on, it was you know, getting into building a custom MCP. That was one thing that we felt really strongly about. So we roadmapped that out right away, getting some metadata into the components, because a lot of Figma's MCP, like, developers are already taking Figma's MCP and just using it with Claude code and getting some output that was okay. And so we were like, well, let's make sure that metadata is in there because we've tested that and we're getting better output using that. So it's really just, you know, for us, it, it is kind of as it comes up, but we always have a little bit of agentic or AI enhancements to the design system every sprint. I wouldn't say, I would say probably since, probably been a year of time-ish, we've continually, every sprint have been adding a little bit and kind of continually enhancing, evolving things, taking a look at things we've built and Okay, we can live with this how it is for now, but we know this needs to change in a couple of months' time. So.

Yeah, I think the biggest thing is there is some urgency around this as AI continues to speed up, right? So I think it's taking a look and we'll talk a little bit about, you know, creating roadmaps and stuff like that shortly here. But I think the biggest thing is looking at what are the swings that make the biggest hits for your team that avoid the, the most drift, right? And I think a lot of that comes back to tokens. It comes back to the, the building blocks that are making those screens composable. And maybe Tim and Billy have a different point of view, but from, from my point, it's really focusing on those foundational elements that then build up into the UI so that you do have what, what Tim shared, obviously, like a custom MCP is built upon those to make sure you're leveraging the right variables, the right naming conventions and those things that make it easier and avoid more drift sooner. Mm-hmm. Not necessarily end-to-end full sweeping patterns or, you know, UX flows or things like that that you might be implementing, but really the building blocks, you know, which is true before agents as well, right? And so I think figuring out how you rectify those sooner than later is good. And we only have 5 minutes here, so I'll kind of wrap us up here and we'll answer some of the questions. Maybe we'll do some follow-ups here. But a big part, really, if you follow me on this, Yep. It's kind of moving into, you know, like, where do you go from here, right? You can adopt starting with a ready-made system. You can upgrade, really improve your existing system. And I think that's part of where a lot of folks are at, whether you're scaling or mature, is like, how do we not start over if we can help it? And I think identifying those key parts is a really big part of that. And then enabling your team to, to build system. I know some of you said like capacity is an issue or capability. And I think that's a big part where we can, you know, help add value to, to everybody here. And really the most common ways that we support teams and design systems and in doing is like consulting call, like, hey, for everybody that spent the time here, we really appreciate you guys taking time out of your schedule. There's a lot of content, there's a lot of noise going on. Hopefully you found some valuable nuggets in here, but we're also down to book a call with, with our team. That'd be Tim or Billy and one of us, whether that's Gus, myself, or Jacob, and really just help drill into specific things that are hard to discuss on a public call like this that you want to dig into and give you some very specific action items and advice on how we might solve that or how you guys might solve that and apply those directly yourselves. The other thing that's probably the most value that we could provide for the least amount of investment and time really is just creating this prioritized roadmap, taking a look at, hey, what are the low-hanging fruit items? What are the— the big swings that kind of make a big impact for your team and giving you a plan that you can start to execute. And then obviously this is where we work quite a bit with a lot of large teams with enterprises, just embedded iteration partner, both from an execution standpoint, but also a strategy standpoint as we think about adoption, as we think about solving, you know, multi-theme, multi-product problems across the org. And that's kind of ongoing and, and team and role dependent. So just a little bit more. If, if you guys are interested on this Agentic Design System roadmap, is just a full audit. It takes 2 weeks end to end. We essentially come into your Figma system and do a deep dive audit. We go into your coded components and review those and kind of the infrastructure and how things are composed and set up. Then we also take a look at your team operations. So how are you guys maintaining it now? What are the, the cadences and things you have in place? And then walkthrough what Billy and Tim were doing with the Agent Readiness Index, like really looking at those things on, you know, at a minute level, at the very, you know, atomic level. How are we, how are you guys scoring on that and what are the recommendations to bolster those specifically? Ultimately getting to that prioritized roadmap in a 60-minute walkthrough with you and your team. And I think the biggest thing is, hey, this is really quick. This is low effort on your side other than, you know, signing some, confidentiality agreements and things like that that we get into. It's really onboarding our team into your tooling that already exists with 1 or 2 sessions. So not a whole lot involved. And we kind of behind the scenes will, will take the ball and move that forward. And so if that is of interest, let's definitely, definitely chat. Would love to figure out how to help you guys move forward from where you are closer to that Agentic system. And ultimately, you know, here's an example of what that looks like when it comes to, you know, component inventory at a glance. Different roadmap items and priorities, health of different things. How are you doing naming conventions and really give you a roadmap for the next, you know, 30, 60, 90+ days that help you figure out how to execute that. And if you guys need help and you have a problem with capacity, we can come help and execute that. If you want to run it yourselves and are really just looking for our advice, we can just kind of hand off the roadmap at that point and, you know, you can continue to iterate. Yeah. And, and move forward as you are. So, again, thank you all for attending, and, and hopefully you got a ton of value out of this. Really appreciate your time, and thanks to Tim and Billy for sharing their perspective and all the stuff that we've been learning as we, go deeper and deeper into design systems with AI.