“

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.