The following is a guest post by Carol Barnum, a professor at Southern Polytechnic State University.
My university recently purchased a content management system (CMS) as part of a complete redo of our website, long overdue. A content management system is supposed to simplify the process of managing content on the web. Maybe some CMS systems do, but not the one chosen for my university.
As the person responsible for managing the content on the Usability Center's website, I have been trying to rewrite the pages in my site, using the content management system. Despite two hours' training on the system and a manual to help me figure out how to do the basic functions, the process has been anything but easy, intuitive, learnable, or efficient.
Useful, usable, desirable. As these are the basic tenets of usability, it would be logical to assume that a content management system should earn high points in each of these areas. But no -- at least not the one I am forced to use.
A quick check of ratings of CMS brings up a website called TopTenReviews.
The top rated CMS systems (the one I'm using is not among them) rate the systems on the categories of
Good and important categories, all.
The site's explanation of the ease-of-use category for CMS is this:
When shopping for a CMS, whether you are a blogger, developer or designer, ease of use is probably the most desirable feature, second only to the actual publishing and performance components. If you aren't able to immediately pick up a software application and start building your site, odds are it isn't entirely user friendly. A CMS should enable both technical and non-technical users to create a truly comprehensive web presence with ease.
I like it. I just wish I liked the CMS system we are required to use. Because our CMS violates the principles of the "ease of use" category, and because this category is "the most desirable feature" of an effective CMS, I have to wonder whether the company did any usability testing on their product prior to, or even after, the launch. I can't imagine that they did, or, if they did, that they tested with "real" users like me.
You start with the cost to purchase the system, obviously. But then what?
If the cost of the product is a significant factor in the purchasing decision, and surely it must be, I wonder whether the cost of support to get the users to use the system was factored in as well.
I doubt my university took this cost into consideration. They should have, however, if my experience has been any indicator of the need for "customer support" to get me up and running.
At my university, customer support is basically one person—the university's webmaster—who offered to help me if I got stuck anywhere in the process of making the conversion.
Little did he know, or could anticipate, the number of phone calls he would receive from me, often adding up to 4 or 5 calls in a single day. And calls every day for at least a week.
He was always patient, walking me through the steps to do—or undo—the content I had created.
Often, however, the method to undo something was more problematic to explain than to just fix the problem himself. Although the goal of the webmaster was to teach us to fish, rather than supplying us with fish (you know the metaphor, I presume), in the cases of the complex problems I created in my bumbling attempt to add new content, the webmaster determined, in more than one or two instances, that it would be easier for him to fix the problem, which he viewed as a one-time issue, rather than to teach me how to undo it and redo it myself.
I couldn't have been the only person needing his help.
Learnability is a usability principle, often hard to measure if you are testing only with first time users. But it's vital to a system's usability to support learning and relearning the system so that first time users get better quickly at navigating the system and so that repeat users (especially those who don't use the system regularly) can retain their ability to use the system when they return.
As for the learnability of the system, I have to give our CMS a failing grade, or put the blame on me for failing to learn the system. Very little of what I did on one day was retained to the next day.
Because of the lack of learnability of the system, I dreaded opening up the software, as I knew I would be confused and frustrated about how to get up and going . . . every time. And if someone else had been working on my pages in the system and forgot to "check the page back in" when they signed off, then I couldn't access the page until I had contacted the other person and asked him/her to check the page back in. You would think that when you logged off the system, it would check your work back in, but that didn't happen.
After many days of "learning" the system, I was finally ready to do the last thing I wanted to do—create news and events pages. This task turned out to be the most difficult part of the process. First, creating these pages required a separate tutorial, as they were handled differently from other pages. Then, there was no easy or obvious way to create hotlinks to full stories or full articles I wanted to cite in the news/events. Then, the events page did not provide a way to include a picture, although the news page did. The list of issues is much longer, but suffice it to say that these were the least usable sections of the CMS. Yet, they are very likely to be the most frequently updated pages!
Calls to my webmaster brought a strange silence, which puzzled me, as he had been so responsive up to this point. I wouldn't blame him if he decided not to pick up the phone when he saw me calling in, but it turns out that wasn't the reason he had not called back. Rather, he and his boss had met to discuss the problem I and I'm sure many others were having with these pages. They determined that the system was not usable enough to allow for quick and easy updates on these pages. So these pages were put on hold (!) until a better system could be located and, I presume, purchased.
For starters, no one asked the UX or content management folks at our university to review these systems and make recommendations. An expert review would have gone a long way to uncovering potential show-stopper problems. Usability testing with some target users would have exposed even more.
Now, with the site launch date pushed back, we may have to launch the site with incomplete information regarding news and events and no easy way to update this most time-sensitive information.
If I have learned by doing, it's a lesson I hope will not have to be repeated by others getting ready to adopt a content management system.
As technical communicators and information designers, we may "own the content," but if we don't have a major stake in the decision of which content management system to adopt for our work, we may end up being "owned" by the system.
Fittingly, the TopTenReviews website ends its description of its reviews of the top CMS this way:
Our trademark side-by-side comparison can only compare the types of features offered by each CMS, but it doesn't really address the power or usability of those features. It is in this way that each of these systems distinguishes itself from another. Ratings and check marks fail to really capture the full worth of any CMS; only each specific user can determine which is the "best" CMS. Every one of the systems reviewed here has a demo version that gives a more accurate picture of its capabilities.
Although I agree that the usability of the features of a system is best determined by users, I do not agree that this has to be done for "each specific user." A quick study of five users in a particular subset of the user population will expose enough overlapping issues to identify quickly and easily whether users deem the system useful, usable, and most of all satisfying.
Carol Barnum is director of graduate studies in Information Design and Communication at Southern Polytechnic and director of the usability center. Her latest book is Usability Testing Essentials: Ready, Set…Test! (Morgan Kaufmann, 2011).
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.