Previously, we looked at the benefits of content and design collaboration for specific activities such as planning experiences and defining interactions.

Now, let’s look at collaboration more broadly. How can the people who produce words collaborate better with those who create screen designs?

The relationship of content to design remains a source of confusion for many people. Is one the child of the other, being dependent on its parent and having fewer responsibilities? Or are they siblings (and perhaps sibling rivals)?

For some designers, the content is one detail among many within the design. For some writers, the design is largely the visual styling of messages and narratives. Most recently, some organizations are using the term “content design,” though it is not always apparent how that concept is different from UX design since both terms refer to a user-centered design approach. 

In a digitally mature organization, content and design work should be a partnership. Project teams should recognize what each role contributes. They need to master the art of collaboration, which can be a challenge when team members and project stakeholders have different perspectives and priorities.

Teams need to balance two objectives:

1. Get the highest quality ideas and most relevant feedback for each task
2. Make sure that all contributions are gathered efficiently so that the project progresses

Collaboration begins with mutual appreciation. Content and design require specialized skill sets, ranging from linguistic expertise to visualization. Content editors can simplify information, and UX designers can simplify tasks. Content and design teams ought to value the competencies and perspectives that each role brings to a project. 

The design frames the content

A design without content is an empty shell. And content without a design is a wall of text. Neither is fully legible. Content and design need each other. 

The design influences how users understand the content in two ways.

First, it supplies the context for the content by connecting it to other content. These relationships influence what else the user sees. It does this by determining:

• The content item’s adjacency to other items
• How users discover the content via inbound and outbound pathways

Second, it provides the containers in which the content appears. The presentation prioritizes what information is shown through choices relating to:

• The space available for messages
• The visual hierarchy of communication elements

The design shouldn’t be “content agnostic”

A design is unfinished if it expects that the content will, later on, conform to it. Take a closer look at any design solution that offers general-purpose boxes that allow you to put any kind of content you want into them—that solution probably isn’t going to deliver an ideal user experience. Instead, it indicates that the substantive topics that the design should be supporting weren’t considered thoroughly.

Design elements must be in harmony with content elements. The intention of a design element needs to match the intention of the associated content elements. When planning systems to support the design and content, it’s important to align them.

Design components will need to be associated with their corresponding content types. For example, designers may create various components to present notifications, such as a banner, a toast, or a modal. These different components will alter the behavior of the notification: whether it is persistent or will disappear, and whether the user must react to them. But the choice of which component to use for a notification isn’t possible without knowing what sort of message will appear within them. Is the notification:

• Providing a warning?
• Signaling an error?
• Presenting an update? 

Even a warning can involve different levels of severity. Should different kinds of warnings be presented in different notification components? Content and design teams should discuss these issues and agree on how to coordinate them. 

The content strategy team at Mozilla embraced such collaboration when deciding how to develop message types: “We partnered with our UX and visual designers to redesign those message types using a content-first approach. By approaching the redesign this way, we better ensured the resulting components supported the message needs. Along the way, we were able to make some improvements to the existing copy and establish guidelines so future modals, infobars, and panels would be higher quality.”

Should the content lead or follow the design? 

Content and design are complementary perspectives. But which one is in charge? Within project teams, questions may arise about who has decision making authority:

• Do opinions about content and design decisions have equal weight? 
• Will UX researchers tell writers what to write? 
• Can editors tell designers how to layout the UI?

But attempting to micromanage the formal responsibilities of different roles can work against the goals of collaboration. A swim lane division of labor works fine for routine processes, but it can stifle innovative problem-solving. Delivering user experiences involves complex decisions and tradeoffs. Anyone on the team may have valuable suggestions to offer. Instead of worrying about the relative importance of content and design, teams should ask: How can collaboration be fostered? How can content and design resources contribute to the best user experience? Users care about both the substance of the content and how they will experience it.

