Many organizations are looking to upgrade the role of content in their products and services. Customers can access content across many channels now and don’t just passively read it on a website. They expect to be able to take action as they view content. 

Interaction design determines what users can do with a digital product. Content provides the narrative that guides the user’s actions. 

For content and UX teams to collaborate effectively when creating a design, they need a common understanding of how people will make use of the app they’ll be creating. 

Interaction design is a content issue. Too often, content is considered only after the UI design has been created. Or content requirements are allocated a secondary role on a project. The whole design team needs to consider: What should be the role of content in the design? How will people use content? The content design must complement the UI design. The app must both support what the user wants to do and help them understand what they need to know. 

Content interaction within an app can be looked at from two perspectives:

1. What can people do with the content? (content is the primary resource)
2. What content is necessary to help people accomplish tasks? (content is a supporting resource)

For example, people may want to transform the content they’re viewing in some way: to sort it, share it, or save it for later. In these cases, the app’s functionality supports deeper use of the content. Having features that let people use the content later or elsewhere is especially helpful when they aren’t finished with it after first seeing it.

Alternatively, people may be using the app to accomplish a task that’s not primarily about content, such as making a travel reservation. But to accomplish the task, they need to consult content to guide them. 

Interacting with content

When deciding on the interactions, the design team should plan:

• The options that users will have to take action
• The communications that should be available

The user interface will present various kinds of advice to help them accomplish their goals: information, instructions, labels, and messages. This content can be: 

• Short – a few words on a button 
• Condensed – a multilayered widget that displays a hierarchy of text, images, icons, color changes, and motion feedback
• Extensive – detailed writing, videos, diagrams, or data tables

The right level of detail will depend on the scope or complexity of the task. 

What users need to understand and be able to do will vary widely. You can look at user needs and goals through the lens of:

• Why: triggers and goals
• When: sequencing and flows
• Where: channels and locations
• What: activities and tasks

Before the project starts designing screens and creating content, the team needs a common understanding of the interaction requirements so they can plan a coherent experience for users. 

The sort of interactions that a design needs to support will depend on:

• How much functionality is associated with a design
• The novelty of the interactions, such as whether the app is addressing a new channel
• Whether the users are presented with open-ended or close-ended options

Design projects can draw on various tools and methods to plan user interactions. No one method is necessarily best, though some will be a better fit for certain projects, depending on their goals. Your project should choose those which seem most appropriate. The most common tools are: 

1. User scenarios
2. Customer journey mapping
3. User flows
4. The Core Model
5. User stories
6. Object-Oriented UX
7. Task analysis and modeling
8. Use cases

These methods address similar issues, so it’s not necessary to do them all. Yet each has unique strengths, and it can be helpful to develop more than one perspective on user interaction opportunities and needs. Some methods go deep into an interaction (breaking down complexity), while others go wide (joining up details and integrating them). 

User scenarios

When users face a specific situation, what do they need to do? What content will they need to consult?

Scenarios are high-level stories about how users think and behave in a given situation. The stories can express what people are doing, thinking, and feeling at different steps. They can be used to probe informational needs, the functionality an app must offer, and the constraints it must accommodate.

Scenarios are primary an ideation tool. Sometimes, they are used later as a script to test the usability of the design. 

For UX designers, these scenarios provide a starting point for thinking about design modules that users interact with inside the app. These could be forms or design components such as notifications, error messages, or CTAs.

For content developers, scenarios generate questions about the user’s situation and how to best meet their needs. It can illuminate:

• The larger context driving user needs
• The user’s mental state, which will influence the voice and tone of the content
• Moments to reassure the users
• Likely questions the user will have at different stages of the scenario

Customer journey mapping

Customer journey mapping is a popular tool to explore and plan the future emotional experience a product or service will offer. The maps provide a customer perspective on how they approach their situation and the goal they have. 

Journey maps provide a detailed look at how a user approaches a scenario. They can diagnose common points of friction that users face. When the end-to-end journey is mapped, it can suggest how to improve the experience. The map can reveal how to transform a current lackluster experience into a much-improved future one. 

