Design Systems and AI

Design Systems and AI have been on my mind all year. I thought I'd jot down some of my general thoughts on how to best serve Design System consumers by leveraging AI. This is something I'm experimenting with and will report back on as I learn more.

My ideal scenario for product engineers is to be able to go into Figma and copy the frame URL for a piece of UI that was built in Figma using the Design System. They'd paste the URL into an AI tool. The AI tool would have all of the context of the Design System – it'll know about all of the components and how to use them, it'll know about the variables, have access to all of the documentation, etc. – from there, the tool will generate the provided UI for the engineer.

It obviously won't be all of the code – it'll handle the visual building blocks though, which saves a bunch of time. Then the product engineers can worry about the "glue code". They'll handle data fetching, conditionally rendering certain things, and other scenarios. But they'll have a great starting point to spring off from. My thinking is that this would help accelerate development velocity and expand the usage of the existing Design System.

The first thing that comes to mind is feeding Figma as much information as possible. I've written about Figma Dev Resources before - this allows you to associate links to Figma components that show up in Dev Mode. It's helpful because it gives developers additional information.

The next logical step is to use Figma's code syntax feature for variables. All of those Figma variables you have? Convert them to CSS variables. Then write them back into Figma so that they show up in Dev Mode as the actual CSS variables you've generated. This way, when a product engineer is viewing designs, they can see the exact CSS variable names rather than the Figma variable name – these are normally slightly different due to syntax difference.

Lastly, wire up Figma Code Connect. I'm working with Web Components. So my plan is to use the Custom Elements Manifest to automate this. But no matter how you get Code Connect wired up, having these snippets available will save product engineers time. They can literally copy and paste snippets right into their editor for the component(s) in the exact designed state.

So now you're probably wondering "now what?". Figma Dev Resources, leveraging code syntax for variables, and Code Connect are all great. But what did that do for us exactly? Not only does this help Dev Mode and provide resources for your product engineers, feeding Figma all of this information gave it a lot of context. If you've been working with AI lately, you know how important context is for LLMs.

The next logical step is using Figma's MCP server. It's currently in beta.

Now that you've provided Figma all of this context on your Design System, I think we're really close to making my ideal scenario a reality with the MCP server. Time will tell, but I hope it'll do well. In theory, it should have a big chunk of the information it needs. Now of course, it may not gracefully handle cases that aren't using your Design System. But if it can get folks 70-80% of the way there, that's a huge win. This could go a long way in helping designers and developers.

What else could we automate and leverage AI for?

I'm thinking you may be able to create your own MCP server with a distinctly different purpose from Figma's. The role of a new MCP server wouldn't be translating the designs to code, but rather focusing on component usage and best practices. Going back to the Custom Elements Manifest, it could read from it and have all of the information it needs on the component APIs. It would know the attributes, properties, methods, etc., that are available. If you're not using a Custom Elements Manifest, there are other ways to get this information about your components (especially with React + TypeScript).

Now add on your Design System documentation on top of that. Best practices, when to use one component over another. All of this is additional context that would help it make decisions and increase confidence.

Folks are already using tools like Claude Code to build UIs. With this MCP server, my thinking is you could promote usage of your Design System. Rather than have it generate custom components from scratch, use what is already available, following the patterns that have already been defined.

Additionally, my hope is that providing an MCP server with this information would cut down on support requests. Fielding Design System support questions is really important. As a Design System engineer, we want to ensure our consumers get correct answers in a timely manner. If you can ask your AI tool instead, it very well may save the Design System team some time. And by providing it as much context as possible, hopefully the answer would be more correct and it'd cut down on hallucinations.

I can see the benefits of feeding LLMs with as much context about your Design System as possible. Not only may it increase velocity, I hope it'll also improve consistency in applications built and cut down on Design System support.

Overall, this is all just me rambling and some general thoughts I've been thinking about all year. I have no idea in reality if it'll work at all! But to me, that's the fun part. It's time to go find out and report back.