AI Agents Need Better Design Systems. Here's Why

The benefits of a design system are just accentuated with agentic workflow. If individuals are prone to start to drift away from the standards that a design system reinforces, the agent's only gonna do that exponentially more and, and faster. And so we just see the, the need for a design system more than we ever have in the past.

Hello and welcome to Even-Keeled, the podcast about the craft of creating software and building effective development teams. I'm John Kinney, founding partner and CTO at Headway, a product design and development agency. Every discussion we share is a window into what we've learned, how our teams are leveraging new tools, thoughtful perspectives on the latest trends in AI development, and more. Today on the podcast, we cover how to actually connect your design system to an agent through MCPs, also agent files and routing solutions, and why a screenshot of Figma only gets you so far. Tim and Dan share what they've been building for a client, including how they used Claude to generate a lightweight agents file that gets 90% accuracy right out of the gate. And we get into the bigger question of what a design system actually is, why it's more than just a UI kit, and why it matters just as much for a solo developer building with AI as it does for a large product organization. Stay tuned, and I hope you enjoy. So at Headway, guys, we've been working with design systems for a long time. We try and help companies implement them. We build with them when we're creating our own internal software. And, you know, we even sell courses and things that help companies level up their design system capabilities. But as we've been talking about AI and agentic capabilities getting more and more adept here in recent months, and certainly over the last year, our workflow has really shifted into a really strong hybrid, but leaning towards AI-enabled development and design. Design systems play an interesting role in helping enable that capability to be even more effective and, and to really help your agents creating the software stay on the rails. Would you say that's a fair assessment of the importance of design systems in the age of AI?

That's well said. You know, it, it's interesting. The benefits of a design system are, are just accentuated with agentic workflow, right? If individuals are prone to start to drift away from the standards that a design system reinforces, the agent's only going to do that exponentially more and, and faster. And so we just see the, the need for it, for a design system, more than we ever have in the past.

Yeah. Dan, how have design systems helped you in your workflow recently?

Yeah. As a, as a new member of a product team with one of our clients, I'm getting to make use of a design system that we worked on, that me and Tim worked on for this client. And so, uh, it's very helpful to be able to just jump in and, and do the work and know that what I'm delivering is going to match the expectation of like design and product because it's locked in. There's no questions. And so then when, when I use, um, Agentic workflows to help me complete tasks even faster or more efficiently, I know that we're not going to end up with some random interpretation of a React component or some hex color that it thought, you know, was good from its training, but it will really like lock in and stick with what is expected, and, and the output is going to be exactly what I anticipate and exactly what our leadership will anticipate.

What do you have against purple gradients, Dan? Just bashing the training data over here.

It's going to put a ring on anything because it glows and it looks great.

Exactly. No, it's funny because there are definitely levels to using agentic coding, right? There's— you can just tab complete and cursor. I think most people are past that these days. A lot of folks have transitioned to using something like a Claude Code or a Codex where they're chatting with the agent. You can even still do that in cursor. I think most of us at Hedway are using, you know, a terminal-based workflow with tmux and, you know, maybe something like lazy git in the left pane and your chat in the right pane. At least that's one of the ways that I'm doing a lot. And I'm in the IDE less and less these days. But, you know, if you have an actual design that you're working from and you're not just quote unquote vibe coding or saying, hey, build me this thing and just hoping that it's going to grab UI somewhere, you do also have to still be in Figma. And I think the next level up from chatting and vibe coding is, you know, a lot of folks probably take screenshots of either a UI component that they see in a kit somewhere online or maybe of their Figma screen directly. And what zoom are you at in Figma? You know, what did you crop in or out? What particular button or element is visible in that frame or not in Figma? So it can get kind of dicey if you're relying on sort of that computer vision capability of the agents and the current frontier models. They're good, right? They're really quite good. And they can even measure pixels and figure out the rounding and all of that. But they don't necessarily understand the intention of a given component or how to compose a consistent design system holistically from a 10,000-foot view. They just understand you want this thing achieved. I will do everything I can to achieve it unless my context is high. Then I'll cut a few corners.

