The Problem with Content Strategy Documentation

Good content strategy projects always include a foundational document. One that is based on good discovery work and a thorough content audit.

What your agency or team calls this document may vary from a “content strategy” as a single deliverable, to a content foundation or content strategy brief. These documents range from a useful, text-dense and information-rich Word document to a 120-page deck with so visuals and creative and sweeping generalities that the reader would be left with no specific clue on what was said or how to execute it. But it sure looks pretty.

The one commonality among all these documents? No one uses them.

Why We Need Better Content Strategy Deliverables

At best, clients and teams will review the Content Strategy documentation, hear the message and apply the direction within the document, perhaps even using templates and including SEO. This always requires a good Content Strategist that is embedded with the project team and who sees the project through from beginning to end. Which is feasible for a web site with somewhat static content, but it is a significant risk for ongoing content efforts to rely on a single resource to stay on the project indefinitely.

At worst, (and most commonly) all the effort of creating this content strategy is left to rot on a Sharepoint or Basecamp repository while a site gets built without regard to content requirements. As the site gets launched and grows — or for recurring content or content marketing projects — the content becomes an organic and evolving body of work. The body of work tends to get farther and farther from the original strategy over time. Meanwhile, the strategic document that was supposed to provide governance languishes in a project folder.

It’s time to update our approach to content strategy documentation to create an actionable, living document, one that is used in every content asset that gets created and one that can be updated and evolved as audience or business needs evolve.

“Content User Stories” an Agile Approach to Content Strategy Documentation

Like our content strategy documentation, business and user requirement documentation had a way of becoming an artifact and getting lost in the day-to-day of development. For Agile projects, User Stories are leveraged as a way to embed the business and user requirements into the ongoing process, and make them an actionable, and ensure that these govern the project outcome.

We can realize the same benefit for our content strategy by making Content User Stories an actionable and living foundation of our content process.

This makes a lot of sense when you examine the parallels between agile development and content process:

  • User stories are leveraged to make the requirements actionable, to map the business value and user need clearly to each requirement. Every content item that gets created for a site and for recurring content or content marketing should also clearly align to a specific user and business goal.
  • User Stories keep the scope of Agile projects on track by ensuring that what gets created has a measurable outcome. By requiring every content item to align to one or more User Content Stories, and validating the content item against this goal, your content team will also be able to govern your content strategy — even across a global effort.
  • User stories are leveraged to prioritize features and functionality against the effort required to develop and the value of the feature to users. Content, too, varies in costs and effort to develop. For example, an ebook or full-length video is much more effort and cost to create than a blog post or a tweet. Content needs have to be prioritized just as software features do.
  • Budget and time are real-world constraints for content, too. As web site content evolves to a recurring effort, stakeholders have to make ongoing decisions on what content to launch and when. This editorial calendar process has been in place in newsrooms for centuries, but it more relevant than ever with an Agile Content process.
  • User Stories are updated and evolve with project and user feedback. This launch and learn path to development is even more immediate and important for content. We have no lack of metrics from social to site analytics to track the impact of every piece of content. A good content process should leverage Content User Stories to adapt to real-time user feedback.

How to Create Content User Stories

Agile User Stories are defined from business and user requirements. Each story is scripted in a very specific format:

“As a <type of user>, I want to <perform some task> so that I can <achieve some goal/benefit/value>.”

Content User Stories are created in the same format:

“As a <audience member> I want to <learn/understand/validate this item> so that I can <achieve some goal/benefit/value>.”

Agile User Stories are organized into “Epic” stories, or larger groupings of related functionality. Content User Stories should be aligned to User Journey States as their “Epic” grouping.

On Agile projects, all of the User Stories are defined upfront in a workshop format. For content, a similar process can be leveraged. The content strategy brief and discovery content audit work can be used to inform a workshop to define your Content User Stories. Collaborative processes have an added benefit of building stakeholder buy in a critical ingredient for success with content not just software.

User stories are often written on cards, organized under each Epic, and posted on the team war room wall. This works great for a small team in a shared space, but content teams are more often distributed. Online tools such as FeatureMap can be leveraged for content teams.

An Example of Content User Stories

I created the following example of Content User Stories for a fictitious brand for dog owners, BarkPlace, a co-op store for rescue pet owners. I’ll confess, that I am one of those irritating people who posts on social media as much or more about her dog than her child.

It’s hard not to with a smile like this.

Part lab, part husky, all hair and love.

Part lab, part husky, all hair and love.

These stories are for a New Pet Owner and the first two “Epic” stages of the User Journey, deciding on a new pet and preparing for a new pet. A few of the example stories are for fun, and also because our rescue is a “Labsky,” and we had no idea how much hair could possibly come off one animal. Seriously. And, yes, she sleeps on the bed. Because the kid insisted. And the dog wore down my resistance.

Content User Stories are a way to make a content strategy an actionable, relevant and useful tool for content projects.

Content User Stories are a way to make a content strategy an actionable, relevant and useful tool for content projects.

As you can see, each user type has a specific journey, and each stage of that journey is our “Epic” theme for Content User Stories. Multiple Content User Stories are created to fulfill what our user needs for each stage of her journey and engagement with our brand.

Other user types for our brand, such as Multiple Dog Owner or Senior/Special Needs Dog Owner, Breeder, Shelter Provider, Foster Care Provider, or Trainer will also be mapped to User Journey States and have their own Content Stories.

The collection of these stories becomes our Content Backlog, a master set of content needs that we will refer as we prioritize and create our editorial calendar. We’ll also use this tool when we create individual content items by requiring that each content asset we create reference the user story it fulfills as part of the document meta data.

The content backlog can evolve over time, based on changing user needs and feedback from site analytics and content performance, as well as inputs like SEO analytics, marketing calendar and events, or evolving business needs.

Using this kind of Agile Content process, no content item will get created that doesn’t directly relate to our Content Strategy. Content authors are required to reference the strategy daily in their work, the strategy itself becomes a living document instead of a discovery artifact, and we can better govern the content that gets created and ensure that it always aligns to our strategy.

The result? Actionable, clear and relevant content strategy documentation that gets implemented, which works a whole lot better than a 120-page deck quietly aging into irrelevance on Sharepoint.

And, for the users of BarkPlace, answers to all their pet hair quandaries, FTW.