Principles of usability for CMS

I have never heard that our (read: soviet) boxed CMS vendors ordered usability testing of their products. This suggests two main conclusions:

1. Usability of these systems and so on top! Each company has its own usability specialists who take part in the development at all stages of product development - organize testing, give recommendations, peer review, etc. In this case, it is UDD - User-Driven Development.
2. Usability of these systems in adult sucks. Programmers make the functionality. Designers make design. Marketing makes sales. The programmer thinks about the eclipse. The designer thinks about Photoshop. Marketer thinks about powerpoint. Well, the end user periodically thinks about all three at once - about their intelligence, sexual orientation and the place of growth of their forelimbs. This is the AUDD methodology - Anti-User-Driven Development or Angry User Driven Development.

If you know companies that work according to the first scheme, then let me know. I have seen enough of the guys doing everything according to the second scheme, therefore I find the publication “ 11 usability principles for CMS products ” written by James Robertson to be useful for everyone to read. Next, let me give a free retelling of the list of the eleven principles of CMS usability, which highlights James, with my comments.

1. The minimum required number of displayed options. The screen should contain only those elements that the user may need here and now to complete the task. The number of elements common to the entire system interface should be minimal.
2. Reliability and error handling. The system must always ensure the safety of data with which the user works. An example is the auto-save function. “Error handling” means not only the clarity of the error message and how to fix it, but also the general tolerance of the system to user errors (if we know how to correct the error, then we need to fix it automatically, and not pull the user).
3. Task oriented interface. The interface logic should come not from how the system works, and how it is arranged inside, but from how the user works with it - from its everyday tasks. Developers often strive to do everything “elegantly” when many tasks are solved by the same set of tools. The problem is that the business journalist of your ingeniously designed CMS is completely violet to an electronic journalist. He wanted to spit on the "module", "information block" and "object" - he would pass the article to twelve.
4. Concealment of implementation details. In the previous paragraph 3, we abandoned the metaphors of the system architecture. It remains to get rid of the details of the implementation - no HTML, JPEG, XML and other technical subtleties and widths. There are pages and daddies - no files, directories and databases with indexes.
5. Visual interface. The user must understand what he is working with now, what he has done and what he can still do about it. The system interface must be complete and coherent. Placing works by Heidegger in 8pt font is also not recommended. Text and signatures must be intelligible and unambiguous.
6. Compliance with mental models of users. In most cases, people think out of patterns, because any mental activity is an energy-consuming thing. Why impose new concepts, schemes and scenarios of work, when there is already a proven "folder", "page" and "basket". In one sentence, this principle was radically formulated by Stephen Krug (Steven Krug): “Don't make me think”.
7. Convenience for both beginners and advanced users. Beginners - tips and clarity, experienced users - hot keys, shortcuts and other means of improving work efficiency up to a specialized interface.
8. Efficiency in interface design. The web interface has traditionally been less efficient due to its slowness and asynchrony. Now, web-style two-null-yo interfaces are already close in efficiency to normal applications. Efficiency consists of a minimum of movements, clicks and transitions between the “screens” to achieve a result. Forms and controls should be logically grouped, and not scattered across pages and tabs. Another important point is the actual speed of the system. Even if the server application thinks for a long time, this does not mean that the client interface should hang in the same way.
9. Help and hints in the interface. Of course, we need documentation (with full-text search!) And training materials (video!). Understanding even a very complex interface can be greatly facilitated by the addition of context-sensitive help. The ability to learn all about the interface element of interest with one click at the same time eliminates the need for all other reference materials.
10. The minimum period of training to work with the system. If you follow all the principles mentioned above, the threshold of entry for a CMS can be significantly reduced. End users rarely dream of sitting back at the desk. Moreover, the developer of a boxed CMS is not an integrator. He earns not on the training of end users, but on the training of developers.
11. Self-sufficiency of the system. Standard tasks should be performed without using any external applications or services. A commonplace example is the generation of previews for photos. Some CMS already have built-in “graphic editors” for correcting and optimizing images before publishing. It is really convenient.