UX Considerations for Building an Amazing CMS
The back-end requirements of the vast majority of websites are not that complex. A reported 30% of websites are now powered by WordPress, and there are many other multi-purpose content management systems (CMS) that are widely in use for generic purposes such as Drupal, ExpressionEngine, Concrete5 and others.
However, for specialist needs these platforms may not be up to the job – oftentimes failing to provide particularly great experiences for the end user. We probably won’t be the first to suggest that one or two of them – without naming any names – could be described as a bloated mess of outdated features and overly complicated menus.
For some projects, a bespoke approach to the back-end can be the best thing for everybody. But what makes the difference between a good and bad user experience (UX) when making a new CMS? Let’s look at some considerations.
Keep It Simple
UX design for a website’s back-end is in some respects a completely different challenge to the one faced by front-end designers. Whereas UX factors for public-facing websites are generally concerned with improving conversion rates and encouraging button clicks, CMS design is about facilitating tasks. In other words, whilst good front-end design is often primarily about convincing users to do something, back-end design is concerned with assisting users to do things they have already decided to do.
However, many of the Internet’s most popular all-purpose content systems demonstrate rather poor UX and are deeply afflicted with feature creep; by trying to be everything for everybody, they have largely ended up with unwieldy interfaces overstuffed with options.
Rule one of good CMS design is to anticipate what the most commonly used tools will be, and make those immediately and unambiguously accessible – the good thing about custom back-end systems is that they can be limited in scope to only the precise needs of the project. If your users only need to add blog posts and event entries, you can make a CMS that handles only those elements and completely remove all of the clutter you might find in another system. This is where user research will come in extremely handy.
If the user is likely to want to add a blog post 90% of the time, don’t hide the button to do that in a submenu somewhere – put it prominently on the main dashboard page with a highly visible icon. Anticipating common tasks and questions (“How do I add an image to my post?”) can help you to design a system that offers clear and immediate solutions to user problems.
Intuitive Categorisation
If things have to be placed into submenus and dropdowns, they should be organised according to common-sense groupings that allow users to quickly find tools in intuitive places. Ideally, tools should simply be found “where you’d expect.” Try tree tests with current CMS users to understand their intuitive categorisation tendencies.
Duplicating a post and using it as a template for another is a common requirement for many users, but in Concrete5 this is a bewilderingly complicated operation. You have to access the Site Map (the full site map, not the little one in the preview bar – not that the system will tell you what the difference is), change the sorting to Flat View (it doesn’t work if you don’t do this, although there is no visible reason why this should be the case), and only then click the post in question and select “Move/copy” – because of course?
When designing a CMS, ask yourself (or even better, ask a few other people):
– where would you expect to find a particular tool?
– what should the label on the button be?
– is the user likely to say, “how was I supposed to know that?” when they find it?
In the same way that business-minded people are popularly derided for using words like “leveraging synergies” and “core competencies,” web designers and developers sometimes have an inexplicable love of “computer-y” words and phrases that are nice and technical-sounding but nevertheless somewhat detrimental for UX.
Don’t make your users look for the blog post creation tools under an option called “content authoring” – and for that matter, don’t make them upload their images via a “media library system.” Nobody talks like that, so put things where normal humans will expect to find them – half of the point of any content management system is to be an easily understandable bridge between non-technical people and systems like PHP/MySQL, so make sure your interface is written in plain English.
Automate Common Tasks
The other half of the point of a content management system, of course, is to save the user time. Even for somebody who does know how SQL databases work, it’s a lot of hassle to separately upload images and create database records containing manually written HTML for a new blog post.
A good CMS designer should be looking to automate as much of the content authoring process as possible. If the user uploads a new image, they shouldn’t need to upload their own thumbnail – your system could easily generate one for them. Dates and times can be auto-filled, HTML content can be auto-generated from a WYSIWYG editor, updates can be installed spontaneously, and so on.
For every micro-task the user will have to complete to create or edit a post (or perform whatever operation is at hand), ask yourself – does this seem like something a computer should do for you? After all, CMSs are ultimately supposed to save the user work, not create it! By automating a large number of the repetitive parts of the process, you can create a system that surprises and delights users with its ease of use and lack of friction.
Explain Everything
We all know that the majority of users probably don’t read documentation until they get stuck, at which point the lack of reference material becomes a glaring omission. Even an elegantly simple, well-designed system should come with a little supporting documentation to explain key concepts to users who, for whatever reason, are having trouble figuring things out.
Even better than documentation is the implementation of inline hints, tooltips and other aids that could appear and explain things without the user having to refer to anything or Google their problem. A key part of the UX design of your CMS might be looking for any areas that may still not be 100% clear and unambiguous (despite your best efforts), and support users struggling with those aspects with some extra helpful descriptions.
A great CMS should ideally be as self-explanatory as possible, and part of achieving this goal can be performing usability testing on the new system. By showing the CMS to a number of different people and observing where they get stuck, you can very quickly identify where some things may benefit from better explanation – as things that make sense to you may not communicate to others the way you might expect.
In the end, the perfect CMS needn’t be the one with all the bells and whistles and the thousands of tools and plugins for doing everything conceivable. As with almost all areas of design, less is more and simplicity is the secret sauce.
By identifying a small number of key tasks that your users will need to undertake, and facilitating those specific exercises in an elegant and effortless manner, you can create a wonderful content system that is a joy to use – saving your users from wrestling with website tech and freeing them to concentrate fully on their work.
