17 usability tips to make your CMS rock

To your attention the translation of the article by Patrick Kennedy on what should be a convenient content management system .

It’s more than likely that there will be a lot of usability issues in your CMS if you use it raw. Participating in projects in which I was entrusted with the implementation of such systems - web site management systems, intranet portals and wikis, I noticed that there are a number of key areas in their user interfaces that need to be corrected in terms of usability.


All usability recommendations that you see here are based on general principles of use and can be applied to any software and web applications, because it is obvious that there are similar problems in most CMS solutions.

Use these tips to improve your existing CMS or to implement a new one.
')
1. If in doubt, do not use

The user interface should be deprived of all that the user does not need to solve his problems. The potential of most CMS-products exceeds the actual used, and you should not demonstrate it if the user does not need it. Many products have a lot of additional features, but your version of the product should not ring all bells. Good or bad, but some manufacturers insert a module into the system to develop the missing features (possibly to stimulate additional sales). Do not show it if the user does not need it.

Use CSS to hide some details, clear the interface. We are talking about the main navigation, links and irrelevant elements of the system. Here it is worth remembering the words of Steve Krug: “Krug's third law of usability: get rid of half the words on each page, and then get rid of half of what’s left”. Each page name, subheadings, buttons, navigation icons, forms, icons and graphics should be useful, meaningful and clearly communicate with the user.

2. Protect users from the complexities of the system

Your CMS can be arbitrarily complex and powerful, but the user should not care. The user interface should be abstracted from the internal functioning of the system and act as a translator between the user's tasks and the functionality that solves them.

Do not engage users in the internal workings of the system by telling them about the “asset model”, data structure, and other things from the “underground vaults”. All this is just the ways in which the system solves user problems. Users do not need to know about them, this only causes confusion. The fact that the interface was built by "developers for developers" should remain your secret.

Manifestations of this can often be seen in the error messages and terminology of the system. And in the process of work, the user has to go through a tortuous path of unnecessary information, even when performing elementary tasks. For example, a common problem in many CMS products is to perform double work or duplication, when the user is forced to move back and forth from one part of the system to another to complete the task.

3. Speak in user language

The user interface is based on communication. You must provide clear communication using the terminology that the user understands and in ways that allow him to take the necessary measures and continue the action he has started. This work is performed by navigation, notifications and messages, buttons, forms. It goes without saying that the jargon and internal system technical dialogue should remain out of the user's sight (although it is possible to use business-specific jargon, see recommendation 10).

Relevant research will help you identify the language that should be used, as well as the edition “Defensive design for the web: how to improve error messages, help, forms and other critical points” from 37signals gives excellent advice on creating error messages, notifications etc.

4. Know your real user.

What the hell, let's find out for whom we are creating a system. Who are the end users? Most likely, this is not techies, not developers and not system administrators. Shame on them, because they do not know how to improve the database or scale the architecture. In fact, they should not care how it all works.

Of course, developers and system administrators can be users of the system, but they are unlikely to make up the majority. The end users will be copywriters, product managers, vendors, editors ... human beings (well, maybe excluding salespeople :).

Do a little research to find out how, when and why these users use the system. Talk to them, look at them, analyze. This will be useful in designing and will help you decide how to apply our advice.

5. Do not forget the real goals.

The CMS abbreviation consists of three words, one of which is much less important than the other two: S. Do not be captured by the system and do not forget about the true goals that are in managing the content and creating it. That is why users use the system!

When designing and building a system, you must take this into account in every detail. The goal of the system is not scalability, data synchronization, referential integrity or network security. All this is only a means of achieving the goal, and they must remain behind the scenes. These things should be focused techies, and all right, because it is their duty and the meaning of their existence. That is why when working on a project a sensible person is needed, who understands that the user’s work should not concern these technical aspects, and it’s about the creation and management of content.

6. Implement individual tasks really well

In the course of exploring the users of the system, you should analyze and find out what the most important tasks they perform. Prioritize, focusing on these key tasks, and implement them truly high quality. Customize the interface, automate some functions to simplify the process, whatever it may cost, but as much as possible simplify the solution of these tasks for users. Let them start solving them right from the main page.

For websites with high traffic and a large amount of content, the main task can be the formation of this content. In addition, for a very large site with tens of thousands of pages, the search for content can be a key activity. In this case, make the search truly quality, perhaps by organizing the structure of the system around the search.

7. Use real mapping where possible.

In the case of CMS, natural mapping is when the user interface imitates the action being performed. A good example is the placement of editing elements on a web page. Typically, in a CMS, this is achieved using input forms (except when using “in-place editing”). But this is not yet a natural display, since the form does not bear any similarities with the finished product. It may seem trivial to you, but regrouping the form fields on the edit page according to the same parts on the finished page will make their creation easier. Or create a visual map that illustrates how each form field is related in the real world. Or, perhaps, just creating a label for each field also makes sense :)

A good user interface reflects the mental model of the user, not the system model.

Another example is the use of thumbnails. These can be pictures when searching, in lists or when viewing properties. It is much easier to determine the content of visual attributes that will be published to the final product, when, for example, it is clear what the image looks like, what is the name of the text or the name of the page.

8. Be consistent
The user interface must be consistent from page to page, from component to component. This includes navigation, buttons, forms, text style, link style, layout, terminology, and feedback mechanisms (for example, alert windows or yellow fade technology).

This is especially important in cases where some parts have been customized, and, as a rule, differ significantly in appearance. The transfer of such "Frankenstein" in use - a reliable way to provide a system of confusion, which does not contribute to the perception and acceptance of the new system by the user. The user must feel - this is a quality product.

9. Remember Compliance

A CMS should not only be consistent on its own, but also compatible with what users are likely to expect from other similar systems. The CMS is a web application, and the standards of web sites assume the placement of a search window, the use of controls, such as a drop-down menu, and a single click on the link. While Rich Internet Applications are becoming more common, there are new standards, but this is not a reason for the initiative. The functionality may be lost due to unconventional methods of interaction (for example, using the right mouse button or double clicking on the link) and will not be obvious, since it does not meet the user's expectations.

10. Redraw the system according to specific conditions.

The principle of consistency also relates to creating a CMS that works in a manner similar to other tools and applications used by users in their standard operating environment. Integration with these tools will be very useful, whether it is to provide easy copying of content from a text editor to the CMS, or to ensure that the CMS works in standard browsers, or perhaps to create a single login for the organization so that users do not have to log in to the CMS separately.

Reshaping the CMS can also mean consistently introducing our own design and branding, with the result that users will feel “their own” for the CMS and will go a long way in accepting a new system (creating emotional investments).

This adaptation should also include the removal of unnecessary elements (recommendation 1), the simplification of the interface (recommendation 2), especially with regard to key tasks (tip 6), the simplification of the language of communication (recommendation 3). For example, if a specific goal is a CMS for an intranet portal, then the user interface should be adapted to the intranet, and not to the website, the terminology of which was inherited out of the box.

11. Create an effective start page.

The main, or start, page or administration panel for a CMS is a great tool if it is well designed and contains useful elements. Do not overload it with standard out-of-the-box elements, better think what users should see when they first log into the system.

Use this page to provide easy access to solving key tasks, in order of priority of all system capabilities, and paying particular attention to basic tasks (they should be displayed in a larger size at the top of the page, and possibly with icons). Rarely or less important functions can be displayed in a smaller size and can be located below on the page if you decide to demonstrate them all.

At the same stage, you should take care to streamline the login process. If the CMS allows you to edit several sites, but a specific user edits only one of them, do not allow him to select it from the list each time he logs on to the site.

In addition, think about abandoning the administrative panel or the main page and generally send the user directly to the most common task (if any), with the ability to go to the main page when he needs it.

12. Create quality forms.

The main data entry method in most CMS products is forms. And, as a rule, they are not very convenient. Your forms should be well designed, with a logical structure, understandable notation, proper verification and a clear call to action. As noted in recommendation 7, a form close to the final product is much easier to use and understand. Great advice on creating forms gives Luke Wroblewski - Web Form Design .

13. Involve the designer in the process.

Do not leave the user interface design to developers who create and install the system. Even if they have the necessary skills to develop the interface, they will not be able to keep in view the future development prospects, as they are too involved in the routine details when developing a CMS. Even experienced usability practitioners are difficult to keep in sight of the end users, they are too focused on the technical difficulties of creating a system.

Most companies do not think about using their graphic designers or usabilityists as a tool on the way to the final product. But they underestimate the importance of this tool, especially when it comes to a large site.

14. Do not rely on learning.

Learning to work with the system will not solve the issues of convenience. Long after the training sessions, problems will continue to arise if the interface is unintuitive and the system is complex. In the worst case, even the teachers themselves will find it difficult to explain how the system works and how to use it, as they try to bridge the gap between the technical system and the users.

Although CMS training programs make life a little easier, in my opinion, they are rarely effective. Why not just spend time and money and make the system easy to use? And then everyone will be able to use it without training sessions and the need to repeat what has been traversed.

15. Provide user assistance.

Learning will not save a poorly designed system, but you must provide user assistance. These may be instructions explaining what and how users should do. They can demonstrate the learning process through training or in the "beginner" mode, in such a way that one day the user will feel comfortable when working with CMS.

In addition to the instructions, you need help in the process of working with content and solving user problems. As with notifications and error messages, help should be helpful. It should not just contain hints about what users see on the user interface (for example, “this screen contains XYZ buttons”), but also should explain to them how to use certain functions, what to expect from them, and how to recover, if something goes wrong.

Of course, a way to reduce the need for reference materials is to develop a clear interface, in which it is obvious how to use it: high-quality shortcuts for navigation buttons, a clear visual hierarchy of pages and forms. The most advantageous position on the page or in the list is given to the most important points. The sequence in which the user must perform actions should be obvious at every step, thanks to clear accents and clear identification.

16. Think over the developer interface

In the process, you will encounter frequent objections like: "But this is useful ... for developers." And, of course, there are arguments in favor of this, because developers and other technical specialists will use the system together with ordinary users (although, perhaps, less). You can provide them with access to the use of all the system capacity that will be needed to manage the CMS and the final product, without affecting the interface of ordinary users. The appearance of the user interface may depend on its username.

17. Do not release in semi-ready mode.

Often there is a desire to do something at a minimum, and later fix it all. That is, to release the raw product, and the convenience of "take care later." It is a bad idea. Firstly, when something doesn’t work from the very beginning, your users are unlikely to experience a sense of gratitude and trust in a new CMS. Second, troubleshooting will further require users to re-learn the system. Thirdly, this “later” is unlikely to happen, moreover, if buyers have already invested money in the purchase / development of a CMS, they naturally expect the result at its best.

All this does not exclude the possibility of continuous improvement of the system, including the user interface, but it means that the CMS must be usable and convenient from the moment it is released. User needs must be taken into account when planning and developing a CMS, they should not be left at the end, otherwise you will never have enough time or resources to meet them.

Conclusion

How important is all this? As long as the instrument is working, life around it stops, right? Well no.The lack of usability will make the system difficult to master for end users, and as a result, this will lead to a decrease in CMS sales, or an increase in unauthorized use.

And these tips are just the basics, the obvious things. They can help you improve the administration of your site, but perhaps it would be better to simply choose a different, better system. Concentrate on the key things you need to do, and not be captured by features or features that you will use only once. Make sure that the projected CMS takes into account the key points described in the scenarios for product evaluation.. If you need to customize, in particular, the user interface, make sure that this happens easily and will not affect the possibility of upgrading in the future. Thus, independence should be maintained between the user interface and the system.

If something is wrong with the translation - write, if there is no account on Habré - comment here . If something is wrong - do not hurt, this is my first post on Habré.


I hope this article will be useful to you.