As a graphic designer, it may come as a surprise that what I’m going to discuss today is the design of content, rather than the display of it. I’m talking of course about the wonderful world of the Headless CMS™ (let’s call it HCMS from now on).

Now, the more techy types will I’m sure frown, but I like to think of a HCMS as a kind of glorified RSS feed. Let me explain…

Back in the old days (c.2012) when iPads were enjoying their moment of ubiquity, there was a tonne of apps that allowed you to pull all your favourite feeds into a single, nice clean-looking interface. Of course, it only really worked well for editorial blogs – but it did at least mean that everything you wanted to read regularly was available in one place. But what’s that got to do with a HCMS you ask?

It’s about having one single source of the truth

In this new(ish) model, content editors create and manage their ‘base’ content, as with any other CMS. But the visual environment is kept completely separate.

Why is this good? Because in the increasingly complicated digital universe we live in, publishers (that’s everyone, folks) need their content to not only be available on their website, but on their apps, social platforms, and increasingly via APIs to other providers and their feeds. Not to mention the burgeoning non-visual universe of voice-controlled devices and interfaces which are picking up where the iPad left off.

The traditional model just does not cut it

In the old world, a back-end CMS is linked to both a code base and front-end templates (possibly via an API). So, every time you want your content somewhere else, you have to publish it somewhere else. Duplicates of your content everywhere… it’s a nightmare to manage, expensive to distribute and host – and is wide open for human errors and security threats.

Not so with a headless CMS

From a security perspective, the content management layer is completely separated, or hidden, from the user layer – so can be made way more secure than a traditional CMS.

It’s also great for the editors and brands, as every digital platform can be managed from a single point.

And from a ‘design’ perspective it means your content is easy to reimagine and display in different, exciting new ways. The front-end look and feel is no longer intrinsically tied in to the content or the back-end, so both dev’s and designers can start to deliver faster, cleaner, better, altogether sexier experiences.

Which is all well and good. But before we get ahead of ourselves and go running off to an agency saying, “I want one of those”, it’s not something you can just migrate to. It needs a bit of a rethink. More than a bit, truth be told.

You need a content strategy

Because HCMS is entirely based around your content and not the aesthetics, you need to consider every channel where the content might be surfaced. Whether that’s an app, a website or Alexa. And this strategy needs to come from good UX. No-one starts off with a nice design, then fits content into it any more. All the best practice groundwork still applies – define the user needs, stories and journeys – before you can create your content to suit them.

Every piece of this content also needs to be structured in such a way that it can be reused wherever it needs to – whether in full-fat or bite-size form. So, alongside the basic ‘body content’, it needs categorising and tagging – so that the right bits can be pulled into the right places. Perhaps a little more complex than just populating some web pages, but remember that you only need to create your content once, then reuse in full or snippets across all your estate – websites, apps, emails, bots, assistants, POS, voice-activated devices, VR/AR experiences. Or whatever new tech comes along next week.

It’s future proof, basically

What I think is most exciting about this approach is that everyone at every stage has the opportunity to do their best work.

Content planners and UX teams can help define better content and the best places to surface it.

Content editors and creators get the chance to spend more time doing their best work – no need for constant edits and rewrites.

Developers get to write cutting edge code independent of back-end constraints.

Designers get to create a modular design language rather than a fixed, constrained framework.

And of course, the brand gets an agile, flexible framework which allows them to react fast and deploy easily to whatever platform they need – safe in the knowledge that their content is always up to date, consistent and in its optimal format (assuming the editors did their job well).

Do I think this marks the end of website redesigns?

Certainly not. But we do need to stop thinking visually in the initial phase – we all need to think content-first.

So, any big brands or publishers who have a lot to say might want to start rethinking the way they do things.

As a result, there will be even more opportunities to create beautiful campaigns and interfaces in the future. Great news for designers like me, then.