From Figma to TV & Beyond: Scaling React UI with Design Tokens & MCP

Hi, everyone. I'm Seungho Park from LG Electronics. Today, I'll share how we scaled a React UI across many platforms using design tokens and Figma. Our goal was simple, design once and scale everywhere. Let me briefly introduce myself. I'm leading web engine and web framework for LG devices. I'm the owner of the Enact framework, which is shipped on tens of millions of TVs every year. It's also open source. In my previous talk at React Summit, I shared production insights and case studies from TV UI development.

Here's what we'll cover today. First, why we need design tokens in the first place. Then, what design tokens are and how we structured our architecture. After that, I'll show our CI CD pipeline and how AI fits into the workflow. Along the way, I'll show you a few demos. Let's get started. LG ships a huge range of products. Home appliances, TVs, mobile apps, web, and much more. Each team built their own UI in their own way. The biggest problem was inconsistency with no central governance for the brand.

The design team introduced a design system, and my job was to turn those tokens into a real code library. What are design tokens? Design tokens are named values for design decisions, colors, spacing, typography, and more. Instead of hard-coded value everywhere, we use one shared name across all platforms. Here's what it looks like in practice. On the left, the color is hard-coded. You have to find every hex code in every file just to change one shade of gray. On the right, we use a token named instead. Change the value once, and everything updates everywhere. Our design tokens have three layers, primitive, semantic, and component. Primitive tokens hold the raw values like a specific array. Semantic tokens give those values a role like a button surface color.

Component tokens describe a specific UI element like a primary button's container. Each layer points to the one above it. We use one shared primitive palette across the whole company. Semantic and component tokens are defined per platform. Mobile, web, and webOS each have their own. This gives us one source of truth for brand colors, and at the same time, each platform keeps the flexibility it needs.

So with this structure, we get one single source of truth. In Figma, the designer manages all tokens in one place. Each platform picks the theme it needs through the Figma's mode feature. This is what made our design system actually scalable. We had the design tokens, but the next problem was keeping them in sync. We solved this with three roles working together.

First, the design team. They update the tokens in Figma and tag or release when they are ready. That's their only job in this pipeline. Then, GitHub Actions takes over. It fetches the latest variables from Figma, dips them against the current tokens, and converts them into the format we need. Then it opens a pull request automatically. Finally, the dev team just reviews the pull request and publishes the release. No manual copy and paste, and no waiting days. So how does the pipeline actually pull data from Figma? Figma provides an official variables rest API. It lets you read all the design tokens directly from a Figma file. We use the get local variables endpoint to fetch every token in the file.

Let's look at how we call it. This is the actual call we use. The full source code is on GitHub, linked at the bottom. During the action, it generates a diff of every change added, modified, and deleted. This diff is what the pull request is built from.

Let's see this in action. In this demo, you'll see the GitHub Action run end to end. It fetches the tokens, opens a pull request, and you'll see the diff right inside the PR. First, let's automate design token updates with Figma Sync. By linking the Figma variables API to GitHub Actions, any design change triggers a workflow to fetch and transform those variables automatically. Of course, you can run the workflow manually.

Now it's checking Figma variables using the Figma variable API. Once the workflow is complete, it generates a new pull request for the team to review. Looking at the PR description, the bot has automatically summarized exactly which tokens were added or modified, making it easy for developers to track changes. And in the File Change tab, you can see the actual updates. Our JSON and CSS files are updated with new design values, keeping everything in sync. Here's another benefit of using design tokens. Applying a constant theme across the app becomes really simple.

Because every component is from semantic tokens, swapping one file at the root changes the entire app's look. No component changes are needed. Let's see this running. In this demo, you'll see two screens side by side. The left monitor is the lge.com website. The right monitor is the WebStv's Home Hub application. Both use the design tokens we just talked about. Watch what happens when I switch theme. Light theme, now dark theme, and finally a Christmas theme. Both screens same theme every time. Two completely different platforms, but one consistent look. That's the power of a shared token system.

