Skip and go to main content

Design & Technology August 14, 2018

Knowing Your Tools – Author Experience Gone Wrong

Image

It is easy to be enraptured by technology and consequently forget what it is meant actually for. This holds especially true for content management systems (CMSs), where businesses require a solution to manage and publish web content with development delivering exactly that. But in practice, that is not always what users actually need. In this blog, I’ll share my personal experiences with a CMS project to help you avoid the same pitfall and give you my key pointers to ensure author experience.

When I crossed over from development to business analysis (labelled the ‘dark side’ by some developers), my former manager gave me a specific instruction: “Don’t get involved with the solution. Just stick with the requirements of your change and let the development team figure out the rest!”

So when a project delivered a new content management solution for the domain that I was responsible for, of course I didn’t look into the way the CMS had been set up. Right? No, not really – I totally ignored my manager’s advice. I actually arranged access for myself to have a peek at the CMS. After all, as a business analyst I needed to know what the CMS was capable of. And it also allowed me to make mockups of pages I’d need later on.

Lifting the curtain

When I opened up the CMS I saw a frightening sight. All the pages in the editor mode consisted of a header area and one big blank space where the content was supposed to be. I could right click the blank area to open up a new configuration window that managed all the things that would happen on the page. But for whoever was responsible for managing the content, the experience would be one resembling horror I imagined.

Sure enough, from a customer’s perspective the pages worked and all the business requirements were met. Functionally, one could indeed ‘manage’ the content. And that’s probably how the project got signed off by the responsible people. But for those who were supposed to be using it on a day-to-day basis? It was Frankenstein-esque.

Time for a chat

The next thing I did was have a chat with the content manager about my findings. He admitted that he was keeping his hands off the content in fear of breaking anything. He simply couldn’t make heads or tails of the thing. Basically, we had a system for content management where hardly any content was being managed.

The CMS solution was never presented to the business because it’s the solution and they ‘Don’t get involved with the solution’. And as it turned out, the developers were staying in their comfort zone and hadn’t explored the CMS themselves either.

Restructuring the CMS

Following that revelation, I decided to make a sandbox page showing the right way of setting up the content components in the CMS. I presented it as a mockup to the team and showed them that they could avoid a lot of work if they just explored the solution. They were impressed with the possibilities and agreed that refactoring would be a worthy cause.

Fast forward in time. Slowly but surely, we started refactoring our pages to make better use of the CMS components at hand. The authoring experience improved to the point where ‘What You See Is What You Get’ became a reality. Secondly, we requested the team to consider the content author as a worthy stakeholder/co-approver and to show him which changes would impact the author experience.

The end result: our author was no longer scared to edit his content and this opened up opportunities that would be normal for a CMS.

Don’t turn a blind eye to the solution in practice
My advice: do get involved with the solution. In the end, a CMS is a system with the purpose to facilitate authors to manage and publish content. Business and development should take the following to heart: it’s not only about putting a solution in place that fits budget and end user, it should also fit the those who support the end users too to avoid having to pay a debt later on.

 

Key takeaways to improve the author experience

  • Know your CMS.
    It’s good to know what your CMS solution can and can’t do, as well as the state it is in.
    My predecessors ignored it, which meant we had to spend significant time re-structuring the solution to make it work properly.
  • Don’t neglect stakeholders that lack a business oriented stake.
    My predecessors ignored a group that should’ve been involved in the project from the start: the actual users. Had they done so, we’d immediately have a proper solution that would help them do their work.
  • Focus on value.
    A CMS is not a goal by itself, it’s a communication tool for your company towards the end user. When you’re unable to communicate efficiently it results in poor or lacklustre communication that eventually will hurt your business. So, make sure your CMS is in proper shape and active use of the CMS will automatically follow.

Questions? We are here to help!