Chapter 8 Implementing Connected Content

Bring the models to life! Just as with the rest of the process, building a content-first and model-based system requires a different mindset for your team. No handoff to the engineer. No big reveal from the designer. You’re in this together, connected, just like your content.

From Theory to Reality

Theory is done now. You’ve created your content strategy and determined what content needs to be made. It’s time to get to work implementing a publishing system. Models are used to build the systems they were designed to represent. In this case, it’s an information technology system that enforces the rules you’ve set for the collection, organization, and storage of content.

It’s not enough to hand off the models with some notes about how you plan to create the content. As the person responsible, you need to continue to shepherd the content through implementation and visual design.

The evolution continues. From domain model to content model to defining specifications for the tool that will manage and publish your content—your content management system. What was a model of content types and attributes becomes a spreadsheet with details of not only each content type and its attributes, but also each kind of attribute: things like numbers, text, files, and images. Together with your engineers, you’ll determine how best to set up the CMS to do whatever you want with the content chunks.

As you go from model to system specification, content types may transform to conform to the reality of your situation. Attributes may change as you think about representations and how the content will be used by visitors and entered by authors. That doesn’t mean you did anything wrong before. You’ve only gotten more specific. You and your team continue to make decisions together. On with the show!

Content Management and the CMS

Every day, millions of people create content. But not everyone who creates content manages it. And not everyone who manages it does it well. Content management is a discipline, as Deane Barker says in his book Web Content Management (O’Reilly). To manage content is to apply a set of theories, best practices, and accepted patterns. And it sure helps to have technology to help you do that.

As we explained in Chapter 3, structure underpins the implementation of your content-first process. You need a system to manage all those chunks. If you publish digital content, a CMS is the tool that lets you do that. Or maybe a product information management system is your tool. Or even a cobbled-together system of spreadsheets and data transfers. There is a wide range of choices to help manage the content that will be created based on your models.

Types of Content Management Tools

Not all content management tools are created equal. Whenever someone asks, “What CMS should I use?” or “What is the best CMS?” the answer is always, always, “It depends.” Many tools can help you put your content on the web. What’s best depends not only on your budget but also on how you want to manage your content and the skills your team has to build and maintain the system.

Web Publishing Systems

Want to get a website going without being a designer or understanding code? A web publishing system might be for you. The hallmark of this type of tool is that it allows you to create a bunch of web pages. With the magic of templates and widgets, you can pull together a great-looking website with content chunks and design elements dragged and dropped where you want them to end up. You might find a few elements of structured content that allow content reuse across the site, but mostly these tools create single-use web pages. Tools such as SquareSpace, Wix, and Weebly are perfectly fine solutions for some situations. But a web publishing system won’t give you the structural flexibility for a structured-content, domain-driven approach.

Web Content Management Systems

To implement your content model effectively, you need a system that stores your content in a database, ready to reuse anywhere. Most of today’s CMSs use a relational database to store structured content.

Here’s the thing about our favorite CMSs: They pretty much start with nothing. A blank canvas. You get to make it all up! That seems daunting for someone who hasn’t done a content model. But not you! You are ready for an approach to content management that allows you to manage content at the resource level, not at the page level. The goal is to create a set of resources with attributes that get pulled into different representations.

So there’s no “best” or “right” one. But we do know that these qualities make for a solid CMS:

• Entity-based

• Customizable content types

• Separate design layer

• Third-party system integration capability

• Customizable user roles and permissions

Let’s look a little more closely at the CMS qualities that support our approach.

Entity-based systems are those that allow you to create resources, as represented by your model. You set up each resource in the CMS and populate it with instance data. To create the display, just specify attributes from the content type to display in a template representation. Add a design layer to position and style each attribute. Design and content are completely separate here; you can even enter content before the design is finished.

In this type of system, the resources themselves don’t change with the representation. That means you have more freedom in how to display or deliver your content. However many ways you want to represent something, you are choosing from the same set of elements.

