A Figma plug-in experiment

published

I’ve been sitting on this thought for a minute: Can I pull live CMS content straight into Figma and drive component design with it? Turns out, yes. This proof of concept does just that. Here’s where it stands.

The idea

Instead of stuffing static content into Figma, why not let a headless CMS handle it? Content creators get a structured environment, designers get more flexibility, and everyone skips the endless copy-pasting.

In theory, we are supposed to move from low to high fidelity, locking things down in progressive stages that don’t require us to look back. In practice, content, structure, and final output are often developed in silos—leading to bottlenecks when everything finally collides. This experiment aims to bring these pieces together earlier, adding more context to decisions while still keeping workflows modular.

But let’s not get ahead of ourselves—first, the technical proof of concept.

Setting up the Figma plugin environment

First, I needed a Figma plugin. In Figma, go to “Plugins > Development > New Plugin…” and follow the prompts. I set up a “Figma Design” plugin with ‘Custom UI’ enabled, making it accessible under “Plugins > Development.”

You get three key files saveed to you local drive:

  • manifest.json – Defines how Figma interacts with the plugin
  • code.ts – The core logic
  • ui.html – The plugin interface

Setting up Prismic

On the Prismic side, I set up a simple structured content model for text and images to test dynamic population inside Figma.

Why Prismic?

No real reason—I hadn’t used it before, and this seemed like a good excuse. Turns out, it’s a simple but highly configurable CMS.

How Prismic?

Prismic’s approach to structured content aligns with atomic design. You build small elements, compose them into components, and stack those into larger layouts. In Prismic, these are called slices, referencing content blocks on a page.

There are two main tools:

  • Custom Types Editor – Define reusable content components (slices) with structured fields.
  • Page Builder – Drag-and-drop slices, reorder them, enter content, publish.

I skipped manual setup and used a blog post template from Prismic’s repo to predefine slices.

To access content via API, I generated an access token in “API & Security.”

The CORS issue

So, just pull the API content into Figma, right? Nope.

First attempt: ping the API inside Figma. Immediate CORS error. Figma runs as a restricted web browser, meaning all requests have origin: 'null', which most APIs block. A proxy was needed.

I started with this prompt in Cursor:

I need to set up an API proxy on Vercel. The proxy will be used by a Figma plugin running in a restricted web browser, which sends requests with origin: 'null'. The proxy must accept these requests and relay data from the Prismic API.

After some trial and error, I ended up with this:

import * as prismic from "@prismicio/client";
export default async function handler(req, res) {
  res.setHeader("Access-Control-Allow-Origin", "*");
  res.setHeader("Access-Control-Allow-Methods", "GET, OPTIONS");
  res.setHeader("Access-Control-Allow-Headers", "Content-Type, Authorization");

  if (req.method === "OPTIONS") {
    return res.status(200).end();
  }

  try {
    const client = prismic.createClient("figma-page-build-test", {
      accessToken: "MC5aNXdBZkJJQU...",
    });

    const documents = await client.get();
    return res.status(200).json(documents);
  } catch (error) {
    return res.status(500).json({ error: error.message });
  }
}

Deployed to Vercel, this proxy finally let me pull CMS data into Figma.

Building the component library

With content flowing in, I created master Figma components that matched the Prismic slices, using consistent layer names for easier mapping.

To reference these in code, I needed their component IDs. The Node Inspector plugin helped with that.

The components

Prepare to be severely underwhelmed

Diving into the logic

Here’s the basic logic:

  1. Fetch content from the proxy
  2. Define what to look for and how to interpret it
  3. Parse the API response
  4. Loop through content and match it to the right Figma components
  5. Populate the page in the correct order

The code.ts

One early hurdle: defining fonts and variants before inserting text elements. Hardcoding worked but didn’t sit right, considering it killed the flexibility needed if this is ever anything more than this experiment.

This was starting to bring up an interesting question. Where should the definitions be controlled from? In Prismic? Should Figma handle them? Should Figma variables be dictating?

The workaround was dynamically loading fonts based on the Figma text nodes:

async function loadFontsForTextNode(textNode: TextNode) {
  if (textNode.fontName === figma.mixed) {
    const uniqueFonts = new Set<string>();
    for (let i = 0; i < textNode.characters.length; i++) {
      const font = textNode.getRangeFontName(i, i + 1) as FontName;
      const fontKey = `${font.family}-${font.style}`;
      if (!uniqueFonts.has(fontKey)) {
        uniqueFonts.add(fontKey);
        await figma.loadFontAsync(font);
      }
    }
  } else {
    await figma.loadFontAsync(textNode.fontName as FontName);
  }
}

This ensures the correct font is always applied—no need to define it anywhere.

Backlog: What’s next?

A list of ideas to make this more flexible and useful:

  • Support more formats and components (Figma + Prismic)
  • Multi-page support
  • Selectable API content feeds
  • Multiple component libraries
  • Content update notifications
  • Inline content updates within existing components
  • Version history (undo/redo for content changes)
  • Modularising the codebase
  • Better loading states and UI feedback
  • Automating Figma-to-Prismic slice conversion

Resources & code

  • Github – contains the full code for the plugin and proxy
  • Figma component library – A reference set of components structured to work seamlessly with the plugin - prepare to be severely underwhelmed

Final thoughts

This proof of concept shows that a Figma plugin can handle live CMS data efficiently. The goal? A content-first workflow that bridges content and design dynamically—without unnecessary friction.

The elephant in the room

Why not just go straight to code—or even a no-code platform? That’s probably the logical future state. But for now, the collaborative, exploratory nature of design work still matters. The ability to fluidly switch between content, code, and visual environments—while keeping everything in sync in real time—is the real goal. That’s the dream.