The usability of many traditional CMSs is poor. Some systems are even inoperable from the user’s point of view. This starts a downward spiral: The more difficult it is to use the CMS, the less it is actually used, quickly leading to outdated content on the websites. Intermittent use lets users get out of practice. Time-consuming and cost-intensive training is unhelpful if the user only occasionally works with the CMS or if its complexity requires insider knowledge that is often poorly documented, if at all.
Why is this so? The idea of a hierarchical site structure borrowed from the file system, together with data storage in relational databases means that content is edited using form fields with magic markup acronyms at hidden places in a deep content hierarchy. Once done, it often requires a separate step of previewing to get an idea of how the content will look on a staging server, often with no possibility to understand how the content will be displayed on other channels such as mobile devices. When more than one editor is working on the content or a relaunch is planned, error-prone coordination often has to be done using traditional means, i.e. by sending emails with attached Word documents and notifications, or by declaring complete sections as “frozen” for other editors. Sometimes, it requires separate staging servers for larger relaunches. This way of working with a CMS often hinders more than it helps.
To exaggerate only slightly, classic CMSs seem to be in two basic categories: Systems loved by developers and systems loved by users. While developers focus on the options to create and enhance internal integrations and the back end, users want the front end to be intuitive and versatile. The ease-of-use requirements of the editors, who are actually using the system and creating value by creating content, often fall short and are addressed very late in the project, if at all.
But focusing on just one of these categories creates alignment issues and communication trouble between the business side and the technical staff. Both are of equal value because both are success factors. To show how technology and users contribute to project success, a hierarchy of demands can be applied to a web application as well.