This is the opposite of page-based systems that force you to create a hierarchical outline of your site (like in Figure 8.1, which shows how that is different from entity-based systems) and then create the pages one at a time. Resources can’t be reused, because they’re assigned to a specific spot in that outline. Admittedly, many page-based systems allow you to create structure within the page by chunking things into various segments. But they still put the representation first—you make a web page with a single objective. Instead of entities and content types, you lay out a web page. To create new content, you add a page to the directory and select a display template. Aggregating content requires an engineer to do programming rather than making some simple choices in the configuration settings.

Having a blank canvas for free-form, or customizable, content types is ideal. Because you’ve already mapped out how you want to set these up, you don’t want to fuss with hacking what’s already there. Hang on for how to set up your content types!

Figure 8.1 A tree structure for setting up the CMS (top) and an entity list (bottom).

To bring the content to the screen, a good CMS brings the interface design layouts and content together on-demand. Thus, it has a separate design layer, independent of the content. The design layer is the set of instructions for what the interface will look like. But there’s no need to think about what it will look like yet, or even about what size screen or device will deliver the content, until you’re ready to create a specific interface.

It is likely you have other systems you want to connect to, so third-party system integration capability is a must. Customer relationship management (CRM) tools, ecommerce software, customer service chat tools, and more form your digital ecosystem. Send data to and from the CMS so you don’t have to duplicate it or manually update systems that share common data. For example, if all your product information is stored in your ecommerce software, create a data connection with the CMS to get the right information published to the website. When a new product is added or a price changes, the content author doesn’t have to keep everything in sync. The system integration means that updates are sent to the CMS automagically.

A CMS should also allow you to customize user roles and permissions to access it. Maybe you want only the public relations manager to create the Press Release content type. Or you want the conference managers to be able to update the events calendar. Likely you have author, editor, and publisher roles, or other terms that define which users can publish content and which can only add or edit content. Each organization is different. The CMS should conform to your business and workflow rules, not the other way around.

The Headless CMs

The design layer could be so separate that you could skip it in your CMS ­altogether. A headless CMS is one without an embedded design layer. It’s the pinnacle of separation of content and design! The CMS stores and delivers content to any interface application. The design—the front end, or head—gets applied at the point of display to the user through a separate system or code-base that pulls the content from the CMS into the representation.

Consider a headless CMS if you are truly ready to create a single resource per thing, want to manage that content in a single place, and want to publish across platforms. If you’ve come this far in the process, this is a viable option.

Some have said that the website is dying. But to paraphrase Mark Twain, reports of its death are greatly exaggerated. Still, there are many other ways of delivering content and only more to come. So if a CMS is strictly a web CMS, you’ll miss a big opportunity. Ideally, the system will manage your content across all your platforms: websites and blogs, learning management systems, conference management systems, native apps, product information systems, and more. We like where this evolution is going.

Build Your Own CMS

What if none of the commercial systems fits your need? Some really advanced and digitally mature organizations have built their own CMS. National Public Radio (NPR) did this around 2012, when they established their “create once, publish everywhere” (COPE) process. No existing CMS fit NPR’s operational or resource-based content model. Although there are a lot more options now, sometimes your needs are so specific that building your own system is the best bet.

For this to be a viable option, be prepared to build the CMS that fits your needs exactly. A true proprietary CMS is not one you buy. If you buy a system that’s already created, it’s no longer just yours. If you do build your own CMS, be sure you aren’t tied to a single vendor to maintain your content or the system that manages it. It’s best to have the skills on your team to build and maintain the system. Creating the in-house engineering expertise ensures you will be able to continue to enhance the CMS as your business and content evolve.

Whatever system you use, think about how to manage your content before worrying about how the web pages will look. There is a time for that, but first you need to get the content management right. All CMSs come with their own quirks, to be sure. But you want to build your tool to fit the model, not model your content to fit the tool.

Content Types—The Technical Side

The content model contains content types. The CMS also contains content types. In the CMS they are the actual container for your content. They may be called something else in your CMS—entry types, data-entry forms, templates. Whatever you call them, they’re the building blocks of your system. We’ll keep on referring to these generic content containers as content types.

