What “Content” Means to Different Teams

What “Content” Means to Different Teams
brandt
Mon, 01/22/2018 - 16:21
Ken Rickard
Jan 23, 2018

The importance of aligning editorial, marketing, design, and development.

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

As we’ve discussed before, understanding the content on your website is a critical element in the project plan. Today, we’d like to step back a bit and talk about how different teams in an organization might think about content.

First, let’s define our common teams by function:

  • The Editorial team produces and maintains content for the site.
  • The Marketing team sets strategy and metrics around successful audience engagement and interactions.
  • The UX Design team creates the strategy, visual and interactive components that comprise the site’s features.
  • The Development team builds and supports the site so that it fulfills the needs defined by the other three teams.

Note that these teams may all be organized within a single department (commonly marketing) or spread across the organization. Our concern here is not with organizational structure but rather with the perspective and concerns that are inherent in each team.

When teams start work on a new site or a site redesign, the most common mistake is for these four teams to work in silos, as if their individual tasks are unrelated to each other. In this case, a number of issues may arise:

  • A design may include elements that place extra burden on the editorial team.
  • An editorial workflow may require the development of custom code.
  • A marketing plan may ignore the limited editorial and design resources available to achieve its goals.
  • Organizations that have a history of heavily relying on non-digital media for marketing and promotions may have to figure out how to incorporate and plan for the digital work into the existing workflow.
  • A CMS implementation may not be able to produce certain essential design features, or budget and timeline prevents features from being designed a certain way.

Working together, teams can work through these types of issues before they become problems. To do so, it’s vital to get everyone speaking the same language around your content. We like to look at five specific factors when helping teams define their content strategy:

  • Audience defines the users and their needs and answers “who is this for?”
  • Purpose asks the question “what end result are we hoping to achieve?”
  • Workflow deals with the mechanics of content production, approval, publication, and presentation.
  • Transformation explores issues of translation and personalization, so that we define how the content might be modified in distinct contexts.
  • Structure defines the input and storage of the content and how it will be delivered to various publication media. The structure is directly affected by the needs outlined by the three previous items.

Each of these elements has a direct effect on each of our project teams. To understand how, Let’s take a look at Dr. Gillinov’s bio page at Cleveland Clinic to see how these questions bring focus to our project goals.

 

There are many elements that make up this comprehensive profile page and they all require each team member mentioned above to consider the following:

  1. Where does the data/content come from?
  2. What pieces of data/content is the editor responsible for?
  3. What does this page look like if it has all of the possible content types vs. physicians who have very little information?

For the purposes of this discussion, however, let’s focus on the top portion of the page addressing the data/content that makes up Dr. Gillinov’s basic information as it will help us illustrate our points.The first thing we look for here is the number of elements within the design pattern and how they might be produced. At first count, there are 11:

Let’s see how those elements break down.

  1. Picture – an uploaded image of the person.
  2. Video Link – a link to an external video service
  3. Rating – 1-5 stars based on patient feedback
  4. Rating Count – the number of patient ratings
  5. Comment Count – the number of patient comments
  6. Name – the name and honorifics for this person
  7. Department – the assigned internal department
  8. Primary Location – the main office location for this person
  9. Type of Doctor – indicates pediatrician, adult physician, or both
  10. Languages – a list of languages spoken
  11. Surgeon – indicates that this person is a licensed surgeon

Audience

There are multiple types of users that would view this page: potential patients, existing patients, families of patients, and medical professionals. Their needs are different based on who they are and where they are in their care journey.

Purpose

The primary purpose of this specific component is to provide basic information to the audience. The information presented helps them understand the services and availability of this doctor. The use of a picture and a video are designed to build trust by establishing a human connection in addition to the facts presented.

The inclusion of patient ratings serves as an impartial arbiter of the quality of services provided, while the department and location information helps people understand where they can go to receive treatment.

Workflow

For this example, the important question is “Which part of this page is editorial and which part is automated?” Here, the ratings pull in from a secondary system, which the editors do not control. The video is merely a link reference, but is editorial data. And while some of the doctor information might be pulled from an external system, here we assume that it can be edited for display on the web.

There is also an unlisted assumption here – call it feature #12 – about whether or not this doctor has active privileges at the hospital. Our editorial workflow needs to account for when an individual physician changes jobs, retires, or moves away.

Transformations

We use the term “transformations” here as a bit of a catch-all to describe how the data might need to change in different contexts. A common context shift is language.

When considering a multilingual website, we need to evaluate each element of the page for the desirability and feasibility of its translation.

Take the Video field for instance: Translating the link text for a video is trivial, but does the video itself need to be recorded in multiple languages (or at least subtitled)? Does it make sense to show a Spanish translation of the video link if the video is only in English?

The other most common transformation is personalization, wherein content elements are transformed based on our understanding of who the reader is and what they care about.

The key factor to consider about personalization is that it can create exponentially more work for the editorial team. Consider that for each element that desires personalization, we must create one new version for each variation. Let’s say that we want to segment our audience experience by three data points:

  • Returning patient (yes / no)
  • Local resident (yes / no)
  • Age cohort (child / adult / senior)

Now our one piece of content needs 2 x 2 x 3 = 12 variants, plus the original. For clarity, here’s how that looks mapped out: 

If we add in cases where one of the answers is not known, then the math becomes 3 x 3 x 4 = 36 plus the original variant.

As you can imagine, keeping track of those options can become a heavy editorial burden quite quickly if we were to personalize multiple elements on a page.

Structure

The above questions help inform how this page is structured on the back end. Additionally, we have to consider:

  • What fields do we need to capture and report this data?
  • What format should the data be displayed in?
  • What services (other than the website) might consume this data?
  • In what other contexts might this data be shown?

This last question gives an easy example of the type of decision that your programmers may need to make. To fully understand, let’s look for a minute at the contexts of a search result.

Here, the results are alphabetized by the physician’s last name. If we were to enter the physician’s name as it appears in English, “A. Mark Gillinov, MD”, a computer cannot natively sort by last name. We should also consider whether the honorific “MD” should influence sort order, and whether to sort by first and last name in the case of multiple matches to a common surname.

That generally leads to a separation of the sort field into a 14th field concept: Sort name. In our example the sort name is likely to be “Gillinov Mark A.” The remaining question is whether editors should provide that detail or if it should be automatically inferred by a custom element in the CMS.

Additionally, look at the elements that contain links:

  • Video
  • Ratings
  • Department
  • Primary Location

The target of these links needs to be captured, and the logic for that link generation accounted for in the CMS architecture. Further, can these elements be automatically derived from existing data (like the doctor’s name) or are they “hidden” metadata points that need to be added?

In most cases, the mapping for these elements is based on metadata:

  • Video – requires a unique URL for a YouTube video.
  • Ratings – requires a physician ID number provided by the ratings service.
  • Department –  selected from a list of Department pages controlled by the CMS.
  • Primary Location – selected from a list of Location pages controlled by the CMS and containing mapping metadata.

And to add one more element to the structure question: Which of these page elements allow for multiple selection? Can a doctor be part of two departments? Have three primary locations?

Making the Complex Simple

These kinds of workflow complexities in your data are absolutely essential to capture as early in the design process as possible. What if we find that “Languages spoken” is very important to patients, but not currently available in our information set? That requires additional editorial work – and likely a staff-wide survey – that could take weeks to complete simply due to the coordination involved. It is also worth mentioning the impact on initial design choices as well. For example, do we need to consider fonts that have text alternates for language glyphs? Does the design still hold up (spacing, line length, relationship to imagery etc) when there is twice as much French text as English?

Since we’re working directly with Marketing to define our audience and purpose of each page, we should understand how each element of the design improves the overall user experience. That knowledge allows the entire team to make informed decisions about the level of effort to produce and maintain each content element.

All members of the team should have a familiarity and respect for the concerns of other members of the team. When developing and planning content, it is imperative to involve all four teams as early in the process as possible. To bring your content into focus, always ask the following questions about any design or content element shown in a wireframe or mockup:

  • What content or data will be needed to produce this element?
  • Does this content or data already exist in a usable format?
  • What format will this data be entered and stored in?
  • Will this element be editorially curated or automatically produced?
    • If automated, do we have business logic to support that automation?
    • If curated, do we have the staff time to support that creation and maintenance?

Building a robust content model and workflow is a team effort. The functionality of the CMS and the designs they are capable of producing is what brings the Editorial, Marketing, Digital and IT teams together. Giving them the visibility into each other's work streams allows them to collaborate. This collaboration also gives the various team members collective ownership over the content experiences within their organizations.

We want to make your project a success.

Let's Chat.

Original Article: