Think of this less as a blog post, and more as a public service announcement. If this was an advert, sad music would be playing as the camera pans round to reveal a content editor weeping at their desk, as they attempt to update a page on their company’s site for the seventh time. They refresh the page over and over to see if they’ve changed the right bit, sighing as a tear rolls down their cheek.
Up until recently, I’ve worked predominantly on apps, web apps, software and websites that are relatively content-light: eCommerce websites designed to sell products, transactional apps designed to complete a task or set of tasks; and for these, the content mostly consists of microcopy.
So it’s been a new and interesting challenge to work on some projects where the design needs to fit around the content. On sites that purely exist to deliver large amounts of information in a meaningful way, the approach is very different. User stories start to go out of the window a little when you realise that the user goal is “find out X piece of information” (times a thousand), or in some cases, “just come to the website to browse and find something interesting, if you want, whatever, no big deal”.
But it’s not the approach to the architecture or site’s UX design that I want to talk about – it’s designing for content editors. The first time I realised the importance of this, I was working with a fantastic Content Strategist who was working to get all of our ‘starting copy’ into the site. She was becoming increasingly frustrated, because she could never find the things she needed to update in the CMS. It turned out that the developer who’d worked on the backend had left a load of old, redundant fields in there- and had used example copy from the designs as field labels.
I can’t really blame him much for doing this; I hadn’t considered that making the CMS nice to use was part of my remit, and nor had he considered it his. He had made the site do everything it needed to do, and you could update whatever you needed to. The more conscientious of developers might’ve asked, “is anyone going to decide what these fields should be called?” – but then the more conscientious of designers might’ve thought of it in the first place.
From that point on, I’ve made it part of my remit to design the CMS as well as the end user experience. This isn’t particularly hard- find out what types of fields are available in your chosen CMS, specify which should be used, provide field labels and validation, and any additional help text that might be required. Some CMS experiences even let you provide thumbnails and descriptions of the things you’re going to add; even better. Here’s a generalised version of one I created recently:
|Field label||Field type||Mandatory?||Validation||Help text|
|Image||Image selection||Yes||Must be 4:3 ratio||Add an image with 4:3 ratio|
|Body text||Free text (multi-line)||Yes||Max 200 characters||Maximum 200 characters|
|CTA text||Free text (single line)||No||Max 50 characters||Maximum 50 characters|
|CTA destination||Link selection||No||Valid link|
|Open in new tab?||Boolean||No||Options: Yes / No|
The final thing I think is important when designing this backend is to use the system’s language. Find out if your CMS calls it a dropdown or droplist, and the types of different sections that need to be completed. Eliminate all guesswork. Let your developers use their super coding brains for super coding. Everyone’s happier in the long term.
Other UXers might be reading this and thinking, well duh, of course you design the CMS experience; after all, content editors are users and they have to use it every day. I really hope that’s the case, and that I’m totally late to the game here. But considering the shocked reactions from any company I do this for, I think this might not be happening too often.
So, I urge you (weeping content editor looks into camera in slow motion) – remember the content editors. And they’ll remember you.
(Fade to black).