How to explain structured content?

This week I was asked how to explain structured content to someone who hadn’t encountered it. It’s a great question, and at the time, I didn’t give a clear answer.

So here are 6 approaches, along with a primer about why structured content is essential and the mindsets and contexts that your stakeholders might have.

6 tips for explaining structured content

1. dissect an example
2. mine project documentation
3. reveal the mess
4. frame the return on investment of content reuse
5. show an opportunity
6. prototype

1. Dissect an example

Consider using an existing or neutral example of a content service with which they are familiar. Ideally, one that has:

• structure,
• instances,
• purpose.

This might be a live service with a good structure or where content designers are faking a content model, like manually creating one for every instance using the CMS editor. Or it might be a service they use outside of work, like newspaper or webstore.

Task them with identifying:

• calls to action for users,
• unique content (that occurs only once in the system),
• reused content (like an author name, or taxonomy tag)
• metadata (like dates, rating scores).

Tips

Probe and explore:

• content bits — what are the parts of the content? Its attributes, bits and atoms? If you break the content down like this, what would that enable?
• content reuse — what happens if you were updating content, like the author’s name category tag? How does this happen? Why is it important? Does this happen today in your content system? Why not?
• relationships — how can you navigate through, or filter, the content? Do you need to use menu systems or search? Why?
• blocked pathways — are there parts you want to interact with but can’t? Are there things that should be linked, but they’re not? How come?

2. Mine project documentation

This can be especially useful if you work with business analysts and project managers. Take documentation like the organisations…

• strategy documentation (5-year plan),
• Wikipedia entry,
• project brief,
• customer care logs,
• site search logs,
• user interview transcripts,

…and work with them to extract things like:

• objects (tangible things)
• roles (on the front-end and the back-end)
• content types (formats, media)
• actions (signing-up, booking, checking out, publishing,…)
• metadata (filters, product IDs,…)

Facilitate towards questions like:

• what do we know about the things identified?
• what don’t we know (and who will find out!)
• where is the content going to come from?
• does anything identified have an apparent structure?
• what are the different jobs that a bit of content might need to do across the product or system? How is that going to be defined?

Tips

• focus on identification and extraction, don’t worry about representing these in an interaction design or the constraints of any current product, it’s content or technology.
• consider a neutral example, or working from a neutral model towards the project and its domain.
• use simple collaboration tools, like pens/paper, word processors or white walls.

3. Reveal the mess

Draw upon the principle of ‘show, don’t tell’ to reveal the costs of an unstructured ‘as is’ state. Instead, by implication, reveal the opportunity to:

• create content once,
• publish it everywhere,
• iterate and govern.

Tips

Try to research and define things that matter to the user and the business, like…

• cost (of work and rework),
• risk (reputation and legal from erroneous content),
• agility (how hard is it to cascade a simple update?),
• opportunity (the valuable work not done).

…and ideally in a quantified form.

4. Frame the return on investment of content and its reuse

Content is a business asset. Indeed, it’s a manifestation of the organisation and its purpose. It’s also expensive to research, produce and govern. But its cost and value are often invisible or not measured by teams.

Structuring content for reuse multiplies the return on investment in creating the first instance of the content. This increases its value and decreases its relative cost across its lifespan.

So if a content asset costs £500 to research, design and publish and is used by 20,000 users in a single channel then its cost per service is:

£500 / 20,000 users = £0.025 

If that content is reused across an additional channel or context, by an additional 15,000 users then its cumulative cost per service becomes:

£500 / (20,000 + 15,000) users = £0.014

Therefore, through effective reuse, underpinned by structured content, the content produces more value than it costs.

By measuring the cost of content, you’ve supported the case for investment in content strategy. By extrapolating for reuse, enabled by structured content and engineered across channels and contexts, you’ve illustrated the return on investment for creating once and publishing everywhere.

Tips

Measure the average cost per user per asset by dividing the content £costs by the rate of use for a period.

Example costs include:

