If your organization uses Figma as part of its design process, you are in good company. Figma has quickly emerged as the preferred tool for developing UI designs by both large enterprises and fast-growing startups. UX teams around the globe are actively exploring how to work with Figma to take advantage of its full potential, and more mature teams use Figma to leverage their design system when creating new designs.

Figma’s popularity with content designers

Figma has been described as an online whiteboard for UI design. Teams can develop and review designs online and update the copy in the design in real-time.

Figma’s widespread adoption by UX teams has coincided with another trend: the increased participation of UX writers and content designers in the UX design process. Figma allows real content to be placed in UI designs—a big leap forward from static wireframes or mockups that show “placeholder” content, especially the dreaded “lorem ipsum” text. Realistic content can be placed in a UI design to see how it would appear. Figma allows designers and writers to collaborate far better than other UI design tools that have preceded it.

Figma works best when each screen component will show unique content that is specific to that screen, especially content that’s written once and never revised later. But Figma becomes harder to use when dealing with a diverse range of content and design variables.

Limitations of Figma for content

Figma is a visual design tool rather than a writing tool. While UX teams increasingly recognize that writing is part of the design, dedicated design tools like Figma were not developed with the needs of content designers in mind.

To use Figma, writers need to learn a visual design tool that has an unfamiliar mental model involving layers and frames. The way that Figma manages visual objects isn’t aligned with how the content should be organized and managed. Even after writers learn the basics of Figma, they can be at a disadvantage when it comes to driving the content requirements. 

Figma can be especially challenging for writers who are developing lots of content that needs to be available in many places. By subordinating text to UI components, Figma makes it is hard to see how specific content is used across many screens or different applications. The copy presented on Figma pages is fragmented. Figma pages don’t represent the structure of the content. The layout of screens still needs to be translated into a formal structure that can be accessed by authors.

Teams need a consolidated view of their content. The fragmentation of content across different pages and frames makes it challenging to maintain and revise content as well. In contrast to well-established best practices that advocate separating the content from the design so that each can be revised independently, in Figma, the content and design are tightly coupled. The content, represented by “strings” of text, and the design, expressed in code, are intertwined in a common file. This can create problems when a change on one screen forces changes on other screens. Developers may need to do a global “replace” operation. Teams then need to review each screen individually to make sure the change doesn’t create other issues. 

While Figma may act as a source of truth for a visual design, it can’t do the same for the content that will be presented in that design. There’s no centralized inventory of the content that’s being presented. It’s hard to know what content is available, what that content is related to, and if it is consistent.

These issues are even more pronounced when working with multiple languages. Phrases and terminology should be consistent not just on a handful of screens currently being designed, but across all content being published. But Figma presents content for specific screens, rather than showing the source content that could appear on many different screens.

Text shouldn’t be subordinate to visual design. Figma’s text management limitations are widely recognized. Various third-party vendors have developed plugins to help teams manage text that appears in Figma designs. Plugins such as Ditto and Strings offer obvious benefits compared to Figma’s out-of-the-box capabilities. But while making Figma more friendly to writers, the plugins still depend on Figma’s native text capabilities, which prioritize visual design over content. Writers are still expected to fill in copy within different UI components rather than starting with content to shape the design. This becomes an especially important issue when the design must present existing content or data instead of copy that’s custom-written for a specific component.

Plugins can work well for smaller projects, such as developing an app with a limited number of screens and a limited amount of copy. But they don’t provide a full solution for enterprises that have content that must be presented across many apps and platforms. Content designers should be able to plan content that will be consistent and easy to maintain. Fortunately, a headless CMS can provide that missing capability.

How to use a headless CMS with Figma

Figma allows external tools to connect to it. It can be accessed by an API and accepts content described using the JSON format, which makes it a perfect companion to a headless CMS.

Many UX teams are not aware that they can connect their Figma projects directly to a headless CMS such as Kontent.ai. Adam Amran provided a tutorial on how to do this on the UX Collective website, showing how a “content-first” approach can work with Figma. Adam described three steps in the process:

1. Modeling the content structure
2. Creating the content
3. Designing the user interface

Teams can use a headless CMS to prototype UI designs using all kinds of content, both existing and potential. A headless CMS that is connected to Figma can support a range of design scenarios. It can be used to iterate both the content and design, or just the design, in cases where the content already exists.

UX teams can pair a headless CMS with Figma to support two kinds of decisions:

1. To decide the design when they already have decided the content
2. To decide both the content and the design

In the first scenario, the content has already been decided before teams start working in Figma. This happens when there’s existing content that needs to be presented in a new interface. It also happens when business stakeholders decide the content ahead of the visual design, such as when a legally required statement must be presented. In both these cases, the design needs to fit the content, making sure it adequately highlights what needs to be presented without being hard to read or notice.

