Usability has moved to the forefront in the past few years, especially for corporate Web sites, as marketing managers seek to understand and measure whether their investments in Web communications are really paying off. Now that Web-based applications have proliferated, enterprises are beginning to look more closely at application usability in general and the usability of content management systems in particular.
Much of the impetus for examining CMS usability has come from systems users themselves. In conference rooms around the world, authors are standing up and declaring, "Our CMS tool sucks!" Many CMS vendors have noted this user backlash and now fall over themselves to tout products as "intuitive," "adaptive," or just plain "easy to use." But what does "intuitive" really mean? If markets are conversations, this interchange between CMS suppliers and users still remains quite muddled, even as it gets louder. I think it's important to tune into the growing volume, though, because when discussing CMS usability, at some level we're really asking, "does the system actually work?" In an age of strict justifications for IT projects, that is an essential question to answer.
In this first of two articles, I'll offer a general introduction to the problem of CMS usability with a particular focus on contributor interfaces. Part two will look at usability in the context of specific features, including classification, workflow, search, help, and other subsystems. The articles will examine usability through the lens of Web content management systems, but the themes should generally be applicable for managing content of all kinds.
What is Usability?
"In its simplest form, usability is absence of frustration," explains Jared Spool, founding principal of User Interface Engineering. "When people claim something is not usable, what they're finding is that they're frustrated because something is harder than it should be."
So, what does it mean to be not hard? According to Dana Hallman, a content management specialist at the U.S. Department of the Treasury, usable means "I should be able to open up the screen and know where to get started and how to put content into the system without going through a three-day training class." This vision is rarely realized, in part because vendors and the licensee's developers often don't understand how intimidating a content management interface can be. "People may be used to navigating Web sites, but a CMS presents a whole new set of buttons, labels, and tabs, and people underestimate how unfamiliar it all is," Hallman adds.
Indeed, CMS vendors incur most of the blame for unusable systems. Vendors in a still immature marketplace attempt to compete primarily on features. James Robertson, managing director of consultancy Step Two Designs in Sydney Australia, argues there is an inherent conflict between capability and usability. He began to notice this when vendors that demonstrated their products while logged in as "superusers" got lower marks for usability by prospective buyers. "More power means more complexity," says Robertson, "so each feature inherently reduces the usability of a product."
There is historical evidence that simpler software products tend to win in the long run. "All great products figure out what big compromises to make," notes Spool. Today, however, major CMS suppliers tend to be reluctant to box themselves (and their salesforces) in for fear of being labeled "niche" vendors, a moniker most analysts ascribe to smaller, privately-held players. For example, Stellent (formerly "Intranet Solutions") has been very successful with intranet use-cases, and a substantial majority of its CMS implementation fall into that category; however, you will be hard-pressed to see the company admit—let alone advertise—its success there for fear of being perceived as less-than-capable for public Web site projects.
It is one thing for vendors to focus on particular use-cases, but quite another for buyers to know what will constitute a usable system, especially since usability can be highly situational. Not surprisingly, the key is to engage users in the exploration.
"Vendors look at features, but authors come at content management from a task basis," argues Ulyssa MacMillan, CMS product manager in BBC Online's "Content Management Culture Group." The concept of "culture" got injected into the new media group after the network had experienced two major failures implementing an enterprisewide CMS (before its current project) precisely because it had failed to adequately take into account the culture of the organization and end-user needs. As they work to roll out a new CMS to some of BBC's nearly 700 Web sites, MacMillan's team has taken a rigorously user-centered design ("UCD") approach to implementations. "If you don't truly understand and support users' work, you won't achieve your business goals, because users won't adopt the system," says MacMillan.
User-centered design means more than working on graphical interfaces. A UCD approach says that everyone working on the project should understand the needs of users and feed those back into all design decisions, including technical design. A UCD process should ultimately define who the users are ("personas") and then capture work patterns and how they would use a CMS ("scenarios"). UCD is "not an occupation, but an approach," says Steve Krug, a usability consultant and author of Don't Make Me Think, "so I encourage people to go ahead and practice it without a license."
The key is to watch people actually employing the system. "If you think you know how other people think, you're probably wrong," counsels Krug. This implies avoiding hard and fast rules. "People designing applications are looking for rules, but practitioners know that it is situational: you could install the right widget, but if it's not prominent enough, it won't work."
I believe it is this situational dimension that leads more than anything else to mismatched product selections. Authors often "feel" that something works or not, without necessarily being able to articulate exactly why. This puts substantial pressure on CMS suppliers, particularly if you agree with Step Two's Robertson, who argues, "A CMS should just work in a way that makes sense, out of the box." The question is: make sense for whom?
Distributed Publishing Pipe Dream?
Maybe the way out of the situational dilemma and the way to improve conversations between vendors and users is to focus on common personas and scenarios that might be broadly applicable. One convention the industry has adopted is a distinction between "power users" and "casual contributors." Many CMS vendors offer separate interfaces for these two groups.
This distinction can become immediately problematic. Is a power user an author who needs an efficient interface to accomplish the same thing repeatedly and often, or a kind of managing editor, who needs a control panel to accomplish a variety of oversight tasks such as moving pages and sections or administering taxonomies? Those are two very different personas who will likely find comfort in very different interfaces.
It may be a bit easier to typecast a casual contributor. This class of authors predominates in large, distributed enterprises. CMS vendor Day Software caters to large multinational organizations, which often use highly distributed publishing models featuring infrequent CMS users. It has to be easy for them, according to Day CTO David Neuscheler, because "every hour of training needs to be replicated hundreds of times."
Casual contributors almost always like in-context editing screens, where they can browse to a page, and (with proper permissions), simply start editing the content. There are usability issues here, as well. A potential problem arises when—for one of many common technical reasons—the edit screen in the CMS does not faithfully represent the look and feel of a published page in a delivery environment. In-context editing in high content re-use scenarios also forces designers to deal with the thorny problem of enabling easy preview of multiple downstream derivative pages when an author changes a content item that is widely reused.
Martin White, EContent contributing editor and managing director of consultancy Intranet Focus, finds the power users vs. casual contributor split too simplistic for enterprises that often employ a broad spectrum of CMS users. "Eighty percent of content may be entered by 20% of the users," notes White, "but that 80% may not be the most important content." He cites the case of an author whose sole job is to hand-craft the Web version of a detailed annual report on a tight deadline. "It requires quite a bit of thinking about how to put together an entire subsite, but only once a year," White adds.
In general, though, vendors tend to equate "easy" with WYSIWYG tools. That's why nearly all CMS products come with a WYSIWYG widget for rich text editing in a browser. The idea is to replicate a familiar word-processing environment, and of course familiar is good. In practice, though, these widgets can bring substantial usability hurdles. First of all, no matter how much it looks like a word processor, editing content in a browser presents a brand new interface for authors, with its own rhythms and rules. Also, nearly all rich text editors in the market today have major accessibility problems, although vendors are beginning to work to resolve them.