Content design for digital products is a fast-growing area of content strategy right now. Do enterprises have the right infrastructure in place to support their digital product development and delivery?
Published on Oct 26, 2020
Enterprises deliver value to customers through products, and content adds value to those products. But as product content has grown in importance, how it is managed has emerged as a critical issue. Product content is different from other kinds of enterprise content in certain ways. At the same time, product content management can also build on established practices used in enterprise content management. This post will look at how these fields relate to each other.
A decade ago, the well-known venture capitalist Marc Andreessen wrote in the Wall Street Journal that “software is eating the world.” He noted that “more and more major businesses and industries are being run on software and delivered as online services—from movies to agriculture to national defense.” Those observations are even more true today.
Organizations of all kinds develop digital products. While SaaS firms are best known for digital product development, almost every kind of organization has joined the movement: manufacturers, retailers, consumer goods makers, travel and hospitality firms, and even governments and nonprofits. The shift toward digital products can trigger organizational change within enterprises, such as:
Enterprises define digital products in slightly different ways, depending on their internal organizational structure and processes. They may have different ideas about the boundaries and distinctions between products, features, services, and platforms. Some digital products are entirely digital (online learning apps), while others facilitate and coordinate customer usage of physical goods or services (food ordering and delivery apps). Most digital products have revenue goals: they are monetized directly, or they influence customer spending.
Most definitions describe digital products as being:
Digital products take different forms. They may be:
Digital products have a different orientation than websites—they are more focused on doing things and less focused on explaining things. That distinction, however, is not absolute but rather a matter of degree.
| Apps | Websites |
| Customers use an app to do something | Customers use a website to view information about something |
| The content supports how to use functionality and do tasks within the app | Functionality on the website supports the content experience |
| Focus on product usage | Focus on content usage |
| Focus on short communications | Focus on longer communications |
In both cases, the content presented influences a customer’s behavior. In the case of digital products, the influence will be more direct but also more limited. The wording of a label in an app can influence how likely someone will be to take an action. But a label by itself will be limited in how much it can convince or inform a customer who does not already have an idea what they’d like to do. For that reason, websites and other online content outside of an app are also necessary. No app, no matter how well crafted, can explain itself completely to everyone who uses it. An app will always need support from other content resources.
Even SaaS firms, whose revenues entirely depend on digital products, rely extensively on content outside of their products. This is especially true for firms with a B2B focus. Many forms of content that explain the product in detail won’t fit inside the product interface. For example, Intercom, which provides chatbot products, offers a range of content on its website:
In addition to content that promotes understanding of how to use the product, firms need to explain the product to those who don’t yet know about it. To do that, they use marketing content that’s published on the firm’s website or posted in an app store or marketplace. They will also use communications outside of the apps, such as email newsletters or device notifications.
Successful digital products deliver routine functionality clearly and pleasantly. But they also need a plan for how to deal with surprises that are outside of the routine. Often these surprises are unpleasant ones, such as when a technical or account problem arises. Occasionally the surprise will be pleasant, such as an upgrade that will happen. In either case, it will require a non-routine action by the customer, whoʼll need to consult additional content to understand and resolve the issue.
A major difference between interface content and content for other channels relates to coverage. A product’s UI must be able to address a range of common customer tasks such as taking actions and tracking the status of activities. Yet the content presented within the UI won’t be able to provide much depth. Websites, video libraries, podcasts, and other channels, in contrast, can address broader parts of the customer journey in greater detail.
In short, interface content within products is just a part of a larger ecosystem of content that product-focused firms need to provide.
All content that supports digital products needs to communicate value. Value is what’s important to the customer—something they’ll get that they don’t yet have. The value that customers perceive when interacting with your organization over time directly impacts revenues. It influences both the price you’re able to charge for your products and the retention rate you achieve. Your content shapes how customers perceive the value they derive from their relationship with you.
When digital products first entered the mainstream, the emphasis was on bringing the power of automation directly to customers. Product teams focused on the functionality offered; the content within products was an afterthought. As the content strategist Melanie Seibert notes, when something was confusing about an app, a common response was to create documentation to clarify the confusion. Yet it is more efficient for both customers and enterprises if the content within the product were clear to begin with. Improving the wording or other content can sometimes eliminate the need for extra documentation.
When a customer’s relationship with your organization is largely through your products, those products need to be clear, easy to use, and compelling. While these user experience qualities have long been recognized as important, only in recent years has the role of the content within products on the customer experience been widely acknowledged. Many enterprises now hire UX writers or content designers to provide great content for their products.
A product’s UI imposes constraints on communication. Because of this, UX teams work to communicate the information succinctly and flexibly. While interface content is brief and compact, it is more than the words on labels and buttons. The content is designed—within the context of the user experience as a whole. Interface content is now routinely prototyped within UI design tools such as Figma or Sketch. The experience that the content conveys extends beyond the literal meaning of words. Sometimes, a few words are insufficient. Different modes of communication within a digital product can exist, depending on the need:
The user interface is where customers either discover or realize value. Shopify, the online e-commerce platform, stresses the importance of product content: “Thoughtful, consistent interface content is a core element of a well-designed user experience.”
Interface content influences the adoption of the product. It shapes the customer behavior by:
Interface content supports high-frequency tasks. Given its influence of content on product usage, the performance of content elements should be tested and evaluated in granular detail. This need is driving the adoption of a more structured and modular approach to content development within digital products, which allows:
No matter how effective the interface content is, digital products also need an ecosystem of content available through other channels that can back up that primary screen. Product teams have to to think beyond the immediate content that appears within the digital product to consider what other content needs to support the customer.
Any product that’s deployed widely will generate edge cases—issues that arise because of the varied circumstances of a diverse range of users. Routine tasks are designed to be easy, but less routine tasks may require information from the customer or necessitate that they look at more information. Products need support from resources outside of the product. Not everything that must be conveyed can be stuffed into a streamlined UI: the product would be burdened by complexity. Other documentation and services need to back up the app. And all this information needs management.
Product-oriented enterprises are weighing the balance between “product content strategy” and “enterprise content strategy.” Many are placing more emphasis on content design for products over content strategy for enterprise content that is used on websites and other channels.
The content strategy teams at Shopify and Facebook both recently decided to rename themselves as content design teams, reflecting their organizational focus on delivering distinct digital products.
Enterprises with content designers include them as part of the product or UX teams. Other enterprises hire UX writers to create interface content. Those who develop interface content consider the impact of content on two dimensions:
UX writers typically support several projects. Because they are focused on delivering specific product releases, they work within UX teams and separately from marketing or customer support teams that also produce content. Different writers talking about the same product will be on different teams. The writers who create content explaining the product to non-customers will be separate from those who write content within that product, and those who work on customer account topics may be a separate group as well.
In many respects, it makes sense to divvy up content creation according to business function (marketing, product, and support). The skills required to produce each kind of content are different, as is the process for delivering and incorporating this content to support these business functions. Separate content teams can play to their strengths. But they should still be aware of what their colleagues elsewhere in their organization are doing. The customer, after all, doesn’t care about internal functional divisions within the enterprise. And the enterprise should be able to optimize all the content that’s created about their products so that it communicates coherently and effectively.
But individual product teams are not in a position to make all content decisions. They lack the perspective of what’s happening across the enterprise and don’t have the time or resources to build long-term knowledge and capabilities.
Agile teams developing products have a bias toward shipping the next release. The improvisational process—figuring out what’s feasible to deliver in the short term—can result in ad hoc decisions that are inconsistent. Different product teams may pursue different approaches in their content. Even the terminology and tone of content within a single product can shift over time unless there’s a process to maintain consistency. When content development is reactive, produced for specific design sprints without a grounding in a broader system, the outcomes will be inconsistent across the enterprise. The content becomes fragmented and incoherent because individual writers work in silos unaware of what other content is being created.
Compared to product content strategy, enterprise content strategy takes a broader approach to content development, one focused on the longer term. It defines a vision and guiding principles for all content based on customer and business considerations that extend beyond the immediate requirements of a specific product.
Enterprise content strategy can support multi-product research and planning, developing in-depth profiles of customer groups, and planning their journeys through different sources of content across many channels. It also develops operational capabilities such as cross-organizational governance, shared standards, and common processes that can benefit writers on different product teams. By focusing on systemic issues, an enterprise strategy raises the overall quality of the content while making the work of creating and managing it easier.
An enterprise content team can bring coherence to different sources of content created throughout their organization. They can ensure that all content is actively managed so that itʼs accessible to all and can be coordinated.
How content gets managed must account for the needs of customers—not only the needs of individual products. Customers interact with more than a product; they have a relationship with the enterprise offering the product. A product may be the primary focus of a customer, but it’s not their only concern. Customers will need to access enterprise content that relates to more than a product. They need content that’s not product-specific.
Even if each digital product is accountable for its own success, each one is not entirely independent of the others. Each product is part of an enterprise’s product portfolio, which will likely develop over time to take advantage of common characteristics of the enterprise’s capabilities and its customers. These synergies between distinct products provide competitive advantages. And the content associated with each digital product will need to work in harmony with the other products.
Different products will need to share common content because:
The portfolio of products, viewed as a whole, influences how customers perceive the brand. Customers encounter the voice and tone of the products through its content. For example, Apple offers many digital products, from subscriptions to credit cards, but maintains a consistent content experience for all.
A product content strategy is not an alternative to an enterprise content strategy. Both are necessary, with each making a specific contribution.
Enterprises should be careful before they devolve responsibility for digital product content decisions to the point where every team operates with complete autonomy. When content activities aren’t coordinated, productivity and customer satisfaction both suffer.
Michael Haggerty-Villa of Intuit notes the need for enterprises to offer “guidance for pieces of content that get written over and over again. You know what they are: headlines, error messages, emails, blog posts, contextual help, help articles, and other content types.”
Enterprises will often have many products, which shouldn’t be managed in isolation.
A unified content strategy, covering both interface content and other content, can ensure that all kinds of content are aligned. For example, the strategy can support:
It can also plan for cases where various products share certain content. For example, customer account information will be common to many products. Consider an invoice problem. Some messages will be presented within UIs, while more detailed explanations will be elaborated on in web pages or other channels.
Without a unified strategy that includes product content, the risks include:
The writer and designer Scott Kubie notes the important role that content strategists play in supporting the design of digital products: “People who write interface copy (often called UX writers) and people who borrow user-centered design methodologies to plan and craft larger content experiences (often called content designers) rely on the work of people who design the organization’s overall approach to planning, creating, and managing content (often called content strategists).”
As Scott Kubie suggests, the content within digital products depends on having an overall approach to managing content. It’s important to connect the wider ecosystem that supports the development, management, and delivery of all content in the enterprise. Interface content shouldn’t be managed separately from that ecosystem.
Right now, many enterprises manage their interface content in isolation from other content they develop. A growing number of tools are available to manage UI text. While they support the needs of product teams, it is less clear they support the global needs of the enterprise.
Text management features have been added to UX design tools, which help writers explore how content appears within the UI. A few vendors are developing plug-ins to design tools that store interface content by synching text in the browser with a file holding the UI text strings. While helpful to writers, this solution by itself does not solve the broader issue of how to align interface content decisions with those involving other channels.
As the interface content goes into production, it will often be stored as part of the front-end code repository such as Github. While convenient for developers, storing interface content in this way is not so helpful for writers and designs. Code repositories are not ideal for storing content. And the interface content is isolated from the wider body of content that the customer will encounter when using the product, which makes content development decisions more difficult.
How can interface content get connected to the wider ecosystem? To start, it can’t be seen as solely a front-end or back-end responsibility. Jennifer Schmich, who works in content strategy and systems at Intuit, advocates a “full-stack” approach to content: “Content strategy requires a full-stack approach, blurring the line between front and back end.”
A good CMS provides full-stack support. It supplies the front end with content while managing what’s created on the back end. It can connect content to other systems, provided it has the right capabilities.
A standard web CMS, however, can’t bridge the gap between interface content and web content. For that reason, few UX writers consider the possibilities of using a CMS in their workflow. But a headless CMS is different. It is not tied to presenting content in a web channel. Headless CMSs often supply content to apps of different kinds, such as smartphone apps and voice bots. It stores content as structured pieces and can manage modules of interface content. And if they utilize APIs, headless CMSs can connect where content is stored with other systems that produce or consume content.
In contrast to a web CMS, the content managed by a headless CMS does not have to be created within the CMS. It’s possible to connect a design tool like Figma to a headless CMS via an API. Other repositories can sync with the headless CMS, providing the possibility that all content can be centrally stored, allowing comparison. In addition to allowing connections via APIs, a headless CMS stores content in the JSON format, which is widely used by both design tools and front-end code libraries. This allows the content to move where it is needed. Moreover, a headless CMS is friendly to both authors (who use an authoring interface to draft or edit) and developers (who can use a command-line interface to get content).
The content requirements associated with digital products are more diverse than those for websites. Digital products need to display content in different ways, taking advantage of the more effective UX experiences on offer. The content relating to digital products must be available in different channels. The versatility of a headless CMS enables it to manage content in any format for any channel.
Digital products are constantly evolving, taking advantage of new hardware and software capabilities. While it is important to know how content appears within a design, it is also important that the content not be locked in that design, since designs will change. By managing product content in a headless CMS, it is no longer embedded in the front-end code associated with a specific design. The content is ready for any new designs. Product teams can figure out what content they can reuse and what content may need to be modified or added.
The ultimate benefit of a headless CMS for the management of product content is that it is designed to support APIs. Many apps are now cloud-delivered rather than locally installed, relying on APIs to provide services and information. Content managed by headless systems is a perfect fit for such products.
More digital products are being delivered as Progressive Web Applications, which have the power of “native” apps installed on a device but can be accessed by web browsers, making them more widely available. “Progressive Web Apps (PWA) are built and enhanced with modern APIs to deliver enhanced capabilities, reliability, and installability while reaching anyone, anywhere, on any device with a single codebase.” Since the product can be available on any device, the content supplying that product needs to be as well.
Like other kinds of content, product content benefits from being managed in an API-oriented content hub. To take advantage of these benefits requires a full-stack approach to content, where writers, designers, and developers understand and support each other’s respective needs. They should be able to use the tools they prefer yet be able to share their work easily. Content can’t thrive if it’s managed in silos. It needs to be connected.
Listen to our new podcast for practical tips, tricks, and strategies to make your content shine. From AI’s magic touch to content management mastery and customer experience secrets, we’ll cover it all.