Design once and scale everywhere. So far, design tokens automated all the visual styling. Colors, spacing, typography, all handled. But there's still one piece left. Turning a Figma design into actual application code with your component. In a real product, you use external libraries like ShedCN, MUI, or Inet. Or you build your own components when you need to. So for the output to be actually usable, it has to be generated using the component your app already uses. That's the real bottleneck. And that's exactly what CodeConnect solves.

To solve this bottleneck, we use two pieces together. First, Figma MCP. It's an interface that lets an AI read your Figma file directly. The design, layout, the tokens, everything. Second, CodeConnect. This is where you tell Figma this component in the design maps to this file in our codebase. When you put these two together, the AI doesn't just see the design. It knows exactly which components to use to build it.

Here's the workflow end to end. It starts with a Figma design. Then, Figma MCP extracts the context, the layout, the components, the tokens. Everything in a structured form an AI can understand. Next, CodeConnect maps each Figma component to the actual file in our React library. And finally, the AI generates the code using your components.

The handoff that used to be a manual is now one continuous flow. This is Figma's own definition of CodeConnect. In short, it's a bridge between your codebase and Figma's dev mode. It tells the AI exactly which file in your repo each Figma component maps to. Full documentation is linked at the bottom.

This is CodeConnect UI inside Figma. What you are looking at is one of our actual app designs in Figma already wired up to CodeConnect. Here you can see how each part of this screen is connected. This screen is a pop-up style view, so I mapped it to an inactive fixed pop-up panel component. And inside the pop-up, I also connected the smaller pieces, the heading, the slider, and the buttons. You can point CodeConnect at a local file in your repo, or at a file on GitHub. Both work. Use whichever fits your team's setup.

Now, let's see all of this come together. In this demo, an AI agent used Figma MCP and CodeConnect to turn a Figma design into real React code, with the real components from our codebase. Let's watch. I'll start by pasting the design link and core instruction from Figma. To guide the agent, I've added three specific guidelines. Build with our app skeleton, use CodeConnect, and apply our design tokens.

The agent begins analyzing the project, linking the Figma data with CodeConnect to identify the corresponding Sandstone component. Sandstone is our component library for WebSTV built on Inet. The agent dives deep into the Sandstone APIs. It's not just looking for component names, it's analyzing the full component definitions. The goal is to find the exact props that match the design state in Figma. This includes everything from button sizes to panel layouts, ensuring every attribute is mapped precisely to our framework's capability.

Now, the agent checks if the required packages are available for install. Since they are missing from the environment, it automatically initiates the installation through the terminal. Once the environment is ready, it moves forward to implement the design, generate the module.js and main.panel.js files. With the code written, the agent runs InetPack to verify the build and check for errors in real-time. Once the task is complete, it provides a summary of all the components and styles it just implemented, confirming a successful implementation. Let's review the results.

As I hover over the code, you can see the real fixed pop-up panel component here and the button components here. In the last file, you can see the design tokens are imported and correctly applied to our semantic color variable. Now let's run the app that the agent just generated. The power icon is applied on the button. The brightness number updates as I move the slider. And the remote control's arrow key also works right out of the box. Here's the code the agent actually generated. On the left, you can see the generated app code uses our components correctly. It uses fixed pop-up panels, button, heading and slider, and each component has the right props applied. On the right is the styling file. The agent imported the design tokens we talked about earlier, and instead of hard-coded values, it used the token variable. So, everything connects.

The components are real. The tokens are real. Here's what to take away from today. First, structure your tokens for scale. Primitive semantic component, three layers, each with a clear role. With this structure, one design system can serve many platforms. Second, automate the pipeline. Don't copy and paste the tokens from Figma into code. Connect them with a CI workflow, so design changes become a pull request on its own. Third, leverage MCP for zero-handoff design code. Pair Figma MCP with Code Connect so the AI doesn't just see the design, it generates code using the real components from your codebase. Tokens, automation, and MCP. That's how we get closer to design-once, scale-everywhere.

These are all the references I used today. The most important one is at the top. Our token repo on GitHub. Feel free to take a look or use it as a starting point for your own. I hope this session gave you a practical insight into building React UIs that scale across many platforms with design tokens. If you have any questions, please reach out through the link here. Thank you for joining me today. Bye!