Smashing Insights on Building Design Systems with AI

Finding the right process for a dev handoff has been part of our jobs as designers for quite some time now, so how hard can it be to prepare design systems for AI? Should be fairly easy, right? While MCPs are already good at transferring single modules from Figma to code, feeding the right context about a whole system and creating an AI-proof structure can be a craft in itself.

Outside Inspiration, Inside Perspective

Last month our UX team gathered in Amsterdam to attend the SmashingConf and fueled themselves with new insights on the interplay of AI and UX processes. One of the highlights was a hands-on workshop called Building Context-Based Design Systems for AI-Driven Product Teams by TJ Pitre that taught us more on how to guide AI to create structured output instead of artificial chaos in the codebase. So here are the key takeaways and learnings that we collected along the way.

The CBDS Lifecycle: A Quick Overview

TJ introduced the concept of a Context-Based Design Systems lifecycle, a four-stage process that bridges the gap between your design system and AI-generated output.

• Structure: Setting up your tokens, naming conventions, and component anatomy

• Connect: Where tools like MCPs and Storybook documentation come into play

• Generate: Where AI actually produces code and UI using your system

• Validate: Closing the loop by linting, testing, and verifying the output

Simple in theory, but as we found out over restructuring our UX processes in the last few months, the quality of what comes out is only as good as what you put in. It's also worth noting that this is not a linear process. You'll find yourself validating before generating, looping back to structure when something breaks, and iterating constantly. We like to think of it less as a checklist and more as an iterative loop, as every design process ultimately is.

Linting: Cleaning Up Before AI Steps In

Even in the most well-maintained design systems, things slip through. Broken token connections, wrongly named layers, components that work visually but fall apart under the hood. Cleaning all of that up manually is not only time-consuming but also far from the most exciting part of the job, and you'll likely still miss a thing or two. Now imagine handing over a messy system to an AI. Spoiler: it won't quietly ignore and fix the issues for you.

TJ introduced FigmaLint, a free open-source Figma community plugin that audits your components against design systems best practices. It scores your components and the target is 95 or above before you even think about handing anything off to development, or telling Claude to do so. We tested it on our own design system and it was both humbling and incredibly useful.

The takeaway here is simple: before AI can do anything useful with your system, your system needs to be clean. Linting isn't a new concept, but the bar for what "good enough" means just got a lot higher.

Descriptions: Writing for AI, Not Just Humans

Here's something most of us are guilty of: leaving component descriptions empty, or filling them with something vague like "button component" and calling it a day. When a fellow developer is the consumer, they will most likely figure it out. They'll look at the component, use their context and prior experience, and move on. AI can't do that.

For a Context-Based Design System to work well, every component needs a clear, purposeful description that tells AI exactly what it is, when to use it, and how it behaves. Think of it less as documentation and more as instructions for a very literal-minded colleague. The more precise you are, the less room there is for AI to improvise in ways you didn't intend.

It's a small habit change that has a big impact. Going back through your component library and writing proper descriptions is not the most glamorous task, but it might be one of the most valuable things you can do to get better AI output.

Context is Key, But Leave Room to Breathe

If linting is about cleaning up your system and descriptions are about being precise, context is about giving AI the bigger picture. The context setup is essentially a directory of Markdown files that contains everything AI needs to know about how your system works: coding best practices, token usage guidelines, writing standards, change logs and more. Think of it as the house rules, written down so there's no room for misinterpretation.

The key is consistency. Always using the same structure in your context files means AI knows where to look and what to expect, which directly translates into more predictable and reliable output. For our latest projects, we set up our own context directory and the difference in output quality was immediately noticeable.

That said, one thing TJ emphasized and that resonated with us is to not over-constrain your prompts. Give AI clear instructions, but leave some room to breathe. Start with less, see where it lands, and then iterate. Over-directing early on often means you miss better solutions that AI might have surfaced on its own.

AI is a Tool, Not the Boss

At the end of the day, the biggest takeaway from the workshop wasn't about a specific plugin or a perfectly structured context directory. It was a mindset shift. AI is incredibly powerful when it has the right system to work with, but it is always a tool. It doesn't make decisions, it doesn't have taste, and it is not in charge.

What the CBDS approach really teaches you is that the quality of your AI output is a direct reflection of the quality of your design system. Clean components, meaningful descriptions and well-structured context don't just make AI work better, they make your whole system better. The work you put in upfront pays off on both ends.

So to circle back to where we started: how hard can it be to prepare design systems for AI? Turns out, not that hard. If you're willing to do the work.