Journey maps can anticipate common issues that users encounter and that interfere with their goals. The maps plan how to reduce or overcome them and can locate where support is missing, time is wasted, or things get messed up. 

Customer journey maps show important dimensions relating to user interaction:

• Phases of a journey
• Sequencing of events and actions
• Various channels and touchpoints

For UX designers, journey maps help with planning services that are delivered across different channels. Many customer journeys involve switching channels, moving between websites, emails, smartphone apps, and other devices or screens. 

When users switch channels, it can often result in friction. Users can have difficulty picking up from where they left off when jumping from one channel to another. This issue provides a big opportunity for content to support the continuity in the user’s experience. 

While many journey maps are high-level overviews, they can also be detailed, focusing on specific phases of the user’s journey. And some customer journey maps can get specific about the content expectations of users, which is useful for planning the user’s interaction with content.

User flows

After developing scenarios or articulating the journey, UX designers will often create user flows to specify the number of screens, their order, and key elements they contain. 

For content developers, user flows help with planning many details. They can use the flows to:

• Clarify what information content types need to cover
• Identify calls to action at branching points
• Plan the pathways through content and how the content will be divided up
• Identify the entry and exit points into the topic or issue
• Identify the alternative paths and exception cases that users may have when performing a task
• Understand the user’s expectations and pre-existing knowledge (what they know already and what they might need to see next) when writing the content

Core Model

The Core Model method is sometimes used for content-centric projects. It lists different user tasks according to the topic area. Unlike some other methods, it assesses business objectives and how they overlap with user goals. It then identifies the core content about a topic that must be covered. 

The Core Model is most suitable for websites and other channels that offer routine functionality. While it can be helpful for making layout decisions, it won’t be as useful in guiding complex interaction designs. It, therefore, isn’t used for functionally-intensive apps. 

For content planners, the Core Model will answer:

• What do users need to know?
• What questions are they likely to have?
• What actions will they want to take after viewing content?
• How did users reach the content, and what have they seen previously?

For UX designers, the Core Model illuminates the pathways and navigation that users rely on when accessing the content:

1. Inward paths, via navigation, links, or search
2. Outward paths, such as related links or calls to action

User stories

Many projects rely on user stories to frame the user interaction of an app. 

User stories are closely associated with agile software development as a way to define requirements and track functionality that will be delivered. They are widely also used in product management. So, it’s not surprising that UX and content teams also plan their design work with user stories.

Like a journey map, a user story explores requirements from the customer’s perspective. Unlike journey maps, however, user stories are written in the first person. This individual is identified by their role or persona, which helps designers understand who will be using the feature.

User stories are specific without being overly specific. 

User stories break down broader processes into discrete steps that users will do. Each story focuses on a specific issue that must be solved for a particular kind of user. The story answers why the issue is important to the user.

Individual stories can be grouped. An epic is a group of related stories. All the stories associated with a design can be rolled up into a user story map that shows the relationships between them. 

User stories highlight what must happen to satisfy the user’s immediate objective, though they won’t specify how that will happen (that’s the role of the design). User stories can suggest the kind of front-end or back-end functionality that an application should offer. But they won’t dictate the specific screen-level interactions used in the design. 

For UX designers, user stories provide incremental targets for what to design.

User stories are equally useful for content planning. Even when the design of the UI is stable, user stories can be valuable to determine the kind of advice that must be presented within the UI. 

For content, user stories help:

• Define who the content is for, what they need to do, and why
• Break down high-level and lower-level questions users have relating to a broader goal
• Identify key entities of interest to users (the nouns in user stories) that will often become content types in the content model

An important benefit for both UX designers and content planners is how user stories identify different user segments and their objectives. By focusing on the role of the user and their objective, user stories can help UX designers and content developers decide whether it is possible to accommodate different objectives in a common way or if the design needs to provide additional variations or options.

