Introducing new channels can splinter content and design operations. Each channel will bring something different. A channel may be supported by specific tools and processes. New channels are often treated as special projects or initiatives that are managed separately from existing operations. 

When every channel becomes a separate silo, design operations and content operations can’t scale. Both must be able to include new channels in their existing processes. They should aim to develop a unified approach to delivering user experiences.

Capitalizing on the potential of multichannel experiences

Channels have been multiplying ever since smartphone apps started displacing websites as the favored channel for certain kinds of content. New channels promise greater convenience or a richer experience. Customers seem willing to use new channels when they offer advantages in a specific context. 

A widely recognized benefit of a headless CMS is its ability to deliver content to any channel. Since the content is decoupled from the design, the content can be presented in multiple ways across different channels. 

Delivering content to many channels from a single source of truth has obvious advantages. Not only can brands serve the growing range of channels that their customers access, but they can also bring greater oversight and governance to the vast range of content being offered to these channels.

Headless content management is closely associated with the approach known as COPE: create once, publish everywhere. COPE burst on the scene over a decade ago with the emergence of APIs that allow content structured by a content model to be delivered to multiple endpoints. 

Content creators are enthusiastic about the potential of structured content to serve many channels. Lindy Roux recently wrote: “in a structured content environment, you only need to create information once.”

COPE is a powerful concept that unfortunately gets misunderstood. Some developers assume that because the content can be technically delivered to different channels easily, all content is ready from an editorial perspective for any channel. That’s not necessarily the case.

COPE is a big improvement on old ways of working with content, where authors would create content multiple times to publish in multiple places. To implement COPE effectively, digital teams should understand how it works in practice, especially when developing multichannel experiences.

COPE is the starting point, not the finish line

COPE isn’t a magic CMS feature you switch on at will. It’s a deliberate approach to planning how to work with content.

COPE means that if your systems are set up properly, you can create everything you’ll need all at once, and they will be available for different channels whenever needed. That power can seem like magic, but digital teams first need to set up their systems to provide this capability. 

COPE doesn’t imply that a single version of content automatically works effectively in every channel all the time. You also need to consider the context where the content will be used.

In many cases, the core content you’ve developed for your web channel will work fine in other channels. For example, much of the content you develop for your website will work fine in a mobile app or an email newsletter. 

Yet teams should also be mindful of how other channels differ. 

The context where the content is delivered and used plays a big influence on UX planning. Teams should consider the diverse contexts when coordinating how content models and design systems work together.

The content model will structure all the enterprise content, regardless of where it is published. Its job is to coordinate many details so that the right information and messages are available where they are needed.  Customers may need or expect different information from various channels. For example, when using a voice bot, they won’t expect to get all the information that’s presented on a website. 

The design system coordinates how content is presented across different touchpoints, which can be websites, apps, or other channels. 

Systems need versatility to respond to the customer’s context.

Customers choose channels based on their context:

• The platforms or devices that are available
• Their environment or location
• The tasks they want to accomplish

The customer’s context will influence the content they can access and how they will use the content. Some channels are optimized for concise content and simple transactions, while other channels can support more complex content and tasks.

The content model and design system should be ready to support customers in various contexts.

The content model structures the source content that’s delivered to customers. It must be able to adjust information according to the customer’s context, showing the right amount of detail in the right format.

The design system specifies how those content details are presented in a specific channel. That presentation needs to match the customer’s context as well. It must be easy to scan and act on, no matter where or when the customer needs it.

The content model and design system both require versatility when dealing with multiple channels. And the more versatile the content model and design system get, the more important it becomes to coordinate them.

As explained in an earlier article in this series, the content model and design system require coordination so that the structure of the content can connect to the structure of design components. Coordination is critical when planning for multichannel content because of the variations in the content and in how it gets presented in design components.

Thinking about differences in channels

Your user experience can’t scale if your content model and design system can’t handle the diverse characteristics of various channels.

Each channel provides a distinctive context shaping how customers access content. The precise content customers will want to access will depend on the context they are in. 

