On Theme: Design Systems in Depth

What to do with AI on your design system right now (and make a better way of working)

• Elyse Holladay • Season 2

Share episode

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 23:25

There’s so much happening in the world of design systems: so much noise, so many new tools, and so much pressure. Where to start?

Building on what I wrote on the Zeroheight blog, in this minisode I’m offering tactical suggestions for cutting through the noise.

I cover the three areas you should be focusing on in your design system right now—MCPs, skills, and agents.md; how to get started designing with code; and defining design guidelines and semantic components—plus a detour into governance and ways of working.

But the bit that’s occupying my brain space right now is that I believe that design system practitioners are uniquely positioned to help organizations change how they work with AI, because we own the layer that says: this is how you build UI and how design and engineering collaborate. 

Maybe the most important thing that you can be doing is thinking about how you can help your product teams think about what it means to build products today, and how we do it.


Resources

📲 Send me a text!

Support the show

Why design systems are well-positioned to help change how we work

1: Creating agents.md, skills, and MCPs

A brief interlude about Figma

2: New ways to create with the system & design with code

3: Defining design guidelines & semantic components

4: Governance

Change is opportunity

Elyse

Hello and welcome back to On Theme. This is Elyse, and in today's minisode I'm diving into some practical, immediate things that you and your design system team can be doing with AI right now. There's so much noise, so many things to pay attention to, but I have some suggestions for how to begin transforming your design system team's deliverables, and actually help change your organization's way of working. This is On Theme, Design Systems in Depth, and I'm Elyse Holladay. Together, we'll be exploring how successful design systems get built, maintained, and deliver impact. let's dive into the show. I would be remiss if I didn't start by saying what works for you and your team is different than what is gonna work for anybody else's team. Before you take action on any of these suggestions, you need to think about what your team's problems are and where you actually wanna apply effort and what success looks like. Despite all of the hype, AI is just a tool, and if you wanna be successful using any tool or any process, you first have to define both the problem and what success looks like. That's particularly challenging right now because there's so much noise, so much hype, so much pressure to ship, and pressure to not think about how you apply AI, but just to simply use it. The idea that using AI will self-evidently be good, is pervasive and wrong. I think we're doing ourselves a real disservice if we just take the ways that we've been working, put an AI on it, and assume that that will somehow make everything magically better. But the last 15 plus years of software development collaboration is built around the idea that execution code is the hard and expensive part. Now that it's not, or at least less so how do we work together? How do we do the activities, we must do: define the problem, research and synthesis, ideation, trade-offs and constraints, iteration. And is it possible to do those activities in a different place in the workflow, or on different timescales, or in a way that might actually be more collaborative and human, rather than less? I genuinely believe that design system practitioners are particularly well positioned right now to help their organizations change how they work with AI, at least in the design to build phase. We own the layer that says, this is how you build UI, and not just, this is how you build UI, but this is how we hand off between design and engineering, this is how these two functions are supposed to work together. And design system teams have insight into that across product teams, across an organization, and I believe we actually have a lot of opportunity and power right now to say, this is the new way we wanna work. This is the way that's gonna get the best outcomes. And I know it may not feel that way. Things are moving very quickly. Your PMs are out there using Lovable and trying to give that code directly to engineers. Everybody's trying to ship some slop. It is just a really wild moment. Erika Flowers put it really well. She said, quote, vibe coding is pointing an AI at a screenshot and saying,'make this'. No architecture. No systems thinking. No intention beyond,'that looks right'. And she calls the output,"pretty, fragile, and disposable," things that break the moment you need them to scale or survive contact with real users. But that's not the only option. And I know it feels out of control, but having control over the process, and being able to control everybody's behavior is not a state you will ever experience. We still have ways to influence the design engineering process to build relationships and trust with people at your company, and show them the value of a better way of working. So with all of that said, let's dive into some things that I think you should focus on tactically right now. First, getting some design system guidelines and skills into your codebase. Discovery and education have always been a core pain point for design system teams. You know, why, why don't people look at the docs? Why do they come in our Slack channel and ask the most basic questions? Now, we have MCPs, agent skills, and written design guidelines, and these are immediate ways that LLMs can help us address this problem. Regardless of where an engineer starts, if they pull in code from a design with code tool, or paste a screenshot in Cursor, if they're in the codebase and they're using an LLM, that LLM will theoretically follow the skills and guidelines that are provided. Perfectly? No, truthfully, I'm still seeing lots of misses, but I'm seeing more correct usage than before we had these guidelines. And this is true for an engineer who is working off a static mock, and it's also true for a designer or a PM using a design with code tool that understands your system. You hear every day on LinkedIn about how generated UI code is full of sloppy patterns, random hex colors, recreations of components you already have. And this is what you get if your teams don't have access to tools that understand your system. So this can take a handful of forms. If your design system is part of a monorepo and you do not version and package it separately, you can work with agents.md files and skills. Skills are small markdown files that help an agent understand exactly how to do an action. This is an a technical example, but you might write a skill that says, this is how you write a good component unit test. When you are building or editing a component, and a test needs to be written or updated, if you say update this test, it should find the relevant skill and use it to write this test. So this is a way you can bake into your codebase, how you like things to be done, whether that is for your design system team internally, building and editing components or skills for the rest of the organization to use on how to write good frontend code, or how to write good UI. There's also agents.md or agents markdown files, which are a little bit more like documentation, so a little bit larger in scope than a skill. I've written two agents dot markdown files in my design system, one around how to use the design system components in code, and another on how to write and edit components in the design system itself. And I find agents dot markdown files are more likely to be used than skills, although skills could be triggered manually by a human too. So skills and agents.md docs for inside your design system, and if you're in a monorepo, the same for how to write UI with your system. But if you are in a multi-repo setup where your design system is separately versioned, packaged, and installed into other project repositories, you probably need an MCP, or Model Context Provider. Model Context Provider is what lets your product codebases reference the information that is in your design system in a deeper way. So getting your product teams access to an MCP, whether that's Zeroheight or Knapsack, or an MCP you build yourself, gives your developers access via agentic workflows to the design system documentation you already have on your doc site right now. We have long talked about design system documentation as all the information a designer or engineer needs to build UIs correctly, consistently, efficiently, you know, following your design guidelines. But we've also been relying on our engineers and our teams to just go look that information up. And agents offer the promise of that information just being available on demand, without taking the additional action of going to research it. I love to talk about flow state. I really believe that this kind of information needs to be available in the tool your designer or engineer is using. And if you don't provide that information right in the flow, they likely won't go seek it out and you're letting them fly blind. You also need to establish a feedback loop, and stay focused on whether or not those agents files and skills and MCP calls are actually working. Because the agents interpret these guidelines in natural language, they mess up. They don't always get it right. They don't always call the skill. Having these does not mean that every single output of the generated code will be great, but it can be improved, and you must get some visibility here. If you don't know what output is being created off your guidelines, you are missing out on an opportunity to substantially improve those outputs. You are not building this documentation one and done, shipping it and just assuming that your engineers and agents are always using it. So there is a feedback loop that must be happening. All right. A brief interlude about Figma. It should not come as a surprise to you that I'm not actually gonna talk all that much about Figma. There are lots and lots of people out there on the internet talking about how to go back and forth between the canvas and code. TJ Pitre is doing some really interesting work here. And if that is a substantial part of your process, if you are very Figma first in your organization, this may be worthwhile for you to explore. It is my personal bet that we will spend a lot of energy trying to go back and forth between code and Figma, and at some point in the next 6, 12, 18 months, design canvas tools that are built on code instead of a vector platform will become sophisticated enough that we won't have to do that anymore. That's a bet I'm making. I might be wrong. Maybe Figma will figure it out. But right now the vector-based canvas will never be a substantial enough representation of what the code can do. I know that the design with code tools are not totally there yet today. Even at Color where we've been adopting this philosophy, we are still in the messy middle of being between Figma and Dessn. There is absolutely still value in a blank page, in drawing, and freely moving things around. I just think that we will soon be able to do it with code underneath. So that is where my brain is at with Figma, and that is why I'm not gonna talk about it a whole lot more. The second area is providing different ways, new ways, to interact with the design system and create new designs. If, like me, you're not going to focus on Figma, you do have to provide an alternative. That can be design with code tools, it can be a local or cloud development environment, or you know, something custom your organization builds yourself. But we need to let people create with the design system, not outside of it. I personally believe that one of the biggest promises of design systems was this idea that we could go from a wire frame to the system. One of the problems with going straight to something high-fidelity and this is a problem that existed long before AI is that high-fidelity locks you into one solution and one way of thinking. Because we can reduce the time it takes to create something high-fidelity, I think we can actually focus more on some earlier steps. Okay, we have a problem to solve. What are all of the constraints and requirements that we already know about? How do we define the problem? How do we define what success looks like for this design problem? Let's actually sketch out a whole bunch of options and you know, talk to some users and stakeholders. Try BalsamiQ again. Play in FigJam or Miro. Buy everyone a dot grid sketch pad. I've been playing with literally sketching components on paper and pasting them into Dessn. Get everybody in a room and do a collab session. So I encourage you to not just think about new shiny AI tools, but also think about old school low-fidelity tools as a really powerful part of your toolkit right now. Once you have ideas, you have a faster pathway to building that in medium- to high- fidelity code, which is closer to how you might actually ship it. And that reduces back and forth and missed opportunities to discuss with Eng how things might work. But that also means you need to have some way for your designers, and yes, your product managers, to actually do some designing and prototyping in code. Regardless of the tool you're using, Dessn or Paper or Lovable or Bolt or Subframe, or any of the other myriad tools that are out there trying to fight for market share right now, I think there are a couple of requirements you need to look at. And one is, can it use my system? And the other is how much product context does it have? The product context problem is the hardest one to solve because having product context means that the tool understands your business and your product needs. And right now, mostly that means having an understanding of your codebase. There are very few tools that are actually in your codebase. Right now, to my knowledge, the only design with code tool that starts in your codebase is Dessn, or something that you hand-roll internally. If you have a platform developer experience team that can build a rendered UI playground, or containerized dev environment, for your designers, then you are very well resourced. For constrained industries like health and finance where security and privacy matter a ton, having integrations between internal data tools and agents is really tricky, so building over buying may suit you. Tools like Lovable or v0 are building an application sandbox, and they might be able to install your design system as a versioned and packaged npm package. But that doesn't give them any understanding of your business or your product. It only gives them some understanding of your components, which is better than nothing, but we know the kind of designs we're getting out of that. They don't necessarily work for you and your business. You may also wanna give your designers and PMs actual local development access. So a containerized dev environment, or just getting them set up on the same development environment your engineers use. And you'll probably run into all kinds of exciting and interesting technical challenges and access hurdles to do that, and the value of that effort absolutely depends on your particular company. But either way, I think it is critical right now to allow designers to have access to the medium of code. Not necessarily because designers should become engineers, I don't think that's the point. But because without that access, you are cutting off your design and PM roles from a really important source of information about how your business and code actually work. At the very minimum, when designers and PMs have code access, it lets them answer their own questions about how things work, and that unlocks understanding. You can run an agent against your codebase and say, hey, the page that has this headline on it, and it has this form on it, what happens when a user with this persona goes through that flow? What page would they see next? And what would happen if I change that page? What would the effect be? And that lets them create solutions and changes to the product that are more realistic and better overall. Plus it gives them, the word of the year, their own agency, to solve problems, to dig into issues that they're seeing in the product, and really take ownership, not over the fancy screenshot mockup that they've made, but over the product that they're actually shipping alongside the rest of their cross-functional team. Another thing we should be focusing on right now, purely within the design system itself, is defining many of the unspoken design rules that go into our design system. We write all of this component documentation about, you know, when should you use an accordion versus an expandable list versus a card, how to use the properties. But we haven't spent a lot of time writing down many of our assumptions or unspoken implicit design rules about what makes our design feel like ours. I've given this example a couple times already, but one of our design rules is that we don't use the chip component to display to patients any information about their health risk. We do cancer screening, and we don't ever wanna put a bright, red, scary chip that says, you're at high risk for cancer. That is so unempathetic to how scary that is and how big of a deal it is in people's lives. But if you ask a agent without any of those guidelines to create a page for a patient that explains their risk for cancer based on certain genetic mutations, it will absolutely put a big honking scary red chip on there. This is one of those things that you cannot encode into the component itself, because the chip has to be able to be an error chip. We actually do have some other products that do wanna be able to show a red status chip, and in our case, we're built on Material UI; lots of existing component libraries have a chip that has semantic error color. So you can't even take the behavior out of that chip component. We need to put something in the system that says, when you use this component, here are some of these rules and principles that we hold around empathy, and here's some things we don't do. If we were able to change the component, instead of naming semantic, error, warning, info, success, we might name the chip colors semantically for different reasons. So if we could make this specifically a cancer risk chip, we would not say, you know, high risk equals red. We might put some other language around that. So that when you go into an agent with natural language and you say, show the patient that they're at higher risk because of this genetic mutation, it would not equate that with an error red state. So there may be changes to your components that you can be working on right now, naming, properties, composability, semantic relationships. I don't know what that looks like in your system, and I don't know exactly what these semantic relationships or usage schemas look like in practice yet, but I believe it's gonna be quite powerful and interesting. Murphy Trueman is the best thinker and writer on this topic right now, so please go to her blog, and look up her articles on how to think about components as semantic APIs and component relationship schemas. Defining the how and the why of the choices behind your design, these are the new deliverables. This written information sits alongside the components and docs we've already been shipping, and is critically important to getting good outcomes from LLMs. And it's not just for agents. Defining these design principles and guidelines helps your designers, and your engineers, and your PMs, make good design decisions themselves. We all know by now that engineers make design decisions. Product managers make design decisions. Now agents are making design decisions and we must be able to put some language and explanation around the kinds of things that we know from experience. This is not a matter of taste. These are explicit decisions that we have made as a design team. These are conventions, and conventions can be documented, conventions can be shared. And it is really important that we share these conventions, because the whole point of a design system is sharing those design decisions and conventions so that design can be consistent across the organization. And I don't believe that this replaces your job as a designer. There's a huge amount of design effort that goes into problem solving, researching, understanding, and creating something that actually works for your user and your business and all of it is so important. Creating the high-fidelity deliverable is just one small part. The last thing I wanna touch on here is governance. I'm gonna namedrop Murphy Trueman again. She had another really incredible article called,"Your Design System Might be AI Ready, Your Organization Probably Isn't". And in it, she's talking about what happens when, even if AI can generate a complete UI, and it's using the design system really well, the tokens are correct, the components are correct, but it doesn't solve a good user problem. It's actually kind of shitty. It's not nice to use and you're shipping something that has no value to your business or to your users. She says,"these aren't technical problems, they're governance ones, and most organizations haven't started solving them." So I think maybe the most important thing that you can be doing right now is thinking about how you can help your product teams think about what it means to build products in this year of our AI Overlords 2026 and beyond. Again, we don't necessarily have control over what all of our product teams are doing, but we do have influence because we own the layer that helps designers and engineers collaborate. And the designers and engineers who are thinking about what problem are we solving, what are the constraints of the business, what are the needs of the user? How does this actually solve the user's real problem and not just ship the org chart? Those people are so incredibly impactful, and those skills and activities are more important than ever. We cannot just say, we get to skip all of that problem solving and design thinking and design iteration, just because now it's cheaper to build things. It's not. It's not, oh, now I can prototype in high fidelity with my design system, therefore, I don't need to do the design feedback loop. We have an opportunity to shift where those design activities happen and how much of them we can do. Murphy writes, quote,"the collapse of roles is framed as progress, and maybe it is, but it's also a governance crisis that most organizations haven't been able to address." I said this in my predictions episode, but I think first we're gonna build a whole bunch of stuff, and then the narrative is gonna be, why does all this stuff suck? Not just even code slop, but why did we spend time building this thing that nobody wants, that isn't hitting our business goals. To me, lowering the barrier to exploring, understanding the code, working in your medium, is so exciting. We can have different discussions about accountability and ownership and collaboration and the way that we talk in our organization about how we build UI and the role of design is so critical right now. And we can bring the responsibility of quality, design quality, not just is the code good? Is the interface good? Are the pixels good? But is what we're building any good? We can bring that ownership to more roles. We are all building this thing together, and I want to encourage you to do these tactical things in service of working in a way that you genuinely feel is better. I know that it feels like the deck might be stacked against you right now, but I hope to be a voice of optimism in your podcast feed. I do believe it is possible to step into this moment of change. All change is opportunity. The future is not fixed, and I don't think there's just one future, in which roles have collapsed and quality has declined, and we're all shipping slop. I think there are so many more interesting futures than that, and I think we have an opportunity right now to begin to affect them from where we sit today. The specific details of how that is gonna show up in your company and your design system are so different. But I hope that this got some wheels spinning for you. I would love to hear what you are doing, what's working and not working, and how you are measuring whether or not those efforts are successful on your product teams. Stay tuned for more interviews. I have some incredible guests lined up, and as always, please get in touch. DM me, send me a note on LinkedIn. Send me an email. I always wanna hear from you and hear how things are going for you. Thanks for listening to On Theme. If you like what you're hearing, please subscribe now on your favorite podcast platform and at DesignSystemsOnTheme. com to stay in the loop. See you next episode!