The collaboration between content roles (planners, editors, writers) and UX roles (researchers, architects, analysts, visual and front-end designers) will be ongoing. Both teams should take their direction from how users want to solve their problems. 

The nature of the user’s problem will shift according to the stage of their journey. At some points, they focus on understanding options, and at other stages, they focus on completing specific tasks. This shift in focus will shape the emphasis of content and design elements within the product or platform.

When the product or channel is primarily focused on communication, especially when users will be spending most of their time reading, viewing, or listening to content, a content-first approach is desirable. For many informational websites discussing how to do something or make a big decision, the user’s main task is to understand a topic. The design needs to enhance the user’s ability to access and understand the content.

When the product is focused on supporting transactional scenarios, such as customer self-service, then it should be led by user and business requirements that specify:

1. The options being offered
2. The tasks users can do

Early design concepts will often help clarify and validate these requirements. Content will help users understand these options and enable them to accomplish their goals. Teams can prototype the experience with realistic content. 

Digital products rely on a mix of—code, copy, and design—that define the interaction, content, and layout. All are important, and any one of them might require adjustments. 

In the past, some designers and developers presumed that the content would adapt to the design and the code supporting it. Their assumption was that content can change easily, but a design is hard to change—that the words are cheap, but the design is expensive.

This attitude is becoming less common now. Pixels and bytes are increasingly easy to change, whether it’s adjusting the screen styling, swapping the front-end libraries and back-end microservices, or iterating the words and images.

Just as the text must support the design, it’s equally true that the design needs to support the message. Words, no matter how well crafted, can’t fix a design that fails to support the user’s goals effectively. 

Design and content both must satisfy diverse stakeholder priorities

In addition to having clarity on how the teams cooperate internally, it’s necessary to plan how they will work with external stakeholders. At certain checkpoints, external stakeholders will need to review and approve work, which can influence outcomes. 

Content and design teams can encounter similar issues when working with stakeholders. Both need to advocate for user interests when stakeholders prioritize business considerations. And both are trying to solve global issues that recur and make sure that these issues are handled consistently. But stakeholders may focus on isolated surface issues, such as specific phrasing or the colors on a screen.

While the teams ideally understand the mutual influence of design and content, the stakeholders reviewing the work may not prioritize them the same. Individual stakeholders may be more interested in either the content or the design. 

Stakeholders have specific responsibilities and will provide detailed feedback on those aspects that affect their goals and priorities. When arranging reviews, pay attention to what aspects the stakeholder cares about. Subject matter experts or legal and compliance staff may care primarily about the accuracy of the words. Marketing may be concerned with brand image. Product managers may prioritize how a new feature works. Customer support teams may channel their worries concerning customer hesitation toward the new design. Sales may be concerned with the release date and whether reviews or changes might cause delays. 

Working together to facilitate feedback

The stakeholder review process can sometimes be more flexible when implementing a project using a headless CMS, which decouples the design from the content. The details of the content and the design can be worked on independently in many situations. If the design or the content requires frequent or extensive feedback from a given stakeholder, it may be most efficient to show only the aspect the stakeholder is interested in. But first, make sure no important information gets lost:

• Can content-focused stakeholders understand how the messages will be used without seeing the design? 
• Can design-focused stakeholders understand how users will make use of the design without showing realistic content? 

If either of those situations isn’t true, then you’ll want to present a preview of the design with representative content to stakeholders. 

Secondly, make sure that the structural relationships between the content and design are stable before asking for open-ended feedback from stakeholders. A streamlined review will only work if no requested changes to one aspect (for example, the content) will fundamentally alter the other aspect (the design). 

If stakeholders have lots of feedback concerning the content or the design, this feedback can create bottlenecks in the project’s delivery. Engage with stakeholders early in the process to avoid a surprise about learning their concerns later on. 

Stakeholder engagement is an important process that content and design teams should coordinate. They should collaborate when planning communications to stakeholders and when getting feedback from them about the features, messages, and presentation.