Content is essential to the success of products. Product teams need a process to ensure that they can provide the right content to customers and have the means to manage that content as the product evolves. A content model provides that capability.

This post will address three critical issues:

1. Why a content model is important for products
2. How to coordinate content model planning with product design and development
3. The kinds of content that product teams should include in their content model

Content should be part of a product’s DNA

Product teams tend to focus on features and functionality. If the product functionality isn’t unique, they may prioritize its design. But it’s less common for product teams to consider how content operates within products.

Content is becoming more influential in products. In the past, content in products was limited to the text on a few buttons, for example, “Ok” or “Cancel.” Product owners assumed the value of their products was self-evident. Today, customers expect far more from products. They use some products daily but quickly drop others. They have countless product options.

Content within products influences how customers adopt and use products. Users must know what the product can do for them. What actions can they take? 

Content guides user action, shaping product usage and task completion rates. Products should clearly describe the actions available in the user’s language.

Product owners increasingly recognize the importance of content. Many are hiring UX writers and content designers to support the development of the product’s design. But content roles on product teams still aren’t nearly as prevalent as developer and UX product designer roles. As a result, content generally doesn’t get considered early in the product development process. 

Content can’t be an afterthought in products. It needs to be baked into the product from the start.

Start planning your content before your UI design

Product owners want to improve time-to-market and agile delivery. Product teams need a way to maintain control over the hundreds or thousands of UI strings that can appear within a product. Rather than figure out these UI strings as the final step in the product, teams should be planning content requirements from the start. These requirements are captured in the content model.

As a team scopes out what the product will offer customers, they will start mapping how the product works as a system: what can customers do and what they will need to know to do those things.

Start with content before screen design. A common practice is for product teams to first decide the design of their product and only then determine what content is needed. They define content requirements within a specific set of screen designs. The product’s content is tightly coupled with specific UI decisions.

But product teams don’t need to follow an incremental, UI-first approach. By following a more robust, content-first approach, teams can:

• Identify all the actions that the product will need to support and communicate
• Figure out where in the product these actions need to be used

With a content-first approach, teams can start to define their content requirements prior to designing the user interface. They’ll determine the user and business needs for content before getting preoccupied with the details on individual screens. They can capture these requirements in a content model, which defines a structure for all the content used in the product. They gain a complete view of the capabilities of the product and how these need to be communicated to customers.

A content-first approach supports a decoupled process to managing content and design, where the content is independent of its front-end implementation. Decoupling reduces dependencies between content and design work, allowing more of the work to be done concurrently.

Another benefit of a content-first approach is that product teams can develop content to support product interactions across different channels. The approach also allows product teams to revise the UI easily as needed.

Content models should be part of your product planning

A content model provides a structure to manage content within products. It can accelerate the development of the product and support its evolution.

Many product teams are introduced to content modeling when they decide to implement headless content management as part of their product’s technology stack. A content model defines the structure of content managed in a headless CMS.

Content modeling for products is an evolving discipline. Most advice about content modeling tends to focus on structuring descriptive content, such as marketing or training content, rather than content for products. While content models for products resemble models for descriptive content, the models for product content emphasize the role of content in supporting product interaction. 

The content supporting user interaction shapes how customers engage with apps. This content, sometimes called microcopy, influences user behavior and the value that users gain from the product. 

A content model provides a central place to specify where content is used in the product. When microcopy is coded directly to UI components instead of being specified in the content model, it becomes hard to manage.

Content models give product teams greater control over the instructions and messages that direct user behavior. By using a content model, teams can keep the wording consistent when it appears on different screens. And the models help when text or messages need revising due to changes in:

• Product features
• Style guidelines
• How users respond to alternative versions being tested

The changes can be readily propagated where needed by the content team without depending on developer availability.

Content models support content consistency, reusability, governance, maintainability, and localization. 

Content models support design and development

A significant benefit of content models is their compatibility with practices followed by designers and developers.

Content models are composed of content types, which are structured units of related information. A content type describes an object or a thing that users interact with.

In a similar way, certain design approaches, such as Object-Oriented UX and Object Modeling for Designers, also capture requirements about objects that users interact with. Domain modeling is another approach some teams use to define user interests that resembles content modeling.

All these approaches complement content modeling. They look at user requirements structurally as a connected system.

Content types also resemble objects in computer programs. The chief difference is that objects reference internal computer data and operations while content types represent content elements that people will view and act on.

Product design and content modeling are both collaborations between technical and non-technical roles. It’s helpful for product teams to see the correspondence and differences between the content model and object model perspectives. Both have similar intents but different responsibilities.

While objects and content types are not identical—content types define much more detail about the content than objects do—they are conceptually similar and provide a basis to coordinate content with design and development work.

Let’s look at how content models and object models are similar. On the right is a UML diagram, widely used by developers, showing how objects (entities) are represented. The left side shows the corresponding content dimensions that will be part of a content model.

Incorporating product interaction in your content model

Generally, the first step in content or object modeling is to identify the things (nouns) that users will care about and interact with. Let’s examine part of a content model to explore the relationships between two nouns.

The diagram below shows the relationship between two content types: a university course and a student schedule. The schedule is a list of courses the student has enrolled in. One schedule will have one or more courses. 

Under the course, we see different descriptive details that users will review. But what might they want to do after viewing these details? We can now think about the interactions users will have with a type of content. Note that in contrast to the UML object model for computer code, the content model should account for both screen-based interactions within the browser as well as interactions between the UI and backend systems.

Include product actions in the content model. Below the descriptive elements is another box presenting some user actions relating to the content type. Here is where we can consider what users want to do when viewing the content. The primary action associated with information about a course is to enroll in the course. When the student enrolls, the course is added to their schedule. But there are other possible actions. The student may not be ready to enroll. They may want to add the course to a course planner, a separate content type that serves as a wish list of potential courses to enroll in (not shown in the diagram). 

Note screen interactions as well. In addition to these functional actions linked to their primary task goal, the user may need to take smaller intermediate actions. Document these screen interactions because they also influence the content structure. For example, when there are many courses, the user may need to search for them by different criteria. The search will need to work with the descriptive elements (for example, location). If the user can search by multiple criteria, they may need to be instructions on how the search can be used. These interactions are generic user needs not tied to a specific user interface.

The student schedule can reference details sourced from the “course” content type and other content types.  The content for the student schedule is mostly a list of items, which users may want to do things with. For example, they may need to change their enrollment status. When making decisions, they may need alternate ways to view the items. Screen-level interactions are decided by the front-end and don’t change the state of the object, but they are vital as they support intermediate steps users take to complete tasks. They will reveal some details that should be included in the content model. For example, for users to see the schedule in a calendar view, the content needs to be structured to allow that. 

The example provides a first look at content elements and actions that can be associated with a content type. More details will be needed for actions, and some widely used actions may be defined as a separate content type as the model is developed.

Naming actions in your product

What does your product do and what do you call that action?

The content model will indicate:

1. Where an action is needed in the product
2. How to describe an action in that context

At the start of the process of developing a content model, you can note a human-friendly name to indicate the action in the model as you develop it. These names can be formalized later.  

Consider different naming perspectives. Actions will have internal code names that will differ from user-facing names. For example, a user might create an account or create a review. Both actions internally may be referred to as “create”, but they won’t necessarily be referred to that way to users, who would be instructed to set up an account or write a review. 

The naming of actions will often depend on the content type and the context where the action appears. Sometimes actions can be described with short names, but other times a fuller name is needed to remove ambiguity as to what the actions involve.

Think about where the interaction would just need a simple term that could be used on a label or link and where the action would need a phrase to explain.

In summary, actions are described in multiple ways:

1. The internal name for the action, which will include an agreed definition of the outcome of the action. For example, would “remove” save the item for later use, or would it delete the item permanently? This is especially crucial if two actions sound similar and might be confused. 
2. The user-facing term for action. A formal term will often be specified in a style guide and may be related to the feature name. The style guide might also prohibit certain terms such as “close”, which could mean different things depending on whether it refers to a UI element, a user account, or an application.
3. Alternative terms or phrases for the action. For example, if the default user-facing name for an action is “dismiss”, in some situations, it might display as “not now.”
4. A full phrase for complete action within a channel, which may reference UI objects such as panels or tabs.  For example, a confirmation message may refer to an action more completely (“item has been deleted from your list”).

The structure of content about an action resembles a thesaurus, providing alternative ways of describing the action. 

Develop a list of all the actions associated with each content type. As the team works through each content type, they may find that certain actions repeat across different content types. These actions can be split out separately so that they are reused instead of repeated. By doing so, all content associated with the action will be managed and updated in one place.

Develop a list of actions that need content planning

While the nouns represented in the content model will be specific to the content of your organization, many of the verbs or actions will follow common patterns. Many actions are shared by different content types. Keep these in mind to ensure your content models don’t overlook any essential actions.

As content writers collaborate with developers when developing your content model, consider how developers think about actions from the computer’s perspective. They will first think in terms of two approaches:

• “Crud” operations (internal application actions)
• HTTP methods (external API requests)

Both approaches yield four core operations that cover a wide range of actions that people will want to do when interacting with content. They provide a starting point for thinking about the actions within the product.

One core action is searching or locating information, which can involve multiple user interactions, such as inputting words, specifying a filter, getting results, and refining them. Note that from a user’s perspective, an action is not necessarily a single tap or mouse click but can be a series of interactions to support a larger one.

Many user actions exist beyond these basic ones. Other common actions relate to:

• Access (joining and leaving an activity, session, or service)
• Movement (proceeding, confirming, concluding a series of steps or decisions, or stopping a process)
• Permissions (allowing and denying preferences and choices)

As you identify actions requiring content, keep in mind completeness in coverage:

• Be sure to include reciprocal actions like add/delete 
• Identify and clarify distinctions among similar actions, for example, undo, redo, reset, clear, or restore

It’s not only button text. For actions that require multiple steps, identify the flow and sub-flows associated with a task, noting:

• Choices
• Informational confirmations
• Inputs that the user needs to make prior to taking their final action

Add action-supporting content to your model

Think about actions as a process rather than as an event. Users won’t necessarily execute an action in a single-screen interaction. Rather, they may require several interactions before the action and sometimes after it.

Content supporting product interaction encompasses more than the labels for buttons. Don’t use the content model to document what microcopy belongs in specific UI elements since your widgets could change. Instead, use the model to specify the role of information and messages in relation to the tasks that the user wants to accomplish. Focus on what users need to understand or decide rather than how they will interact with this content, which could vary in different channels or product iterations.

In addition to specifying the content describing the action (what the user tells the app to do), the models should specify other kinds of content the user will need to see:

• Options
• Instructions
• Explanations about why to do something or what has happened
• Statuses conveying system messages 

Options let users choose who, what, where, when, or which item to act on. These are generally predefined inputs that users will select. While ideally the options are self-explanatory, in some cases, options may have their own explanations if they aren’t already familiar or might be confused. For example, if the user has a choice between the premium and deluxe packages, these terms may need elaboration to highlight how they differ.

The user may need to be able to specify multiple choices instead of just one. In these cases, options will need to indicate whether they are available, selected, activated, or unselected (and available again).

Instructions tell users how to specify an action and why it needs to be done a certain way. They are critical for any unfamiliar or complex action and whenever users need to provide information that is not a predefined option, such as personal information. 

Instructions influence how users provide information in input fields. Some content elements associated with instructions include:

• Prompts such as labels telling users what information is needed
• Examples illustrating the kind of information needed, such as helper text
• Indicators about what information is mandatory versus optional
• Feedback on whether the information provided by the user matched what was expected

Explanations tell users why to do something or what has happened they should respond to. Explanations may be provided proactively or at the request of the user.

The most common type of explanation is help content, which varies in length and detail:

• Brief help clarifying an instruction, such as a sentence that might appear in a tooltip
• Guided help, such as multi-step guided tours explaining features or options
• Diagnostic help, such as in-context help
• In-depth help in articles or videos

Error messages explain situations that require immediate attention. Errors can be broken into three specific elements:

1. The alert communicating the problem
2. An explanation describing the cause or consequences of the problem
3. One or more calls-to-action giving users ways to resolve the problem

In-product notifications concern less urgent or upcoming events. They commonly have two main elements:

1. The notification message
2. A recommended next step

Statuses are predefined messages indicating the availability and readiness to provide things requested by a user. The status can relate to system or outside resources or past actions by the user. Statuses can indicate if:

• A product is in stock or not
• A time slot is available for booking
• The system is down
• A transaction was processed

Status messages can describe system changes, indicate past interactions by a user, and provide confirmations of user actions. The message will describe a status of some variable that is linked to an action the user wants to take or has taken. The status of variables can take many forms:

• Time-based (ready, delayed, canceled)
• Permission-based (allowed, permission required, prohibited)
• Availability-based (in stock, low stock, out-of-stock)
• Outcome-based (success, failure, pending)
• Risk-based (danger, warning, safe)

A status may be expressed as content in various ways, depending on the context. The content model should identify:

• Statuses that require content
• The different kinds of messages needed for each status 

The status can influence how a message is presented in the UI. For example, the message may get different visual treatment by being disabled or shown in red, for example.

Mapping the content model to the user interface

So far, we have been looking at the development of the content model in terms of user and business requirements for the product, independently of the UI design.

The content-first approach yields a richer perspective on the product than a UI-first approach. The content model reflects the capabilities of the product, not a specific UI. A content model should reflect the role of content to support interaction with the product rather than how users encounter a user interface that could change in a future product iteration. By doing so, it will be flexible enough to support different channels for the product and alternative UI designs.

Integrating content with design and development. Once the foundation of the content model is in place, teams will look at how it will connect to the product’s UI. The details within the content model will bring more specificity to the UI design. This mapping can sometimes reveal additional content elements that need to be included in the content model. 

The first step is to cross-reference the content model with the design system for your product if you have one already. Check whether your existing design system covers all scenarios that your product will need to support. Consider any channel variations that will influence how content needs to be presented.

The next step is to look at how content will slot into specific UI dialogs or screen flows. 

When you have a mapping between the content model and a screen, it becomes much easier to change the specific content presented on a screen. If a user needs to input their date of birth, the instruction can be changed from “Enter your date of birth” to “What’s your birthday?” The model allows the content to be managed independently of the UI. 

Content models provide long-term benefits for products

In the early stages of product development, the content model provides a product-wide overview of what content will be needed. Instead of deciding content requirements incrementally as each screen is designed, teams gain a comprehensive insight into the structure of the content that the product will have. The model helps teams plan requirements so that they aren’t caught by surprise by unanticipated requirements that can arise from piecemeal content development.

After the product is released, the content model facilitates the support of the product. Product teams know where in the product certain terms and messages are used. They can revise these easily to respond to product changes or customer feedback.