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.
This makes a lot of sense…as long as you are confident that an editorial team will be put in place to write the content to fit the new model. Otherwise you might be better off taking a phased approach and keeping the model more flexible until you are certain that content will be developed. For example, you could add the fields but not make them required. In my experience, writing or editing content is the biggest lift on any design project and often the resources are not provided to do so.
We just wrapped up a redesign that followed this similar path.
1. Create Content Strategy
2. Audit and Revise Content
3. Design the Site and Information Structure
4. Revise the Content
Reading this read like my (still-a-work-in-progress) debrief.
Eileen, I loved your post. I’m with you on structure first when you’re dealing with content that needs structuring. Based on my experience, it’s less emotionally taxing to make adjustments to your structure than it is to make sweeping changes to content you’ve asked writers to develop. So I prefer to map out the requirements before assigning content development to a team of writers.
I also agree with @Lisa on taking a phased approach with non-required fields if some content will be trickier to generate. I’ve had to do this when trying to integrate content from other systems (like a massive ERP or something). Sometimes that data needs a lot of clean up and work before it plays nicely with the CMS. So letting those fields be flexible until the data is ready can be helpful.
Love this. I think structure has to come first (with the stated caveat of flexibility as you approach final). I am also one who bridges the content to tech space, but I find a content-first approach tends to neglect the possibilities of a better user experience that are possible from a tech/structure side. If I don’t know the site’s behaviour, how can I write copy for it?
Thank you, thank you. Whenever I am explaining content strategy and management to clients or colleagues, I like to say that you need a skeleton, whether that be a wireframe for a landing page or a set of modules on a CMS template. Once you have the skeleton in place, you can put meat on the bones. If you don’t have a skeleton first, things get messy.
I agree that strategy and communication goals definitely need to come first, and I also like to get that skeleton sorted out before editorial rewrites come into play. But one thing I’ve found really useful is to start having content creators “play” with editorial stuff as a means to define the model.
That is, I’ll have them evaluate the existing content based on the new strategy and the user journeys we want to enable, and ID what’s missing or not working about it. Then we’ll use that to list out the bits of content we need to be thinking about to achieve our goals.
It’s a loose mix of editorial and structural planning done at once, and it serves two goals: it gets the team thinking about the rewrites they’ll need to do (and clearer about how to identify content problems and fix them), and it gives us a rough sketch of the content model. From there, it’s a lot easier to rewrite a small set of sample content to fit/vet the model, iterate, and then engage a larger group in the actual rewrite process—which typically needs its own parallel timeline and management from the technical build-out of the model.
Thanks for this, Eileen!
Hi there –
Very interesting article and super relevant to work I’m doing right now. Totally relate to the “chicken and egg” feeling about content & structure. On content-first projects, it sometimes feel that UX is looking for guidance from me and I’m just not sure where my work ends and theirs begins.
I find it intriguing that you’re pushing for “structure first.” Just one thing, though…
What do you mean by “structure?” Do you mean IA? Do you mean sketches? Do you mean content priority templates?
I’ve toyed with the idea of creating a “content model” and ultimately abandoned it because I didn’t see the relevance to work we were doing. It felt duplicative of both a content audit and IA.
So are we talking about some interim sketching step? What do you mean??
Ahh! 🙂
Thanks for any thoughts you may have.
Hi Alex,
I totally hear you on “not sure where my work ends and theirs begins”! I feel like every project and team has a different dynamic, and there are no clear-cut universal boundaries for our job descriptions anymore. (Which I like! But it can be frustrating, too.)
When I say “structure first” I’m talking about content models like the kind described by Rachel, which for me often represent the intersection of the larger content strategy with IA (those fuzzy boundaries again!). I do sketches, wireframes, etc as part of my content model, but more as alternate views of the same model so that we can understand it from a number of different angles.
We recently got a real estate project where the client is into selling and rental of properties, more specific, flats. He has absolutely no idea about content. He gave us his visiting card and said to take care of rest. The problem is his property data changes, depending on the sales and rental occupancy.
We are planning to get internal details of his functioning and trying to also understand what makes him unique, if it does and what could be his additional expertise to put on website. He says expertise, is related to property verification and that is sometimes like a case study. Putting such details on web could pass on trade secrets on which he convinces his client, on case to case bases.
It is becoming difficult to frame a content based structure, other than just positive information, general in nature.
A blog cannot survive for long without quality content. If you post quality content on your blog, you’ll see quality backlinks generation on autopilot. Other than that, guest posting is also very important to get backlinks and readers. I enjoyed reading this post. Well written. 🙂
Nice insights. I agree to the point that keep the structure first for any website development process. It is important to have clarity of thoughts before running and searching for a system that supports business functions. A proper plan guides a decision maker right from the content management selection phase to the development and maintenance of a web application. Make sure to understand business requirements and consider a system that fits them. There are numerous web content management system and the one that is flexible, scalable and reliable will best satisfy future requirements. The structural plan help developer to decide on tools that must be included in a website. It also allows to decide the user roles and responsibilities. Plans acts as a guide for a developer.
trully amazing concept.. piastre per capelli
Dear Sir/Madam,
Do you need funding?
Do you need a loan?
Do you need Business or personal Loan?
Do you wish to refinance your company?
We give out loan to any individual and company at 3% interest rate yearly. For more information, Contact Email: (tombradinvestment(at)gmail.com)
Name:
Country:
Amount:
Phone number:
Regards,
Money Essentials®
E-mail: tombradinvestment(at)gmail.com
Address: Texas 34475
Country: United States America