In the early days of web content management system (WCMS) implementations, the design of the author user interface was something that was not on the top of the priorities list. It was mainly done by a developer, without a lot of consulting with the actual content contributors. Content authoring was seen more as a technical operation, in most cases performed by the webmaster, who typically had a more technical background. The result was a user interface that lacked usability for authors with different profiles such as marketers.
Throughout the years, the WCM systems started to offer more options to create user-friendlier interfaces. The main reason for this is that the nature of the content editing process has changed. Today, content editing is no longer done by a single, technically skilled webmaster. In most companies you now find (decentralized) teams of non-technical authors, specialized in marketing content creation, who make extensive use of the system on a daily basis. It becomes clear that the user experience of the authoring back-end needs to be as optimal as the user experience of the website itself.
Nowadays we can say the success of a WCMS project is not only determined by the visitors’ experience, but also by the content authoring team’s experience. However, during the website project planning, we see that often the authors’ experience is not always taken into account. The reason for this is that people presume that well-known WCMS, such as Adobe Experience Manager (AEM) or Drupal, will automatically deliver an optimal experience out-of-the-box.
In reality, this is not necessarily the case, as different organizations, content teams and types of websites have different requirements. Of course, these WCMS offer a standard author interface with authoring tools to organize and edit the website pages, manage assets, and so on, but most web teams also require specific development for their WCMS to manage the actual content that is displayed on the webpages.
WCMS platforms allow developers to build these custom interfaces, offering a set of (technical) building blocks with different levels of flexibility. But how these building blocks are put together is not predefined, and the choices that have to be made during the creation of the author interface can appear simple, but are not so straightforward. Is a functional component, like a video, predefined on a web page or not? On which location will you manage the properties of the component? On which part(s) of the page can you add it?
This is why, just as is it for the public interface of the website, a UX definition is required for specific aspects of the author interface of the WCMS. Skipping this stage will most probably result in a poor author experience, which will also impact on how effective they address the visitors’ expectations and on the overall website success.
At ACOLAD, we believe author experience is a mandatory aspect to take into account during our analysis phase. When defining the functional specifications of each functional component on a webpage, e.g. a content banner, we always make sure that we look at it from both perspectives: on one hand, from the visitor perspective, we describe in detail how the component will be presented, how it will behave and which interactions are possible.
On the other hand, we also look at the component from the author perspective. Before implementation, the specifications of the author interface are discussed thoroughly with the project stakeholders to make sure that the author team can provide inputs and give feedback. If relevant, wireframes are created to illustrate the behavior of the WCMS interface in a clear way, just like we do for website pages. Typical topics that are addressed during these discussions are the following:
- Which properties of a functional component are required? Which can be edited by the author and which are automatically managed by the system?
- How and where will the content author manage the properties of the component?
- Which name can be used for a component in the system, so that it is trivial to understand what this component is meant for?
- Are there types of components to which we should add sample content to make it easier for the authors to do their work?
- Is the content well structured, as to allow web teams to easily re-use blocks of content?
- Do the website pages follow a strict structure, or do they allow more freedom to the authors? How many different page types are required? Usually, less options allow for greater content consistency and less risk for confusion.
Web project teams often get so focused on the end goal of the website and the visitors’ experience that the authoring experience is left on the back burner. But the truth is one of the factors determining the success of a website is the number of visitors, and this in turn depends on the success of the WCMS.
A user-friendly WCMS that’s easy and quick to learn and allows even non-technical profiles to do their work efficiently. In return, it will reduce your authors’ training costs, enable content to be updated more often, and ensure the WCMS long-term viability.