Most web content projects have both structural and editorial aspects: for example, the information needs to be structured to support the new responsive design, and the current copy needs an update so it adheres to messaging and brand guidelines.
I’m often asked which is the best order to approach the work: structure first and then rewrites, or the reverse? I didn’t used to have a strong opinion, because it seemed to me like a chicken-and-egg problem. If the project starts with structure, I’m building content models off of bad information. If, instead, we start with rewrites, the writers don’t know what pieces we need to fill the models, because the models don’t exist yet. It felt like both directions were equally fraught, and I didn’t have any strong reasons to recommend one over the other.
(Note that I’m not talking about starting without the editorial foundations of a project: understanding the business goals, establishing a message architecture, and knowing what the work is supposed to accomplish are core pieces of any project. I’m talking instead about rewriting poor content—editing and creating new copy based on those foundations.)
Structure the content first, then do rewrites
I recently finished up the second phase of a project that we organized to focus on structure first, and reasons to stick with this approach piled up in my lap like turkeys going to roost. I think that a structure-first approach does make sense for the majority of my projects, and here’s why.
Content models are based on what content is for, not what it says
On this particular project, the existing copy was horrible. Jargony, clichéd, and almost stubbornly unhelpful. How could I build a useful content model off of bad content?
As I was working, I realized that the quality of the copy–even if it’s terrible–doesn’t really affect the models. I don’t build models off of the exact words in the content, but instead I build off of what purpose that copy serves. I don’t actually care if the restaurant description reads like teen poetry (sorry teens, sorry poets): it’s the restaurant description, and we need a short, teaser version and a long, full version. The banquet facilities should include well-lit photos taken within the last decade, and the captions should use the appropriate brand voice to describe how the rooms can be used. I don’t actually need to see decent photos or strong captions to build space for them into the models.
Structure decisions influence development and design direction
A complex content model will help inform all kinds of site decisions, from CMS choice to data formatting. Developers can make better architecture decisions when they have a sense of what kinds of relationships exist between content types, and designers can organize a pattern library that matches the granularity of the content model. The earlier the structure work is done, the easier it is to build integrated design and development plans.
Cramming bad content into strong models is an incredibly compelling argument for editorial intervention
When projects are focused on the structural aspects of the work—we want to recombine content for different channels, or make a clever responsive experience using structured fields—people often start out convinced that the current content is decent enough to do the job. “Sure, it could probably use some spiffing up, but that’s just not in the cards right now.”
I have never seen a more effective argument for the importance of editorial work than taking existing copy and seeing how inadequately it fills a model that we’ve already agreed meets our business goals.
A model I built recently had a content type for holding gushy snippets about the business’s amazing customer service. When we went to move the existing content into the new models, the only copy we could find to migrate amounted to “free ice water” and “polite employees.” We had already agreed that telling the story of the brand experience was a key job of the new website, and seeing how thoroughly their current content failed to do that was the kick in the pants they needed to find budget for an editorial assist.
Content models are easy to iterate
Waterfall isn’t a great match for content development any more than it is for design and code, so editorial rewrites often trigger adjustments to the content models. I may split one large field into two smaller ones, or the writers will find a place where I left out an important piece of content altogether. Refining the models is an expected part of the process.
On projects where editorial rewriting has been done first, though, I often end up with copy that, although now written beautifully, has no place in the model. In the course of structuring the information, we combined two pages into one, or are reusing the same description in three places, and so the editorial effort that went into fixing that copy is thrown out before it ever sees the light of day. That’s discouraging, and can lead to content creators feeling like I don’t value their time or their work.
What works for you?
It’s nice to have some strong reasoning behind my structure-first leaning, but of course my experiences may not translate to your project needs at all.
If you’ve worked on a project that organized structure work first, what advantages or drawbacks did that process uncover? From a design and development perspective, are there pros or cons to either direction that aren’t covered here?
If you’re a writer, does creating copy within a content model free or stifle your best work? If you prefer to start with editorial rewrites, what are the hidden benefits for the structural side of the project?
I believe there are real benefits to taking a structure-first approach to organizing content activities, and I’d love to hear how and if that works for your projects as well.
via planetweb
0 commentaires:
Enregistrer un commentaire