What does “content strategy” even mean in practice?
3 Lessons from our Content Strategy Workflow meeting
My team and I have been doing strategy and planning for product (web/app) development for a while now.
But, until a few day ago (as of this writing), we didn’t have a standard way of dealing with “Content Strategy” and “Content Planning” for websites and apps.
We’ve already developed and launched a marketing campaign-blog, a marketing campaign-video uploader, a news publisher, a movie catalogue, a rush donation microsite, a career website and a lifestyle category publisher in the last few months.
And, still, no standard workflow.
We decided to finally have a set of meetings for determining the ways-we-work. And these are what we’ve learned, from our first meeting, about our practice of content strategy:
1. Aligning terms is important.
Digital work has a lot of jargon, with new buzzwords coined every day.
Which is why it becomes even more important for the team to have a common understanding of what the real meanings of the buzzwords are.
Such as…(and these come from the actual things that people ask us for):
a. Content Strategy?
In layman’s terms, our team defined content strategy as:
- Why you’re supposed to be posting anything in the first place;
- What you’re supposed to post to get to that;
- How you’re supposed to talk about it;
- When, where and how you’re supposed to get it to people
The answer to these basically define your product’s content strategy.
For an official answer from one of the most prominent content strategists in the Western world, check out:
b. Content Plan?
So, what does it mean for us when people (clients, bosses) look for a “content plan”?
We divided it into what the (product) team needs through different phases of development:
A content plan should give you a roadmap of every piece of media (e.g. text/copy, photos, video, descriptions/tags/metadata) that you need to populate your website or app.
- Initial (Prior to design work; usually for approvals):
Audit + Inventory + Info Architecture (+ Tone and Manner)
- During design and development:
Editorial Tasks (or Schedule) recommendations
c. Content Audit versus Content Inventory
We see both these terms a lot online, and teammates end up throwing both around frequently, but, for our team’s specific purposes, we differentiated them as tasks:
- “Auditing” (Technically, it means the same as creating a content inventory; but, we want to highlight that, unlike “inventory”, it can also mean scoping out the broader field): refers to scanning competitors and best practices (External), versus
- Collecting an “inventory” of what you have or need (Internal)
d. Sitemap versus Information Architecture
- Sitemap: (Deliverable) What you give the Development team, for them to understand the — Pages to be constructed
- Information Architecture: (Discipline, covers a broader set of actions/deliverables) Organization of site information, i.e. Sections and Hierarchy for Content
We also learned that…
2. There is no “standard” project.
Each project has unique challenges and capacities.
We have to be flexible, but there has to be a bare-bones structure to our workflow.
3. The way we automatically think might not be the best way to present information (for our audience).
My brain works in “tables”, and so far, my “audience” — who are mostly web designers and developers — would have a bad retention rate whenever I present data that way.
Just as challenging, though, is using bulleted lists.
It’s how we all automatically write notes (on our team), but when you’re planning a 30+- page website, this might not be the easiest way to digest info.
No real (final) solutions yet.
We’re still working on how to create usable content deliverables that will work from project-to-project, but we hope that these help for people who need an introduction to the work.
More from my next post: Content Planning Workflow and Documentation.
For further reading, you can also check out this comprehensive content audit case study from Gov.UK’s Government Digital Service Team:
