17 usability tips to make your CMS rock
More than likely your content management system (CMS) will have many usability problems if you just use it “out of the box”. Having been involved in a number of projects tasked with implementing a these types of systems—including content management systems for websites, intranets and wikis for knowledge management—I’ve noticed that there are a number of key areas of the user interface that frequently need fixing from a usability point of view.
All the usability tips you see here link back to general usability principles, and they apply to any software package or web application, it just seems that they are an issue in most CMS implementations.
Use these tips to improve your current CMS or to help you when implementing a new one.
1. If in doubt, leave it out
The user interface should be devoid of everything that is not necessary in terms of users completing their tasks. Most CMS products will have capabilities in excess of what is being used, but don’t show it if they don’t use it. And many products will have optional extras and upgrade possibilities, so your version might not have all the bells and whistles. For better or worse, some vendors will leave a stub to these missing features (possibly to help encourage up-sell). Don’t show it if they can’t use it.
Use CSS to hide stuff if you have to, but clean up that interface. We’re talking about main navigation, links, and irrelevant details spat out by the system. This also applies to words; as Steve Krug said “Krug’s third law of usability: get rid of half the words on each page, then get rid of half what’s left”. Each page title, sub heading, button label, navigation label, form field label, icon and graphic should be useful and meaningful, clearly communicating what it should.
2. Shield users from the complexities of the system
Your CMS might be complex and all powerful, but users don’t care. The user interface should provide a level of abstraction away from the inner workings of the system, performing a translation between what users want to achieve and the technical functions that make it happen. Don’t expose the user to the inner workings of the system by referring to things such as “asset models”, data structures and other things found under the bonnet. These things relate to how the system performs what the user needs it to. Users do not need to know about these things and will be confused by them. They are a dead giveaway that an interface has been built “by developers for developers”.
Frequently you’ll find this kind of thing popping up in “error” messages and terminology used. But also in the convoluted processes users have to go through and the assumed knowledge they need to interact with the system in even the most basic ways. For example, a common problem in many CMS products is ‘pogo-sticking’ or ‘hub and spoke’ where users are forced to go back and forth between different parts of the system to complete their task, usually with some degree of ‘double handling’ or duplication.
3. Speak the users’ language
On that note, the user interface is fundamentally about communication. You have to communicate clearly, using terminology the user will understand and in a way that allows them to take the necessary action and continue with what they were doing. This effects navigation, notifications and messages, button text, form labels. Of course, it goes without saying that jargon and internal system techno-talk should be nowhere in sight (although you might want to use business jargon that is specific to your particular organisation, see tip 10).
User research can help uncover the language that should be used, and Defensive Design for the Web by 37signals gives excellent advice on error messages, notifications etc.
4. Know your real users
What the heck, let’s go all the way and find out who it is we’re creating the system for. Who are the end-users? Chances are they are not techies; they’re not developers and they’re not systems administrators. Which is a shame because they won’t get how perfect the database schema is or how scalable the architecture is. In fact they don’t care about how it’s built at all!
Sure, developers and sysadmins may be users of the system, but they unlikely to be the majority of the users. The end users are going to be writers, producers, product managers, sales people, editors…human beings (ok maybe not the sales people 
.
Do some research, find out what, how, when and why these users are using the system. Talk to them, watch them, crunch some server logs, do a task analysis. It’ll all inform the design and help you work out how to apply the tips you see here.
5. Don’t forget the real-world purpose
The acronym “CMS” is made up of three words, one of which is much less important than the other two: the S. Don’t get caught up in the magnificence of the system and forget its true purpose, which is to manage (and create) content. That’s why users are using it!
Everything in the design and construction of the system should keep this in mind. The purpose of the system is not scalability, data synchronisation, referential integrity or network security. These are simply a means to an end, and should stay behind the scenes. Techies will focus on these things, which is fair enough, it’s their responsibility and their reason for being. Which is why there needs to be someone calling the shots in the project who understands that the job of the user is not these technical aspects, it is about creating and managing content.
6. Do a few things really well
Getting to know your users should include some kind of task analysis, find out what the most important tasks are that your users perform. Prioritise and focus on these key tasks, do them well. Customise the interface, automate some tasks to simplify processes, whatever it takes but make doing those tasks as easy as possible for users. Allow them to initiate those tasks from the home page.
For a busy, content heavy website, a key task might be writing content. This is “on the critical path”, to use project management parlance, so ensure you get that right if nothing else. Similarly, for a very large site with tens of thousands of content pieces, a key activity might be searching for content (either to re-use it or attach it as a related item). In this case make search work really well, perhaps structure the system around searching.
7. Use natural mappings where possible
In the case of a CMS, a natural mapping is where the user interface mimics the action being performed. A great example is when editing the placement of items on a web page. Typically in a CMS this is achieved using a form to capture input (unless you’re using “in-place editing”). But this isn’t natural, since the form doesn’t bear any resemblance to the finished product. It seems trivial but re-arranging the form fields on the edit page to be similar to the finished page being created, will make it much easier to understand which bit is which and where they should type what. Or provide a visual map that illustrates that each form field relates to in the real world. Or your could just label each field so it makes sense
A good user interface mirrors the mental model of the user as opposed to the internal system model.
Another example is if dealing with images, show them. This could be thumbnails when searching or listing, or bigger versions when viewing properties. It’s much easier to identify content by visual attributes that will appear in the end product, such as what an image looks like or title text or name of a page. Compare this to an arbitrary system generated ID, which means nothing to a user.
8. Be consistent
The user interface should be consistent across screens, pages and components. This includes navigation, buttons, form controls, text styling, link styling, form layout, terminology and feedback mechanisms (ie alert boxes or ‘yellow fade’).
This is especially the case if certain parts have been customised, which normally stand out as being substantially different in look and feel. Delivering a “Frankenstein” is a sure fire way of making the system look like a hodge podge which won’t help user’s perception or acceptance of a new system. They must feel it’s a quality product.
9. Stick to established conventions
Not only should the CMS be consistent within itself, but it should also be consistent with what users are likely to expect from other similar systems. For example, if the CMS is a web application, standard website conventions apply, such as the placement of the search box, use of form controls such as dropdowns, and single click links. As Rich Internet Applications become more prevalent, additional conventions will emerge, but this is not a licence to do whatever you please. Functionality hidden behind unconventional methods of interaction (such as right-click or double-click for web) will not be discoverable because users will not expect they can interact with the interface in that way.
10. Tailor to suit your specific environment
Consistency also extends to making the CMS look and feel like other tools and applications provided to your users in their Standard Operating Environment (SOE). Integration with these tools will be hugely beneficial, be it ensuring content from the SOE word processor can be easily copied and pasted into the CMS, or ensuring the web-based CMS works in the SOE browser, or perhaps integrating the CMS into the organisation’s single-sign-on so that users don’t have to login separately.
Tailoring the CMS might also mean using consistent visual design and branding, making users feel like the CMS is “theirs” can go a long way towards them accepting the new system and creating emotional investment.
This tailoring should also include removing unnecessary items (tip 1) and abstracting a simpler interface (tip 2) especially for key tasks (tip 6) and speak their language (tip 3). For example, if the specific purpose of the CMS is for an intranet, then the user interface should be tailored to make reference to that, rather than a “website” which might be the out-of-the-box terminology.
11. Create an effective “home page”
A home page or start page or dashboard for the CMS is a great idea if well crafted, containing useful items. Don’t load it up with out-of-the-box clutter (typically “workflow” related items) find out what your users need to know when they first login. Use this page to give easy access to key tasks, by prioritising all the things that the system can do, and giving prominence to the core tasks users need to perform (displayed bigger, higher on the page and perhaps with icons). Infrequently used or less important items can be smaller and further down the page, if they’re shown at all.
Hand in hand with this is streamlining the login process itself. If the CMS allows editing of multiple sites, but a user only ever edits one of those sites, then don’t make them have to choose the site every time they login; an unnecessary step standing between the user and them getting on with their work.
Furthermore, consider dispensing with a dashboard or home page altogether and take users straight to the single most common task (if there is one) and let them navigate to the home page when they need to.
12. Get the forms right
The primary method of data entry in most CMS products is a form. And typically they’re not very usable, so get this part right. The forms should be well designed, with logical structure, meaningful labels, proper validation and a clear call to action. As mentioned in tip 7, making the form more natural in terms of its relation to the end-product will make it much easier to use and understand. Web Form Design by Luke Wroblewski is an excellent reference for creating usable forms.
13. Get a designer in on the action
Don’t leave the design of the user interface up to the developers who are building/installing the system. Even if they do have the required skills for interface design, they necessarily lack the perspective because they have been involved in the nitty gritty of the inner workings of the CMS. Even experienced UX practitioners find it hard to maintain an end-user perspective if they get wrapped up in the technical complexities of building the system.
Most organisations would not think to use their graphic designers or UX people on the tool as opposed to the end-product. But this underestimates the importance of what is often a mission critical tool, particularly if you’re in the business of publishing information on a large website.
14. Don’t rely on training
Training users will not completely resolve usability issues. Long after training sessions and user manuals have been disregarded, an unintuitive interface or overly complex system will still be causing problems. In the worst case, even the trainers themselves will have difficulty explaining how the system works and how it should be used, as they try to bridge the gap between the technical system and the users.
While CMS training programmes make everyone feel better, they are rarely effective in my opinion. Why not just spend that time and money making the system easier to use? Then anyone should be able to use it without needed repeat or refresher training sessions.
15. Provide user assistance
Training won’t save a poorly designed system, but you should provide help. This might involve some instructions that explain what users are supposed to do. These can be shown during a “training wheel” stage or in a “n00b” mode, such that they turn off once users are comfortable with using the CMS.
Other than instructions, there should be help content in-situ, when and where it’s needed to help users perform a task. As with notifications and “error” messages, the help should be helpful. It shouldn’t simply re-state what users can already see for themselves on the user interface (eg “this screen contains the XYZ buttons”) but should tell them how to use a function or feature, what’s expected from them and how to recover if something goes wrong.
Of course, there are ways to reduce the need for instructions and help content, simply through the design of the interface making it more obvious how users should use it: good labelling for buttons and navigation, clear visual hierarchy for pages and forms, and prominence given to the most important items on a screen or in a list. The sequence a user should follow, and what they should be focussing on at each step, should also be clearly indicated.
16. Consider an expert interface
There will be some (if not a lot) of push-back from developers when it comes to these tips: “but it is useful…for developers”. And, there is certainly an argument for this if developers and other technical roles will be using the system alongside normal users (although perhaps fewer in number). You want to give them access to use the power of the system and the information they need to administer the CMS and the end-product site, without affecting what normal users see. The view a user sees could be based on their login.
17. Don’t release something half cooked
There is also usually a really strong push to do the bare minimum and then fix it later. That is, launch the CMS out-of-the-box and then “take care of usability later”. This is a bad idea. Firstly, launching something that isn’t working well will not engratiate you to your users nor give them much faith in the new CMS. Secondly, fixing usability problems later on will require users to re-learn the system all over again. Thirdly, “later” rarely ever comes, especially if the business has just invested a lot of money in buying/building a CMS, they will naturally expect something that is finished and the best it can be.
This doesn’t rule out continual improvements to the system—including the user interface—over time but it means the CMS should be usable and useful from the get-go. The user experience need to be taken into account when planning the implementation of the CMS and shouldn’t be tacked on to the end, otherwise there will never be enough time or resources to include them before launch.
Conclusion
Is this important? As long as the tool works everything else is just icing, right? Well no. Lack of usability will make the system difficult for end-users to learn and use, resulting in lower up-take of the CMS, or the rise of unauthorised workarounds.
And these tips are just the start, the obvious things. They can help you improve the usability of the admin end of your website but perhaps it’d be better to choose better in the first place. Concentrate on the key things that need to be done and don’t get caught up in “featuritis” or go over the top with future-proofing (ie including requirements for things you might use one day). Make sure the CMS you’re considering does the key things well, possibly using scenarios to evaluate products. If you need to customise—particularly the user interface—then make sure this can be easily done and doesn’t interfere with upgrades in the future. There should be independence between the user interface and the system.
[Photo courtesy of Brymo]
