Your company is using a traditional, fully-featured CMS that promises to provide an all-rounded digital customer experience, but teams continuously need to work around it in order to deliver? Licensing and hosting costs are high, and in addition, you also need developers just to maintain the product and assist content creation teams? You hear complaints regarding the CMS from different parts of the organisation, saying it’s limiting capabilities in digital marketing and new service development? Chances are, you’ve already heard of headless CMS by now and wonder if it could solve these needs any better, and if it could fit your organisation.
Too often I’ve heard stories where a traditional CMS was changed into another traditional, or changed to headless, or headless changed to traditional and still people are unhappy with the result and want a new change. I’m going to reveal a secret: technology change alone is never a solution to this problem. Or to most problems for that matter. In order to do my part and reduce the number of disappointed people telling those stories, I’m going to explore in this article:
- How an organisation suffering from the limitations of a traditional CMS could transition to a headless one.
- What areas in the organisation this change affects and how
- What technical capabilities are needed in order to do this
- How to not fail when doing a transition like this
You will hear if traditional CMS causes you pain
Today’s omnichannel digital experiences require the development and marketing teams to be increasingly agile, and deliver value to customers at an ever-increasing pace. Because the traditional CMS’s are large monolithic systems originally designed to do a great job in static desktop content, creating new kinds of content or interactive experiences can often require so much time and effort that teams start to resort to different workarounds: using landing page tools, hiring 3rd party agencies to create separate websites, setting up other CMS systems to offer a solution that wasn’t included in the capabilities of the original CMS.
Utilising these workarounds is fine for experiments and smaller-scale projects, which first need to prove themselves before being fully integrated into the core offering and processes of an organisation. Nevertheless, if you listen to your marketing, development and content creation teams, and you hear it becoming a continuous issue and reason for delays in project deliveries, it’s a good time to start investigating headless CMS alternatives.
How headless CMS changes the way we work
I won’t describe in detail how headless CMS is different from a traditional one, as there’s plenty of these comparisons already, and most of them are biased towards one or the other. This comparison from CMSWire nicely summarises the pros and cons of both in an agnostic way, which I can fully agree with. The main difference is that headless CMS has no head: it’s decoupling the end-user’s presentation from the content itself. In practice, this means that it comes without a front-end, which in turn means that you need more effort from development teams at the beginning for building it. And no service is ever done until it’s dead — it needs continuous development effort to improve it and create new components for editors.
New projects, such as product experiments or larger marketing campaigns can quickly plug into the existing, already created content, and borrow the work already done to build similar look-and-feel experiences if they want. They could also create their own content, and build their own front-end experiences from it. But content creation gets more complex for content authors and editors, as headless CMS editing interfaces usually don’t have WYSIWYG editors (yet). We’ll deal more with this dilemma later in this blog.
Since headless CMS is consumed with APIs like most other modern SaaS services, it’s a perfect place to pick and choose the best pieces to build the full service: best CMS, best AB testing tool, best marketing automation tools, best ecommerce platform, best payment gateways etc. You are not tied to the traditional CMS seller’s ecosystem (although open-source platforms like WordPress and Drupal have almost limitless offering on those), but the world is your oyster. Some services plug together easily like Duplo-blocks, while others require more tinkering and creating integrations. So choose wisely, and take into account your organisation’s technical competence and resources.
Is my organisation ready for headless?
Probably not, since you’re reading this article — but you can become ready! The shift to headless means that the nature of work will change for many people. Some may like it, some may not, and doing this phase wrong is usually the biggest reason for failing to adopt a new CMS. In order for this transition to be successful, everyone’s needs and concerns need to be heard and addressed. As always, the best results are achieved when creating change together.
Creating and editing content in a headless needs a different approach than traditional CMS. You’re not editing individual pages anymore, but instead creating reusable content that gets linked or referenced to multiple different places. It requires a different mindset, and is technically more complex. In order for a large amount of content to be manageable, the setup and content structure needs to be carefully designed together with content creators, designers and the developers who are implementing the system. Biggest pitfall here tends to be that developers first set up the system, build some visual building blocks with designers, and then hand it over to editors to use. This is a sure way to lose editors’ engagement and it leads to issues down the road.
Marketers are often the group struggling most with traditional CMS, so they have a lot to gain here in terms of getting more flexibility to building compelling content. But in order to enable them to create visual and interactive content, these building blocks need to be designed and developed, as traditional CMS doesn’t offer front-end out of the box. So ensure your marketers are on board with planning the transition and prioritise their needs among others when roadmapping the trip.
They are the ones enabling this transition, as headless CMS requires a lot of development effort at the beginning to create the head matching your company’s brand and style. Developers usually also embrace this change, as it lets them use the modern front-end technologies best fit for the team, and build pipelines where tests and deployments can be automated to multiple environments. But as mentioned, do not let developers alone drive it, because content creators are the ones who need to manage the large amount of content every day. Even after the initial setup is ready, it’s important to ensure close and continuous collaboration between developers, designers and content team, in order to fulfil the content creators’ needs and build more blocks/components for them to use.
Finally designers get to use their creativity to the fullest, without the limitations imposed by the page structure or theming system of a traditional CMS. But now, instead of designing pages, designers need to start designing blocks or components, which adapt to different forms depending on whether it’s shown on mobile web, a hybrid tablet app or a desktop-like kiosk vending machine. A good practice here is to move towards using a design system, where visual components can be demonstrated and shared easily within an organisation so that each team doesn’t need to create their own. Designers have a big role to play here.
If you have a multilingual site, chances are you’re either using a localisation agency or have some in-house translators or multilingual editors localising the content. In case your translators will access the CMS directly, you trust them, and you can provide training for them, you are good to go. In other cases, ensure your translation agency can integrate to the headless CMS, or be ready to develop custom import/export scripting tools and perform manual hassle every time a translation batch gets created.
By understanding where you stand today, what in-house capabilities you will need and what you can outsource, you can start moving toward an organisation that can successfully handle the change tomorrow. Or a month from now. Or a year.
A CMS in many companies has deep roots around the organisation, so it touches the work processes of a large number of people. Transitioning to a headless CMS causes major changes to the ways how people work, and it can also require changes in the personnel, so these should not be taken lightly. In order to ensure a successful journey, it’s best to involve your people from the content teams, developers, marketers and designers into designing the new CMS setup together. Facilitating workshops at the beginning, where everyone’s needs get taken into account, and ensuring a continuing collaboration between designers, developers and content creators when the new system has been taken into use, are the only ways to ensure a successful transition.
In an upcoming blog, we will look into the concrete requirements you should consider when choosing a headless CMS. Of course, your mileage may vary, but we can offer a solid list that will work as a starting point for any company.
As sales are going digital, IT’s role is becoming increasingly crucial. What is the role of IT as a sales enabler in future companies? Can new ways of working make IT an active driver for digital sales instead of being just a back-office function? Should investments be focused on enabling data capabilities, sales process automation, or on leading customer experience?
Join our free webinar on how to go from business and cost-driven IT toward sales-driven IT. Learn what it takes to make IT a driver of digital sales, on November 4th, 2020.
Originally published at https://www.columbiaroad.com.