Right.

And, and then it, you know, can even fall further down the path there, even when you have specific Figma files that you're, say, sending a screenshot. So what's the answer to that from a design system perspective? I guess, Tim, I'll start with you to be able to not just, you know, have the shotgun approach of paste in a component from a website that you see, or even a screenshot of Figma. If you have a design system in Figma, but you want to use it inside of the context of your agentic workflow at a deeper level, how do folks go about being able to do that?

That's sort of the key question that I, I think folks are bumping into, that teams are bumping into right now. We all see the speed with which I can get a reasonable level of fidelity straight from Claude Code. If I just simply hand it a screenshot of a design, or I leverage Figma's own MCP, I get an even higher level of fidelity. Of that design implemented in my, in my code. But at some point, that model starts to fall apart because the language of your design system is specific to your organization or to your team. And it especially becomes an issue when you have multiple teams within the same organization. If you think about just a single team working on a singular product, you can sort of corral your agent to stay within the bounds of your brand standard or the language of your design system or some of the API of the components that you've created that represent the design system, you can keep it possibly on the rails, possibly within a single product. But if you start to— within the same org, again, if you have multiple products, it just becomes very, very difficult. And so what we've seen is when we leverage anything from an MCP that is specific to the design system that can speak the language of the design system. And so then connecting Claude to that design system MCP does the work of keeping Claude, keeping the agent on the rails of the design system. It's not guessing because it can get specific API information of the components that you're using, or it can get specific tokens that make up your design system. So MCP being one that might be a good fit for your organization. It might also— we've, we've seen something simpler, just a well-written agents file. Like if that agents file is detailed enough to describe your design system, that your agent is likely on the rails of your design system just from that markdown file. That's, I think, a more narrow case because typically a design system is bigger, like there's more context to a design system than would just fit in a single agent file. It is worth considering because it's, it's simple. One of the other challenges with an agents file is your design system's obviously it's living and breathing. It's going to continue to evolve and grow. And that agents file is static, whereas something like an MCP can be dynamic and can evolve along with your design system. So your agent's always getting relevant information. There's other solutions too. Like if you start to take, instead of a single agents file, you take a routing solution so that if your design system is robust enough, a request could come into your agent and then you can route that request to a more specific agent file or like a more specific context file. And then that context file might describe a specific type of component. Possibly it's like a layout category of, of your codebase. That layout information that's specific to your design system. Again, the agent could be routed to that, can add that context to the current session, and then should be able to get a well-informed result from, from the agent. But again, I guess the point being, like, if you don't have some context that's specific to your design system. The agent is only gonna get you so far. There are some very good options. You just, at this point, I wouldn't say you can prescribe one-size-fits-all options to your organization. You kind of have to evaluate the size and scope of your design system, where you're headed into the future as an organization, how many product teams you're looking to support. There's some pretty challenging questions to answer.

Well, what type of products too, right? Like, is it a mobile and web? Is it a refrigerator screen? I mean, who knows, a dashboard UI in a car, right? There's a lot of different things that we've done with design systems that span not just different desktop web applications or mobile devices, but other areas where you have digital UI as well. So I think being able to have a system and a set of agent files and a set of guide rails that can really help make sure that what it's creating isn't, you know, like you said, just, uh, its own best guess or in the training data is really super important. And I think there's the Figma MCP capabilities that you talked about, but if folks are just getting started and even don't have Figma, don't probably know what Figma is, but if you don't know how to use it well to create a full design system within the context of Figma, where everything is componentized and you can change something in in a component in Figma and it all cascades through just like code essentially. Has it been your experience that you could grab something like a ShadCN or Tailwind Plus with the HTML and JavaScript components, uh, or React if, if that's what you're coding in and give it some direction in those agent files, but say always use these components and sort of get a little bit of a hybrid there where you can say, here's my flavor of these stock components, and then what, you know, I guess would be the edges around that if you've ever tried something like that.

When Dan and I started on this most recent project, there was, I mean, there was a number of product teams that are looking to support both web and mobile, and they had existing products that some, I believe, were using Vue, some were using React, whatever your favorite is. And so, so it's not only the challenge of starting from scratch and we want to support some unknown architectural decisions from an engineering perspective that our organization may make in the future. Maybe we want Tailwind, maybe we want React, maybe we want something else, right? We want to give product teams some freedom, but you almost always, you're going to enter into a situation where there are existing products that you have to try to retrofit into. Into this without there being a ton of friction.

And then I guess the second layer to that question is how do you then get whatever system you're building within to actually create a reusable slice of code that could be a Vue component in Rails. It could be, you know, a React component. It could be whatever your particular system, you know, uses for encapsulating that, but I often find myself at least needing to say like, hey, that's great. You duplicated that again. Can we please abstract that somewhere? And so if you don't have a strong, I guess, context or setup or set of files or folder hierarchy that the agent is going to know about and that's going to be super obvious, you might find yourself having to continually prompt it and help it and correct and direct the agent. So. I was just curious, you know, and I don't know, Dan, if you have some thoughts on, on how you've seen that happen.

The great thing about all of this tooling is that it functionally behaves like another developer, right? It's, it's not just a process that goes off and, and does some black box magic. And then at the end of it, you get a thing. It tries to mimic what a developer would actually do. And so all of the things that you would put in place to help other developers, junior or senior, will benefit here, right? So creating good documentation is going to be super crucial to having any kind of success with this. And so what does that mean in the context of an agent? Like Tim mentioned, agents files is a really great place to start. If you're pragmatic about how you set up your system at the beginning, you're going to have a lot of success down the road. So coming into this, maybe we just have a theme, right? And we were, we're going to build a design system up around that. That's probably not super common, but I think a lot of people, that might be a lot of their understanding of what a design system is. And you can still get some of the benefits of a design system from even just that really simple base. Telling your, your agent of choice, whether it's Claude or, or whatever, in its own configuration file, that as you're creating components, make sure to extract them and add them to the agents file, that, that you start to build up this like global context that can be reused in every single session. It's very similar to like what a developer would do in a pull request if we said, hey, that's a, that's a great component you're using. We actually have that now in a couple places. Let's extract it and put it into something more reusable. I think that you're going to find that an agent will work with that tooling really, really well. And so like when Tim mentioned, we, we've had good success with agents files. Let me describe how our system in this client situation works. We're extracting all of the tokens that we need from Figma into one hard file that's split by multiple themes. And so a theme contains the same tokens and the tokens all have different values, right? So like your background color might have the same name, but the value of it might be different depending on the theme. And then that theme feeds into every component we've built, whether it's a button, whether it's a dropdown, whether it's a carousel, whatever. Every one of those is built up from like smaller atomic components. And because we're building this whole thing in React, they all have their own interface that we can document, right? So there's an API for every component that says how to use it. Just based off of how the props are named. And so it was very simple to take that entire definition of the design system from code and have our agent of choice, Claude, crawl through it and build out an agents file based on that. That's a very lightweight representation of the entire component tree with all of its props. And now that exists at a, at a high level that anytime I ask an agent to do a task, it's got that context at the very beginning. And so really without prompting, we are finding that if I were to like open a new agent session with that agents file and drop in a screenshot of Figma and say, can you build this? Or can you give me some JSX for this? It will grab the right components, even though it has no context that the component in Figma is the component over here. It can make the inference and it will grab the correct ones. And now because it knows the API of them, it will provide the right prompts. And so we're getting like, I don't know, shotgun approach with 90% accuracy for these things. So it's, it's all about, I think, pragmatism and how you would build up a system in a way that's going to support any new hire as they come on. And so can just considering that these agents are, are are extra resources on your team, extra people that are gonna need to know how to do the thing the right way, you're gonna find a lot of success.

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

