What is the best way to use a headless CMS?

With headless content management systems (CMS), designers and developers are given incredible power and flexibility, like we never had with the monolithic solutions of the past like Wordpress, Drupal, Shopify, or Magento. The problem is that with great power and flexibility, comes great complexity. We spend a lot of time and energy on the design of our interfaces for customers. Yet, we think very little about the user experience of the back end systems that go into this.

With great power and flexibility, comes great complexity.

The prevailing belief is that employees and administrators can suffer the pain as long as the user experience for customers is great. When it comes to the classical content management systems, many of us have been institutionalized. We're years away from the pain of learning our way around Wordpress or Drupal or BigCommerce. When we build for headless, a CMS like Contentful or Contentstack can be a dream. However, because the configuration is largely dependent on the developer setting it up, the user experience for your internal teams can manifest as a nightmare.

This is the side of headless that the industry itself still has not come around to. There is an entire user experience that now must be crafted behind the CMS itself. In fact, headless content management systems can be used to house far more than just content. At Cause of a Kind, we're using headless systems to build entire command and control centers for applications. They come complete with the ability to modify the content and imagery, craft event triggers with web hooks, and even modify the UI of the CMS itself. They give us everything we need not just to control our web interfaces, but also a way to tie together disparate internal systems. They help us wrangle a tangled ball of third-party systems into a neat pipeline of data. We can then safely give control of these systems to non-technical stakeholders.

This frees development teams from one line text changes and running simple scripts to migrate data from one system to another. We've used headless content management systems to build everything from complex brochure and e-commerce websites, to feature flag systems for continuous integration, all the way to medical software that aggregates data from remote devices. This type of power gives us the ability to deliver value faster to customers and more power to internal stakeholders. That being said, leaving this kind of UX design to a team of engineers is often the place where things go south.

Headless content management systems have created their own uncanny valley. The closer the system gets to a great user experience, the more intolerable things can become for users. For example, let's take an old school CMS like Joomla. When modified it becomes quite odd to use. It is riddled with terms like articles, modules, and components that end up representing different entities than we would expect. However, it is understood by the users that there will be a learning curve. They will have to memorize where these things go and what they will effect. The expectation is that this system WILL NOT be intuitive, and this is understood as soon as the user logs in.

With legacy content management systems, you didn't have to consider the user experience. The user experience was dictated for you. You suffered repurposing entities like posts, blocks, components, and articles for new use cases. Administrators decorated their monitors with post-it notes full of little tips for how to use the CMS. Internal stakeholders understood the tradeoff of using what's available to avoiding building something from scratch. These oddities became acceptable abstraction leaks and a challenging user experience was the expectation.

With legacy content management systems, you didn't have to consider the user experience.

Contrast this with a headless content management system. Here, the workflows can be carefully crafted, entity terminology can matched to the industry, and custom plugins can make the editing experience more intuitive. The problem is, when users expect something intuitive and simple to use, yet it is not, that friction if felt ten fold! It's even worse when you get almost everything right.

So how do we get this right? You need to talk to the users! It's important during the process of configuring the CMS, that you, the engineer, sit down and talk with some users. Show them how you're thinking of configuring things. Ask them about their workflows and pain points. At Cause of a Kind the user flows in the back of the house make it to the story map and design documents.

We may not need UX designers to create mockups like we do for the customer facing application, but we certainly need to prototype. Before you hook up the CMS, create some models and fill in some data. Share it with the people that manage the system and ask for their feedback. You won't get things perfect, but you'll be able to cross that uncanny valley between expected discomfort and that thing that was almost delightful.