The Elements of Content Strategy - Erin Kissane [21]
Business goals are the overarching aims that an entire organization tries to achieve. To select a well-known example, one of Google’s business goals is “Don’t be evil.”
Tactics are all the detailed, specific requests you’ll hear again and again in stakeholder interviews. “Clarify navigation” and “improve search” are two that come up a lot.
Requirements are the project’s immovable objects: launch date, project budget, available staff members, and so on.
Project objectives live under business goals and above tactics, while respecting requirements. They are things you can actually accomplish with content strategy, like “change our website to reflect our new organizational focus on education.”
Seriously, this section is worth the purchase price of the book all on its own, so go buy it and read it.
How do I know when it’s love?
To complete the project definition phase, you’ll need to know what “success” means for the project—and that means you have to decide what to measure. Some people call this stuff “success metrics,” which is pretty clear, but I like “victory conditions,” a term borrowed from the game design world. In chess, the victory condition is checkmate. In War, it’s not running out of cards. In the game of Go, it’s controlling the most territory. In all these cases, it’s clear what you have to do to win, and that’s a great quality to emulate.
A measure of success that cannot, in fact, be measured is a lousy measure of success. Try to turn as many soft, aspirational goals as possible into success criteria, and make them specific enough that you can actually tell whether or not you’ve met them. If you’re trying to increase traffic or sign-ups, what numbers will you try to hit? Are those numbers possible and realistic? When do you need to reach them for it to count as a victory? How will you tell if you’ve achieved other, softer goals?
After you’ve documented victory conditions for your project, it’s a good idea to collect all your project definition information in one place. If you show it to your client or employer, you may even want to create a formal summary in the form of a project brief or communication brief.
Research & Assessment
Now that you know all about your project goals and your clients’ desires, it’s time to begin the real research.
Users: who they are and what they want
Modern web development teams usually begin projects by conducting user research and developing tools that keep user needs at the project’s center; the same is true for content-only engagements. The purpose of user research is to move beyond assumptions, guesses, and stereotypes to discover what your human readers, viewers, and listeners really want and need.
Who conducts user research? It depends on the project. Information architects and user experience designers have pioneered most of the techniques involved and frequently do the research themselves, but content strategists can make perfectly good researchers. My own preference is to work with an IA or UX person whenever possible, including the user research phase.
Internal teams are often tempted to rely on their gradually accrued and informal understanding of their users. This kind of knowledge is valuable, but if you don’t supplement it with disciplined research, you risk missing important but submerged needs. If you’re working on an informal internal project, you may be tempted to put off user research until you’ve developed a “first pass” at content. Just remind yourself that even if you meet all project requirements and fully understand what your employers expect to see, if people don’t read, watch,