That's interesting that you talk about sort of building up the context in an agent's file that is inherently already in the source code. And I've, I've heard some recommendations from people where, you know, don't list out your directory structure in your CloudMD or your agent's file or whatever, because A, it's going to get outdated and B, The agentic capabilities of the system are better at just saying like, list the directory structure. Now I have it and it's always gonna be live and updated. But I think the thing that you are exposing is A, maybe try and have AI help maintain the agents file for you so it doesn't get out of date. And B, it isn't just a directory listing, which would be repetitive wasted tokens, it's sort of an answer key to, uh, not having to scan and find all of the props and all of the different capabilities of a given component. Do you think the unlock that giving it those props and not just the names, uh, or like where's that line where you don't want to, you don't want to like replicate your whole code base, of course, in a, in an agent's file. That's a little bit of ridiculous piece, but.

And in our particular instance, the way every component is built as a separate package, and so the way like our agents file is representing them is not your repo parent, you know, packages, whatever. Like it doesn't actually have a context of the path. What it does know about is that this is like at product name slash button, and it knows that it can import those things whether it comes from, um, an npm registry or it comes from you know, a local instance of it, it almost doesn't matter. And I think your point about having the agent maintain it, I think that's critical. And that's one of those things that you would want to capture in your configuration so that way as you're making changes, you don't end up with any kind of drift because they're super good at following these rule sets and you can ensure that before you commit and push anything, that it's going to ensure that that documentation was updated correctly before it goes out the door.

One thing people might not have reached for enough yet is hooks. And so you can write rules in your ClaudeMD or your agent's files that say, always make sure you update the design system. But depending on where you are in the context window, it may have forgotten that that's important to do. And so I think instead you can write a hook that says like, anytime we write code in this folder, for example, make sure to check the agents file and see if we need to update any documentation. And then that will run deterministically when the file's changed because it knows that something has been updated. So I think maybe that's one way if folks are curious about how to help better have the system maintain itself, look into hooks.

Yeah, I think that's a really good callout. And just to extend what Dan was saying, what we found, and also back to your question too, John, about something like ShadCN, we've found using Adobe's React ARIA package as an example, if we use something that's foundational that can be applied, like accessibility, that's what it solves. Now, if we can use that as a foundation for most or not, if not all components that we create, we don't necessarily have to recreate that context for the model because it's coming from a known source. It's documented. It's well documented open source package. So we can build on top of that and not have to concern ourselves with all of the context associated with accessibility. And then keeping an eye on like, who's going to be the user of your design system from a developer perspective, cross-platform, make it friendly to React Native, make it friendly to web. We even made it friendly to a Swift project. And being able to create a, a pipeline so that information flows from one end to the other in a way that's agentic friendly, that, you know, reinforces your design system for an agent has been a huge unlock for us and, and for the client to be able to empower product teams to sort of make decisions. And not have to come back to us continually for changes or improvements.

Yeah. Starting with a strong foundation is, I think, one of the key things to having any kind of success with this, because the design system itself will then become a foundation other things are built upon. And so if you architect it well at the beginning with, like Tim said, accounting for accessibility, accounting for cross-platformness. It's not instant. It's not a, you get this for free, but the jump from like A to B, the jump from, we have a React design system and we want to have, you know, a corresponding Swift design system implementation is dramatically faster to implement than it would be if we didn't have that, that smart foundation at all.

So you just said something there, Dan, that I think is really interesting, a design system implementation. So that leads me to the question of what truly is a design system. And maybe this question has contextual and multiple answers, but is a design system or can a design system just be the implementation that you have within the context of say a solo coded application, or does a design system inherently require the ability for those pieces of UI to be applied in more than one context? And/or does a design system require a window into it visually through a design tool like Figma?

