Design Systems for AI and Agentic Development
Learn how to connect a design system to AI agents using MCPs, agent files, and structured component APIs. The Even-Keeled podcast breaks down what actually works in production.
Presented by
Key learnings
Design systems are more critical in agentic workflows, not less
Tim opens the episode with a clear-eyed observation: the benefits of a design system are amplified with agentic development, but so are the risks of not having one. If individual developers occasionally drift from established standards, an agent will do the same thing exponentially faster and at greater scale.
Dan reinforces this from direct experience. Working as a newer member on a client product team, he can rely on the design system he and Tim built together to ensure that everything he ships matches what design and product expect. When he layers agentic workflows on top of that foundation, the agent inherits the same guardrails instead of inventing its own.
Why screenshots and vibe coding only get your agent so far
Jon walks through the progression most teams are on right now, from tab completion in Cursor to conversational agents like Claude Code to terminal-based setups pairing tmux, lazygit, and a chat pane.
The common shortcut at the next step is pasting in a screenshot of a Figma component and asking the agent to build from it. Jon identifies where this breaks down:
- Zoom level, crop, and what's visible in the frame all introduce ambiguity
- Frontier models can measure pixels and figure out rounding, but they don't understand the intent of a component
- They can't compose a consistent system holistically from a high level
- As context windows fill, the model starts cutting corners without flagging it
The agent will do everything it can to achieve what you described. It just won't do it the way your design system intended.
Three ways to connect your design system to an agent
Tim lays out the practical options, each suited to different team sizes and design system maturity. There's no one-size-fits-all answer, and the right choice depends on how many product teams you're supporting, how many platforms you're targeting, and where your design system is headed.
Design system MCP
An MCP server that speaks the language of your design system gives the agent access to specific component APIs and design tokens in real time. Unlike a static file, an MCP evolves alongside the design system so the agent always has current information. This is the strongest option for multi-product orgs where keeping a single file up to date isn't realistic.
Agents file
A well-written markdown file describing your design system can keep an agent on the rails for simpler, single-product setups. The tradeoff is that it's static. As the design system grows, the file drifts unless someone actively maintains it. Tim notes this is a more narrow case, but worth considering for its simplicity.
Routing to context files
For larger systems, a routing layer can direct incoming agent requests to more specific context files based on the category of work. A layout-related request gets routed to a layout context file. This keeps any one file from becoming unwieldy while still giving the agent precise, relevant information for the task at hand.
How to generate an agents file with 90% accuracy out of the gate
Dan describes the specific approach he and Tim built for a client, which is the most concrete example in the episode.
The design system is token-based, with all tokens extracted from Figma into a single file split across multiple themes. Each theme contains the same token names with different values, feeding into every component in the system, from buttons to dropdowns to carousels. All components are built in React as atomic units with documented props, giving each one a clear, importable API.
From there, the workflow was straightforward:
- Used Claude to crawl the entire component tree from code
- Generated a lightweight agents file representing the full component tree with all props
- Stored that file as global context loaded at the start of every agent session
The result:
Drop in a Figma screenshot, ask the agent to build something, and it selects the correct components and passes the right props without being told which Figma component maps to which code component. Dan describes this as roughly 90% accuracy on the first attempt. The agents file acts less like a directory listing and more like an answer key, giving the agent what it needs to make correct inferences without scanning the whole codebase.
This is the kind of structured, agentic-ready design system foundation that connects directly to what Headway offers through design systems for development.
Keeping the agents file from drifting as the system evolves
Jon raises a practical challenge: even a well-structured agents file goes stale if code changes without corresponding documentation updates. Writing a rule in CLAUDE.md that says "always update the design system file" helps, but deep in a long context window the agent may forget.
Two approaches the team recommends:
- Have the agent maintain the file itself. Instruct it in configuration to update the agents file before committing and pushing. Agents follow rule sets consistently when they're part of the setup.
- Use hooks. A hook that fires when code is written to a specific folder can trigger a deterministic check against the agents file and prompt an update if anything has changed. This is event-driven rather than instruction-driven, which means it runs reliably regardless of where the agent is in the context window.
Jon also points out what the agents file should not be: a directory listing.
That's wasted tokens, because the agent can always list the directory structure itself and get a live, accurate result. The agents file earns its place by documenting component APIs and props, the things the agent can't easily infer on its own.
Building on well-documented foundations to reduce context overhead
Tim addresses a related question about off-the-shelf component systems like ShadCN or Tailwind UI and whether they can serve as a design system foundation in agent files.
The approach Headway has had success with is using Adobe's React Aria as a foundational layer. React Aria solves accessibility, and because it's a well-documented open source package, the model already has context for it from training. That means the agents file doesn't need to re-explain accessibility behavior for every component built on top of it.
The same principle applies to cross-platform architecture. Tim describes building the design system to be friendly to React Native, web, and Swift simultaneously. With a clean pipeline that flows design token values from one end to the other, the jump from a React implementation to a Swift implementation becomes significantly faster than it would be without that smart foundation.
A design system is more than a UI kit
Roughly two-thirds through the episode, Jon asks a question that surfaces an important distinction: what actually is a design system? Dan inverts the phrase usefully: it's a system you build design with, a governing set of rules, practices, and decisions about how to handle any design situation.
Dan draws a clear line between a design system and a UI kit:
- A UI kit is a set of components you can use
- A design system includes documentation and usage standards that define how those components should and shouldn't be used
- You can use the right components and still violate the design system if higher-level rules aren't encoded
Headway's design team on the client project didn't just create components in Figma. They documented correct and incorrect usage side by side. That documentation creates a one-to-one-to-one chain from design system to designer to developer, where no one has to ask how something should be done because the answer is already there. For agents, that documented rule set is exactly the kind of structured context that produces consistent, predictable output.
Design systems matter for solo developers too
Jon turns the conversation toward an individual use case, pointing to Tim's experience working as a solo developer on a side project where he's handling both design and development. Tim's answer is direct.
Without a design system, small inconsistencies compound as a product grows. A form looks slightly different from another form. A screen built two months ago may not match the current direction. More and more time goes toward correcting drift instead of building forward.
Tim describes pausing on the project to use Claude to extract common design decisions into reusable components, working backwards to build a design system retroactively. He's clear it's not the most efficient approach, but it's still better than continuing to add features without one. Even a crude design system reduces the cost of inconsistency over time and gives the agent a consistent instruction set to work from.
Design systems as a backstop for longer agentic loops
Jon closes the episode by connecting design systems to a broader challenge: getting agents to work reliably in longer, more autonomous sessions without constant intervention.
Agents need test criteria or verification to know whether what they built actually works. Jon uses the example of a searchable dropdown: the agent might build all the right pieces, but if the search stays focused on the wrong menu level, the components don't function correctly together. Without a backstop, the agent doesn't catch this on its own.
A design system serves as part of that backstop. If an agent builds something that looks off and you point it toward the correct component, it self-corrects immediately because the implementation is already in context. The framing Jon lands on is worth holding onto: give your agent Legos with an instruction set, not a bin of mixed colors and a wish. The design system is the instruction set. For teams looking to evaluate where their current system stands before investing further in agentic workflows, Headway's design systems and technical and code audits services are practical starting points.
For the design team's take on the same shift, check out the Intent & Craft episode Design Systems in the Age of AI Agents.
Transcript
[00:00:00] Tim Gremore: 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.
[00:00:18] Tim Gremore: And so, we just see the, the need for a design system, more than we ever have in the past.
[00:00:25] Jon Kinney: Hello and welcome to Even-Keeled the podcast about the craft of creating software and building effective development teams. I'm Jon 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.
[00:00:46] Jon Kinney: Today on the podcast, we cover how to actually connect your design system to an agent through cps. 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 agent's 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 solar developer building with AI as it does for a large product organization.
[00:01:17] Jon Kinney: Stay tuned and I hope you enjoy.
[00:01:19] Dan Diemer: 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.
[00:01:29] Jon Kinney: And you know, we even sell courses and things that help companies level up, uh, their design system capabilities, but. As we've been talking about AI and agentic capabilities getting more and more adapt here in recent months, and, and certainly over the last year, our workflow has really shifted into, a really strong hybrid, but leaning towards ai.
[00:01:51] Jon Kinney: Enable development and design. Design systems play an interesting role in helping enable that capability to be even more, uh, 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?
[00:02:09] Tim Gremore: that's well said. You know, it, it's interesting,
[00:02:12] Tim Gremore: 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 gonna do that exponentially more and, and faster.
[00:02:32] Tim Gremore: And so, we just see the, the need for it for a design system, more than we ever have in the past.
[00:02:39] Jon Kinney: Yeah. Dan, how have design systems helped you in your workflow recently?
[00:02:44] Dan Diemer: Yeah, as a, as a new member of a product team, with, uh, 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 gonna match the expectation of like, design and product because it's locked in, there's no questions.
[00:03:10] Dan Diemer: And so then when, when I use, um, AgTech workflows to help me. Complete tasks even faster or, or more efficiently. I know that we're not gonna 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 gonna be exactly what I anticipate and exactly what, our leadership will anticipate.
[00:03:42] Jon Kinney: What do you have against Purple gradient? Stan just bashing the training data over here.
[00:03:47] Dan Diemer: Just gonna put a ring on anything 'cause it glows and it looks great.
[00:03:51] Jon Kinney: Exactly. No, it's funny 'cause
[00:03:53] Jon Kinney: there are definitely levels to using agentic coding, right? There's, you can just tab complete in 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.
[00:04:09] Jon Kinney: You can even still do that in cursor. Uh, I think most of us at Headway are using. You know, a terminal-based workflow with tmux and, uh, you know, maybe something like lazygit in a left pane and, and your chat in the right pane. At least that's one of the ways that I'm, I'm doing a lot and I'm in the IDE less and less these days.
[00:04:27] Jon Kinney: but you know, if you have an actual design that you're working from and you're not just. Quote on Quote vibe coding or saying, Hey, build me this thing, and just hoping that it's gonna grab UI somewhere.
[00:04:37] Jon Kinney: You do also have to still be in Figma and I think the next level up from chatting and 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.
[00:04:52] Jon Kinney: Uh, 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.
[00:05:11] Jon Kinney: 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?
[00:05:32] Jon Kinney: I will do everything I can to achieve it unless my context is high, then I'll cut a few corners, right? Uh, 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?
[00:05:50] Jon Kinney: 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?
[00:06:10] Tim Gremore: 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 fig MA's own MCP.
[00:06:29] Tim Gremore: I get a even higher level of fidelity of that design implemented in my, in my code. but at some point, that model starts to fall apart
[00:06:38] Tim Gremore: 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.
[00:06:50] Tim Gremore: If you think about just a, 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 hit within the same org, again, if you have multiple products, it just becomes very, very difficult.
[00:07:21] Tim Gremore: And so what, what we've seen is when we leverage, anything from an
[00:07:26] Tim Gremore: 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.
[00:07:46] Tim Gremore: 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 simple, just a well-written agent's file.
[00:08:06] Tim Gremore: Like if that agent's 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.
[00:08:29] Tim Gremore: it is worth considering because it's, it's simple. one of the other challenges with an agent's file is your design systems. Uh, obviously it's living and breathing. It's going to continue to evolve and grow, and that agent's file is static,
[00:08:46] Tim Gremore: whereas something like an MCP can be dynamic and can evolve along with, your design system.
[00:08:47] Tim Gremore: So your agent's always getting relevant information. there's other solutions too. Like if you start to take instead of a single agent's file, you take a, 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.
[00:09:11] Tim Gremore: And then that context file might describe a specific type of component, possibly it's like a layout category of of your code base, 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.
[00:09:37] Tim Gremore: 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.
[00:09:54] Tim Gremore: 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 in
[00:10:06] Jon Kinney: 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.
[00:10:27] Jon Kinney: 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.
[00:10:45] Jon Kinney: 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 a component in Figma, and it all cascades through just like code essentially.
[00:11:03] Jon Kinney: has it been your experience that you could grab something like a, a Shad CN 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.
[00:11:28] Jon Kinney: and then what, you know, uh, I guess would be the edges around that. If you've ever tried something like that.
[00:11:33] Tim Gremore: 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.
[00:11:47] Tim Gremore: View, some were using react, Whatever your favorite is. And so, so it's not only the challenge of, you know, starting from scratch and we want to support, some unknown architectural decisions from an engineering perspective that our, our organization may make in the future. You know, maybe we want Tailwind, maybe we want react.
[00:12:09] Tim Gremore: Maybe we want. something else, right? We wanna give product teams some freedom, but you almost always, you're gonna 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.
[00:12:22] Jon Kinney: 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.
[00:12:32] Jon Kinney: A reusable slice of code that could be a view 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?
[00:12:54] Jon Kinney: And so if you don't have a strong. I guess context or, or set up or set of files or folder hierarchy that the agent is gonna know about. And that's gonna be super obvious. You might find yourself having to continually prompt it and, and help it and correct and direct, uh, the agent.
[00:13:12] Jon Kinney: 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,
[00:13:18] Jon Kinney: 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.
[00:13:45] Dan Diemer: Right? So creating good documentation is gonna 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 gonna have a lot of success down the road.
[00:14:04] Dan Diemer: So coming into this, maybe we just have a theme, right? And we we're gonna 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.
[00:14:23] Dan Diemer: telling your, your agent of choice, whether it's Claude or, or whatever in its own configuration file that as you're creating components, um, make sure to extract them and add them to the agent's file. That, that you start to build up this like, global context that can be reused in every single session.
[00:14:42] Dan Diemer: it's very similar to like what a developer would do, in a poll 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 gonna find that an agent will work with that tooling really, really well.
[00:15:01] Dan Diemer: And so, like when Tim mentioned we, we've had good success with agents files. let medescribe 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?
[00:15:22] Dan Diemer: So like your background color might have the same name, but the value of it might be different depending on the theme. And then the, that theme feeds into every component we've built, whether it's a 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.
[00:15:42] Dan Diemer: and because we're building this whole thing and 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.
[00:16:05] Dan Diemer: Crawl through it and build out an agent's 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 were finding that if I were to like open a new agent session with that agent's file.
[00:16:33] Dan Diemer: 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.
[00:16:54] Dan Diemer: And so
[00:16:55] Dan Diemer: 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 gonna support any new hire as they come on. And so, just considering that these agents 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.
[00:17:21] 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 product ideas to life through design, development and product strategy.
[00:17:45] 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.
[00:18:06] We've worked with startups in industries like Logistics, healthcare, FinTech, and EdTech, helping them solve their biggest software challenges. And here's the thing, no matter how complex your product is, we can help you gain clarity and get the job done together. We're so confident that we'll be the right fit, that we offer a 50% money back guarantee.
[00:18:28] 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.
[00:18:40] Jon Kinney: 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 cloud MD or your agent's file or whatever, because A, it's gonna get outdated and B, the agentic.
[00:19:02] Jon Kinney: 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 agent's file for you so it doesn't get out of date.
[00:19:20] Jon Kinney: And b, it isn't just a directory listing, which would be repetitive wasted tokens. It's. Sort of a 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?
[00:19:42] Jon Kinney: Uh, or like, where's that line where you don't
[00:19:44] Jon Kinney: wanna,
[00:19:45] Jon Kinney: you don't wanna like, replicate your whole code base? Of course. In
[00:19:48] Jon Kinney: a, in an agent file, that's a, little bit of a ridiculous piece.
[00:19:51] Dan Diemer: and in our particular instance, the way every component is built as a separate package, and so, the way like our agent's file is representing them is not, you know, repo parent, you know, packages, whatever, like it doesn't actually have a context of the path.
[00:20:06] Dan Diemer: 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. An MPM 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.
[00:20:28] Dan Diemer: And, 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. It's going to ensure that that documentation was updated correctly before it goes out the door.
[00:20:52] Jon Kinney: one thing people might not have, uh, reached for. Enough yet is hooks. And so you can write rules in your Claude MD or 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.
[00:21:09] Jon Kinney: 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 agent's file and see if we need to update any documentation. And then that will run deterministically when the files changed 'cause it knows that something has, been updated.
[00:21:29] Jon Kinney: So I think maybe that's, uh, one way, if folks are curious about how to help better have the system maintain itself, look into hooks.
[00:21:38] Tim Gremore: Yeah, I think that's a really good call out. And, and just to extend what, what Dan was saying, what we found, and also back to your question too, Jon, about something like Shad cn, 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,
[00:22:00] Tim Gremore: 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.
[00:22:18] Tim Gremore: So we can build on top of that and not have to concern ourself with all of the context associated with accessibility. and then, keeping an eye on like who's gonna be the user of, your design system from a developer perspective, cross platform. make it friendly to react native, make it friendly to web.
[00:22:38] Tim Gremore: 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 agent 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,
[00:22:58] Tim Gremore: Empower product teams to sort of make decisions, and not have to, come back to us continually for changes or improvements.
[00:23:07] Dan Diemer: 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 wanna have, you know, a corresponding swift design system implementation.
[00:23:46] Dan Diemer: Is dramatically faster to implement than it would be if we didn't have that, that smart foundation at all.
[00:23:55] Jon Kinney: 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
[00:24:08] Jon Kinney: 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?
[00:24:17] Jon Kinney: 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?
[00:24:33] Dan Diemer: 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, 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
[00:24:55] Dan Diemer: 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 informed designers of how they would build anything.
[00:25:13] Dan Diemer: 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 designs, implementation of the branding guidelines with extra thought given to how you would use things in any situation. So usually it will factor in, you know, spacing, accessibility, typography, color usage, things like that.
[00:25:40] Dan Diemer: 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 gonna get potentially into a spot where that implementation can drift, right? If it doesn't have a rule set to follow, then anything goes.
[00:26:02] Jon Kinney: 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.
[00:26:16] Jon Kinney: Uh, thank you Google AI search, pulling that from who knows how many different articles, but, uh, I think that's a pretty fair summarization and, 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 a hundred percent require those coded components?
[00:26:35] Jon Kinney: Although this doesn't say coded necessarily, it just says reusable components. Uh, well pre-designed and coded elements. So, Yeah, I, don't know. Kind of interesting to determine what, uh, exactly qualifies as a design system.
[00:26:49] Dan Diemer: 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 call outs 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.
[00:27:18] Dan Diemer: 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 lead has, has gone through a lot of investigation and.
[00:27:35] Dan Diemer: looking at, what actually makes sense for the product or the organization? You, and we've decided we don't want more than two calls to action on a screen. So like there's ways that you could use components that, seemingly are right, because you're using The design system system components, but you're actually like violating other standards that if they're not codified, you wouldn't even know about.
[00:27:57] Dan Diemer: 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.
[00:28:16] Dan Diemer: 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, life cycle, right? Where it's like the, a design team comes up with the design system. The individual designers implement their designs according to design system.
[00:28:37] Dan Diemer: 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.
[00:28:46] Dan Diemer: how do I do this? Because everything tends to be one-to-one, to one to one. All the way down.
[00:28:52] Jon Kinney: it's an interesting, uh, 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.
[00:29:14] Jon Kinney: 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.
[00:29:31] Jon Kinney: Creator. Uh, 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 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.
[00:29:48] Jon Kinney: do you feel that a design system is important for that individual person creating a, a system with ai?
[00:29:55] Tim Gremore: Yeah, a hundred percent. 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.
[00:30:20] Tim Gremore: 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 I 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.
[00:30:45] Tim Gremore: Then I start to question, did that screen I developed, you know, two 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.
[00:31:09] Tim Gremore: 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, I like where this is headed. I'm gonna continue on it. I have paused and said, Hey, let's, you know, with the help of, of Claude, let's extract some of the common design decisions that I've made into some reusable components.
[00:31:31] Tim Gremore: 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.
[00:31:51] Tim Gremore: It is still gonna help me as a solo developer on this product.
[00:31:56] Jon Kinney: 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. Uh, backstop, some sort of test criteria. Did the thing get implemented correctly based on what you said you needed it to do?
[00:32:17] Jon Kinney: For example, in like a, a dropdown that also has a search, uh, 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?
[00:32:35] Jon Kinney: Technically, uh. 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.
[00:32:57] Jon Kinney: 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.
[00:33:16] Jon Kinney: 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.
[00:33:31] Jon Kinney: Like you mentioned, Tim, that looks just a little off because it's, you know, looking at its past, uh, form entrees and maybe a screenshot that you sent in 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?
[00:33:55] Jon Kinney: Is the search filtering correctly? Uh, because the components are already codified, like Dan said, to a spot where they're gonna work if they're composed in an intelligent way. So
[00:34:05] Jon Kinney: 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.
[00:34:15] Jon Kinney: 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.
[00:34:39] Jon Kinney: So, I know we've got some other content coming out too, around design systems. Our design team led by Billy Sweetman is gonna be doing. some podcasting and some, tutorials and blog posts and things. We do have the design system, uh, 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's involves a Gentech coding or, or not, uh, we can definitely help level you up there.
[00:35:09] Jon Kinney: 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.
[00:35:27] Jon Kinney: Thanks, Tim. Thanks Dan, and we'll see you all next time.
[00:35:31] Jon Kinney: 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 podcast 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-Keeled podcast.