Another angle: IAs frequently focus on structure and functionality, not the overall story and page-by-page content details that will be housed (or powered) by that structure. So, if you’re doing a content strategy, and the information architecture is being done by someone else, you probably still have structural work to do. If you own the content, you’ll need to be a part of all IA documentation reviews to ensure that it meets content requirements.
What do you need to do?
To figure out how content should be prioritized, organized, formatted, and displayed, you’ll have to make a lot of decisions. There are high-level decisions (What channel should we use?), decisions about minute details (How will we label that web page?), and everything in between. Here are just a few of the elements you’ll need to consider:
Channels, platforms, and formats
At some point, you need to decide where you want to make your content available. That means you’ll need to choose channels, platforms, and formats.
• Channel is the place or service through which you are communicating with your users. Examples: email, websites, SMS.
• Platform is the technology upon which you build your content or service in order to deliver or exchange content. Examples: content management system, mobile technology.
• Format is the way in which information is presented. Examples: text, audio, video, or images.
The primary question is, how can we get the right content, to the right person, at the right time, and in the right place? These decisions, like so many others, are not the sacred domain of the content strategist. But, when the time comes, here are some key content-focused questions to bring to the table:
• What are the best formats to communicate (and demonstrate) your key messages? For example, if you’re a tool manufacturer, and you target the home do-it-yourself market, you may want to invest in a series of how-to articles focusing on home projects. It also might be smart to produce a video series showing how to do those same projects step-by-step.
• Are these formats achievable? It’s easy to brainstorm great ideas, but they’re useless unless they’re workable. Do you have the time and resources to create a video series? If you decide on a weekly podcast, can you commit the time to prepare for the podcast, record, edit, and publish it?
• Where are your audiences? We talked about channels in Chapter 6, Analysis. Look back at your user research and determine which channels will be most effective. Think about where your users are, who they’re interacting with, what they use those channels for, and so on.
• How “portable” should your content be? Users love to share content—they link to it, email it, embed it in their blogs. Will your content formats encourage or discourage this sharing? Are you comfortable letting your content “be free,” or are there copyright or legal considerations that prohibit it?
A brief note about social media: “Social media” is plural for “social medium”; that means social websites and services are channels you use to deliver content to and receive content from your audiences. Is your CEO blogging? She’s creating content. Is your intern tweeting? Content. Do you have a Facebook page that you’re updating now and again? Content.
Here’s another thing to consider: Just because you know where your audiences are doesn’t necessarily mean it’s a good place to talk to them. Case in point, take Facebook. Brands have jumped at the opportunity to build a presence on Facebook. Some of them have been quite successful. But many of them are out of place and generally ignored. Do I really want to become a fan of my neighborhood plumber on Facebook? No. I do not. I am too busy taking the “Which Star Wars Character Are You?” quiz and arguing with my mother on her profile wall.
Don’t waste time delivering content where your audiences don’t actually want you to be. Get their permission. Be supportive, not interruptive. Be persuasive, not overly persistent. Meet them in the middle.
Navigation and nomenclature
When users get to a website or similar channel, they need to be able to find the content they need quickly. That’s why navigation and nomenclature are so important.
Nomenclature is the task of identifying which labels will be assigned to different components of a website. A navigation system defines how all of those labels work together to guide the user around the site.
Navigation comes in many different formats, from the traditional tree-like structure (with the home page at the top, main categories underneath the home page, and detailed content pages nested beneath the categories) to cloud-based sites with no permanent navigational features at all. What you choose depends on what the content needs to accomplish and for whom.
Nomenclature is necessary—not only for navigational menus but also for content modules (for example, the label for a sidebar on a web page). When choosing labels, it’s important to:
• Keep an eye on how labels might support key messages
• Ensure context, consistency, and clarity at every level of required labeling
• Make sure, above all else, that the labels are intuitive to end users
Links
Part of your job may be to recommend how and when certain links will appear on the page (or as a specific module). As you think through this, consider that links can, for example:
• Drive users to tasks that support fulfillment of business objectives
• Steer users toward additional, related information that may support their decision-making processes
• Offer relevant pieces of information that will further engage the user in your brand experience
• Encourage users to join an online community, participate in a social media channel, or comment on a blog
Be sure to call out where links should appear, under which circumstances they should appear, how they should be written, and any consistent calls to action.
Microcopy
Microcopy is copy you probably don’t even notice when you’re using a website. It appears in menus and next to form fields. It can act as signposts throughout a website, so you can keep track of where you are. It gives instructions, alerts you to errors, even congratulates you when you’ve completed a task.
These little words have a big impact on your user experience. Joshua Porter, director of user experience at HubSpot, has written extensively on the power of microcopy. He writes:
Microcopy is extremely contextual ... that’s why it’s so valuable. It answers a very specific question people have and speaks to their concerns right on the spot. And because it’s so contextual, microcopy isn’t always obvious. Sometimes you have to hunt to find the right words.*
* http://bokardo.com/archives/writing-microcopy/
Microcopy is often a focus in usability tests. As a content strategist, you probably can help out with some of this writing and evaluation. Ask the IA or interaction designer if you can sit in on the tests, or if they’d like your assistance early in the process.
What you should definitely do is collect requirements for microcopy—such as error messages or inline help text (that’s the text that appears right in your screen when you click or hover over a link or object). Record them in a specific document, so that you can hand it over to a writer, or at least have it for reference during final content quality analysis (QA).
* * *
Preparing Content for the Future
It’s difficult to get a handle on structural considerations when things seem to change constantly. Karen McGrane has spoken extensively on the topic of adaptive content. Here’s what she has to say:
For years now, organizations have been trying to retrofit their print content and digital documents into a web-based format: web pages published and managed by a web content management system (WCMS). Just as the old document model broke down when the Web arrived, the web page model is going to break down in the years to come, as we confront a future of multiple devices and platforms.
If we’re going to survive and thrive in the future, we need to start thinking about content as so
mething that lives beyond a particular publishing platform. We can’t just imagine how content will appear in a particular document or page or screen. Instead, we have to structure our content for reuse.
Now, structured content isn’t new, but it’s always been positioned as a technology problem, the province of arcane acronyms and competing technical standards. But this isn’t a technology problem; it’s a strategy problem. What are the essential content objects we deal with? What metadata do we need to organize them effectively? What are the rules that our business has around them? If you can’t answer those questions at that level, you’re going to be caught off guard when the latest and greatest device or platform is introduced.
Starting now, we need to finally separate content and form. Unless we really sit down and address our core content challenges—what we publish, why, who’s responsible for it, and how we know if it’s working—we’re going to remain stuck where we are today: pinballing madly between devices and platforms, without any coherent long-term strategy.
* * *
Metadata and tagging
Metadata is “data about data.” It’s the specific words, numbers, and any other data that’s assigned to different kinds of content—pages, modules, products, and so on. Metadata makes content findable, portable, and adaptive to different platforms. It’s part of what web search engines look for in order to recognize and categorize content for their search results. It’s what defines the results that come up when we use our internal site search engines. Metadata can also handle the organization and display of the content, along with links between the content.
As you can see, metadata is a big, unwieldy topic. But, with new channels and platforms being introduced every few months, it’s more important than ever to consider metadata as part of structural recommendations. You should ensure that metadata:
• Accurately reflects the content substance
• Has attributes that will organize the content in an intuitive way
• Is consistent across content types and topics
In general, don’t be afraid to dig into the details behind the scenes. These words and concepts might be unfamiliar to you, but once you understand the basics, you’ll quickly recognize the power and potential of metadata.
What Tools Can Help?
For more than a decade, “good” websites followed a common structure using the traditional tree-like navigation. As a result, some of web development’s most recognized documentation tools were developed to design these sites.
Sitemaps
The sitemap is the most popular structural tool of all. A sitemap is a useful tool, no doubt; but sometimes, they fail to capture or communicate even the most basic content requirements.
Take, for example, the page stack—a stack of boxes that means “a bunch of other pages go here.” Here’s what it looks like:
In his book Don’t Make Me Think, Steve Krug describes page stacks as a smoke-and-mirrors way of abdicating responsibility for what actually happens after the first few levels of navigation. Krug says that, with page stacks, the IA is basically telling project stakeholders, “... and then the MAGIC happens!”
Page stacks are fine if the sitemap comes part-and-parcel with detailed recommendations about content. If it doesn’t, the content owners are stuck with no direction, no context, and no idea what should actually go on those mysteriously stacked pages. We’ll talk about how to avoid this problem later in the chapter.
Wireframes
In most IA documentation, page- or component-level content requirements are captured in wireframes (which are similar to architectural blueprints) or a prototype (a functioning version of a few pages of your website or web content components).
These tools can very accurately and effectively document content requirements for the pages they show. But, there are a few problems with them, too.
First, typical wireframes and prototypes show only a few “representative” pages of the website. (Obviously, it wouldn’t be cost- or time-efficient to do them for every page.)
Second, there’s some seriously important information about the content itself that’s missing. To close the gap, there is another layer of “design,” which considers how content—defined and driven by messaging, business objectives, and user goals—will receive the attention it deserves, at the right time in the project process.
Page tables
In order to take sitemaps and page templates to the next level, the level at which key content recommendations may be identified and explained, we need a third document, called a page table.
The page table tells you everything you need to know about the content on a specific website page (or content module): the content objective, key messages, specific content recommendations, source content quality, and requirements for how to create and maintain the content.
Here’s an example of a page table:
Page tables are easy for stakeholders to edit and change, which is critical when there are tons of pages to review. And, for writers, page tables are pure gold: Having all of the source content locations, content owners and reviewers, message priorities, specific topics, and more right there on one page—before they start writing!—is every writer’s dream come true.
When page tables aren’t enough ... or too much
On a website with hundreds, thousands, or hundreds of thousands of pages, it’s neither cost-effective nor time-efficient to create a page table for every single piece of content. Sites of this magnitude include:
• E-commerce sites: mostly product descriptions
• Encyclopedic sites: sites that offer thousands of articles, indexed by topic
• News sites: articles and other content artifacts (images, audio, video) that are typically archived both by date and topic
In these cases, you can create a content requirements template (formatted like a page table) for all pages that have the exact same purpose and use. Not “sort of similar” pages or components. Exactly similar, like a press release, a product description, or a specific type of article.
Regardless of website size, all content recommendations need to somehow be documented to assist with content creation, maintenance, and migration tasks.
Keep up the Good Work
There it is. Useful, usable content that’s valuable both to your audiences and your organization. The stuff you need to succeed.
You’ll notice, however, that the book isn’t over yet. While substance and structure are essential to a successful content strategy, good content itself isn’t enough. You need processes, procedures, policies, and—of course—the people who make it all happen. There’s an entire lifecycle to consider and plan for.
Let’s get to it.
9. People
YOU KNOW WHAT’S GREAT about the Web? There’s always room for more content. And, thanks to the magic of distributed publishing, anyone can do it! Your website can just magically expand to include everyone’s everything. And if stuff starts to get a little disorganized on your main site? Just get a different URL and call it a “microsite”!
Soooo ... how’s that working out for you? Not so swell? Believe it or not, it’s often not the content, itself, that’s the problem. In this chapter, we’ll focus on the people components of the content strategy quad:
• Workflow: What processes, tools, and human resources are required for content initiatives to launch successfully and maintain ongoing quality?
• Governance: How are key decisions about content and content strategy made? How are changes initiated and communicated?
Although they’re two different words with two different meanings, workflow and governance are not easily separated. If you have workflow defined but no real standards or oversight to guide the people involved, it’s already broken. Similarly, if you have all sorts of policies and people in charge but no process for implementation, then what’s the point?
In this chapter, we’ll talk about:
• Defining ownership and roles
&nbs
p; • Designing content processes
• Documenting your processes
• Making it all happen
Whether you need totally new processes, roles, and tools or you just need to refine what’s already in place, by documenting workflow and governance, you’ll have a very clear vision of how, when, and by whom the work will get done. And, with better processes and more clearly defined roles, people will be much better prepared (and, likely, happier) when it comes to creating and caring for content.
Defining Ownership and Roles
So, this content. Whose job is it? Who’s responsible? Who owns it?
It’s safe to bet that there are lots of different people responsible for different aspects of your content and content processes. From requests to creation to publication, there can be all kinds of cooks in the kitchen. But, is anyone clear on who’s really doing what? If not, you’re going to end up with duplicate tasks, unclear authority, and a general lack of quality control.
It’s critical for each person to know what their role is and how it fits into the larger content process. This is why defining ownership and roles is one of the most important aspects of workflow and governance.
Content Strategy for the Web Page 11