Design to Code Using a Custom Design System with AI

Hey, folks, I'm Chaitanya and I work as a Principal Engineer at Atlassian. I'm extremely happy to be here at React Summit today. Today I'm going to talk about the work I did at Razorpay where I worked as a Staff Engineer. And I'm going to talk about AI, UI, DS. Well, that's a lot of jargon. I wonder who created this title? Well, let's try to dive deeper into individual things and try to untangle it slowly.

First up, what is a design system? It's basically a collection of reusable components, patterns, and guidelines that help teams build consistent high-quality UI efficiently. Well, essentially you build good and you build fast. And that's exactly what we did at Razorpay. At Razorpay we built a design system called Blade and with Blade we were able to have a consistent look and feel across all of our products. We made reusable components about more than 65 plus components and patterns and everything that we were building was accessible right out of the box. And we saw about a 3x boost in designer and developer productivity. We were very happy with what we achieved and we loved Blade.

And that's when the AI boom hit us. And everybody started asking questions about do we really need a design system? Can AI do it better than the design system? Can we just replace the design system with AI? And that got us thinking and we started toying around with AI. And what we found out is that AI knows a lot. It definitely knows React and it knows TypeScript. So we asked it to build a UI. And it did a decent job. It actually built some UI but it looked like a college project. What we realized is that AI is good at building UI code really, really fast but it can't generate good UI code really, really fast. And now I know this is very controversial, right? How do you define what good UI code means? So that's what we asked ourselves at Razorpay. What does good UI code mean for Razorpay? And the answer was simple. It needs to be consistent across our products. It needs to be reusable and it needs to be accessible right out of the box. And this sounded awfully similar to something that we were already trying to solve with our design system. And it hit us that design systems and AI are a match made in heaven like Romeo and Juliet minus the tragic ending where the design system will ensure that whatever you build, it's good and AI will help you do it really, really fast. So naturally we just asked AI to use our design system and to its credit, it did a decent job because Blade is already open sourced. It has some fair bit of understanding on how to use Blade. But we ran into a bunch of errors that we were not able to solve and we started asking ourselves why did it fail? But we realized that AI knows a lot, but it doesn't know much about our design system.

So we can't just say that, hey, go ahead and build a login page. We need to tell AI to use these specific components. We need to tell it the documentation of these components. We need to give it a few examples of how to use these components. And we need to give it some instructions about our internal coding practices. So we built a very detailed prompt to help AI understand how to build a simple login page. It had a really nice structure. It had tasks, guidelines and context, which helped make it very simple for AI to understand how to build a UI. But this is extremely tiring to do every single time. And some developers would even argue that it's easier to just write UI code than to write such detailed prompts for AI.

What would our dream prompt look like if we don't want to write such long, detailed prompts? What if we could just ask AI to build this? Just give it a Figma link and ask it to figure out how to build the exact same UI from Figma. What this would ensure that we are leveraging the expertise of our design team and we're not relying on AI to come up with a new design. It will ensure that we are not writing detailed prompts for AI and we spend most of our time actually focusing on the business logic. This sounds quite magical, right? Let's actually see if this actually works in action.

So here I have a Figma design of a simple login UI. I'm going to copy the link to the selection of this Figma design and give it to Cursor, which is our preferred IDE, and ask it to build this design. It's going to do a bunch of stuff on the right side that we're going to ignore for now. And it generated a bunch of code that we've accepted and all of this code is coming directly from Blade. And if we try to run this code, it looks exactly like the UI design that we had on Figma. That's absolute magic. But how does it actually work? So we have our Cursor IDE that talks to Blade's MCP server, which in turn talks to Blade's AI server. And this is how it actually works. To understand this better, we'll have to dive into individual pieces. So Blade's MCP is a Model Context Protocol. It's a standard protocol for AI models to connect to different data sources and tools. Think of it like a USB port for AI. It makes connecting to new data or tools simple and universal. It works in a client server setup, where you have MCP clients like Cursor or Cloud Desktop, and you have MCP servers like Blade's MCP, which provide very specific data or features. And this is still a lot of jargon, and it's hard to understand what it actually does. How I understood it as if you have Alexa at home, and you ask Alexa to play uptown funk, Alexa is hopefully not going to sing the song herself.

She's going to reach out to a music provider like Spotify, and ask Spotify to play the song. But if I ask Alexa what the time is, Alexa already inherently knows the time. It doesn't need to reach out to anybody to get this answer. So it's just going to tell you the time. If you ask Alexa what today's news is, it's going to reach out to a news provider like CNN and read the news briefing to you. So this connection of what and how to connect to is what MCP does for AI.

So instead of Alexa, imagine you have your Cursor IDE. If you ask Cursor how to build a login page with Blade, it knows that it needs to reach out to Blade's MCP to understand how to actually do this. If you ask it what's a promise in JavaScript, it already inherently knows what promises are, and it doesn't need to reach out to any other service provider for this. If you ask Cursor to disable this Blade button, it knows it again needs to go to Blade's MCP to figure out how to disable this button. If you give it a dream prompt, which is build this Figma link, it knows it again needs to go to Blade MCP to figure out how to build this. So we realize that Blade's MCP has a few very specific tasks. It needs to understand how to use specific components, and it needs to understand how to convert Figma to code. So we built two separate tools for two specific tasks.

First tool is get-blade-component-docs, which simply gets documentation for any Blade components. And second is get-figma-to-code, which converts Figma design to code. So the get-blade-component-docs it takes comma-separated component names as input, and it gives the actual documentation of all the requested components as output. So let's see this in action. So here I'm gonna ask Cursor how to disable this button. It made a tool called to get-blade-component-docs tool. And if I look at this tool call, the input is the button component and the output is the actual documentation of the button component. And that's how it figured out how to disable this Blade button. Similarly, Blade's Figma-to-code MCP tool, here the input is the Figma URL where what's important is the file key and the node ID that's part of the Figma URL. And output is the actual UI code written with React and Blade. So let's look at the earlier example that we saw, but this time a little bit slowly. So I'm gonna select the link to this design, ask Cursor to build this. Now Cursor will actually reach out to Blade's MCP tool. Here's the tool call, the input is file key and node ID. And the output is the actual React code that's built with our design system. Cursor realized that it needs to get a few more details about some of the components, so it's making another tool called to get Blade component docs.

It's got the documentation that it needed. Now it's trying to figure out where to place this UI code. It's realized that there are some linting errors in the code. It's fixing those errors, applying all the changes and letting you know all the changes it has made. All I have to do is accept the code and run it. And the UI code looks exactly like the Figma design.

The big question still remains about the tool call that gets Figma to code. How does this transformation actually occur? When Cursor makes a tool call to Blade's MCP server with the file key and node ID, Blade's MCP server forwards this to an API named Figma to code on Blade's AI server. The magic unfolds as Blade's AI server communicates with Figma and OpenAI to generate the UI code. By engaging with Figma, the AI server obtains the UI design screenshot and JSON representation, which is then processed to understand components and their documentation.

Additionally, the AI server interacts with an LLM to delve deeper into the design. It requests information on component hierarchy, positioning, alignments, spacing, colors, and text content. This detailed UI description is stored alongside other contextual information. To culminate the process, the final step involves constructing a prompt that transforms the Figma link into UI code. This task involves structuring tasks, guidelines, and context to achieve the goal of generating UI code from a UI screenshot and description.

So first we take the design screenshot and keep it in our context store. Next we fetch the JSON representation of the Figma design. So just like how we have an HTML representation of every web UI, we also have a node representation of every Figma design. But it's a bit complicated and it's not easy to understand for humans or AI. So what we did is we did a bit of data massaging here to make it a little more clearer. In this example, you can see the component name is text input and you can see all the props for the text input that are also there in this Figma design. We will also store this in our context.

Next because we know the JSON representation of the design, we also know the list of components that are used in this design. And because we know the list of components that are used in the design, we can also fetch all the documentation for all of these components and put it in our context store as well. Now we're going to send the design screenshot to an LLM and ask it to describe what it sees in detail. We'll ask what the hierarchy and grouping of the components look like, what the positioning of the components are, what the alignments of the components are, what the spacing between the components is and if there are any colors in the design that it can see and if there is any text content in the design. And we're going to take this UI description and store it in our context store as well.

Finally, we are going to actually build the prompt that's going to convert our Figma link into UI code. So here we are going to have a structure of tasks, guidelines and context. We have the task which is to generate UI code given a UI screenshot and description. We have very detailed guidelines on how to use the components, how to use the prompts, what the import rule should be, how to build layouts with Blade and how to convert a Figma node into a React component with proper prop mappings and what output requirements that we expect from this. And we're going to take all the context that we collected and pass it here in the system prompt. And with this entire system prompt, we're going to invoke a call to LLM and this is where the actual conversion of Figma design to UI code will happen.

So to recap, the Blade AI server will talk to Figma and get as much design context as possible. It will talk to an LLM, it will pass all the instructions, design and component context and get the actual UI code that's written with our design system. So when we build both of these tool calls, we realize that we are not just building for engineers, we're also building for non-engineers who are now builders at Razorpay. So we didn't just stop at these two tool calls. We built a tool call that gives you an overview of what Blade is, a tool that helps create cursor rules, a tool that gives you general documentation of Blade, a tool that gives you documentation for patterns of Blade, a tool that helps you scaffold a new project using Blade. And the best part is that all of this is available in the open source.

Since Blade is open source, our Blade MCP is also open source, so you can go to this link and check out all of these tools and how we've built them. And the real magic happens when all of these tools work together to build something beautiful. Let's see it in action. So here I am asking Cursor to build a simple dashboard using Blade. It's making a tool called scaffold a new project. It's inserting some cursor rules and actually starting the project. Now it knows that because this is a simple dashboard, a dashboard needs a top navigation and side navigation, as per Blade's guidelines. So I'm trying to build this dashboard out, figuring out where to place this, fixing some basic errors that it finds, and now spinning up the server.

And we actually have an interactive dashboard with proper top navigation and side navigation that aligns with Razor based design philosophy. But the main content area is still empty. Let's try to fill up the main content area. Let's actually pick up a Figma design, copy a link to this design, and let's ask Cursor to build this design and put it in the main content area. Now Cursor is making a call to get Figma to code tool call. We've got the UI code, Cursor is figuring out where and how to place this in the main content area. Awesome, we actually have the design already placed there. We're going to ask it to put a heading in the main content area. What we realize is that the button is still not interactive, it does nothing. It's an add additional website button, but it's non-functional. So let's ask Cursor to actually make that button functional and add additional website flow. And this flow needs to adhere to Razor's design language. It needs to have a stepped form group. So it's reaching out to Blade's pattern docs tool call, and it's getting patterns for creation view and form groups. It's got the documentation for these, now it needs to contextualize it to add additional website flow. It's doing a bunch of stuff, figuring out how to create a form group.

Now if I click on the add additional website, there's an actual flow that's working and not just a dummy flow. It has validations and everything in place. And all of these patterns are as per Razorpay's design language. This is completely functional. And within minutes we were able to not just create a simple dashboard but actually have it being functional.

Now all we need to do is hook this up with our APIs and this should be ready for production soon. And that's how all of these tool calls will work together to actually build something beautiful that not just engineers can build, but also other builders in our organization can. And that's how we didn't just leverage AI in our design system, but we fundamentally changed how engineers and other builders interact with our design system and leverage AI to build products with our design system.

Throughout this process, we faced a lot of challenges, a lot of pivots. We started off as a Figma plugin and eventually moved to becoming an MCP. We wrote a bunch of evals to measure the generation accuracy and have it constantly improve over time. We realized that we need to possibly integrate with white coding tools like Replit and Lovable at some point. We realized the importance of documentation and we want to keep improving the accuracy with strategies like design chunking that we're already working on.