Content structure for content strategy

One of the key messages in the IA world at the moment, in the wake of the rise of content strategy, is that planning content structure is just as important as planning, um, content.

Indeed, many would say they were inseparable, but while content strategy looks at what needs to be said, content structure looks at how it can be formatted, shared and re-used.

Not shared as in posted on Facebook, but shared as in passed between pages, sites, apps and templates so that the same knowledge can be distributed across any device and channel. Content, once an infinitely sized bucket into which Lorem Ipsum could be dropped, or vital information locked into a 15mb PDF (which won’t open until you update adobe, twice), has moved on - and so must the structure that underpins it.

The way the web is moving, the way we are maturing in responsive design and innovating in open shareable data means that how we structure and label our content is crucial. Content structure affects everything from the poor sod populating the CMS, to cross-device compatibility, to how our carefully-crafted set pieces display on social media.

The BBC News desktop site uses difference aspects of the news article content model, compared to the mobile version. Without a single point of reference, it can be hard to make sure that all the appropriate data is captured and stored.

Facebook’s OpenGraph API lets content producers specify parameters e.g. Spotify's song title, composer, album cover, etc. and displays them in a structured format – so this metadata also needs to form part of the content model.

This isn’t new. Those who manage big hulking sites like the Guardian and the BBC have recognised and embraced this for years now. Now, as IA becomes subsumed into UX and we focus on the front-end challenges of responsive design and touch screen interactions, the rest of us are evolving quickly to meet these challenges and make sure that our content modelling is up to scratch.

Modelling content in wireframes doesn’t cut it any more. True's UX team know from experience that structure and data like mandatory fields, formats and restrictions live next to the wireframe, not within it. They exist outside of screen size and viewport, so we document them outside of that.

Rather than thinking of content structure as implicit in wireframes, we plan and model it separately so that it can support all formats and devices from the start, and provide a clear model for designers, copywriters and developers to work to.

Once we’ve got the basic model in place, we supplement this with other metadata. These will vary from project to project, but can be logged against individual content items for easy reference.

In short, specifying content models separately from wireframes, and paying them as much attention as I do to those boxes and lines has done wonders for team collaboration, development handover and future-proofing our work . Because while design and devices will move on, we also need to be building content that’s reusable, sharable and that lasts.

If you'd like to understand more about planning content structure, please do get in touch.