Many designers don't realize it, but they are modeling content.
Every time a new interface is built in Figma, a content model is born. Whether it is a mockup of a webpage, a prototype for an app, a flow chart for a conversational UI, or any other digital interaction — some form of content structure is being implied.
Designers create content structures implicitly while innocently designing user interfaces. They are designing not only the visual aspects of the interface, but also crafting the underlying structure that organizes the content and data displayed on the screen.
Here are some ways in which designers create content structures implicitly:
Grouping related content: Designers organize related content in ways that make sense to their users. For example, they might group all the symptoms of a health condition into a standard table structure that repeats for every other condition.
Creating hierarchies: Designers create hierarchies by prioritizing and organizing content in a way that helps the user navigate the interface. For example, they might use different font sizes or colors to indicate headings, subheadings, and body text. Or, they might arrange offers in a related-product feature carousel.
Defining relationships: Designers define relationships between content elements to help users understand how they are related to each other. For example, they might use arrows or lines to connect different elements or show the flow of information.
Labeling and layering content objects: Designers label containers and frames in Figma, and label layers in Photoshop, Illustrator, or other design tools. Often these labels have meaningful names. For example, the names might imply content types, like “Recipe”, or content elements within a type, like “Ingredients”.
So, we can see how easily informal content models get created by designers as they build new interfaces. These “accidental content models” are born when content designers or interface designers simply lay out what content will fit where on the screen. These content models focus on design placement, rather than the meaning of content and how it gets used across an enterprise set of customer experiences. They need to connect up in the bigger picture.
Customer experience composition, orchestration, and dynamic assembly all depend on component content structures working together from design on through to delivery.
Getting designed content structures to play well with headless
Whether your content management system is headless, monolithic, simply based on strings, or based on custom code, in order for content to get to customers, some significant labor is going to be involved in getting the designs to match the way the content gets stored. That labor expands dramatically the more interfaces, designs, content types, languages, variants, and changes need to be made.
When content models are totally accidental, content is not reusable or componentized. A messy repository of duplicate objects ends up getting created that becomes an unruly manual mess to maintain.
While implicit content structures are useful during the design process, they can cause negative effects when the design structure doesn’t align with the schema of a headless CMS. Here are some potential issues:
Inconsistent content: If the
content structure in the interface doesn't align with the CMS schema, it can lead to inconsistencies in the content displayed to the user. For example, if a designer uses different content elements than the CMS, it could result in content being displayed incorrectly, requiring a lot of manual monitoring and QA.
Difficult maintenance: An ad-hoc
content structure can make it more difficult to maintain and update content. For every addition or change that doesn't match the existing schema, it requires manual intervention to update the CMS schemas, and ensure all the content items are displayed correctly.
Limited reuse: A lack of structure can limit the ability to reuse content across different parts of the application. For example, if a designer uses a unique structure for a particular page or feature, it might not be possible to reuse that content elsewhere in the application without significant customization. This leads to redundancy and inefficiency as elements get repeated, and content duplicated, rather than being efficiently reused.
We need a better way to align content design and headless content structures
Using structured content from a headless CMS directly inside a prototyping tool like Figma can help designers avoid these issues.
The
Schematica team at [A] has built a Figma plugin that brings component content together with the design process. It’s called RealContent. By connecting your headless CMS to Figma using the RealContent plugin, content designers and user interface designers can:
Use real content: Instead of using placeholder text, designers can use actual content from the CMS to ensure that the design accurately reflects the content that will be displayed to users.
Ensure consistency: By using the same schema as the CMS, designers can ensure that the content is displayed consistently across different parts of the application.
Enable reuse: By using a structured content approach, designers can create reusable content that can be easily used across different parts of the application.
In short, designers create content structures implicitly when designing user interfaces, but an ad-hoc approach can cause negative effects when it doesn't align with the schema of a headless CMS. By using structured content from a headless CMS inside a prototyping tool like Figma, designers can avoid these issues and create more consistent, reusable content.
If you’d like to try out the RealContent plugin for Figma, let me know and I’ll send details.
RealContent: The Innovative Figma Plugin for Component-Based Content Design
Tools and approaches are continuing to evolve along with the compostable customer experience that is underway. The right path is the middle way. Something that allows for flexibility and autonomy of designers, but incorporates structural component reuse of both design and content components.
That’s why [A] has been working to innovate new Figma plugins that bring component content together with the design process.
The most mature of these is a plugin called
RealContent that connects content from leading headless CMS providers into Figma designs directly. Designers can still roll their elements outside of what is in the CMS directly, but it brings them closer together with content structure elements and thinking.
This creates a collaboration around component-based content design that helps everyone move toward a smarter and more integrated way of thinking.