Figma Sites CMS

Figma Sites launched into a category Framer and Webflow had defined: design-tool-native website building. It shipped without a way to manage content at scale, and the feedback came fast—people needed collections for portfolio project pages, blogs, product catalogs. A CMS built into Sites was the obvious answer, not as a standalone product but as a layer on one that was itself only a few months old. Its absence was a major adoption blocker on top of being a gnarly technical problem.

The design challenge was the canvas. Everything in Figma is directly editable, inline. But a templated CMS page isn't WYSIWYG by definition—it's one representation standing in for what might be dozens of pages. Resolving that tension in a way that felt intuitive and was actually buildable was the job.

We came at it from two angles: canvas interaction and content management.

The canvas had to stay true to Figma—directly editable, with all the tools, properties, and flexibility people already expected. The CMS layered on top: hooks in the design that propagate to every connected CMS item. Content was the opposite kind of surface, built for text and language rather than visual editing. Connect the two and you have a CMS.

Designer Kelly Li started the project a few months before I joined and drove the core experience. I owned many of the layers built on top of it: Rich Text, content publishing, AI features, onboarding, templates, import / export, and linting.

I was also working on Figma's Payload integration alongside this project, which made me the only person on the CMS team with a foot in both worlds. Payload had solved a lot of these problems already—we were learning CMS as we went, and I could bring established patterns and industry conventions in rather than reinventing them. Being that connective tissue was part of the job.

The team included:

• Design: Kelly Li / Tee Hodgson
• Product: Albert Song, Luke Zhang
• Eng: Artem Pasyechnyk, Arjuna Hayes, Jon Yee Chuah, Jimmy Wang, and Robbie Zhuang.

Rich text and layout don't map cleanly onto a design node. Editors need real formatting—headings, lists, emphasis, links—but a CMS page is a template standing in for dozens of pages, and formatting the design can't absorb breaks it.

Lexical set the boundaries. Building on it meant the node model and its assumptions about document structure were settled before design started, so the question wasn't what an ideal editor would do—it was how to map what Lexical gives you onto a surface it was never built for. Both obvious answers were bad: expose everything and layouts come apart; lock it down and writers get a tool that can't do their job. I designed the mapping in both directions—what rich text can express, and how the design responds to each case—plus a preview so editors saw the published result before committing. Where Payload had already settled a convention—both around content tags and blocks in rich text—I brought that model over rather than re-deriving it. The cost is that some formatting isn't available, and that we now maintain a mapping between two models that will drift as either one changes.

Getting content people into Figma meant getting non-designers into design files. Marketers and writers needed to ship copy without waiting on a designer, and designers needed confidence that nobody would publish a half-finished layout on the way. Permissions alone don't solve this—they decide who can enter the room, not what leaves it.

So we split publishing itself: content changes could ship without shipping design changes. That meant reworking the core Sites publishing flow to understand CMS, which was work outside my surface and required getting another team to absorb it. Two publish paths is more surface to reason about than one, and we took that on to keep both audiences in the same file instead of separating them into different tools.

Getting started had to work for two very different people: a designer with existing Sites work, and a marketer with a spreadsheet and no designs at all. We built for both—pick or generate a template, import existing collections in a few formats, or start with content and figure out design later.

The one thing we cut was the most appealing: automatically connecting a CMS collection to designs someone had already built. It demos beautifully. It's also non-deterministic—it guesses at intent, and when it guesses wrong it does so inside work people already care about. We tabled it, which means anyone with existing designs still wires things up by hand. I'd rather ask for that than ship a feature that's right most of the time in a place where most of the time isn't good enough.

A full CMS inside Figma Sites, shipped over roughly a year: collections and content modeling, rich text editing, a content-only publishing path, onboarding and template generation, and import/export.

The whole content workflow runs on the web, so contributing to a site never requires opening the design file. Marketers, writers, and anyone else on the team can create and publish content alongside the designers who built the thing—which was the point. A CMS that only designers can operate isn't a CMS.

Figma hasn't published adoption metrics, so what follows is scope and reception rather than numbers.

Every layer of this was new ground for Figma. Sites had already retrofitted the canvas for concepts the product had never held—breakpoints, HTML and CSS semantics, a publishing pipeline—and CMS had to bind onto that: design nodes connected to content records, so one template could stand in for dozens of pages while staying directly editable. The other half of the problem was making it legible to people who had never opened Figma and had no reason to find a canvas intuitive.

Content management is where I spent most of my time. Where established CMS conventions existed, I followed them rather than inventing Figma-native equivalents—users arrive with expectations from tools they already know. Rich text was the exception: Figma has no rich text capabilities outside of this, so there was no prior art for how formatting should behave when it meets a design system. That model, and the two editing modes on top of it, are how the product works today.

CMS was among the most requested additions after Sites launched—the content-at-scale gap came up constantly in community threads and forums. Shipping it removed a hard blocker: for a set of customers, a CMS was the precondition for adopting Sites at all, and several large contracts were waiting on it.