Object-Oriented UX

Object-Oriented UX (OOUX) is a newer method to defining interaction requirements that’s gaining popularity.

Like user stories, OOUX breaks down the many details that need to be considered in a design. The key difference is while user stories are organized around specific user sub-objectives, OOUX focuses on the inter-relationships between different details. With OOUX, the focus is not on whether the design satisfies specific goals but how it can support many goals.

The major output of the OOUX approach is the ORCA diagram. ORCA is an acronym that refers to:

• Objects
• Relationships
• Calls to action
• Attributes

In OOUX, requirements are explored from the perspective of how users interact with “objects” representing the people, things, services, topics, or media that they are using, influencing, or reacting to. 

OOUX is useful to explore and decide what people need to know and do relating to a domain. OOUX can represent many details before developing a design solution, such as creating wireframes. 

For UX designers, ORCA diagrams can help them:

• Translate how to represent objects on screens and in design components
• Prioritize elements that will need to be presented
• Identify actions that users will expect to take

ORCA diagrams provide many details that will be required in the content model. Content planners can use the diagrams to:

• Identify content types associated with OOUX objects
• Prioritize informational elements within content types
• Decide how to structure content to support user actions

Task analysis

Some UX designers utilize task analysis to understand interaction needs. This approach identifies the tasks and subtasks that users want to do. It can help with understanding similarities in tasks and ranking higher-level and lower-level priorities.

Task analysis is similar to OOUX in that it breaks down complex details and interactions. Compared to OOUX, task analysis and modeling have a stronger emphasis on task interaction and less emphasis on content requirements.

Task analysis can be a good way to explore what users might want to do or should be able to do. It can provide a holistic overview, offering a multi-purpose rather than single-purpose perspective of user interaction. It’s especially useful for exploring complex situations. As one expert notes: “Not all users accomplish goals in the same way. For example, a novice user might perform more tasks than an expert user—the latter might skip certain steps.“

For UX designers, breaking down tasks helps with specifying:

• What sorts of interaction are needed
• In what order tasks should be presented 

This knowledge can help to shape the information architecture of a digital product or service.

 On the content side, task analysis will reveal requirements for:

• Content types supporting calls to actions
• Content elements such as instructions and labels relating to tasks
• System messaging such as status and error messages providing users feedback relating to their interactions

Use cases

Use cases are a long-established method of defining requirements, though they are used less often now than they were in the past. They can overlap with user stories in coverage, especially when the digital product or service does not involve lots of new functionality. Many projects find that user stories are adequate for their needs.

However, use cases can be helpful when the product or service needs to interact with back-end systems extensively. A use case will specify the actors, systems, the user’s goal for the interaction and will indicate preconditions (what the user and system have done already) and postconditions (the outcome). Use cases typically reflect business requirements rather than user requirements. They will often be developed by someone outside of the design team, such as a business analyst. 

For UX, use cases reveal:

• How the user interface will connect to and integrate with back-end systems
• Points where the system needs to indicate the status of an interactive sequence, which will influence choices around design components to use
• Different states of activity, such as incomplete, error, or success

For content, use cases provide an understanding of:

• The triggers that prompt the interaction, such as whether it was initiated by the user of the system
• What the user already knows about the situation
• The kinds of messages the system will need to provide
• The kinds of instructions required
• Alternative flows that must be accommodated

The benefits of unified requirements

UX designers and content planners use many of the same methods to understand user needs. These methods provide insights into what users want to do, which will suggest the kinds of interactions a product or service needs to support. But they don’t specify how the interactions are designed, which will be done during wireframing or prototyping. 

But user requirements are not limited to what people want to do. It also involves being clear on what people need to understand. A unified set of user requirements will illuminate both aspects: what users want to do and what they need to know. 

By drawing upon a unified set of user requirements, UX and content teams gain a common understanding of what they need to create. While their specific concerns are not always identical, they overlap considerably. Both sides can collaborate productively around a common vision for what the design will deliver.