I think the design system from my perspective, I mean, it's, it sounds silly. And if you invert those two things, right, is a system that you build design with, meaning it has a set number of rules and practices and thoughts. Around how you do any particular thing. So I think it's, it's very easy to look at a UI kit and combine that in your brain with design system, but I think they're different. And that's why I use the term implementation, because at a higher level, the design system really should be a driving set of guidelines that inform designers of how they would build anything. And maybe it is an entire component system like we're using, but it might just be— it might just be rules. It might just be like the design's implementation of the branding guidelines with extra thought given to how you would use things in any situation. So usually we'll factor in, you know, spacing, accessibility, typography, color usage, things like that. But that doesn't inherently make it a UI kit that you can go use either. And so I think it, it does have to be more than just the implementation itself. Otherwise you're going to get potentially into a spot where that implementation can drift, right? If it doesn't have a rule set to follow, then anything goes.

So Dan, you were talking about design system. So I pulled it up here. The definition of a design system is a comprehensive framework of reusable components, standards, and documentation that ensures consistent efficient and scalable digital product development across an organization. Thank you, Google AI Search, pulling that from who knows how many different articles. But I think that's a pretty fair summarization. And what you said, you know, fits into that. The one thing I guess maybe that's a little bit of a question is, does it 100% require those coded components? Although this doesn't say coded necessarily, it just says reusable components. well, predesigned and coded elements. So yeah, I don't know, kind of interesting to determine what, uh, exactly qualifies as a design system.

I think if you think about it this way, the reason why it's more than just a set of UI components that a designer or developer can use is because the usage matters, right? One of the callouts there was, was documentation and standards. And so. It could be completely valid to have a screen that has nothing but buttons on it that are coded and designed according to design system standards. Like they have the correct spacing, they use the right colors, et cetera. There's like a higher level of standard that usually we see factored into the design system of, of how you would use this, right? Maybe there's the design leads has has gone through a lot of investigation and looking at what actually makes sense for the product or the organization.

You—

and we've decided we don't want more than 2 calls to action on the screen. So like there's ways that you could use components that seemingly are right because you're using the design system components, but you're actually like violating other standards that if they're not codified, you wouldn't even know about. And so that's where The overall tooling of all of it together is super helpful. And what we've seen be really, really successful just from a knowledge point of view is that our design team, they've created the components in design, but they've also documented usage and how you would use them correctly and how you would use them incorrectly. So you have both examples. That's super helpful for the designers then to like use them in their products and Ideally, you have this entire, like, lifecycle, right? Where it's like a design team comes up with the design system, the individual designers implement their designs according to the design system, the developers implement the development according to, like, what the design has, and it trickles all the way down. And you never have these questions arise of like, oh, how do I do this? Because everything tends to be one-to-one-to-one-to-one. All the way down.

It's an interesting proposition that you suggest there, where inside the context of an organization, a design system can help empower the various individuals with specific skills to collaborate more effectively together. And I think we've seen that for sure, uh, in the last 10 years of Headway, even way before agentic coding was a thing. And so now the speed at which features are coming to market, the design system really just helps empower that and it can help the individuals do their best work across their slice of what they need to do. But I'm also curious about that individual developer. And Tim, I know you're working on a project where you're kind of the solo creator. And the design aspect is something that you are— I don't know if this is a fair characterization, but coming up with on the fly, so to speak. Hey, what would I need on this screen? What should the interaction look like and do? And then the look and feel of it, right, and the implementation as well. Do you feel that a design system is important for that individual person creating a system with AI?