Employee costs — these can be tricky, and political but can still be calculated. For example, use median data from salary bands at your organisation or that from industry salary surveys.

Employee time — a full-time UX Writer isn’t designing content 100% of the time. Use time tracking software, or estimates from the team, to create a metric for the percentage of time spent on their primary tasks. For example, the time spent actively designing or governing content at one organisation was only 30%, with the remainder consumed by meetings, training, support, etc. Cascade across all roles involved in content production and delivery.

Agency costs — you may depend on agencies to deliver the product or service aspects. Whether development, search optimisation, continuous improvement or consulting. Track down annual investment in these services so that you can divide it by the number of content assets in play.

Technology costs — you will also have expenses for your technical architecture. Whether your content management system, hosting, content delivery network or font licensing. Track these down for the period you are measuring.

Duplicate costs — be mindful of rework, perhaps across technologies, channels and teams. If this is happening, capture the instances, scale and costs. Estimate the efficiencies of creating content once and then distributing it.

Example usage metrics include:

• Users,
• Sessions,
• Views (page and/or unique),

…via Google Analytics, and per content asset, for the period you’re measuring.

5. Show an opportunity

Revealing an opportunity can be a valuable way to connect thinking, content and opportunities for structured content. For example, you can outline how structured data works. In particular, its outputs across contexts and channels.

Some simple examples include:

• how search results and user behaviours are influenced using structured data mark-up schemas to create:
  • featured snippets,
  • knowledge graphs,
  • rich answers.
• testing production content against schema validation tools, including from competitors.
• playing with user stories and jobs to be done statements and extracting the calls-to-action and (meta)content attributes. How can these be represented and reused across channels? How are they different today? Should they be?

6. Prototype

A final example is prototyping with content parts — the essential components that structure and inflate the experience design.

Create a simple mix of content, metadata and calls-to-action and have participants create an example of authoritative content. For example, a product page for a webstore or a profile page for a people finder can work well.

Then, the participants begin to model all the other contexts and channels where the parts could be used. Such things like:

• indexes and lists,
• internal search results,
• external search results,
• across the technology domain (website, extranet, intranet, CRM,…),
• customer channels (product, support, print, web, voice,…).

The tyranny of unstructured page-based content design

People often don’t realise that they are grounded in a page-based mindset — a world where they think of content as a linear, single blob.

If they apply any structure, this might be limited to headings or strong/emphasis.

Usually, they aren’t consciously thinking of applying semantics, structure, or landmarks when they do this. Rather, aspects of visual and typographic style.

They use word processing, email, and messaging tools at work to create (mostly) linear/sequential prose-based content. In their personal lives, they consume linear media.

So when they think of content design, they think of the prominent, tangible surface/presentation experience layer. In particular, the graphical interface design (at least for people with working vision).

They usually won’t have grasped that content is split across design languages and layers at the outset. For example, web-based content services are devolved across the ‘holy trinity’ of web standards:

• semantics (HTML),
• presentation (Cascading Style Sheets (CSS)),
• behaviour (JavaScript).

Whereas content platforms themselves are split across the…

• experience (presentation),
• content (data)
• technology (CMS, APIs, servers),

…layers.

However, the very tangibility of the experience layer can create a fundamental paradox for design teams. It’s easy for them to fixate on the content wrapper rather than the content itself. And the user doesn’t come to the service for its wrapper — no more than one who buys chocolate.

This is particularly true in the world where:

• the fundamentals of most interface and interaction patterns are well established, particularly via design frameworks,
• Jakob Neilsen’s First Law of the Internet applies, whereby users spend most of their time in other organisations’ experiences.

In turn, this means that really valuable design advantages are found via:

• code design,
• content design,
• content model design and information architecture.

This is where the value is for the user and the business. But how to introduce it, especially well structured, governed and reusable content?

Summary

There are a number of things you can try to build an understanding about how structuring content works, its benefits and opportunities for users, product teams and the business.

But what has worked for you? Let me know in the comments….