To start planning your technology implementation, go back to your model and decide which content types and attributes need to be exposed. What once were abstract domain objects, then further defined as content types, now become fields in a CMS. Relationships between the content types are expressed by connecting certain fields. The model provides the answers to how those relationships work, and it’s a blueprint for all the kinds of content you might want to surface. A Session is hosted by a Person with the Role of Host. A Sponsor can sponsor an Event or a Session. A Person is the Author of a Blog Post. And so on.

We’ve finally come to the part when a spreadsheet makes sense. You’re defining engineering specifications. Your engineering partners can build what you specify, but first they must understand the specifications you give them. Work with them. Be the advocate for content and the people who manage it.

Author Support

For the sake of simplicity, we’ll use authors to mean the people who create and enter content into a CMS. These people may fill many roles, but what matters is their role in using the CMS. They are its users. Consider how they use this tool, whether it’s every day or once a year.

The usability of the CMS is every bit as important as the technical attributes. You want flexibility in making the user interface, one the authors can actually use and that supports their content management efforts. Think of it as “­training the CMS,” as Eileen Webb says (https://alistapart.com/article/training-the-cms). There’s a lot to remember, so rather than issuing a manual, build the guidelines and governance into the CMS itself.

Authors are not necessarily familiar with breaking up content into chunks for reuse. They may complain that they used to have more flexibility when there was just one big WYSIWYG editor for them to use. But structured content provides many benefits that are not obvious at first glance. Show them how putting these rules in place helps maintain consistency, makes it easier for them to enter content, and allows their content to be reused in various ways. All of this helps them to drive business success.

All the principles of user-centered design apply just as must to the back end of your CMS. Authors are your users too.

Content Types in the System

Use a spreadsheet to document the technical specifications for building content types. Our typical spreadsheet contains the following columns for specifications, but modify these to suit your needs.

• Content Type Name

• Description (what is this content type used for)

• Field Label (what each entry field is called)

• Data Type (technical term for the type of field this is)

• Notes

Fields

Each content type is a form in which each attribute becomes a form field. Each field has three components:

• Label: What the author sees as the name of the form field

• Data Type: Defines the kind of information that can be entered into a field

• Value: The actual information entered into a field

Think of this as form design. Forms are the interface layer between a user and a database. Borrow principles of information design and hierarchy, interaction design, and stakeholder management to make the content types easy to use and intuitive.

Back to the IA Summit. When the time came for us to plan the Session content type for our CMS, we started with our list of attributes:

• Session Title

• Person

• Description

• Takeaways

• Session Type

• Topic

• Time/Date

• Duration

• Venue

• Room

• Cost

• Sponsor

This was a good start. But as we planned the representation of each Session instance, we found we needed a few more things. See Table 8.1 for why we made changes when setting up the CMS. Figure 8.2 shows how it ended up coming out in the CMS.

Table 8.1 Differences in Content Types from Content Model to CMS

Model Attribute	CMS field Label	Reason for Difference
Session Title	Session Title	n/a
Person	Presented By	This label made more sense.
Description	Session Description	To be specific about what was being described.
Takeaways	Session Takeaways	To be specific about what takeaways were to be listed.
Session Type	Session Type	n/a
Topic	Session Track	We didn’t have well-defined topics, just a loose collection of sessions that had similar themes or formats.
Time/Date	Session Date (start)	To provide a start and end time specifically, these needed to be divided up (date field types include time).
	Session Date (end)
Duration	Workshop Length	Duration was automatically calculated with start and end date and time, but we wanted to state whether a workshop was full- or half-day.
Venue	Location	We combined these into a single field because all but a few sessions are in the same venue.
Room	Location
Cost	Cost	n/a
	Sold Out	We needed a way to let people know when a workshop was full.
Sponsor	Session Sponsor	To be specific that this was for the session.
	Main Event	To link it to a particular instance of a conference.
	Comment	The co-chairs also wanted to say why a session was valuable or give some sort of commentary.

Technical Attributes (Data Types)

Your content management system is a database. That means you also have to define data types (Table 8.2), or what kind of field each of these attributes needs to be, and assign one to each attribute. The good news is that there aren’t many of them. There might be some variance from system to system, but keep this list handy to endear you to your engineering team.

Use these field types when defining attributes for content types in your CMS or information system’s database.

Table 8.2 Data Types for CMS Field Specifications

Data Type	Description
Boolean	One of two values Examples: Yes/No, True/False
Date	An entry as an ISO date or Unix timestamp; includes date and time
Email	Email address; turns addresses into mailto links
Entity reference	To select instances of another content type
File	Reference to a file in the file system of the CMS Examples: PDF, Excel worksheet, Word document
Image	Reference to an image file
Link	For storing and validating URLs
List (text)	List of text options (can be formatted as either a drop-down list or checkboxes)
List (float)	Drop-down list of floating decimals
List (integer)	Drop-down list of integers
Number (Integer)	A whole number, such as a year (example: 2012) or value (­examples: 1, 2, 5, 305); does not allow decimals
Number (Float)	A number that can use decimals Examples: 0.012, 138.7, 200.87
Number (Decimal)	A number that allows exact decimal values; often used for price Example: $199.99
Term reference	Reference to an existing taxonomy term
Text (plain)	Short text (limited to 255 characters) Examples: Name, Title, Company
Text (plain, long)	Long, multiline alphanumeric text (no HTML tags allowed)
Text (formatted)	Text field with rich text editor (basic HTML tags allowed)
Text (formatted, long with summary)	Same as formatted text, but with an additional summary text field

From the IA Summit content model, the technical specifications for the ­Session content type looked like Table 8.3.

Repeat this process for each content type. Just as when you went from domain model to content model and split up and merged objects, you may do the same at this point with content types and attributes.

There’s no rule about the minimum or maximum number of fields to use or how many content types you should have in your system. Be like Goldilocks: Have just enough fields so that it is intuitive for an author to use when entering content and for the content to translate to the display properly.

Table 8.3 Data Types for CMS Field Specifications

Name	Description	Field Label	Fields/Types
Session	Holds information related to individual sessions (workshops, socials, keynotes, etc.)	Session Name	Text (plain)
		Description	Text (formatted)
		Presented By	Entity reference (Person)
		Session Type	Term reference (Session Type)
		Workshop Length	Term reference (Workshop Length)
		Cost	Number (decimal)
		Sold Out	Boolean (Yes/No)
		Session Date (start)	Date
		Session Date (end)	Date
		Location	Text (plain)
		Main Event	Entity reference (Event)
		Session Track	Term reference (Session Track)
		Takeaways	Text (formatted)
		Comment	Text (formatted)
		Session Sponsor	Entity reference (Sponsor)

Relationships

You may have noticed the entity reference data type in Table 8.3 and that it was used many times in the Session content type definition. And you might be scratching your head over this one. Let’s back up and explain. An entity is a thing or concept that is unique, distinguishable, and self-contained. A ­reference is something that points to another thing. An entity reference is the center of the content relationships. When you use an entity reference (or whatever your system calls this type of field), you are saying to the database, “I want to connect this instance of the thing I’m creating to that instance of another type of thing.” In this case, when creating the Session instance for A Tale of Twin Cities we selected Karl Fast and Kristina Halvorson from the Person content type in the Presented By field. Now the computer knows that these things are related and can make all kinds of inferences from them.

That’s nice for the computer, but it’s also nice for you. It means you can create less content. Instead of entering the Host’s information with the Session, you’ve already entered it as a Person and all you need to do is select the right name from a list. In the display of a Session, you can pull in any attributes about the Host that you want. Likewise, you also can pull in attributes from the Session to the Person’s biography page, which is exactly what we did
on the IA Summit website (Figures 8.3 and 8.4).

Guess what else? Change the name of the session, and it gets changed in every relationship. If a person gives you a new photo, it gets uploaded once and displayed wherever that person’s photo appears in the interface.

In the longer term, this relationship building has even more benefits. For the IA Summit, it might be tempting to think only of a single year’s event. But as we’ve pointed out, the same people hold different roles from year to year. This year’s co-chair could be last year’s workshop speaker and next year’s keynote speaker. With the Person content type, the information about the person stays the same no matter what the year and the role. A new relationship with the new instance of an Event and a Role can be created without re-entering personal information. Just go to the Person entry and choose the new Role once they sign the keynote speaker contract.

Having these relationships means you must think about which way they flow. In the Live Music domain, does a Performer belong to a Lineup or does a Lineup have Performers? Since the Performer always has the same values no matter which Lineup they belong to, it would make sense to have Performer as an entity reference in the Lineup content type (Table 8.4).

Performer has no entity references in its attributes, at least not in the Live Music domain. That content type only describes the Performer. A Performer can have many relationships through the Lineup reference for reuse in various representations (Table 8.5).

Table 8.4 CMS Specifications for Lineup

Name	Description	Field Label	Fields/Types
Lineup	Brings together individual performers for a specific combination	Lineup ID	Number (Integer)
Group	The collective group or band represented by this lineup	Group	Entity reference (Group)
		Performers	Entity reference (­Performer)—allow multiple

Table 8.5 CMS Specifications for Performer

Name	Description	Field label	Fields/Types
Performer	Individual who puts on shows	Full Name	Text (plain)
		First Name	Text (plain)
		Last Name	Text (plain)
		Birthdate	Date
		Birthplace	Text (plain)
		Birth Name	Text (plain)
		Biography	Text (formatted)
		Genre	Term reference (Genre)
		Photo	Image
		Website	Link

Taxonomy—A Quick Note

We’d be doing structured content a disservice if we left out taxonomy. Officially, a taxonomy is a classification of information into ordered categories. When it comes to digital content, taxonomies allow you to organize, categorize, and relate content. Apply them to various content types and you can hook them up by matching terms. The Person content type in which the Role is Keynote Speaker. Performance with the Genre of Indie Rock. Vehicle with the Style of Coupe. Some of the content types from the model are really taxonomies that allow you to classify other content types.

A content type can be classified in many ways. A Recipe has ingredients, a type of food, a preparation style, a season, and preparation ease. And you could assign any or all of those a value for a chocolate chip pumpkin muffin recipe and find it in many places, depending on how you wanted to discover it: pumpkin, breads, baking, autumn, and easy. This is the beauty of digital classification: You don’t have to decide on just one categorization, like you do with paper (Carrie keeps it in the Breads category of her recipe binder).

A taxonomy shows intent. You define the terms in a taxonomy based on how you want to position your content in your domain, or even in the wider world. For the giant panda, the location could be China, Asia, or Yangtze. Just be sure you pick the level to classify all the instances of Animal the same way: country, continent, or region. Do you classify it as a bear (Ursinade), or do you put it in the same genus as the raccoon (Procyon)? Classification opens up debate, and with each decision you take a side. Be deliberate.

Whether people want to search or browse, a solid taxonomy improves findability and discoverability by allowing them to choose their own path. Most internal search engines allow for faceted narrowing by any number of things, from content type (book, journal article, blog post) to publication year to topic and beyond. Visitors who don’t know exactly what they want can narrow the selection by choosing which facets to apply to their search.

Since you’ve created your navigation structure based on resources and your content model, it’s easy enough for someone to start at the top of one of the categories and make choices all the way down when they want to explore by browsing. What to do with all that July corn on the cob from the farmers ­market? Start at seasonal foods, click on summer, easy, and main dish. Bam! Basic corn chowder for dinner! Or just as easily, choose side dishes instead. Bam! Creamed corn. Hungry yet?

The benefits of taxonomy and using it to bring your model to life go on. But that is for you to discover when you create your interface. When you’re building your CMS, decide how to classify the content and make sure the terms will be easily understood by authors when selecting appropriate terms during content entry.

Taxonomies may manifest themselves in many ways, including metadata. Metadata is machine-readable information that describes a thing. It is descriptive and structural syntax for your fields. Some metadata is standardized for interoperability. Schema.org and Dublin Core are two of the most common metadata vocabulary sets. The good news about this is that your CMS may have this built into its core code and will do the work for you if you choose the right data types. For example, choosing the Date data type automatically applies the worldwide ISO standard that allows any computer to understand the values in this field as a date and time.

Taxonomies are woven into the fabric of your content. They can be as simple as select lists or checkboxes. Or they can be complex sets of terms that guide an entire domain. They can be hierarchical or flat. Whatever they are for your content, take full advantage of them.

Content Creation

The skeleton of your content is ready to be filled in. At last, you can start creating the content. And it’s important to start doing that as soon as possible. You’ll want to use sample content and start to enter it early to make sure it’s all doable—that the authors understand this new way of creating content and that the system is indeed set up to accept and display it in a way that makes sense for the user.

Structured Authoring

You probably get that writing big blobs is not the way to fill out your content model. What was once a blob becomes chunks, which means that the people who write the content need to approach their writing differently. First, get the authors thinking about how these pieces fit into the bigger picture. If they are used to writing web pages, you’ll need to coach them about techniques that we covered in Chapter 7 about designing content, not just writing it.

To help authors wrap their head around this structure, provide a guide for them. We call these content spec sheets. They specify the nature and structure of the content to be created. You can use a Microsoft Word document with a table that mirrors your structure (Figure 8.5). Include governance notes in them.

If you have a big team and lots of content, use a content production tool like GatherContent to organize, produce, and manage the production process. A pre-CMS tool like this can also export directly to some of the more popular CMSs.

Content Entry

Start entering content into your system as soon as possible. You’ll want to do this to make sure everything is working as planned. Start with a set of sample content. Decide how many instances of each content type you need to test to know that the content fits into the CMS just right. Having the right combination of sample content will also help when it comes time to create and test the different interface representations.

This might sound simple enough, but sometimes it takes a little extra brainpower. When we were deciding how many entries we needed to test Person, we had to consider all the roles and where the Person content type needed to be displayed. That meant we needed at least two of a bunch of different combinations:

• Role = Co-chair

• Role = Team Lead

• Role = Peer Reviewer

• Role = Host, Session Type = Keynote

• Role = Host, Session Type = Session or Workshop

Having all these instances would let us know whether the resource displays were correct. It would also let us see if the Speaker and Team indexes that list those groups separately were ordered and displayed as intended.

If it all comes out the right way, carry on! If not, make some changes and try again until it all works for the authors and the system and the delivery to the interface. Now development and design can continue in parallel with content creation and entry.

Use your spreadsheet to track progress on the content types. We include ­columns to track progress of the build:

• Set Up

• Sample Content Entered

• Content Quality Assurance (QA)

We also create columns for tracking content creation for each instance to make sure we don’t miss anything:

• Author

• Content Written

• Content Entered

• Reviewed in Final Interface

There’s a lot to track. Having one place where everyone can go to see progress and next steps keeps things moving.

Assemble the Implementation Team

Planning and implementing connected content isn’t for a team of one. We’re not saying you can’t use the information in this book to create better products and put your company on the right path. But it really does take a village; expertise in project management, design, development, and writing all combine to pull this together.

Earlier you worked with subject domain experts. You pulled from their heads everything you could about the domain and expressed it in your models. Designing a CMS around that model shifts you into design-team mode. We use the term “design team” very loosely. There’s no universal term for the group of people who come together to implement a digital product. We like to use “design” in its purest sense: the plan and process of bringing something into the world. Therefore, the design team are the group of people who plan and create a product.

While this team lays the foundations for the CMS, the experts and stakeholders get a break. But don’t go off into a cave, only to emerge once you’re finished. There should be no “big reveal” of the CMS, declaring it ready for content. No presentation to your senior leadership team of mockups of a home page. No command to create some content for the website. Instead, use the process outlined in this book to include everyone continually who has a stake in the end product (you knew they were called “stakeholders” for a reason, right?):

• Product and project managers

• Engineers

• Front-end developers

• Designers

• Marketing/communications teams

• Senior leadership

• Stakeholders (content owners and authors)

• Content strategists

What is the role of each member of the design team? It might seem self-evident what the designers and engineers do, but humor us. Let’s also be clear that these are roles, and an individual person may play several roles.

Product manager or project manager: Usually the product manager or project manager is in charge of the process. Whichever one you have on your team, they control the levers of the implementation players—who does which task, how much time they have—as well as managing the communication with the people outside that team. With lots of coordination, check-ins, and collaboration, they will bring the people and process together for a successful delivery.

Engineer: The engineer is the one who sets up the technology that delivers your content and interface to a user on their device. This includes the CMS or other information system that stores your content as well as the server that connects it all to the internet. The engineers should be involved in creating the content model to head off complications that could occur later in the process.

Front-end developer: The front-end developer writes the code that makes up the user interface. They’re usually the HTML, CSS, and JavaScript experts. They might even be the person responsible for the “skin,” or theme, of the CMS. You’ve given your content meaning by assigning attributes. Front-end developers translate the content model to HTML and JavaScript and then assign CSS to describe how each element should appear.

Designer: The designer shapes the experience, in part by orchestrating the details of the interface. From the overall graphic aesthetic to the cause and effect of interaction, they help to craft a positive experience for the user and generally make sure people notice all the right things. It’s not just about making the product look good; it’s about breathing life into the structure underneath.

Marketing or communications: The marketing or communications team defines the target audience, determines the message, manages the publishing schedule, and determines a dissemination or publishing strategy. They may even create content. If this is a separate group where you work, don’t wait until the end of a project to bring these professionals in. Since they’re responsible for helping your audience discover your content, they need to understand the content model and even contribute to its development.

Senior leadership: These are the decision-makers. The bosses’ bosses. If you work at a bigger organization, you might not have much contact with these people. But you need to find a way to get their attention and buy-in. They are a relatively small group of people (with varying titles), but they can kill a project. Don’t wait until you’re almost done to show them your work. Early on, explain how your work helps the organization become more efficient and effective. Most likely, they care not about how so much as about so what. However, if you have to change the patterns of work or relationships between teams, they need to be onboard very early to support the changes. You don’t want to go to all this effort only to be told “never mind.”

Engage them at critical decision points:

• When you start the process—they may even be some of your domain experts

• When you have an early prototype or minimally functional product

Since everything is based on content and how that is best supported for use by your audience, they really only need a tour of what you’ve created. And a reminder of the so what. What is going to be different when this launches? How will this help the organization? And, for the chief operating officer, how it is built with a process that makes your internal team or your relationship with vendors better?

Stakeholders: These folks own the content. You’ve been working with them all along. First they were among your expert interviewees. Then they helped validate the domain model and ensure that the content model represents the right types of content. Now they approve the content that gets published.
Keep them engaged. Content could be how their own success is judged. Does it help them meet their goals? Can they better serve their customers, clients, members, donors, advocates, or funders?

Content strategists: Maybe this is you, if you are the person who shepherds the content from conception to infinity. Content strategists serve many functions, depending on the organization and the team, but on the design team they champion content that is user-focused, aligned with business goals, and properly structured for reuse.

There are myriad others who could be involved: information architects, copywriters, account managers, business analysts, UX researchers, data analysts. The bottom line is this: Talk to others. Invite them into the process when it makes sense or when you need their expertise to make it all come out right. Involve them and you’ll make allies, if not advocates.

Everything Is Connected

Despite the linear format of this book, this process keeps a lot of plates spinning at once. Content creation, design, and engineering happen in parallel. Iteration comes at every step. As you create content, you sometimes realize that certain interface design choices would improve its usability. When the CMS is built, engineers find quirks in the system that require a rethink of some of the content types or fields. When coding the responsive templates, the front-end developer may discover that the images aren’t suitable for high-definition display. And the more content you add, the more likely you are to find exceptions to all your rules. It’s no big deal if you start small, have clear directions, and test early.

You’ve probably noticed that we’re saving interface design for last. It certainly isn’t least. You just needed to get all the content organized and structured for the design to be applied. It’s like the frosting on a multilayered cake. The cake is delicious and stands up on its own, but something is missing that pulls it all together.