How to include the right details in your content model
Experts agree that getting your content model right is critical to your long-term success. Can your digital team plan your model without getting lost in the details?
Published on Nov 11, 2021
Experts agree that getting your content model right is critical to your long-term success. Can your digital team plan your model without getting lost in the details?
Published on Nov 11, 2021
Content models bring focus to details. But identifying the right details to include in the content model can be challenging.
Content models are easier to plan when teams are guided by a common understanding of what they need to achieve. Content types can play different roles.
Teams should think about content types in terms of topics, tasks, and containers. These concepts will help to clarify how a content type is meant to support users.
The content model structures what an organization will say online. It defines a common structure for how to talk about things. The model can cover all the information and messages organizations provide customers on websites, mobile apps, emails, social media, chatbots, in-product UIs, and other channels.
The content model allows content to be modular. Enterprises can use content models to manage which details to provide to customers and when. The model structures all the content within a headless CMS and makes specific details available via an API when they are needed.
Customers move between channels, switching devices and platforms, sometimes with interruptions. They will start a task in one channel and complete it in another. No matter where they are in their journey, they expect the details they view to be relevant.
Because users are touching content many times instead of once, they won’t necessarily want to see every detail on a single web page. Brands need to break their content into smaller pieces that are pertinent. The model can manage what details to show to:
The secret to making content relevant is to structure it from the customer’s perspective.
Before breaking down the details associated with content, teams should consider the user’s broader purpose when scanning content—their larger motivation. Users need content to be structured in a way that helps them:
Each of these motivations will be important at different stages of a customer’s journey.
From purpose to detail. As teams model their content, they should think about how customers interact with specific elements within that content. Look at particular scenarios and note what details customers need to view as they do things.
Writers and backend developers should work together when planning models. Writers provide editorial and domain expertise, while backend developers plan the abstraction of the model to accommodate API calls. But neither of these roles is necessarily familiar with the design system that will present the content to users. Even when they know details they want to offer to customers, they may lack insight into how those details will be presented and used in different UIs.
Be sure to include someone with UX expertise who can speak to how the details could be presented in various scenarios. You don’t need to design screens when creating a content model, but it helps to understand the range of ways content can be presented in different channels. Consider how the customer will make use of details structured in the content model. How can content be assembled in different ways to be useful in different scenarios? When the content is structured with user relevance in mind, it is more powerful.
Let’s look at the different roles that content types can play. Content types can have slightly different goals, depending on how users need to access the content.
Content can talk about almost anything. There are hundreds of potential content types that can structure content about many kinds of issues. Yet we can classify content types as belonging to one of three conceptual categories:
The below table summarizes the relationship between user goals and kinds of content structure:
User goal | Kind of structure | What it does |
Understand a topic | Information content types | Structures the details of information about a topic |
Complete a task successfully | Task-focused content types | Structures messages and instructions to help users to act |
Orient themselves to the available information | Containers of content types | Structures other content types into larger content products |
These conceptual categories can be broken down further. The diagram below illustrates the landscape. By understanding different ways content can be structured, your team can make its model more robust.
Most content types will structure the details of a topic to allow users to understand what they need to know.
But what do users need to know? What’s relevant to users will depend on the scenario: when they need to access the information and where. The content model allows the level of detail presented in the UI to adjust, much like a knob on a radio can adjust the volume of the audio.
Topics are defined by their coverage—their completeness or depth. This raises the issue of how much detail might be needed. The details associated with a topic are broken out or structured within a content type to present specific details in different scenarios.
Experts often recommend structuring content according to its “semantics” or meaning. That’s good advice for structuring topics, though it may be less helpful when structuring content that's not focused on topics. But this emphasis on semantics, even when relevant, can sometimes be misleading. The goal of content structuring isn’t to enumerate every detail about an entity you might need to discuss. Rather, it’s to provide the right details that people need to know.
Structure information according to user needs. Identify and break out those details that users will:
A good starting point for structuring topics is to identify the common questions that users have. If users were looking for specific information with a label or heading, these would be elements within the content type. Topics have relationships to other topics. Think about what other topics are related and other information users might want to access.
Explanations help users, especially non-specialists, to synthesize various details. They are an important kind of content because:
A common misperception is that general explanations lack structure because they are narrative in their orientation and can’t be broken down into brief, discrete details. This misperception arises when planners assume that content structure is only intended to present detailed data and not narratives. Yet narrative content can be editorially structured. Doing so increases the flexibility of the content. And adding structure to narrative explanations provides more context to readers, so they can locate what they need to know.
Some examples of general explanations include:
Narrative structure will reflect the aspects that require elaboration. Consider how content might talk about a complex issue with a long history. Because of the complexity of the topic, a narrative is needed, rather than simply an abbreviated timeline of dates and decisions. The narrative can be structured into parts, summarizing past events relating to the issue, its current status, and the expected outcomes in the future. Someone already familiar with the issue could skip the summary of the past, while someone less familiar with it might appreciate that summary.
Long-format content—narratives having more than 500 words or videos longer than a minute—can discuss a range of topics. They can be structured into elements that can be hidden or reused, depending on the context. The structure will emerge from thinking about the user’s journey when encountering the content. Some common elements include:
Specialized topics are those related to “entities” (a thing or process) that have standard properties that need to be mentioned as part of the description. For example, an airline flight will have unique properties, such as a departure and arrival time, that will differ from other kinds of events or services.
Specialized topics included descriptions of details about:
These content types will break out the important properties of what they are describing. Sometimes developers will characterize this content as “data,” but the content does not need to be a numeric or controlled value. The value can be a text description though it will generally be short.
Some topics are associated with complex decisions or plans that won’t be decided all at once. The detail required will depend on the customer's importance of considerations (costs, location, dates, availability, risks, etc.). For example, someone in the early stages of planning a vacation may not yet be assessing exact costs or dates. Still, later they'll want less general information and more specific details. When the user is considering decisions broadly, narrative content is appropriate.
Examples of topics involving decisions include:
The more important a detail is as decision criteria, the more important it is to break out these details so they can be presented in different ways and at different times. The structure should break out decision criteria, especially when they can change or become a ranking item. It’s also possible to structure the decision process by breaking out:
Not all decisions are complex and require lots of explanation. When decisions can be made online in a single session, the content type becomes task-focused.
Tasks-focused content helps users complete tasks online. This content focuses on messages about actions rather than information about things. Because of its focus on messages, the wording used in the content is vital for task-focused content types, especially the button text.
Online tasks can relate to:
Users need guidance on how to perform these tasks. Task-focused content is generally UI copy or microcopy, but it could also be conversational copy for a voice bot or an interactive diagram used in a product repair diagnostic. While commonly considered as “product content,” it is not limited to in-product UI copy. Task-focused content can appear in communications outside of products, especially when presented to users who are not yet customers.
In contrast to topic-focused content that often relies on longer narratives, task-focused content is much more succinct. It tends to:
Tasks are sometimes related to an entity, such as a service or an event. But in such cases, normally, only select information about the entity needs to be presented. For example, the content might present information relating to a service (your payment is overdue), but the emphasis would be on the action (pay immediately to avoid interrupting your service).
Content supporting tasks are essential to business outcomes. Most enterprises will have fewer task content types than they have topic-focused ones. But task-focused types are heavily used: the content and design presenting tasks need to work well together. Tasks are often critical to delivering expected business outcomes, so the task completion or conversion will be measured carefully. The structure allows for different content combinations and variations to be tried. Teams will track metrics on feature usage, measure usability, and optimize the structure.
UX writing is concerned with the wording used to support tasks, especially the role of clarity, tone, and persuasiveness. Task-focused content can include both marketing copy used in promotions as well as UI copy. It can be useful to distinguish whether tasks are utilities that everyone needs or whether they will be specific to certain groups of people in specific scenarios.
Certain tasks are routine, involving functionality that all users will need to access. Apps will provide global utilities. Much of this functionality is identical to what’s available in other applications and familiar to most users. If an app has introduced a new feature, the content describing the feature can be crucial. The user may not expect the functionality or be familiar with how to use it.
After the user becomes aware of the functionality and decides they want to use it, they need to do so easily. The clarity and usability of the labels and instructions are essential. Though the volume of content is small, it’s important that it can be managed centrally. Because these utilities may be available in different apps and platforms, they should provide consistent wording. The wording may also need to be translated.
Content types can structure microcopy for UI functionality such as:
Certain tasks are discretionary and dependent on the user’s context. Not everyone needs this content related to these tasks, and no user will need to view it all the time.
In contrast to utility tasks, where the user initiates the action, the user is prompted to act with context-dependent tasks. The content will often need to convince the customer to do something. It will present messages about specific issues for the customer to consider. The content may change depending on the scenario, such as the customer segment or situation. The content model allows digital teams to manage message variations. It also allows the content to be managed across channels. The customer may be notified by text or email to do something and presented with a link to complete the action on a website.
Context-dependent tasks include:
How many messages are needed will depend on how whether the user will have any questions or concerns. Scenarios that are unfamiliar or seem less urgent may require more messages. Promotional CTAs sometimes will link to more detailed, topical content narratives, such as a video explanation.
Content that supports online tasks is typically brief and does not provide much elaboration. By contrast, instructions and procedures that relate to offline activities resemble information content more than task-focused content. They primarily explain rather than motivate action within the UI.
Many content items are built from other items. Behind the scenes, containers will structure other content types. Think of them as “slots” for other content types. Containers enable modularity.
Structural containers help users with:
Structural containers are sometimes overlooked at first because they aren’t focused on discrete information or messages. Only when teams think about the user experience does the need for structural containers become evident.
Authors can use containers when they need to assemble or aggregate different content items made from one or more content types. Containers are useful for:
Unlike other content types, containers hold little unique content. They can structure Information architecture elements and metadata. But they mostly aggregate other content types. For example, a web page featuring different products might have a unique title, but most of its content is composed of other content types. The web page framework is primarily a container for other content types.
Think of structural containers as frameworks, not designs.
Structural containers are not layout. The structure of the container is independent of its specific presentation in the UI. The layout reflects the structure but does not define it. Containers can indicate logical hierarchy, but they won’t define spatial positioning, for example, whether items are displayed horizontally or vertically.
Examples of containers for other content types include:
Some containers, such as the newsletter framework, may be specific to a channel or digital product. Containers can set the context for how content is consumed, accounting for how many details can be presented at once and how much users will interact with these details.
Content modeling requires thinking about many details, which may seem overwhelming when first starting the process. The good news is that the process becomes easier when teams plan according to the purpose of various content types.
This post introduces a conceptual scaffolding to classify content types according to their role. At a high level, content types are related to topics, tasks, or containers.
Role-based content modeling provides benefits:
By considering the content type’s role, teams will identify the details that are needed to support different use cases. It prevents unnecessary details from cluttering the model and ensures that the range of content types is complete.
This process also helps design team members. They can understand why the content exists to plan how to present it. For example, topic-focused content can be presented in various layouts. Cards could present selected details. Task-focused content would need to be presented in appropriate design components. Containers could provide the skeletal foundations to populate multiple page layouts.
When teams can see the broader purpose of each content type, it's easier for them to connect the content structure to the design structure.