It’s hard to talk about usability features of content management systems because of a few factors, the big one being that so many of them aren’t used out-of-the-box – they’re customized to meet client requirements. It’s a little like going to an architect and having them build a house. You may look at basic floor plans, but the final house gets built based on many individual factors having to do with the lay of the land you’re building on, what you’ve told the architect about your family and its requirements, and so on. Theoretically, final product should be usable because it should be to your specification, but as we know, situations aren’t always that simple or easy. But, just as we worry about the usability of the products and services we provide to our own customers, we should be concerned with the usability of the systems we bring into our organization. After all, these are the tools that our teams will have to work with (or endure) for years to come. For communicators and other content developers, the keyboard is like a paintbrush, and the tool the canvas used to fix the words and images into place as part of the bigger picture. When writers, for instance, knows a tool extremely well, they can devote 90% of their cognitive load to writing, and the other 10% works in the background at the task processing – keystrokes, pointing and clicking, dragging and dropping, without them really being aware of what commands are being invoked, because it’s so mundane. When a new system is implemented, during the adjustment period, the world changes. For the initial period, a large proportion of brain power now becomes devoted to the task processing, as the writers have to remember both the new business processes, the new paradigm within the application, and the new keystroke combinations that go with them. This reduces the amount of cognitive load left for the higher-level thought processing. Instead of the previous 90:10 ratio, it could drop to 20:80 the first week, 25:75 the second week, 50:50 the third week, and so on, until the writers feel comfortable with the new system and have internalized the new system. The speed with which staff can return to a 90:10 is critical to their feeling of well being, and that depends on how usable the system is – system, not product, which I will explain in the next paragraph. The more usable the system, the less resistance to adoption; the less resistance to adoption, the higher the acceptance rate. To understand tools usability, understand system usability A CMS implementation is not simply the implementation of a tool; it is the implementation of a system (a group of independent but interrelated elements comprising a unified whole) that includes process control and change management, which is then enabled by a sophisticated tool called a CMS. In any CMS implementation, the goal is to achieve some business goal (such as get to market faster or meet regulatory requirements) by improving processes. So to the logical start to making the tool more usable is making the processes more usable. If that doesn’t make sense, read on. Human nature is such that we take the path of least resistance. If a process is complicated and cumbersome, and there is an easier, more efficient way or doing something – even if it only seems that way – people will find many ways to work around the official way of getting something done. Therefore, to get usability of a tool, you need usable processes. This means paying meticulous attention to the processes you intend to implement. Numerous systemic changes will need to be addressed within the organization, which you’ll no doubt discover as soon as you start changing processes, and these end up taking as much or more time than anything else in a project. Just as you wouldn’t begin constructing a building without extensive planning and ongoing discussions about how the project is going, you wouldn’t simply jump into buying and implementing a corporate tool that could have critical-path implications without going through the steps of due diligence such a project deserves. As well, the process changes are likely to create changes to roles and responsibilities, which will change the dynamic within the department or between departments. Recent surveys have also shown that roughly 25% of communicators have a hard time transitioning to structured content. This doesn’t necessarily mean that these people become redundant to an organization, but it does mean that a skills re-assessment should be undertaken by a professional who can help with the department re-organization that plays to staff strengths in the new reality. Once your have the process changes and the change management issues under control, only then, should you be looking at software, because once you’ve worked on your processes and change management issues, you’ll come to table armed with the use cases, IT requirements, and corporate requirements that you need to be able to explain to the vendor what you need their software to do. Also, because you’ll be clear in your mind about your requirements, you’ll be less distracted in figuring out what features you want to see, and you can then focus on how the vendor delivers those features, and determine whether the usability of their tool will work for your organization once the vendor has done the customizations. (Vendors will love you for this, as well.) It’s important to ask the “how” question because every vendor thinks their product is “intuitive” and “robust” and all those words that have relative definitions. What you need to take responsibility for is understanding how key features work so that you can determine whether they are suitable for your particular organization. All three factors - process control, change management, and CM tools – must be present to make the system usable, and these factors must work together to make the system effective and ensure timely user adoption.