Yeah, 100%. It's so interesting to feel the slowness, the repeat work that happens when you're trying to build a product and design, right? Prototype some things, test some things, and then eventually adopt a new feature. When you're doing that without the guidelines of a design system, without the constraint of a design system, you just, you redo things. You end up looking at this form and it's not exactly the same as the other form. There's inconsistencies. The, the experience begins to show up as they continue to build out the product and it grows in scope. All of those inconsistencies become more common. And then I end up spending time correcting and redoing, and then I start to question, did that screen I developed, you know, 2 months ago, is that also, is that in need of attention? Whereas if I had some confidence that I had been staying within the bounds of a design system, I would, I just wouldn't be thinking about that stuff. I would be able to continue to push forward with, with the important aspects of product development. So Even for something like that, and even after I got to a place of, I like where this is headed, right? I've got this idea and I like where this is headed.

I'm going to continue on it.

I have paused and said, hey, let's, you know, with the help of Claude, let's extract some of the common design decisions that I've made into some reusable components. I'm sort of working backwards. It's not the most efficient way to do it, but it's still better for me to pause, try to begin to build up a design system before I continue to simply add new features and work, because it's only gonna cost me time in the future without that design system. No matter how crude it might be, it is still gonna help me as a solo developer on this product.

We've heard folks talk about the fact that one of the ways to get agents to work in longer loops, you know, if you want to think of it as a loop or just longer sessions where they're building more, they need some sort of backstop, some sort of test criteria. Did the thing get implemented correctly based on what you said you needed it to do? For example, in like a dropdown that also has a search, does it filter the correct dropdown that's currently exposed to the screen? And the agent could build a dropdown where the flyout menu comes and the second one shows up, but maybe the search is still focused on the first level menu, right? It technically has all of the pieces there, but they don't necessarily function correctly together because you may not have given it enough context or that backstop or those tests to be able to understand, did what I built actually function correctly? And I think what hopefully folks are starting to realize by listening to, to this and seeing other folks talking about design systems in the context of Agentic workflows is the design system is not only a backstop of, you know, did I build the component correctly? Because I would guarantee that if an agent built something and it didn't look right and you said, hey, did you use the, the component for that? It would go, oh no, you're right. Sorry. And then it would just go fix it because it would have the correct implementation at the ready. And hopefully you can strengthen your prompts and strengthen your agent's files and things so that it has more of that context like Dan talked about, so it doesn't accidentally create that form like you mentioned, Tim, that looks just a little off because it's, you know, looking at its past form entries and maybe a screenshot that you sent and inventing, reinventing the wheel. So adding this design system in addition to test criteria and verification can really help the agent not need as much handholding and not need you to say, hey, did the menu work correctly? Is the search filtering correctly? Because the components are already codified, like Dan said, to a spot where they're going to work if they're composed in an intelligent way. So directing the agents at Legos that it can put together with an instruction set versus just, hey, here's a bin of mixed mashed colors, good luck, which is, I think, kind of their training data by default. You really need to give them that instruction set. And so there's multiple ways to do it. Design systems are, are certainly one aspect that helps you be less in the loop without losing actual control. And I think that just increases your speed, increases the correctness of your workflow, and lets you ship more, better, faster. So I know we've got some other content coming out too around design systems. Our design team led by Billy Sweetman is going to be doing podcasting and some tutorials and blog posts and things. We do have the design system reset offer as a company at Headway. If you want us to come in and take a look at your design system and audit where you're at, what we think would be the most impactful thing for you to do immediately, whether it involves agentic coding or not, uh, we can definitely help level you up there. And we also have the design system course that you can take a look at and has a lot of helpful videos and other ways to level up your team around design systems. So I think that will wrap us up for today. Hopefully you've, uh, learned a few new things and if you have any questions, definitely hit us up. Thanks, Tim. Thanks, Dan. And we'll see y'all next time. Well, that wraps it up for today. If this content is helpful for you, it'd mean a lot to me if you could rate and review the podcast on iTunes or wherever you get your podcasts from so that we can help share this info with even more people. Until next time, I'm your host, Jon Kinney, and this is the Even Keel Podcast.