For years, choosing a content management system (CMS) meant picking sides: a developer-first platform or a marketer-first one, but recently the designer-first CMS has gained traction. Earlier this month Figma Sites debuted at the Config 2025 conference and garnered a lot of buzz. While Figma’s dominance in the design market accounts for much of this excitement (and some skepticism), what interests me is its signal toward a new demand for designer-first experiences for application and website building empowering designers to ship. I observed this directly as a frontend engineer at a digital marketing agency. When a landing page or simple site needed to be deployed fast, but the engineers were swamped, our design team used Webflow to spin up a quick and dirty website–no developer resources required (although we were sometimes later brought in for tweaks). But that was five whole years ago. Things are changing fast, and these designer-targeted solutions are getting more sophisticated and fully featured.
Three designer-first CMS vendors today include Builder, Framer, and Webflow. While Builder.io markets itself explicitly as a “visual headless CMS,” Framer offers a unified platform for design and CMS management, emphasizing ease of use and rapid prototyping, and Webflow’s CMS offers a visual interface that allows designers to build and manage complex websites without coding. Most recently, Figma Sites allows users to push designs created in Figma Design straight to production, with a CMS for managing site content promised “later this year.”
Expanding the Designer’s Role
The emergence of tools targeted at the designer persona suggests growing demand for designer-first experiences that effectively bypass the frontend developers historically tasked with interpreting their designs into code. It also suggests a broader movement toward empowering designers and freeing devs from rote drudgery. Andreas Møller, co-founder of Nordcraft, characterizes the Nordcraft web development engine’s inception in terms of bypassing this designer-dev handoff pain:
One of the things I noticed was this process when you’re sitting in a product team where a designer, or usually a product manager, will come and say we need this kind of feature … a designer will go and and do a layout or a design of what that needs to look like and then you get a hand off to the developer, right? This was me. And the handoff is something along the line of like here’s a picture of what you need to do. Please do it like exactly the same way. We usually call it pixel perfect, right? And pixel perfect means don’t add anything of yourself into this task whatsoever. Just do the exact thing that’s been shown you, but in code, right? And I like my job, but that particular part was the least favorite part because that’s the bit where I don’t really matter. I just need to repeat the task someone else did. My opinions don’t really factor into this. Now, in actuality they do [matter], because the design is never complete. But I always felt that part was kind of pointless, like, if the designer already built it why are we doing it twice, right? And so I wanted to play around with this idea of saying, well why do we duplicate this step, right? And I’ve seen tools like Webflow, and like you can build visual tools for building websites, but there wasn’t anything built for applications, right? There’s sort of a limit and the second you get above a certain complexity or you need some flexibility some dynamic content, then we’re going back to everything is done in code, right? And so I wanted to figure out why is that if the UI can be done visually why can’t we build something like this that would work for the kind of application I’m building, which was mainly SaaS applications.
The designer-first CMS numbers among the tools intended to close the gap between image and code that Møller identifies. Part of the issue standing in the way of this joining is that designers and developers have had their own separate tools. Designers create in Adobe, Figma, Sketch, Canva, etcetera, and hand off their files to frontend engineers who code them out in their preferred IDE like VS Code, Sublime Text, etcetera. Frontend engineers then hand off their code to backend engineers, who add functionality, and then Ops folks deploy the application, again, using their own devtools and workflows. Of course I’m oversimplifying and omitting significant players and steps in the SDLC like product manager whiteboards (ClickUp, Canva) and wireframes delivered by UX teams (Balsamiq, Miro). In the future, AI code assistants and the move toward agents and “vibe coding” will exacerbate the continued smooshing of these roles and tools. As Elie Thomas Majorel, senior product designer at Coveo, says of the “evolution of AI and imagery”:
Spending weeks on perfect screens that never reach users no longer (never?) makes sense. Try building it!
By reducing reliance on developers for website deployment, designer-first tooling enables faster iteration and greater creative control. Although this post focuses on just one of these tools, the CMS, my claims are extensible owing to the designer’s shifting role and capabilities across the org.
A Framer billboard I photographed down the street from Config 2025.
The Traditional Polarization
In order to get a handle on this burgeoning designer-first CMS market, let’s dig into what separated the two more established paradigms of dev-first and marketer-first CMSs—especially as designers have so far remained divorced from most ecumenical fights within the web development space. For instance, the debate between static site generators (SSGs) and CMS architectures center on the trade-offs between simplicity and flexibility, which my colleague Rachel Stephens has researched. SSGs—with Jekyll, Hugo, Gatsby, and later Ghost setting the tone—are ideal for straightforward, content-heavy sites like blogs or documentation, offering fast load times and enhanced security due to their static nature. However, they can be limiting for marketers and designers, as content updates typically require developer intervention.
What do developers want from a CMS? Developer-first platforms like SSGs and CMSs often rely on Markdown and Git-based workflows that align with how developers already manage code through version control, pull requests, and text-based file formats. Because Markdown is lightweight, portable, and integrates cleanly into repositories it is ideal for static content like documentation, blogs, and technical marketing pages. GitHub workflows, such as content stored in Markdown files and deployed via CI/CD pipelines, embody this model by allowing developers to treat content like code. Even GitHub Pages, which itself isn’t a CMS, reflects the ethos of developer-first content management by being versioned, code-reviewed, and deployment-friendly. These systems prioritize developer control and technical precision over ease of use for non-technical contributors.
Recently, most developer-first CMSs are “headless” (more on this below), which allows them to offer both flexibility and modern tooling. Flexible dev-first platforms like Contentful, Contentstack, Sanity, and Strapi prioritize speed and omnichannel delivery. Content is managed as structured data via APIs, decoupled from any specific presentation. This approach gives developers full control to build websites or apps with whatever frontend tech they prefer. Such platforms are lightweight and integrate easily into a modern development stack. For example, Contentful is API-first, composable, and targeted to agile teams that need content delivered to web, mobile, or any other channel. Meanwhile Sanity requires defining schemas in JavaScript/TypeScript, which encourages version control and consistency. Unfortunately, some marketers using these tools were put off by the fairly spartan admin interface. Content is separated from design, so users from the marketing and the design sides struggled to visualize how a page would look without a developer-built preview. Marketers had to adjust to managing raw content chunks and relying on developers for layout or styling changes. This reduced dependency on engineering resources for publishing simple updates (since content could be edited and pushed live anywhere), but more complex page updates or new landing pages still often needed to pull in developers for every minor change.
Marketer-first CMS suites (Adobe Experience Manager (AEM), Sitecore), sometimes called Digital Experience Platforms (DXP), provide rich visual editing and marketing features. These platforms have traditionally been coupled or full-stack CMS suites exemplified by the unchallenged elephant in this space: WordPress. These systems come with all the bells and whistles for enterprise marketing teams such as in-context WYSIWYG page editors, form builders, digital asset management, personalization engines, workflow and approval systems. Users of AEM and Sitecore are perceived to be non-technical, and the system is set up so that they can log in, drag and drop to build a new page, author content and media, and hit publish without fiddling with the code. These systems shine in large organizations that need strict governance, consistency, and scalability. AEM is part of a broader digital experience platform and is built to handle complex, multi-site, multi-language content at scale—a boon for users who want integrations to Adobe’s analytics, targeting, and other marketing tools. The disadvantage here is cost, complexity, and rigidity on the development side. Traditional suites often require specialized development skills. AEM, for example, runs on Java and has a steep learning curve in its OSGi/Sling architecture. Implementations can be lengthy and expensive, and developers are constrained by the CMS’s framework. In short, these marketer-centric systems can be heavy and bloated with features not all teams will use, yet they provide out-of-the-box capabilities that larger business users rely on.
In the old paradigm, organizations often had to choose between flexibility for developers and rich features for marketers. Developer teams leaned toward headless solutions for modern frontend development and performance, accepting that editors might have a less visual experience. Marketing teams leaned toward the big suites so that they could build and edit content freely, even if it meant a more rigid tech stack or higher cost. This polarization left a significant gap, and has led to widespread adoption of “headless” architectures.
Move Toward Headless CMS Platforms
In the past couple of years there’s been a flurry of movement in the CMS industry to blend the strengths of both dev-first and marketer-first paradigms using the headless model. A headless CMS separates the location where content is stored from how it’s displayed to users. This decoupling of frontend from backend lets teams manage content centrally and distribute it across multiple platforms like websites, mobile apps, or social channels. Older CMS platforms were typically built with websites as their main focus, which often led organizations to use different systems for other digital experiences. Headless CMS vendors deliver content via APIs to whatever “head” you want.
Although the headless model is in the ascendent, a more nuanced look at the market suggests that at the same time traditional CMS vendors have been refactoring their products to be more headless and developer-friendly, born-headless dev-first CMS providers have also started adding the kind of authoring tools that marketers expect. In fact, the past couple years have seen numerous headless platforms adding page builder UIs and legacy suites going headless under the hood, all aimed at mending the dev-marketer divide. What interests me is what this convergence says about the evolving role of the designer in shipping to production.
Storyblok (founded 2017) is born-headless, and markets itself as “the first headless CMS that works for developers & marketers alike.” The screenshot above shows a Storyblok interface exemplifying its preference for visuality. On the left, the user sees a real-time visual preview of a webpage (“Demo Space Adventure” content), and on the right are structured content fields and settings. There’s even an inline comments panel (the “Discussions” pop-up) where team members collaborate on content. This kind of UI marries the what-you-see-is-what-you-get ease of a traditional CMS with the structured content model of a headless CMS. A content editor can drag, drop, and edit components on the page and immediately preview changes (and you know I love a page builder), all while the system maintains a clean content structure underneath. The intention is to accelerate iteration. Marketers can build and tweak pages on their own without sacrificing the developers’ need for structured, reusable content and omnichannel delivery.
Many traditional CMS vendors are following this trend by going headless with products like Sitecore XM Cloud mandating a headless setup, while WordPress, Optimizely, Adobe, and Acquia (Drupal) offer headless capabilities. Even WordPress, which still leans marketer-first, has evolved to better accommodate developers, particularly in small-to-midsize orgs, by offering a headless experience and tools like WPGraphQL and integrations into Jamstack or React frontends. Seeing the pain points on both sides, many vendors are now converging toward a “hybrid” or “composable” CMS approach. Users in all sections of the org increasingly prefer to leverage a headless content repository in conjunction with visual editing, preview, and other experience management features. By introducing headless content APIs and decoupled frontend editors, marketers can still use familiar page editors while developers fetch content via API on the front end.
Optimizely’s evolution is another useful case study. Formerly Episerver, Optimizely has shifted its positioning from a traditional CMS to a Composable DXP. In 2024, Optimizely launched a managed headless CMS SaaS (often called Optimizely Content Cloud SaaS or Optimizely CMS 12 in the cloud) that a “Visual Builder” drag-and-drop interface with on-page editing and preview, very much like what traditional marketers are used to, now built into a headless system. Optimizely’s strategy is to couple its digital experience capabilities for content, commerce, and personalization (they’re known for their experimentation and A/B testing tools) with a headless, API-first backend. For marketers, the advantage is an all-in-one environment where they can edit pages visually, run experiments, and manage omnichannel content in one place. For developers, Optimizely’s GraphQL-based content API (Optimizely Graph) and its support for modern frontend frameworks remove the previous .NET web form limitations, as this tightly coupled architecture limited frontend flexibility and required specialized .NET development skills. Essentially, Optimizely is betting that enterprises want both the completeness of a DXP suite and the flexibility of headless. The trade-off is that it’s a large platform, but for organizations already invested in Optimizely’s ecosystem, the new headless SaaS gives them cloud scalability and a modern developer experience without throwing away the marketer-centric features.
What Headless Trends Reveal About Designer-First CMSs
Headless architectures have mitigated many pain points within the dev-marketer divide, and vendors ranging from startups to incumbents have jumped on the bandwagon. So why do we now need a designer-first CMS? The rise of designer-first CMSs like Webflow, Framer, Builder.io, and soon Figma Sites, is not just a parallel trend but a logical outcome of the headless movement. As developer-first platforms added marketer-friendly page builders, and legacy DXPs started exposing content via APIs, a new opening appeared: tools that let designers ship production-quality sites directly from the design canvas. Today, organizations expect designers, a group long expected to hand off static mockups to devs and marketers, to take a more active hand in managing these tools. Vendors will need to adapt to these particular users by reducing friction and meeting them where they are. They must offer designer-friendly interfaces resembling the ones they use already while providing features designers rely on. Interfaces must offer fine grained control of the website or application’s appearance and interactivity. To sum up, the most successful tools within this new designer-first CMS category will reduce friction and make the user experience by seamless and fun.
The CMS landscape today reveals something deeper than just architectural preference: it suggests a fundamental reshaping of who gets to own the web-building process. If the paradigm of the designer-first CMS does materially challenge the incumbent dev and marketer-first CMS market it means that the “headless vs. coupled” debate was never just about architecture. It was about control, collaboration, and who gets to ship. This is a positive development for organizations seeking agility across multiple internal teams. It already seems obvious that the demand for headless CMSs with visual editors was never truly about the underlying tech, but rather a cry for better shared tools. The designer-first CMS takes that a step further by offering an on-ramp for designers to both create and ship.
Disclaimer: GitHub and Microsoft (VS Code) are RedMonk clients.