Usability principles for CMS

    I have never heard that our (read: shovels) vendors of boxed CMS ordered usability testing of their products. There are two main conclusions:
    1. Usability of these systems and so on top! Each company has its own usability specialists who take part in development at all stages of product development - organize testing, give recommendations, expert evaluation, etc. In this case, it is UDD - User-Driven Development.
    2. Usability of these systems in an adult way sucks. Programmers make functionality. Designers make the design. Marketing makes sales. The programmer is thinking about eclipse. The designer is thinking 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, so I find it useful to make everyone familiar with the publication of “ 11 usability principles for CMS products ” by James Robertson. Next, let me give you a free retelling of the list of eleven CMS usability principles that James highlights with my comments.
    1. 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 interface of the system should be minimal.
    2. Reliability and error handling. The system must always ensure the safety of the data with which the user works. An example is the auto-save function. “Error handling” implies 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 fix the error, we need to fix it automatically, and not pull the user).
    3. Task oriented interface. The logic of the interface should not come from how the system works, and how it is arranged inside, but from how the user works with it - from his daily tasks. Developers often strive to do everything "elegantly" when many tasks are solved with the same set of tools. The problem is that the journalist of the electronic publication is completely violet with the business logic of your ingeniously designed CMS. He didn’t give a damn about the “module”, “information block” and “object” - he should submit the article to him by twelve.
    4. Concealment of implementation details. In the previous paragraph 3, we abandoned the metaphors from the system architecture. It remains to get rid of the implementation details - no HTML, JPEG, XML and other technical subtleties and broadness. There are pages and folders - no files, directories and databases with indexes.
    5. Intuitive interface. The user must understand what he is working with now, what he has done and what he can do with it. The system interface should be holistic and logically thought out. Placing Heidegger's works in 8pt is also not recommended. Text and signatures should be clear and unambiguous.
    6. Compliance with mental models of users. In most cases, people think in a stereotyped way, because any mental activity is an energy-consuming thing. Why impose new concepts, schemes and work scenarios when there are already proven “folder”, “page” and “basket”. In one sentence, this principle was radically formulated by Steven Krug: “Don’t make me think”.
    7. Convenience for both beginners and experienced users. For beginners - tips and visualization, for experienced users - hotkeys, shortcuts and other means of increasing work efficiency up to a specialized interface.
    8. Efficiency in the design of the interface. The web interface has traditionally been less efficient due to its slowness and asynchrony. Now web-two-zero-yo-style interfaces are already approaching regular applications in terms of efficiency. Efficiency consists of a minimum of movements, clicks and transitions between the “screens” to achieve the result. Forms and controls should be logically grouped, and not scattered on pages and tabs. Another important point is the actual speed of the system. Even if the server application is thought for a long time, this does not mean that the client interface should freeze in the same way.
    9. Help and tips 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 adding 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 training period for working with the system. If you follow all the above principles, then the entry threshold for CMS can be significantly reduced. End users rarely dream of sitting down again. Moreover, the developer of boxed CMS is not an integrator. He does not earn on training end users, but on training developers.
    11. System self-sufficiency. 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 adjusting and optimizing images before publishing. It is really convenient.

    Also popular now: