Workflow presents another area for usability challenges. Oftentimes, the submission of a content item will "trigger" a workflow, but from there, things can get perplexing for both author and editor. Harried editors frequently complain about interfaces that don't allow them to see what content has been previously modified and by whom, or screens that force them to add comments to description boxes rather than referencing a paragraph in-line. "Senior managers don't have the time or patience to learn clever little tricks," notes Martin White of consultancy Intranet Focus.
A traditionally important part of workflow is messaging—letting users know via email that something has happened or a content item is waiting on them. This looks neat in a demo, but in practice it can lead to a maddening clogging of your inbox with messages whose subjects make little sense. One emerging practice is to make message subjects and CMS taskbox headings as informative and verbose as necessary to allow editors to properly triage their queue. FirstGov's Godwin got a lot happier when her CMS was reconfigured to send only one email message per content item per day, even as that item was modified multiple times by various members of her editorial teams.
CMS users also frequently decry workflow subsystems that mandate steps they don't need or don't understand. Very large implementations are rife with user shortcuts to evade official workflow that doesn't make sense to them. Sometimes contributors print and route content offline. Other times they log in as someone else to complete a task.
Indeed, the whole concept of workflow for basic document and Web content management is coming under serious reconsideration. Many enterprises believe workflow will bring order and compliance to chaos. This may be true for workaday forms processing by clerical staff, but content publishing by knowledge workers tends to be a much more ad hoc, intuitive, and oft-changing activity that is difficult if not impossible to capture completely in a static model.
James Robertson, managing director of Australian consultancy StepTwo Designs points out that "[n]ot every organization runs like a factory floor. Many organizations are much messier, where changes in one place can have dramatic changes downstream." Robertson argues that successful organizations are more adaptive and experiment with processes a lot more than outsiders realize. Therefore he recommends implementing only the most basic workflow capabilities at first and avoiding substantial customization until such time that a consensus emerges among the participants about how they want to work together in an online system.
CMS vendors are adapting by allowing for more ad hoc and collaborative workflow steps, but like so much else, it's really an implementation issue. For one content type—say "case studies"—you may need a strict approval workflow, but what about the rest of your information? It may be crafted through a series of ad hoc steps, where final publishing capability rests with any individual on the team who judges the material ready. Or another rule could be: three of my peers need to sign off on content item, except for some random cases, where only two of them do. Empowered contributors often seem to just "know" what to do, and therefore find maddeningly unusable a workflow system that tries but inevitably fails to emulate their varied work patterns.
Given the potential complexity of using a CMS, the "Help" function would seemingly comprise one of the most useful features of a CMS. In reality, however, Help is rarely used. "In general, help routines are not terribly helpful," according to White, of Intranet Focus. "They tend to be generic text illustrations and difficult to customize."
Some vendors have focused more effort here than others. Some CMS product "help links" send users to remote and poorly-navigable support Web sites while others simply pop up generic PDF user manuals. An emerging standard now is to provide in-context Help with editable screens, sometimes including Wiki-like author contributions in real time.
Nevertheless, most Help systems still sit unmodified. Says White, "Enterprises don't realize the effort that's evolved in customizing help text—it requires good feedback between developers and content team as well as remembering that most problems crop up three or four months after implementation."
Most usability gurus see the entire idea of "Help" as a failure in initial design. If users need assistance, there is something fundamentally wrong with the system. Steve Krug's mantra (and book title) "don't make me think" certainly applies here. At FirstGov, authors don't use the product Help screens. Instead, says Godwin, "We have Russell's phone number," echoing many the editor who relies on an agreeable engineer to refresh their memory regarding system arcana. Remember, though, that Russell is a costly and potentially transient resource. Wouldn't it be cheaper to just make the system more usable in the first place?
By now you've probably concluded that making a content management system truly usable is hard. Like so much in the content management world, usability is better understood as a verb than a noun: it takes ongoing work to make a CMS usable for contributors. Just remember that more usable means more effective. In the meantime, here are some final pieces of advice:
Adopt "user-centered design" (UCD) approaches. Recognize that usability of your CMS may depend far more on your implementation than may the particular vendor you select. That's a good thing; you can control your implementation. The sooner users can see and touch real application screens, the sooner they can show you how much you didn't understand what they really needed.
The corollary to UCD is that usability no longer becomes strictly IT's problem. Hartman goes so far as to say, "Editors pull out of projects prematurely and are themselves to blame—they leave it up to IT, who run out of time and budget—and no one takes it seriously until complaints roll in. . . ." Authors need to step up and engage early and often in any CMS project if they want a usable system.
Make it easier for users. "With a CMS you have an organization trying to impose control, and people don't react well to that," argues Steve Krug. Therefore, if you want broad adoption, make sure that any system you put in place creates less work for people rather than more.
Learn from your peers. You can make a more usable CMS for your company by starting to talk about it with people outside your company. But with mainstream outlets focused on Web site usability, don't expect a surfeit of venues to discuss CMS usability. "There's no discussion in the commercial marketplace about this stuff," argues StepTwo's Robertson. "The problem is, people do CMS procurements only once, so lessons get learned all over from scratch." Robertson thinks "CM Professionals," the new professional association for content management practitioners, could provide a good venue for discussing usability lessons. I agree.
You can't "view source" on another content management application, but increasingly you can talk to other engineers, designers, and editors on the topic of usability. Slowly a discussion is emerging. For users' sake, tap into it.
Companies Featured in This Article
BBC Online www.bbc.co.uk
CrownPeak Software www.crownpeak.com
Day Software www.day.com
Other Featured Resources
Matthew Clapp www.nautis.com
CM Professionals www.cmprofessionals.com
Erik Hartman www.hartman-communicatie.nl
Intranet Focus www.intranetfocus.co.uk
Steve Krug www.sensible.com
StepTwo Designs, Pty. www.steptwo.com.au
User Interface Engineering www.uie.com