Content Structure: An Editor’s Perspective

Laura Creekmore and her company, Creek Content, develop content strategy and information architecture for organizations with complex communication needs. She also teaches content strategy as an adjunct faculty member at Kent State University.

We asked her a few questions about content structure — and how it fits into an editor’s everyday life — in advance of her workshop, “Content structure: An editor’s perspective.”

We hear the term “content structure” thrown around a lot, but you use another term: “narrative structure.” Tell us what you mean when you talk about narrative structure.

I think so many writers, editors, and content people of any sort see “structure” as a four-letter word. Often, they’ve come to this work as a writer first — they view it as a creative pursuit, almost artistic in some cases. When I approach them and say I want to help them with their structure, they’re like “Oh! Stay out of my business!“

I, on the other hand, take a really radically different approach to writing and to editing and to content as a whole.

What I mean by this is that, if you’re thinking about it from a user experience perspective, our first thoughts about structure are probably something about the website navigation. The site map, or how things fit together, or the categories we put things into.

But I also really like to think about what I call the narrative structure, which is the structure that is inherent within the content.

Sure, there’s the kind of narrative structure that is very rigid: for example, a product description where you have actual fields, like width or height or weight.

But there there’s also things that are more open, like an article or blog post. You think back to what we all learned in grade school — those five paragraph essays, with an introductory paragraph and three supporting points and then a concluding paragraph. And every paragraph has a structure. We learn these rules as we develop as writers, and then once we know the rules, we don’t think about them intentionally any more. Many of us get into the habit of just writing, instead of planning the structure of the writing.

We don’t necessarily think about that internal or narrative structure in our day to day writing. While I agree you need to know the rules in order to break them (and when you do it tends to work well), I also think we need that intentional structure within our content, particularly for marketing and product purposes. It really helps your audience have a predictable experience.

Is this the same as what we mean when we talk about “content structure?”

Well, I think it depends. Sometimes, that narrative structure all goes into a single body field in a CMS. The ideal, though, is that it’s broken out into disparate chunks. It depends on the goal of the content — there’s no need to build structure into the CMS just because you can. It needs to be done for whatever reason makes sense.

One example is a recipe. It makes sense to us that recipes get broken into fields. There’s the list of ingredients, and there’s the directions. Those are two different kinds of fields. Also, you might make a separate field for the ingredient, and another field for the amount or weight, so that the site can begin understanding and operating on the content — so if we ask to double the recipe, we can program in the right numbers because we’ve broken those numbers out on their own.

However, you may have reason to create structured fields in plain old text as well. So many of us have messages that get repeated multiple times on a website, or some kind of boilerplate. We don’t want to enter this identical content dozens of times on a site — that’s crazy pants! Six months from now, we may need to change it, and you don’t want to have to change it in those dozens of places.

I do a ton of work in healthcare, and we use “standards of care” that represent evidence-based best practices on how a condition should be treated. A couple of years ago, they changed the recommendation for how statins should be prescribed, and we needed to change verbiage across an extensive set of content—the statin references occurred dozens of places within a multi-thousand record database. In a case like this, if that content isn’t structured on its own, in one universal place, you then have to go search the entire site for any mention to confirm it’s correct — and we can go on for quite some time on why text search isn’t sufficient to find that information, especially when there’s a real legal liability in getting it correct.

You also mention “content architecture” in your workshop description. Tell us what you mean by this term.

A lot of content work is done by people who think about user experience, and about the information itself. This is great. Someone needs to focus on that. But I think a lot about how we put content pieces together, and how that tends to make the editors’ and writers’ jobs a lot easier.

I want to think about the content model, and how the pieces fit together on the backend. What the templates of the different pages need to look like. What elements or fields need to live within that template, and how different fields relate to each other. This is the content architecture, and it helps make the writing and editing — the content operations process — more efficient.

When we talk about structured content, especially within the CMS, it’s obvious how it positively affects both the content operations team and the development team. But how does structured content help the people actually using the site?

At a very baseline level, if your content is structured better — which in turn makes your operations more efficient and easier to keep it up to date — your site users are going to have a more predictable, more reliable, and more professional feeling experience. Simply put, it reduces human error.

I worked on a site last year where I helped a large company redesign not just the site design, but the very way they talk about products. From a site experience, there’s not a lot that looks fundamentally different — it’s still paragraphs on a page — but we were able to come to a standard set of information that is now provided for every product.

Anyone who’s worked on a site of any size over any length of time knows — even when you start out with a standard structure and process — over time, things get tweaked. One product manager has a bigger budget, so they’re using video, for example. So it’s important to go through the site often to re-establish whether the existing structure still works, and in turn, whether the existing structure still makes the user experience more predictable.

You talk about understanding the framework in which the customer lives. How does this affect the content structure?

I love to talk about audience understanding and audience context, no matter what the actual topic is. I think so many organizations have this innate tendency to get out front with a message — “We want to tell people X, Y, and Z” — but if we don’t start with an understanding of what the audience actually wants, they won’t give a #$%^ what you have to say!

What you really need is to solve the customer’s problem. If you don’t start with an understanding of an audience’s needs and business goals, you’re not going to answer those problems. Having that framework of where your audience is and what information they’re seeking is the baseline of everything we ought to be doing in content strategy.

From a structure perspective, we have to realize that every page can be the front door to the site. For a project I worked on last fall, we wanted to help the customer understand we were solving their problem no matter where they entered. We wanted the customer or prospect to recognize themselves and know that we understood. We knew their mindset, no matter where they were on the site.

So in our narrative structure on those pages, the first paragraph was always about identifying with the customer and the particular shade of what they needed. We didn’t need to change anything in the backend — we just needed to understand the customer’s goals and needs and reflect them in the structure of our writing.

A lot of this sounds somewhat technical. Is this something writers and editors can take on themselves, or are we at the mercy of the database and our developers?

I think understanding content structure is one of the doorways through which we as writers and editors can gain some control.

I was lucky enough to start working on the internet when content creation meant writing actual HTML in a code editor. So I ended up in a lot of situations where I would sit side by side with a developer or a database architect and was able to work directly with them to make things happen. I would ask them to show me how it worked, and I learned to express myself in a way that made sense in development terms.

I didn’t realize at the time how fortunate I was to be in a situation where I could work closely with technical people, but realized later that I had a base level of technical understanding — what role the code plays, what role the data structure plays — and that gave me the ability to ask questions without fear that I might sound dumb in asking them. I was able to ask questions and get real answers.

I do think not enough content people demand what they need from their technology. In many cases, and in many kinds of systems, you can get what you need out of your technology — if you get in the system early enough, and if you know how to ask the right questions. Most importantly, you can get what you want if you can demonstrate to the business and technology teams why what you’re asking of them matters — that you’re asking for features because it will make the business work better, or because it will solve the problems of your audiences.

For people who might feel scared of the technology, I think it’s to their benefit to get over it by asking questions. Don’t worry about sounding dumb — you’re going to learn from that, and you’re going to get a lot out of it. Sure, sometimes a request or solution might not be technically possible, or the cost is too high, but often there’s a technical solution — as long as you’re willing to get in there and advocate and learn and ask the right questions.

Awesome — thanks so much, and we’ll see you in April!

Laura Creekmore will be presenting her workshop, “Content structure: An editor’s perspective” at Now What? Workshops on April 25-26, 2018.

Tickets are now on sale — we’d love to see you there!