The Elements of Content Strategy - Erin Kissane [19]
By method: how does it work?
You might also consider placing each deliverable you develop on a continuum with objective, analytical work at one end and subjective, creative work at the other. This approach can be particularly helpful when you work with clients or colleagues who haven’t ever seen a content strategy document and don’t know whether to expect naked spreadsheets or prosy conceptual recommendations.
If I plot some of the deliverables I work with most frequently on a chart according to their function (I’ll just use evaluate vs. design for this example) and their nature (analytical vs. creative), it looks something like this (FIG 3):
FIG 3: Content deliverables and processes plotted according to function and nature.
In real life, few content documents are 100% analytical, and almost none are 100% creative, but having a sense of the character of each piece of work can help streamline the development process. If you’re working with a team of content people, this sort of breakdown can also help you figure out how to divide up the work in a way that takes advantage of your colleagues’ various skills. Got a data nerd handy? Put her on that content audit and gap analysis. And your content specialist who used to edit a magazine? Let him lead the feature design recommendations and voice and tone work.
By audience: who is it for?
Programmers rarely present raw code in client meetings. For every visual design comp or interface prototype that goes to the client (or manager), there are dozens or hundreds of cocktail-napkin and whiteboard sketches that no one outside the core team ever sees. In the same way, we should resist the temptation to show our clients everything we make.
Some documents are for you alone, to refine your thinking and organize your work; some are best used by information architects, visual designers, or CMS developers; some are intended to offer ideas to clients for approval or revision. Each may be valuable, but it’s quite rare for all of them to have the same audience. Some clients are not best served by spreadsheets or detailed content docs—they need executive summaries and any pertinent questions that have arisen during the document’s development, but not the thing itself. Conversely, members of our own teams often require details that clients and managers don’t. Information architects, for example, often need to know far more about the nature, structure, and relative importance of each kind of content than a client will ever want to see.
Give people what they need, and don’t deluge them with things they don’t. Some clients will want to see absolutely everything, but if you make a general rule of showing less, your approval cycles may move more quickly—and you won’t have to say “That’s not really something we can talk about just yet” more than three or four times per presentation.
Consider your audience in the selection, introduction, and preparation of your deliverables, and even your most overworked client or manager will have an easier time giving you the feedback and approval you need.
On being an advocate
Nearly every project contains within it two sets of needs that are held in tension: the needs of the client and the needs of the user. In successful projects, these two sets of needs tend to be complementary, but you will also encounter situations in which client and user needs appear to conflict. In this situation, content specialists are well placed to act as user advocates, as we often have an easier time finding and citing user research to back up our positions than do visual designers held hostage by a client’s personal fondness for mauve.
In practice, this means that when someone dictates that a certain piece of content must be on the homepage (or landing page, or moral equivalent) you should try to discover whether doing so helps users. If it doesn’t, you may not be