We built a Figma Plugin because AI design tools weren't built for Design Systems
A product designer's account of building Spark Kit at Light-it: 13 days, 30 commits, and a Figma rejection that taught us more than the launch ever would have.
Table of Contents
- What Is AI-Assisted Design using a custom design system?
- Why do AI design tools fail teams that already have a strong system?
- How design teams were using AI in 2026 (and where it broke down)
- The decision that started everything
- How we Were using the figma MCP before it was officially launched
- How spark kit works: The context-first design method
- Does a Figma plugin have to be published to be useful?
- Why your design system is the real foundation for AI-Assisted design
What Is AI-Assisted design using a custom design system?
“AI-assisted design with a custom Design System” means connecting a large language model to your team's documented rules: component naming conventions, spacing tokens, color semantics, variant logic, and structural patterns specific to your organization. Instead of generating generic UI from broad training data, the model reasons from your actual documentation and produces output that matches your system. The result is components that fit the team’s standards and require far less manual cleanup before they can be used in production.
That is the theory. Getting there was not a walk in the park. It required us to learn (more than we were expecting to), try, and build a tool. Is it published? No, does it matter? … Let me tell you more about our journey.
Why do AI design tools fail teams that already have a strong system?
Most AI design tools are trained on patterns from across the web. They know Material Design. They know common UI conventions. They can produce something that looks like a button, a card, a modal.
But they do not know your button. They do not know the naming convention your team agreed on two years ago, or why you structure your color tokens the way you do, or that your spacing scale follows an 8pt grid with specific intentional gaps. They cannot know any of that unless someone tells them.
Every time our team at Light-it tried to use a generic AI tool inside Figma, the output looked plausible and was contextually wrong for us. Wrong names. Wrong token references. Wrong variant structure. Most of the time we were supposed to save ended up being spent fixing the output.
The AI had everything it needed except context.
How design teams were using AI in 2026 (and where it broke down)
By early-2026, the AI wave had hit the design world in three directions at once. Figma launched its own AI features. The Model Context Protocol ecosystem expanded fast, making it possible to connect large language models to almost any external tool. ChatGPT and Claude had become daily utilities for half the people on our team.
We ran experiments. We tested prompt-to-UI tools. We tried Figma's built-in AI suggestions. We described components in plain language and asked models to generate them.
Every experiment produced the same pattern: impressive at a glance, unusable in practice. Someone always had to rebuild what the AI gave us before it could enter the Design System.
The real question was never "can AI generate UI?" It was "can AI generate a UI that matches how we work?" For most design teams in 2026, the answer was no.
The models were good. The information fed to them was incomplete.
The decision that started everything
At first we were all excited and trying different approaches (you can even read what we experimented on and tried here). But then, Light-it gave our team something that changed the direction of our efforts: dedicated time and a research budget to actually sit down and figure out how AI could work for us in practice, inside real workflows. That decision brought the design team and Light-it's AI department into the same room working toward the same goal.
We were not a group of designers experimenting on the side. We were a cross-functional team with a dedicated AI engineer, structured hours, and a clear mandate: figure out how to make AI work for our design practice.
What started with a small experiment was now an active project. I passed our Design System documentation as context into a Claude prompt and asked it to generate a component structure. The output was different from anything a generic tool had produced. The naming matched our conventions. The spacing references were correct. The variant logic followed our patterns.
The quality shift was immediate and specific. That told us we had a direction worth building.
How we were using the figma MCP before it was officially launched
This is the part of the story that still surprises people when we tell it.
Our AI engineer had been working with OpenCode, an MCP-based tool the team used for code-level work. He identified that the same MCP connection architecture could be adapted to point at Figma instead of a codebase. We found an open-source project called cursor-talk-to-figma-mcp that provided the foundation. Our engineer adapted it to work with Claude and OpenCode rather than Cursor, renamed the package assistant-talk-to-figma-mcp, and got Spark Kit connected to Claude's MCP roughly one to two weeks before Figma officially announced their own MCP server. This was on February 2nd, 2026
We did not know Figma was about to launch the same thing. We just knew the connection worked and we were already using it.
That early access came with friction. The MCP SDK itself was evolving while we built: we went from version 1.13.1 to 1.26.0 during the development sprint. Token budgets ran out faster than expected. We had to build reusable prompting patterns because improvising each prompt was too slow and too expensive. Every failed generation cost tokens and time. That pressure forced us to get precise about what we were asking for and how we were asking for it.
How Spark Kit works: The context-first design method
What we built is called Spark Kit. At its core, it is a Figma plugin connected to Claude through a WebSocket relay server and MCP. What distinguishes it is the context layer we built around every request.
The Context-First Design Method at Light-it works like this:
- Every request to Claude is preceded by structured documentation from our Design System: naming conventions, spacing scales, color token logic, component variant rules, and interaction patterns.
- Five strategic MCP prompts are baked directly into the AI context as reusable strategy guides (for designing from scratch, reading existing designs, bulk text replacement, annotation conversion, and prototype visualization).
- The designer writes a plain-language description of what they need.
- Claude executes against 30+ MCP tools that can read, create, style, and modify Figma nodes in real time.
- Output comes back into Figma matching the team's conventions, ready to connect to existing components.
The entire Design System can be generated in a single action: 407 variables across 8 color palettes, 99 primitive colors, 70 semantic aliases, 45 spacing variables on an 8pt grid, 49 size variables, 32 typography primitives, and 41 semantic text styles.
Spark Kit and a generic AI tool run on the same models. What sets them apart is context.
| Generic AI Design Tools vs. Spark Kit (Context-First Approach) | ||
|---|---|---|
| Generic AI Tool | Spark Kit / Context-First | |
| Context source | Broad training data | Your team's Design System docs |
| Naming output | Generic / inconsistent | Matches your conventions |
| Token references | Approximate | Correct |
| Variant structure | Invented | Follows your logic |
| Correction time | High | Low |
| Access to DS variables | None | Full (read and bind) |
| Who can use it | Anyone | Any team member, technical or not |
Does a Figma plugin have to be published to be useful?
No. And the most meaningful outcomes came from exactly that constraint.
We built Spark Kit in 13 days across 30 commits: an MCP server, a WebSocket relay, a Figma plugin with role-based flows for designers and developers, full Design System generation, and a natural-language chat interface for prompting from inside Figma.
When it felt ready, we submitted it to the Figma Community. A few weeks later the answer came back: they don't approve plugins that overlap with native capabilities in the Figma MCP server, and they suggested building on top of the official use_figma tool instead.
It makes sense. Figma has been building its own AI layer, and a plugin that connects Figma to an external model with custom context and 30+ tools sits close to ground they want to own natively. Building on their tooling rather than alongside it is a reasonable ask.
Not the outcome we wanted, but a fair one, and as it turned out, publishing was never where the real value of this project lived.
Spark Kit runs locally, deployed via Docker or directly through Bun. That constraint changed what we did with it. Instead of a community plugin, we have a focused internal tool used in workshops, onboarding sessions, and production work across the team.
One of the most concrete outcomes is what it did for the technical gap. The plugin launches with a role selection screen: designer or developer. A designer who has never opened a terminal can send a plain-language message from the Figma plugin UI, get Claude to read the current design, generate output that matches the Design System, and hand off production-ready assets. No Git knowledge required. No understanding of MCP configuration or package management. Claude becomes the translation layer.
The design-to-development handoff changed in a specific way. Developers now receive Figma files with a documented, step-by-step workflow that uses AI to read designs and implement them. Not just a link to a frame. A structured process with clear AI-assisted steps built on the same context stack that powers Spark Kit. Back-and-forth between design and engineering has decreased. Good practices are documented and repeatable.
We built SparkKit in two weeks. The capability it created for our team has been running for months.
Why your design system is the real foundation for AI-Assisted design
Building Spark Kit made something urgent that had always been important.
You cannot give an AI useful context if your documentation is incomplete. You cannot rely on a model to follow your naming conventions if those conventions exist only in your team's memory or Figma Files. Before Spark Kit could work well, we had to audit and repair documentation we had been meaning to improve for a long time. As we always say, the quality of AI results depends exclusively on the data it is fed.
The process of building the tool forced us to clean up the system it depended on.
Because we were running this infrastructure before Figma's public MCP launch, before the ecosystem went mainstream, we had already worked through the hard parts: the limitations, the token constraints, the prompting patterns that produce consistent output. By the time the rest of the industry started experimenting, our team had a working methodology.
If there is one thing other designers and product teams should take from this: start with the system. Not the AI tools. Not the plugins or APIs or MCP servers. The system. Document your conventions in structured, specific language. Write down the rules that live in your team's heads and make the implicit explicit.
When you connect that documentation to a language model, the gap between "AI that guesses" and "AI that works like your team" is not subtle. It is the difference between a tool that creates cleanup work and one that removes it.
Every team chasing AI-assisted design is really chasing this: does the model know how you work, or is it just guessing well?
Fix your documentation first. The tools are the easy part.