Modular content, working in partnership with modular design, can supply the flexibility that’s necessary to support tailored experiences in a range of scenarios, provided they can adapt to the unique contexts associated with different channels.

Teams that are planning experiences will want to separate which elements will be consistent across channels and which ones will vary. 

Distinguish core content from channel content. Michael Kinkaid, in his Kontent.ai ebook, Content Modeling in a Headless CMS, distinguishes:

1. The core content of the business
2. The content that needs to be varied for a channel—the channel content or “user interface stuff”

This distinction is a useful starting point for thinking about what content can be potentially available to any channel and what content will be specific to a particular channel. Each plays a particular role:

• The core content is vital information that gets presented in all channels. 
• The channel content helps people access the core content.

The core content provides the base foundation for a COPE approach. A customer will likely want to know the price of a product regardless of what channel they are using. The price and other details about a product are core content that needs to be available to all channels.

Yet the COPE approach needs more than the core content to be versatile. The channel content allows the content model to support many channels.

The channel content refers to the content that design teams must create and present for the experience to make sense in the context of the channel. It supplements the core content. Each channel will have a different UI. For example, some use menus and others don’t. Each channel will require some content that will be unique to it.  Different channels can sometimes share channel-focused content. But such content won’t be used by all channels the way that core content is. 

Design systems need versatility as well. They should specify how UI components behave in different channels. 

Modeling content variations

While a good deal of content can be reused across channels, not all content will be “universal” where it can be delivered to all channels.

Consider whether the content will be dependent on the context where it is presented. 

Michael Kinkaid notes three considerations on how channels influence content:

1. What people expect from the channel—how content behaves in the context
2. What the channel supports—how the channel shapes what can be presented and how
3. What the channel interface needs—how customers access the content and take action

The below table provides examples of how various channels handle content differently from the web channel.

Channel	Differences from the web channel
Mobile apps	Space considerations: more progressive disclosure, images as navigation and CTAs, non-keyboard user input (voice, image recognition, QR code)
Digital signage and kiosks	Time- and location-based messaging, touchless and gesture inputs
IoT	Need to convert sensor and telemetry data to human-understandable values
Chatbots	Entity classification of answers, keyword matching of user questions, labels for form elements
Virtual assistants	Will have specific prompts and error responses
Search engine results pages	Meta descriptions, structured data
Social media channels	Metadata (Open Graph, Twitter cards) with an optimized short description
Email	Preheader for content preview, thumbnails for web content preview, a footer with legal disclaimers
Conversational UI	Platforms have specific markup requirements relating to intents, actions, and text-to-speech enunciation
Mobile OS notifications and widgets	Ultrashort titles and descriptions, icons can substitute for images, platform widgets require templated structure for content
Virtual and augmented reality	Content needs to conform to platform operating standards, which can include file formats and geolocation metadata
Screen readers and assistive technology	Non-perceivable content options (captioning, alt text, sign language), ARIA landmarks for banners, alternative names for secondary interaction options such as pointing and tabbing

The core content provides the baseline. These content types will generally be context-independent and can be used in any channel. In some cases, though, elements within content types may need variations to work effectively in different channels. For example, the title may have an alternative short title that’s used on platforms where space is limited. 

Channel content, in contrast, will generally be sensitive to the context in which it is presented. However, similar channels can sometimes share non-core content. Michael Kinkaid observes: “You might find that, with a little tweaking, non-core content types that you originally created for a single channel can be extended to work for multiple ones as well.”

Fine-tune your content model. When planning content types, consider how each channel will need to present content:

• Add content types or elements that are specific or unique to a channel
• Hold back on presenting content types or elements that the channel can’t present
• Substitute content elements that need to be tailored to a channel

Extend the range of channels you can address by adding channel-specific content to the model.  For example, websites have footers that will be unique to websites.  Emails have footers as well, but they will have a different structure.  Footers will be a channel-specific content type. 

Include content in the model that might not be available to all channels but understand the impact of its limited availability. Video and audio content can’t be presented in all channels, for example. When content isn’t available in a channel, make sure it won’t be needed in the channel. Some content will be “bonus” or secondary material that won’t be essential in more basic scenarios. In other cases, content that’s not available in a channel will need to be presented alternatively.

