“

Fish/Bird Tessellation by Escher

I first discovered I was a content strategy guy at the 2009 IA Summit, at which Kristina Halvorson (@halvorson), CEO of BrainTraffic, organized the “Content Strategy Consortium.” It was a natural awakening for me, as I believe it is for others, since I’ve been working with content all my life in one context or another. When content strategists talk, I find myself nodding: I recognize their stories instinctively as part of my own.

The idea of content strategy isn’t as easy to grasp for others, and that’s ok because some folks appreciate naming things and seeing them all in relation to one another. It’s a kind of wayfinding in the growing complexity of the digital age.

This conversation is ongoing, and most recently I found it in the Boxes and Arrows group on LinkedIn: Why IA Should Focus on Content

Here are a few snippets from the conversation:

Regan McClure • I completely agree. I’ve been mulling over the IA/UI/UX/CS job titles for a while (because I do all of them and can’t answer well when people ask for my job description) and I really can’t decide because they are ALL related. Inherently. Completely. Fundamentally. […]

Laura Hampton • Labelling does create an issue, agreed. When everything becomes so integrated it’s important for each area to retain its own merits but it is also essential that the overlap between them all is well communicated.

Kathrin Peek • There is also the discipline of content strategy to consider. This in and of itself is an even younger discipline than IA but ultimately evolved from it and the very need to focus on the content elements themselves. It’s a subset of UX from my perspective[…]

A year ago, Dan Brown (@brownorama), experience designer and founder of Eight Shapes, wrote a Letter to a Content Strategist on his blog, GreenOnions.com in which he said:

“But, aside from the composition of content, content strategists haven’t (to my satisfaction anyway) defined what it is they design, what’s the output of their work.”

It’s a good article, and I recommend it because he talks about what the other design disciplines need from the Content Strategist. I trust that better apologists than I have explained it to his satisfaction, but I’m going to pick up the gauntlet here anyway, perhaps better a little late than never.

Content Strategy in an Oversimplified Historical Context

I find it helpful to talk about the rise of Content Strategy as simply another thread in the spinning of the Worldwide Web. It is, of course, a gross oversimplification, but I have observed that we, as “WWWWorkers,” have always defined new disciplines to help us come to terms with each new BIG THING we’ve learned about our craft. In a continual dance among engineering and design, culture and communication, we have expanded our skills, each according to his/her own gifts. There has always been room for one more…

In the beginning…the Net

In the beginning of the Web, there was the infrastructure: Networks and protocols. It was exciting back in the early 80s that you could type some words on one computer, and they could be transmitted to another computer somewhere on the Internet. E-mail became the new telephone, and we figured out all sorts of ways to use it. We stored files on servers and used elementary browsers to list them. These were the heydays of some really powerful communication forms, like listservs, gopher sites, USENet, and IRC. With the possible exception of Gopher, these are all still going strong.

And there were links…

Then arrived the hypertext transfer protocol (http://), and we began to structure simple text documents, so that browsers could render them. Hyperlinks began to tie the Web together, and everyone was excited about publishing “personal web pages.” We learned basic HTML (or installed an MS Word add-on, so that it could save HTML), and we created websites of a few pages, all of which were lovingly hand-crafted—and painstakingly and painfully maintained!

Xtreme makeover

But webpages were ugly. They were U-G-L-Y, and there was no consistency across websites because we had no conventions beyond the obligatory “about us” page. In the 90s, we grew impatient with web pages because we couldn’t express ourselves as creatively as we could in other media, like print. So graphic artists began to apply their skills to the visual design of the Web, pushing the boundaries of markup, learning to make things more visually attractive, and establishing some standards for page parts—headers, footers, etc. In their turn, web browsers improved to render what the designers and developers created.

Pretty, but DUMB

As the Web grew, however, we learned that the more information we packed into websites, the more we tried to make them do, and the more we tried to give people a real, touchable experience, the harder and more frustrating it became for the users. We had to face up to the fact that just because websites were beautiful did not mean that people liked using them. They couldn’t find what they wanted, and they were foiled by navigation sequences that didn’t make any sense to them. Fifteen years ago, Vincent Flanders founded Websites That Suck, the original rogues gallery of bad design. (Unfortunately, he still has plenty of material to publish.)

So were born the twin disciplines of Information Architecture and Interaction Design, who along with their elder first-cousin Usability, went to work on restructuring and reinventing the web experience. They brought rigor not only to the structure of sites and consistency to interactive forms, but they recognized the importance of testing the sites on real people. Processes, methods, and tools arose to bring consistency to the disciplines themselves. These fields drew on all sorts of existing disciplines—graphic design, library and information science, engineering, and programming—so that they could stand up for themselves and point to what was important.

Dogs wagging tails

But at the turn of the 21st Century, it became unavoidably apparent that although a certain amount of design could be successful based on one’s own insight and the information itself, we still had little understanding of the people who actually were using the websites. So the discipline of User Experience arrived to embrace and extend IA, IxD, and Usability. Now, we understood that we needed to study the people on the other side of the code—their contexts, their goals, their preferences—in order to create usable sites. Personas and other models grew up to inform all the decisions that we were making.

Yes, but “content is king”

Now, in the latter half of the 00s, we have reached conclusion that we have not paid sufficient attention—have not applied sufficient rigor—to the actual substance of our websites, nor to its appropriateness to our reasons for wanting websites in the first place. And not only on our websites, but in our applications, in our marketing materials, and in our documentation.

In its broadest sense, the disciplines of content strategy (and there are quite a few) add structure, rigor, and discipline to all the questions about content: What content will help us reach the people we intend? What do they need to know from us? What information will best support our audiences and bring us long-term success?

What do we design?

We design the processes by which organizations decide what content they should publish to meet both their business needs and those of their customers; how they will create that content to ensure that it maintains the right voice, message, and perspective; how that content should be matched to delivery channels and measured for effectiveness; and finally, how that content is managed, refreshed, and retired.

Why do we need a “new discipline?”

There are indeed areas in which all these disciplines overlap, and every content strategist brings a wealth of other disciplines and experiences to bear. Stop content strategists on the street, and they will probably tell you that there is nothing “new” here. Knowing what to call something, however, and being able to draw broad lines around its parts, can help us to focus our attention on it. Erin Kissane (@kissane), in her wonderful and succinct treatise The Elements of Content Strategy, talks about content strategy as a descendent of the fields of publishing, museum curation, marketing, and information science. But these roots only make sense in the wider context of all the other disciplines out of which the Web is spun.

Our challenge and promise to one another

So in answer to Dan B., and as my contribution to the LinkedIn discussion, I say that although there is indeed overlap in our areas of interest, content strategy deals directly with the substance—the content—which the other disciplines help make usable and engaging. We worry about the business strategy the content is meant to fulfill, about how the organization is going to create and manage all that content, and about how the organization will maintain a clear and flexible control over the content’s lifecycle.

We must not allow our desire to draw distinctions for our own understanding to hamper our recognition of each others’ perspectives and contributions. In a few years, there will undoubtedly be new discoveries that lead us WWWWorkers to define new disciplines, but they will take nothing away from all the disciplines and wisdom that we exercise now.

Rachel Lovinger of Razorfish began a conversation recently about adopting Agile/Scrum software development practices for content strategy, and as synchronicity would have it, I am, e’en now, working on helping my team explore Scrum for our migration to Drupal. Rachel’s articulation—and subsequent posters’ agreements—of the challenges of working with CMS builders in Agile mode to craft content and system simultaneously has raised for me a few thoughts.

Waterfall Content: Must we adopt the monolith?

Traditionally, software systems have been built by the “waterfall” method. An elder child of “scientific management,” the waterfall sees development as a long, linear sequence of requirements gathering, followed by design, followed by building and coding, and wrapped up with testing before release. Without going into a complete review of the difficulties with this method, its underlying principles suppose that it is possible to foresee all the features and details of a system in advance, so that no change to the design should be required (or indeed allowed) after development has begun.

All the laborers in the process, from the “overseer” project manager to the lowliest coder, must build their part of the plan, and then hand it off to the next phase of the waterfall. Any change to the “master plan” is considered a threat to the success of the project, so a serious set of blinders must be kept in place to preserve the sense of moving forward. By the time the system is delivered, even if it conforms perfectly to the original specifications, it may not turn out to serve its users very well. The waterfall makes no allowance for learning, for creative discovery, or for unforeseen circumstances.

Now, since I’ve become acquainted with content strategy (now about two years, and still a noob!), I have got the impression that large content projects are often done in the same way: Gather requirements, design content models, build templates, create content, and deliver.

And why not? When you’re embroiled in a monolithic CMS project, if any thought has been given to content at all, the system won’t be ready for it until late, late, late in the waterfall. Content types will have been fixed in data capture templates. Layouts will have fused with information architecture. Workflows will have been encoded deep in the CMS DNA. At best, content strategy becomes a parallel cascade that will merge (eventually) with the technical cascade, as the whole project rushes to the sea.

Challenges to Content Agility

Let me draw out some of the themes from the e-mail conversation to which I referred earlier.

I can’t design content in iterative cycles without the “big picture.”

It is a natural panic when abandoning the waterfall, that if we can’t know all the requirements, all the specifications up front, then ipso facto, someone must be expecting us to work without any of them. I’ve heard this cry regularly from waterfall practitioners in my own organization: “But you have to have some idea up front of what you’re trying build!” Yes, absolutely. You have to have “some idea.” You have to have a very clear idea, a rich idea, in fact, a vivid idea of the final product. We don’t, however, need a perfectly detailed idea of it.

The starting point for the Agile/Scrum is an enormous, rich “product backlog,” which includes all the features and attributes that could possibly be included in the final product, captured as “user stories.” These user stories come directly out of strategy: business strategy, market strategy, content strategy, and technology strategy. The whole Team has access to that prioritized backlog from the beginning. Even if the Team is working on specific stories during a sprint, they can infer a general design from any important perspective from the entire backlog in order to guide their work during the sprint.

We use “agile” within the context of a larger “waterfall.”

It is tempting in a disciplined field like technology development to think that methods, like software components, can be disassembled and reconfigured in other combinations, thereby achieving the best of all possible worlds. Of course, “Agile” was first a set of principles set out in a manifesto before it collected any specific techniques. (agilemanifesto.org)

The Agile Manifesto and its extensions stand in direct opposition to the waterfall:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

These principles were articulated in this way because the latter of each pair was considered a principal impediment to the former: Process deadens individual interactions. Documentation delays completed work. Contract negotiation undermines collaboration. Rigid plans shatter in the face of change.

So in my view, the fundamental philosophies of the two approaches are direct opponents. I don’t think you can do both to any real benefit.

Specialists sit idle if they aren’t involved in the stories in this sprint.

Agile refuses to believe that work must be sequential. Each sprint is planned according to the prioritized backlog, the needed skills to fulfill the user stories, and the available resources. A fully-utilized Team should be able from the full range of stories to select enough work to keep everyone fully engaged during the sprint, and it’s the responsibility of each member to estimate his or her capacity. But at the same time, the Team doesn’t have to limit itself to the current sprint backlog.

In addition, a sprint is simply a “timebox” into which the Team plans its work. Saying that you have “potentially shippable software” by sprint’s end doesn’t mean that you don’t work on anything but the stories to be completed during the sprint. In fact, the Team must always be looking ahead to future sprints, so that if there is “prework” to do before future stories are selected, the Team needs to plan when and how that work will be done within the sprints.

Because some work is dependent on other work, someone will get left at the end with too many tasks and not enough time.

Part of the Scrum philosophy is that the whole Team is responsible for the success of the whole. It’s a team issue, rather than a methodology issue if the work is not evenly distributed, or if the Team is in danger of missing its commitments. It is also important to expect that over time the Team get a better sense of its own process and relationships. One sprint or two of someone getting left holding the bag should be enough to raise a flag to the Scrummaster: Something’s not working, and that’s not the fault of Agile/Scrum, but of the Team’s ability to select and complete an appropriate number of user stories for a given sprint.

Agile is too loose to “manage” large content projects successfully.

I have also heard it said that Agile development would work if human beings and their projects were more predictable. Also, I have heard that the larger the project the more important hierarchy and sequence becomes. These are exactly the myths of “scientific management” and its child, the “waterfall.”

• A large system can be controlled with the proper structure and oversight.
• If they work hard enough, people can be predictable.
• Error and inefficiency are the results of carelessness and poor planning.

It is counterintuitive, but true nonetheless, that waterfall approach cannot work as long as any human beings are involved. We are inherently unpredictable. We learn. We communicate ineffectively and incompletely. We make mistakes. We fail. We discover. We invent. We play.

Agile and Scrum accept the ultimate truth that no system can be controlled or predicted as long as human beings are involved. Instead, by breaking the work into short bursts, emphasizing conversation and regular inspection over the course of iterative and incremental work, and accepting change as inevitable, it becomes possible to:

• Minimize the long-term impact of inevitable mistakes.
• Take full advantage of humans’ creativity and inventiveness.
• Move forward without being paralyzed by uncertainty.

Your Platform Needs to be Agile, Too

As a final comment, as I posted to the e-mail conversation, whether you have the freedom to be Agile depends a lot on the CMS you’re using. A monolithic platform that was designed to be implemented according to the waterfall—get all the requirements together, build it, launch it, and don’t make any changes—can absolutely kill any flexibility that an Agile approach might have afforded. It’s well and good to say that your CMS developers are using Agile techniques, but if it requires tons of rework to change the content templates because you learned something later on that shifted your modeling, then you’re really still working under the waterfall.

On the other hand, a system like Drupal, can handle lots of global change as the sprints progress, so it actually supports the Agile process better. For more idea of how that works, look for presentations by Rob Purdie at The Economist.

We owe Jeff Foxworthy of debt of gratitude for this comedic formula, and I think that it serves us well in content strategy. We who work in the content of websites generally are already doing “content strategy,” because being a content strategist is really more about who you are and how you do your job, than your job title or responsibilities.

You just might be content strategist if:

• You spend a lot of time looking at websites, wondering, “What am I supposed to do with THIS??”
• Your internal customers tell you that they want you to build them their own section of the website. They provide you with wireframes and a new logo because they say they don’t want it to look like the REST of the site. For content, they provide you with 10 “webpages” of rambling business gobbledygook that could really be edited down to one bulleted list. They think you’re being difficult when you suggest that no one’s going to read it because it doesn’t say anything.
• You break down people’s monolithic documents into manageable chunks, so that people won’t have to wade through them because you know that creating content for the web isn’t just about text, text, text, and annoying pop-up ads.
• At the end of your work day, you look at your organization’s website and think, “Our users deserve better than this.”
• Your favorite websites may not be “pretty,” but you just keep going back to them again and again because you just feel so at home in what they say.
• You approach every content project with two questions in mind: “What does my audience need from this piece?” and “How does this fit in the overall strategy of the website?”
• You squeeze out a little of your day to cull outdated and neglected content from the website because no one else seems to recognize that it needs to be done.
• You have definite ideas when people complain that no one seems to be “responsible” for the content on the website.
• You read “content strategy” blogs and mail lists hungrily, yearning to contribute and feeling like there must be some initiation into this bright and shiny world…

I invite everyone in the community to add to this list. Basically, if you work in content, you’re probably a content strategist, at least in some, small way. So you can tell people when they ask you what you do, “Well, my title is [blank], but I’m a content strategist.” We do that now, anyway, until the titles catch up to our jobs.

In today’s conversation on the Content Strategy maillist, we’re once again struggling with how to show people “what content strategy looks like.” Of course we’re struggling! “Strategy” represents your whole approach—your planning, your understanding, your vision. “Strategy” is about your ideas, your insight into your audiences, and your sense of how best to reach them. “Strategy” is the lovely aroma from the oven when you’ve baked a loaf of bread—and not just any loaf, but the loaf that draws on years of experience and passion for baking.

Strategy: Just do this…

I love—LOVE—Kristina Halvorson’s book, Content Strategy for the Web. Everyone who worries about websites must buy it and read it. It gives the overall shape of the practice and offers nothing but encouragement and insightful advice the whole way through. On the other hand, I think that there will always be two responses from readers, which illuminate the nature of our struggle:

1. Yes! This is what I’ve been doing—now I understand it better, and I can do it better. Thank you!!!
2. Wait! You haven’t told me anything! How do I do that…?

Even when beautifully articulated, content strategy can come across like this:

Master Strategist (from the podium): “Content Strategy begins with understanding your goals and your audiences’ goals and preferences. Then you figure out what content will meet both sets of goals, and you plan how you’re going to create it. And oh yeah, don’t forget how you work out how you’re going to oversee and maintain it.”

Novice Strategist (blank look): “Right. Well, I’ll try that, then…”

Master (click, click, click…):  “Here…Let me show you some really good/bad websites, and we can talk about the good/bad content strategies underlying them.”

Novice (squinting at the screen): “Yes…but what does the strategy actually look like?”

Master (distributing handouts): “Ah, well let me show you these sample deliverables that document the strategies.”

Novice (passing them along): “But how did you come up with these? Are there templates?”

Master (nodding hesitantly): “Well, yes, but you have to adapt them to your own situation.”

Novice (hopefully): “Maybe if I could just see it in action. Are there case studies?”

Master (apologetically): “Yes, but not many: We’re working on pulling them together from other practitioners around the world. I included one in the handouts…”

Novice (reading): “Yes, I see…but my world isn’t really like that…”

Master (glancing helplessly back at the screen): “Well, really, all content strategy is the same: You just understand your goals and your audiences’ goals and preferences, and then you figure out what content will meet both. Then you plan how you’re going to create it, and oh yeah, then finally how you’re going to maintain it.”

Novice (in despair): “OK. I’ll try that, then…”

I mean absolutely no criticism of any content strategist who tries to explain what we do: I think this is just the way it goes when you try to explain something new to someone who’s never encountered it before. We talk with one another, and we nod in recognition: So why the blank looks and frustration when we try to tell others?

Doing and Being: Craft and Art

Content Strategy, like any field of endeavor, has two aspects: Craft and Art. In that order. For a reason. (Homage to Ian Alexander of Eat Media <g>)

Craft is about the doing of something: Skills, tools, techniques, artifacts, and expertise. The Craft is easy to watch, its results are easy to see, and its techniques are usually straightforward to demonstrate. That’s why we tend to demonstrate Craft first when people ask about the Art. We show the deliverables, give examples of good and bad, and tell stories.

Art, on the other hand, is about the being of something: Perspective, wisdom, creativity, perseverance, and experience. You can feel the power of the Art emanating from the artifact, and you can recognize the authentic wisdom in the artist, but that’s as close to it as you can get.

So when people read an excellent book on content strategy, those who have enough experience in the craft—those who have already been doing it—recognize what they already know: “Yes, of course!” And those who haven’t really started, don’t recognize it: “No, you haven’t told me anything!” The answer is dissatisfying because the more they understand what it is, the more clearly they see how complex it is and how much practice it really takes to do it well.

It is but a glimpse…

By all means, we who are doing content strategy should compile our deliverables and case studies for the benefit of those who want to learn, and we should tell our stories about what we do to anyone who will listen, but we must also acknowledge that as “artists” in our field, there is no way to convey all at once what we have spent our careers compiling.

And one more thing: We must not suggest to anyone that what we do is either easy or straightforward. Saying that only makes newcomers feel like they can never be successful. I know when experts say something is easy, they mean to be encouraging, but for the novice, it generally has the opposite effect. We just have to own up the fact: Content Strategy takes as much time to learn as any other discipline worthy of our effort. It can be learned, and there are tools to help, but it does take significant practice and support from mentors. So dive in! You can do it! It will just take a little while to find your way, and we’re all here to help!