The case for building your own Figma plugins

One of the subtler hazards of senior design work is that the skills you most want to keep sharpening are rarely the ones your day job can teach you. I ran into this pretty directly at Meta when I was working on Messenger and Instagram Direct. Deciding to build a conversational UI kit from scratch was how I practiced designing from nothing while staying current with the newest parts of Figma. The systems I was working with day-to-day were years old, with most of the foundational decisions having long since been made. Working directly with the Anthropic APIs was how I built real fluency with frontier LLMs. Internally, the only models approved for use were Meta's own Llama variants. And reverse-engineering Apple's iMessage by creating workable prototypes in code was how I understood the architectural decisions behind a shipped interface I couldn't read the source of.

The project that pulled all three threads together was a Figma plugin that used AI to do something Figma couldn't do on its own. It takes a text prompt and a few additional inputs, then uses Claude to generate a realistic iMessage conversation before assembling a pixel-perfect interactive prototype on the canvas. I released it as a proof of concept before Figma Make or Claude Code existed, in what already feels like a different era.

The problem bespoke tooling solves

The specific problem was familiar to anyone who's populated realistic UI content in Figma: it's historically been quite tedious. For conversational interfaces specifically, the challenge is obvious. Designers create message bubbles individually, with variants tweaked by hand. Grouping logic, timestamps, and countless other details require attention that quickly becomes tedious at scale. It was detail work that required precision but not judgment, exactly the kind of thing a designer shouldn't be spending time on. Agentic coding tools didn't exist yet, so I was writing everything by hand, but building a tool that could do this work for me was the whole point.

What I designed was a three-part system: a UI kit built entirely in Figma, a plugin that sat on top of that kit to enable functionality Figma couldn't provide on its own, and eventually an exported version in code that became a living prototype. Each layer built on the one before it.

What I built

The plugin itself is simple by design. You describe a conversation and the plugin handles assembly. It pulls from the existing component system, pipes in structured data from Claude, and lays everything out with the correct variants, grouping, and timing. Designers can edit the result the way they'd edit anything else they built in Figma.

The domain specificity is where this gets interesting. The plugin encodes knowledge about how iMessage conversations actually work (grouping logic, participant roles, timing) directly into the prompt:

export function getInstructionsPrompt({
  prompt,
  maxMessages,
  participants,
}: GetInstructionsPromptParams): string {
  const participantCount = parseInt(participants, 10);
  const recipientCount = participantCount - 1;
  const chatType =
    participantCount > 2 ? 'GROUP CHAT conversation' : 'conversation';
 
  return `Generate an iMessage ${chatType} as a valid JSON array.
  ...

What it returns is a structured prompt built around iMessage's specific rules:

<requirements>
- Topic/tone: ${prompt}
- Max messages: ${maxMessages}
- Total participants: ${participants}
  (1 sender + ${recipientCount} recipients)
- Times in "H:MM AM/PM" format, chronological order
</requirements>
 
<messagesInGroup_rules>
messagesInGroup = total consecutive messages by the same person.
Every message in that group gets the same count.
  Alice  -> messagesInGroup: 2
  Alice  -> messagesInGroup: 2
  Bob    -> messagesInGroup: 1
  Alice  -> messagesInGroup: 3
</messagesInGroup_rules>

That messagesInGroup logic exists because the plugin was built for exactly this problem. A general AI feature has no reason to include it. Users configure participant count, message volume, theme, and conversation tone, and the plugin handles the rest with the precision a designer actually needs.

I kept the scope narrow on purpose. The plugin only builds realistic iMessage conversations and prototypes. That focus is what makes it precise. The same thinking applied to the UI. Figma gives plugin developers access to their UI3 design tokens through CSS variables, which is a good start, but you're still building the interface yourself. I designed the plugin to feel as indistinguishable as possible from Figma's own UI. The best plugin is one you forget is a plugin.

General-purpose vs. purpose-built

Figma offers some native tools for content population. Dragging an auto layout handle generates text variations with AI, for example. That's useful for filling a list view or populating a shopping cart with realistic items. But it's generic. It doesn't know anything about your domain, your components, or how they relate to each other. Microsoft recognized this years ago and built Content Reel, a custom plugin for their teams' specific content needs. Figma wrote a whole blog post about how they did it. The pattern isn't new. What's new is that agentic coding has collapsed the effort required. A single designer can now build what used to require a dedicated tooling team. And it runs on Claude Haiku, the cheapest, fastest model Anthropic offers. When the domain knowledge lives in the prompt and the assembly logic, you don't need an expensive model. You need a precise one.

When Figma Make shipped, I pointed it at the same design system. It couldn't produce the same result. That's the difference between a general-purpose feature and a purpose-built tool, not a knock on Figma Make specifically. And it gets at a broader question about how Figma thinks about extensibility versus how tools like Claude Code do. Anthropic builds a platform you can build on top of. Figma ships features that solve their version of your problem. If your problem is slightly different, you're on your own.

Build the tools your team needs

If you're still choosing to work within Figma, and many teams will continue to, consider building the tools your team needs rather than adapting to the ones Figma ships. The plugin API has rough edges. The documentation is outdated. Figma's role in the design workflow is shifting in ways that make this kind of investment more important, not less. But even with those limitations, a single designer built a tool that does something Figma's own AI features can't replicate.

This is probably the last thing I'll ever code entirely by hand. I built the first version before agentic coding tools existed, partly because I wanted to learn the Anthropic APIs directly. Now I'd build the same thing with Claude Code in a fraction of the time.

Figma is an investment of your team's time. Plugins are how you make sure that investment pays off. They can enable entirely new capabilities, speed up complex workflows, or solve problems Figma will never prioritize because they're specific to you. The tools to build them have never been more accessible.

The UI kit, the plugin, and the prototype app are all open source: the UI kit and plugin on the Figma Community, and the plugin source and prototype app on GitHub. The plugin source is the part most worth reading if you're building Figma tooling against your own design system. Pair it with the UI kit if you want to see what the plugin produces.