Certain content details within a core content type may need to be presented as variations. While it is generally good to reuse content as much as possible across channels, sometimes certain details need to be tailored to different channels. Non-text content will often require alternatives to support the needs of screen readers and other text-centric channels. 

Plan the structure so that it’s channel inclusive. Ask:

• If it would work on voice channels? 
• If the content is heavily visual, how is it presented as text? 
• If links aren’t available, what else might be necessary to say to let users access the information? 

Examples of core content variations include:

• Headings worded as questions versus as statements
• Short and long summaries
• Images and alt text descriptions
• Audio and text transcripts

Channel content that supports navigation and actions will also require variations since these features can’t be accessed the same way in all channels. These can include:

• Instructions involving actions
• Links that may need alternatives
• Button text and other invitations to action

Don’t try to force-fit content that’s optimized for the web channel into a different channel where it seems awkward and not usable. In many cases, it will be possible to develop channel-neutral content so that variations aren’t necessarily. The copy patterns specified in design systems, for example, can guide authors so that they don’t use channel-specific terminology. Your content guidelines should consider differences in channel terminology. Mobile apps might use the term “tap,” while responsive websites shown on a mobile device might say “click.” The term “select” would be more channel-neutral.

Planning design system variations

Design systems will similarly define rules for where UI components should be consistent and where it’s necessary to vary a UI component’s presentation or behavior. 

Some enterprises will need to create stylistic variations or “themes” within the single channel, for example, when they maintain separate websites for distinct brands.

A more common form of design variation arises when brands present content in different channels.

The design system needs to balance competing priorities in multichannel experiences:

• Maintaining a unified brand
• Adhering to typical UI conventions associated with specific channels and platforms
• Promoting consistency in naming and interaction conventions across channels
• Enabling parity in the experience of different channels as far as possible
• Supporting coherence in customer journeys that move between channels

The web is just one kind of experience. The web is designed to link together documents. The user is presented with a lot of content at once to read and must notice what’s relevant to them. They are continuously making choices about what to read next. 

Other channels involve different models of interaction and will rely on structured content much more. Structured content can support guided interactions, for example, by structuring questions and feedback.

The assumptions of web channel interaction patterns won’t hold when addressing other channels. Some channels are multimodal, combining visuals, motion, and audio with text.

Screenless interactions, such as voice bots and IoT devices, will depart significantly from web channel UI patterns.

Make sure your design system covers all your delivery channels. The content delivered in various channels will be presented differently, and that presentation can influence how the content should be structured.  

Channel needs: the example of chatbots

Chatbots illustrate how both the content and the design will need to adapt to the context of a channel. 

Chatbots share similarities with both browser-based websites and screen-less voice bots. 

Publishers may be inclined to treat chatbots and voice bots as similar channels. While their mode of presentation is different, the content that they present would seem the same. But these channels provide different contexts for interaction, which will influence what content to present. 

Like voice bots, chatbots accept questions and provide answers by listening for “intents.” Unlike voice bots, chatbots aren’t used as much for making commands and complete transactions, although they can be. 

Voice bots have a more limited range of queries they can respond to. They present short answers that can be spoken. 

Voice bot and chatbots both use simple text content. But chatbots can also display links, multiple choices, images, video, and cards, in addition to straight text. Chatbots can support more complex interactions and present links to website content when the customer needs to read more detailed explanations.

Even though chatbots draw on some of the same content that might be presented on a website, only some website content will be appropriate to present in a chatbot due to the small space available in a chatbot window.

Are you ready to support all channels?

Customers expect to access content in a growing range of channels. Brands need to offer a good experience in all the channels they serve. If the experience is poor in any one channel, it hurts the brand overall.

The value of content models and design systems depends on their reliability in a range of scenarios. The introduction of new channels can stress test your existing content and design structure. Test your content model and design system with realistic content to make sure the experience feels right and works for customers.

When content models and design systems are planned with all channels in mind, they provide the foundation that allows brands to create once and publish everywhere.