Last week I had the honor of speaking at an event for web developers and small agency owners (most of whom are developers-turned-business-owners). I have attended a lot of conferences in my career, and Peers was one of the best. This is not a post about conferences (though I have a lot to say about them), but let me say that it was good because of 5 things (in no particular order):

It is for a specific community.
It was small: 130 people, +/- 10.
People were focused on the sessions.
Attendees were passionate about what they do.
A diverse speaker lineup.

If you are a web developer or small agency owner whose team creates websites, you should put Peers 2018 in Austin, Texas, on your list of conferences to attend.

Content-First Websites

I was invited to submit a talk proposal by the conference organizer, who had seen my content and conversations about back-end content strategy. This was exciting because one of my goals this year was to reach the web development community. It's been too long since I interacted with the people who create the systems that deliver the content I help to create. And there is an obvious connection with structured content and web development.

"Content-first" is something content strategists talk about often. And it makes sense to us. But it is a bit of a mystery to others. Thus, the name of the talk: Content-First Websites: From Theory to Reality. (See the slides.) My goal was to remove the mystery and show a process that puts content first in a collaborative environment to find the best way to deliver valuable websites.

My very first conversations told me I was in the right place. As soon as I said I was a content strategist, people opened up about all the problems they had with getting content from their clients, how projects were inevitably late because there was no content to put in the CMS, and all the last-minute changes to the CMS and design because content didn't fit. This must be what doctors feel like when they meet someone with an ailment!

Let's clear up what "content first" means:

con•tent first
starting the design process by determining the story before the form and structure

(Thanks to Steph Hay for helping me articulate this clearly.)

Content strategy and web development

Most developers (and even designers) think content isn't their job. And they are right. But the work they do should support the story and the content itself. That's the job of content strategy. (I don't say content strategist because anyone can do content strategy; don't wait for a title.)

back-end con•tent strat•e•gy
planning appropriate structure, technology, and processes to support content reuse

Most people think of content strategy as being the messaging, voice and tone, editorial calendars, and writing. It's so much more. Just as there is front-end development (creating the code that tells browsers what things look like) and back-end development (building the system that delivers the code and content), there are both types of content strategy. My speciality is the back-end kind. This is the bridge between content and the system.

As a content strategist, I don't really want to know how to create the CMS and all its widgets and plug-ins and modules. But I do want to understand what it can do. How it can be set up to support semantic relationships, content reuse, mixing and matching the pieces of content, and workflow for the people who enter and approve the content.

It was so exciting to talk to developers who wanted to know how to automate governance and build SEO support into the CMS. I do not have a developer's brain, but I do like how they think. So few content strategists talk with developers and vice versa. We are all missing out because of it.

Content-first process

Maybe I should call it "content always." Because it isn't just that the content comes first, it's that our web design and development process should be content first and foremost. There is no hand-off of content. There is an on-going dance between what meaning the words, images, files, and functional widgets need to convey and how they get from someone's head to the screen to be viewed by another person.

Just as there are functional requirements, there are content requirements, which include (but are not limited to):

patterns and structure
potential reuse opportunities
image requirements and specifications
governance rules

You might also call this content design.

con•tent de•sign
an approach to creating web content that takes something that meets a user need and presents it in a way that makes sense to the user

When we maintain focus on content the whole way through – and put someone in charge of it – we fundamentally change the process of creating websites. Not only can you build a better CMS, but content creation and design can happen in parallel with the CMS implementation. This is the equivalent of an orchestra score – different music for the violins, the cellos, the bass, the woodwinds. Every instrument plays its part to create the symphony. In this case, we create an interface that is

useful – it's got the right content
usable – it's designed to facilitate ease of use
sustainable – it can be maintained and can grow without having to tear down and rebuild

No more waiting, and waiting, and waiting for content at the end of a project. No more containers that aren't the right size and specifications for the content someone else created as part of a separate content creation process. Instead, you get happier (and more functional) teams, clients, and stakeholders, and a better world wide web. What's not to like?

How does your team bridge the gap between content and development? Leave a comment, start a discussion, get in touch. At Tanzen, we love these problems and love working with CMS developers to make better systems that help us manage content better.