I've been seeing a lot of posts lately about using AI — literally everywhere. Most of them come from people who don't necessarily have access to code but are using AI to build out small, experimental apps. Don't get me wrong — those projects are super fun and creative, but they often stop there. They don't always consider the deeper foundations of design or product development and lean more on the side of "this is a new thing and I can build from scratch." My belief is that people should keep doing these, but having built out hundreds of features in my career, I started to think about how AI can be integrated into existing companies and into the design process itself, since a lot of products arent new and have complex applications.

Recently, during an interview, I was asked directly how I use AI in my work. My first response was the usual — for prototyping, synthesizing research, analyzing transcripts, etc. But when I thought about it more, I realized that in my last role, I actually used AI to build an entire design system in a real-world production environment. I thought I'd write about it because it was a really fun project and I think it's a practical way of using AI that integrates into existing systems and cuts tedious dev work out of the development workflow.

Here's how it worked on the surface:

Foundations: I created all the variables and tokens in Figma and connected them to our codebase through Cursor and Storybook. When I updated Figma, I'd run a script in Cursor that automatically updated Storybook. Then I'd check everything locally and create a pull request through GitHub — no engineer needed. (I did use one initially to set things up, but after that I was independent.)

Components (the "bricks"): Once foundations were set, I used Cursor to generate components — from simple buttons to complex toolbars. I'd prompt Cursor with detailed instructions like: "Create a button component using token #3 for border radius, include error states with X color, add interactive states, and use Tailwind CSS with React Aria base code."

Prototypes in dev environments: After building components, I could create interactive prototypes directly in the dev environment — no waiting for full development cycles. I'd prompt the AI with what I wanted, test with users in a real environment, and hand off mid-fi prototypes that were essentially production-ready since the foundations and components were already in place.

This workflow drastically sped up our process — we shipped a near 2.0 version of the product's UI in just about three months. That's lightning-fast for a SaaS product with complex data and ML integration.

At previous companies, it would take weeks just to build Figma prototypes — and that's all they were, static prototypes. Getting engineers to log into Figma and walk through flows was often clunky and time-consuming. With this new workflow, I could simply share a live dev environment with real components, button states, and interactions already in place. It made collaboration faster, clearer, and way more efficient.

This workflow was incredibly powerful because it let me manage quality, test much faster, and ensure design consistency in real time. My theory is that this same workflow could work even within companies that already have established design systems — you'd just start by rebuilding or updating existing components to sync with this process.

Below I have detailed out how it was done in detail:

Step 1: Choose your design system

If you already have a design system, you might want to skip this step. You can pick an off-the-shelf design system like Material UI or you can try to build your own. Believe it or not, there are a lot of things to consider when choosing a design system, so you want to strategize.

When choosing, there are two types of design systems to consider:

Step 2: Design your components

When starting to build your components, think about the strategy around how you want to build them. This philosophy goes even for your existing design system in Figma—you can always modify or run maintenance on existing systems without compromising the app, but it is definitely best practice to think about the strategy around your design system early on. It's a lot harder to switch over once it's baked in. Here are a few things to consider:

Step 3: Connect your components

Something to note here: when using variables, you absolutely need an Enterprise license in Figma to fully automate into Storybook. Build some of your components in Figma so you have an idea of what they will look like.

Now you will start building in Cursor. You can try to do this on your own or get help from someone on your development team. However, you can just ask Cursor to connect your tokens to itself.

Step 4: Build the Update Script

Now that your Storybook is connected, it’s time to automate the process. The goal here is to create a workflow that updates your code automatically whenever a token or style changes in Figma. This script will convert those updates into live, usable components—so your development team can simply plug and play.

This step can be a bit tricky (I definitely ran into a few challenges getting it to work), so don’t worry if it takes some trial and error. Give it a shot on your own first, and reach out to your development team for support if you get stuck.

Here’s a prompt to help you get started:

Step 5: Build the components in Cursor

Try to build them one by one and not the entire system. In general, I have found that trying to get it to do some massive task will cause it to completely fail and not build them correctly, so start smaller. Make sure when you do this that you are double-checking that it's similar to your buttons you designed in Figma. This is all about quality control here.

Future

The future of design is automated — powered by real code, not static screens. Once your system is fully set up, you’ll be able to design and prototype directly within real development environments. This means faster iteration, seamless collaboration with developers, and the ability to bring ideas to life without ever leaving production-ready code.

Too Many Layers

Using AI to Automate Design System Workflows