In the second scenario, the content that will be presented is still yet to be determined. This could be because teams need to try out different wording in the copy to see what works best for users. In other cases, it can involve deciding how much detail to include. The wording choices and amount of detail can influence the design. Sometimes the design can reduce the need for text. The interaction between text and design layout can be fluid. Sometimes messages and information will be broken out over several screens. Teams will want to try out different combinations of content and design options.

	Using existing or approved content: Focus on iterating the design	Developing proposed content: Focus on exploring copy and design possibilities together
Single item (only one instance of the message, often associated with a single UI component)	Design optimization: Fine-tune the design to ensure it displays required information or messages optimally	Convergent iteration: Iterate copy and images together with the design to find the most effective combination
Multiple items (many instances of information or options for messages to present, sometimes affiliated with more than one UI component)	Design parameterization: Explore how different content items that will display in a single or different UI component/screen	Divergent exploration: Try out many content options in a single design, or in many design alternatives

Content and design decisions involve two levels of issues:

1. Factors that directly influence the “ideal solution” when considered in isolation
2. How the “ideal solution” will perform in different contexts

Consider a simple case of a component that presents a primary and secondary action to support a sign-up process. The team must decide the text for the two actions and the button or link designs to present the text. This simple component will be incorporated in other larger UI components that present a range of text. Teams will want to be able to know if their decision will work to support all kinds of sign-up processes.

Understand the variety you must present. Designing with real content can be messier than when using placeholder content. That’s especially true when working with content that already exists. The team can explore different questions and options.

Both the content and the design will have a “shape.” The content’s shape (number and length of fields or image characteristics) will influence the shape of the UI (layout and emphasis of elements).

The shape can change. Different instances of content may not have the same profile. A generic UI component that presents various kinds of content such as a UI card may need to accommodate information where some fields aren’t always available. Teams will need to decide when presenting the content if variations of the base UI component are required or if an alternative UI component would be better.

The table below reveals some of the questions that teams might explore under various scenarios.

	Content that’s presented in a single UI component only	Content that could be displayed in different UI components or variations
Need to present many instances of a specific kind of content	How much do the instances vary in the length of fields? Do all instances have the same fields? What rules will be needed governing the creation of new instances?	Which components can be used? Which component is the best fit?
Need to present content on different topics	How much does the content on different topics vary? Are variations of the base component needed?	Do any components need to adapt to display diverse content?

Benefits of using a headless CMS with Figma

A headless CMS provides a single window into all the content that will be presented in various UIs. It offers four main benefits:

1. The ability to precisely manage the actual content being presented
2. The ability to prototype with many content and design variations
3. An authoring environment that’s friendly to writers and business stakeholders
4. A genuine source of truth for content

Access the actual content, not just copy fragments

A headless CMS provides teams with an organized inventory of their actual content. When connected to Figma, it lets them understand how their content is being presented. It manages all the content that will be published in UIs rather than merely storing strings of UI copy.

The Figma app, even with a text management plugin, doesn’t provide a complete inventory of enterprise content that’s shown in UIs. Plugins handle strings of UI copy, which are just one subset of the enterprise’s content. Access to plugin-managed text can be restricted: it may not be available to all stakeholders or accessible throughout the content’s full lifecycle. 

Since the goal is to present real content in the Figma designs, it makes sense to provide the actual content from where it is stored: in the CMS. 

Content designers need to know the context in which words, phrases, and other content are used. They need the ability to zoom out from looking at specific screens to see the broader landscape of the content.

Focus on the usability of all the content that’s presented to customers. Consider a common usability problem that enterprises face: their smartphone app uses one term to refer to a feature or service, but their website uses a different one. Unfortunately, it can be difficult to catch that problem within the Figma app, especially if it is only being used for the smartphone app’s design. The website may have been created earlier by a different team, and it’s hard to see the contexts where the two phrases are being used without looking at many screens.

Managing the content that appears in various UIs entails more than managing UI wording or “copy.” Teams must be able to use real-world information and data that will be presented in the UI. For example, they need to see how existing product information will appear or check that data is formatted appropriately in the UI. And they want to check that the library of image assets will display clearly in the design.

A headless CMS already stores all these kinds of content and can provide them to Figma.

Structure your content to understand relationships and distinctions. When using a headless CMS, the content appearing in the UI can be formally structured. The content is organized in the CMS’s content model, showing the relationships of all content used in the enterprise. 

A content model structures the content into distinct content types with unique fields, in contrast to Figma’s jumble of generic text fields. Figma associates text strings in relation to components; a text management plugin can at best retrospectively manage the content appearing in UI components with tags. But tagging the content shown within UI components isn’t a scalable approach. Because the content in Figma lacks its own structure, the tagging is done incrementally as each UI component gets added. You might tag the button text for a CTA button as “CTA”—until you realize you need to create another CTA. Teams need the ability to precisely describe the content directly, instead of trying to infer the content characteristics according to tags that describe the UI components. Because the content will have many variations and nuances, it’s important to have a handle on what’s available.

A content model delineates the structure of content by topic or task across screens. Defining a formal structure enables teams to manage the content more thoroughly and avoid ambiguity about what a message, piece of information, or phrase is supposed to relate to. When using a headless CMS, teams can tag distinct types of content with precise taxonomy terms. You can find out not only if you use a phrase, but in which content types the phrase is used. Teams can apply taxonomy terms to indicate the goals the text is supporting. This granularity can help teams understand at a high level the context in which words and other content appear without needing to view each screen individually. 

Zoom in and out to get the context. A headless CMS can provide a single view of content that appears in multiple places. A good one will provide numerous features to access and manage content such as:

• Filtering content items by content type to determine their consistency or differences
• Organizing and filtering by taxonomy tags relating to customer journey stages, customer segments, or products
• Searching for occurrences of words or phrases according to context
• Comparing the information in specific fields
• Tracking changes in different versions

Structured content management allows teams to zoom out and compare details that are hard to notice when embedded in many different screens. Teams can explore when and where it is appropriate to use certain wording or provide certain information. They can compare many variations and options that are being presented or might be.

Better prototyping with content

The second benefit is that using a headless CMS can make prototyping with content more efficient. You don’t need to copy or rekey existing content to get it in your designs. And when you have many variations or options to try out, these can be provided to various Figma designs easily.

Structure lets teams prototype more scenarios:

• Deciding which fields to present when facing limited space
• Developing alternative fields when needing to present different message variations
• Testing the design’s capacity to present real information that may have different lengths

Because the content is stored in the CMS, and not embedded in layers of UI components, teams can show the same content in different ways. They can try out how the content appears in different variations of a specific UI component, or they can see how the content might appear in different UI components—which is an especially useful benefit when planning content that needs to be presented in different channels or on different platforms.

A more helpful, easier-to-use authoring environment

Unlike Figma, a headless CMS is designed to support writing. It structures content into descriptive fields, not generic rectangles on a page. Writers can focus on what needs to be said as they develop content.

Help authors with guidelines. Certain headless CMSs allow the embedding of “guidelines” for each content field that can offer additional instruction about the goals, audience, tone, text length, or image characteristics. These guidelines can reflect enterprise standards such as style guidance or design system-defined character limits. Guidelines can be presented in the authoring environment for fields such as headings, labels, buttons, or descriptions. The fields can also indicate allowed text formatting, specifying plain or rich text and whether bullets can be used.

Writers can work in a familiar authoring environment to update the text that’s presented in a Figma file, without having to learn how to use the layers of a design tool. Writers can access spell-checking and custom writing tools, such as terminology lists and style guidelines that may have been integrated into the CMS.

Help reviewers focus on the content. Using a headless CMS for content review offers benefits as well. It’s easy to collect feedback and suggestions and maintain a record of versions over time. Everyone can add comments directly to the content—even business stakeholders, who will feel comfortable using a tool that looks and feels like other editing tools they use. By contrast, when reviewing content in Figma, business stakeholders need to adapt to an unfamiliar application they rarely use. In Figma, they may also be inclined to comment about things other than the content, such as button colors—topics that may not even be open to discussion if determined by the existing design system. Content review in a headless CMS can keep the discussion on track, focused on the content and not the visual presentation.

Finally, a headless CMS allows the team to include supplemental information related to the content. They can include fields to annotate accessibility information and capture related metadata that’s not displayed.

A central source of truth for all content

A headless CMS provides a comprehensive source of truth for all content. It can manage the content that’s used in any platform or channel, including those without screens such as voice bots. It can even manage and track translated content and localized variations.

Give authors independence. The content in a headless CMS is always available to authors, in contrast to plugins that store content during the drafting phase but that subsequently become inaccessible to writers when strings get stored in a code responsibility such as GitHub at deployment. Authors maintain ownership and control over the content in the CMS and don’t have to rely on developers to make revisions.

The content stored in the CMS is decoupled from the design and is not hard-coded into the software application presenting it. Front-end developers can change their code library without disturbing the content that’s been created, reviewed by business stakeholders, and tested with users. It keeps the content revisions separate from design revisions, so they never mess up the design file.

Integrating a headless CMS into your UX design process

Using a headless CMS can supplement other ways your team develops UI text. You don’t need to drop your current practices if they meet your needs. You can synch content you’ve developed within Figma to a headless CMS, so you have an inventory of content that’s ready to deploy. The content stays independent of the code and can be revised easily later.

The goal should be to extend your practices and try out new approaches. Adding a headless CMS to your UX toolkit gives teams more versatility to explore and validate options and develop better requirements, improving the governance of content by promoting reuse and consistency. This can boost the maturity of your content design operations.