A common misunderstanding is that a CMS could be so simple and intuitive to use that training and support for editors wouldn't be necessary. This is probably the reason why, in most projects where clients look to upgrade or replace a tool for publishing information to the internet, "usability" and "ease of use" often are mentioned as important. At the same time, , many information and web managers with a decentralised editor organisation experience that there is a high and constant demand for training and retraining appointed editors without feeling that this training has the desired effect on the final experience of the end user.
To improve, we need to be able to specify what we mean by terms like "ease of use" and at the same time adjust the training offered to content editors. This requires an understanding of your editors' needs and a way to describe it in relation to the tools available.
The editor resource should be monitored and evaluated just as your publishing tool. The changing profiles, backgrounds and how frequently your editors use your WCM-tools influences how you should plan for system upgrades, improvements and training packages.
My model for describing the needs of content contributors needs has been developed based on my work as a vendor neutral CMS-consultant and a facilitator in J. Boyes community of practice where I have discussed it in workshops with more than 40 web project managers, information managers and editors.
The underlying principles are:
1. Focus on your core content contributors. When complaints of your current solution or wishes for a new one comes in the relevance of these should be decided based on whether they represent a group of editors who are important to the content or not.
2. Don't underestimate your need for super-user functionality. Features such as "in site editing" and "drag and drop" are all very good. But make sure super users can work efficiently in the tools too, especially if you rely on them to review content and trouble shoot.
3. Make editors focus on content before you introduce the tool. Learning to use a WCMS or other tool is always easier if you know what you are communicating. Making editors think about their content before you bring them to a training session is always worth while.
Welcome everybody. It’s great to see that some of you are still around here on the last day of the conference. My name is Peter Sejersen, I come from Denmark and as you can hear I’m not a native English speaker, so please interrupt if you don’t understand what I’m saying. I am going to talk about “Why usability in a CMS is overrated”. What I’m saying is based on the vendor-neutral consulting and research we have done in J. Boye (for exaple this report “Best practices for selecting a CMS” and not least listening in our large European community of practice. Our Community of practice is where online professionals can meet each other and share experiences in a confidential setting with us as moderators. So what I’m going to share here today is mainly based on what I have heard from actual frustrated CMS users. Abstract: http://www.online-information.co.uk/online09/seminar_description_online.html?presentation_id=765
There are still many ways to do content management and most systems are good for at least one organisation. There is no overall best CMS! Instead there are many good systems which are good for certain organisations and scenarios. It is still a very immature market and there are very few standards in the industry, which makes it hard to compare systems. Another basis condition is that organisations usually only know one solution intimately… the one they are currently using! Add to this that vendors have difficulties keeping their focus on their users. They are generally more interested in developing new functionality. Together, all these things mean that it can be very hard for organisations to not only select a new CMS but also assess the quality of the one they are currently using. Image credits: http://www.flickr.com/photos/8136496@N05/2327243497/
So when organisations say they want a system that is easy to use, they first need to consider whom they are targeting! As the quotes here illustrate you can see that the first one is targeted toward the internal developers. For some organisations, the most important thing is that is should be easy to customise and develop for the system. Others have a frequent turnover of their editors meaning that the system should be intuitive and easy to use for them. And some organisations have the impression that it is not necessary to focus on the super users, as they will learn to use the system no matter what. On the other hand, if you only have 5 super-frequent users, you probably want to focus more on the super user functionality. So usability can mean many things Image credits: http://www.flickr.com/photos/mukumbura/4043364183/
Another problem is that many organisations see technology as a cure in itself. They experience problems with their web content and look for ways to control these problems, as these quotes illustrate. Many want functionalities like: Link-checkers, Search and Replace on all pages, built-in image editing. All of these are available in some systems, but maybe it’s not the systems that is to blame poor content? Actually all these things can also be achieved by having a solid content strategy in place and by having an aligned behaviour among your editors. I think these wishes reflect a need to control the organisation rather than the technology and the web site. Technology is easier to control than an organisation. And it is typically other things that the technology that gives a good user experience. So fixing the technology will only get you so far… Image credits: http://www.flickr.com/photos/59334544@N00/2322167178/
And no matter how good the technology is, there is a big difference between what you want and what you often get. What organisations want is alignment and consistency - What they often get is a lot of individual creativity at best, and in the worst cases they get ugly content and editors who are not making an effort. So the real challenge is to find a way to overcome this gap.
First it is very important to define what you want to achieve with the website. If this is not clear, your editors will be wandering in the dark, without having a clear idea of what the should aim for. This is very basic, but it is also very important to remember.
Secondly you should look at the raw material you have in form of your website editors, here illustrated by a flock of sheep. This is where all the complaints and good advice will be coming from, so you want to listen to what they have to say. It can actually be a good idea to sit down with them and evaluate their current work and communicate what can be done better and ask them what they see as being the problem.
When doing this you should take a step back consider why you need to improve the tool. By talking to the editors, you get an overview of who are actually complaining, and put the complaints in relation to the quality and amount of work they are doing. You also want to know how frequently they use the system. With this in place you can try and see whether it is bad usability, a lack of support, poor governance or something completely different that is causing the problems. And this is where many organisations actually find that usability really isn’t that big a problem.
So having collected all this data from your editors you still need to know whom you should listen to if you are buying a new system, and want to define some key requirements. This can be a difficult task, so in order to get an overview, we have developed a model.
You can use this model to plot in your users and see where you should focus your efforts. The vertical line represents how good their technical and communication skills are. The horizontal line represents how frequent they use the system. As an example, some organisations have many editors in area one. These editors usually have no organisational credit, there is a high turnover, the content they produce is of bad quality and they require much support. In the other end of the graph you have the good communicators with good technical skills. These often have organisational support and produce great content. And will probably do it no matter how poor the system at hand is. Another case could be that you have few great communicators who are not that frequent users. This was the case for one of the members of our community of practice and they solved it by letting these users produce their content in word and then mail it to a super user who then published it. In this way the model can be very useful, and I will know talk of 3 specific use cases.
First of all the model can help you map out which needs your editors have. For example: - If you have many in area 1, you might need to offer some more training in both the technical things and how to communicate. If you have many with good communication skills, but with poor technical skills you might want to make better support options - Another scenario could be that you have many editors who are great at both things who frequently use the system. These might be better of with less constraints, like simplifying the workflow or expanding their editing options.
Secondly, you can use it to understand the governance structure behind your editors. Ask why they are editors in the first place? Is it something they do because they like it or is it an annoying extra burden? This has much to do with whom they report to and whether their work is actually appreciated by their managers. Again, if you have many in area 1, you’ll probably find that they have little organisational power and that you will have difficulties communicating editorial standards to them, simply because it is not important to them or their managers.
Thirdly you can use the model to prioritise. - You can see whether it would actually be best to reassign some of the editors, or simply remove them. Do you really want 100 local editors who rarely publish content and when they do the quality is poor? - Maybe some of the good editors can even be assigned to helping the others or reviewing their content if it is not the case already. You can also see where you should focus your fire. If you are looking for a new system and have many in segment 1, you don’t want to spend too much time looking for systems optimised for super-users.
So, having said all this I also have some examples of findings about the editros herad in our community of practice. (Say something to each bullet)
So when you a looking for a new CMS or looking to upgrading your current solution, you can use this model to get an overview of what you actually need. You can find out what the cost of your current editor demographic is and this can help you plan for the full package, not just the tool. It can also help think about if you have the right training offer in place and have an organisation that understands the end goal of your online presence? Are there any minimum requirements for someone to get access and training to the tool? It can also help you to map out the total-cost-of-ownership for the system, and maybe even give you a bigger piece of the budget. With an overview in hand you can also rule out the opinions of those who shouldn’t be working on your web site anyway.
Then you can begin to invest in usability too: - When you know the product and editors well - When a governance model and standards for content management are well established in the organisation - After a clear decision has been made about who the important users of the tools are Image credits: http://www.flickr.com/photos/inoxkrow/150080109/
So when you start to invest in usability according to your editor demographics and organisational requirements, here are some general principles you can be inspired by. The list comes from James Robertson from Step Two Designs The problem with these principles is of course that they mean different things in different places. Efficiency and mental models differ, so you really should do you homework and relate all the points to the graph you have mapped out. – Source: http://www.steptwo.com.au/columntwo/11-usability-principles-for-cms-products/ Image credits: http://www.flickr.com/photos/liberato/2292651755/
And finally a few more suggestions before I wrap up: Editors will have to work within or around the limitations of the system. Again: There is no perfect system, so maybe the resources will be better spent on training or on providing effective support. And the more you change the system the harder it will be to upgrade to a new version. - And finally: Creating web content is complex, but in general good communicators are better editors just like IT-savvy editors are better editors. If you can combine the two you usually get a great editor.