Firstly, with devolved authorship, I want to point out that I think it is a good idea in principle. The theory behind it is sound - the people who work in a service tend to have the best knowledge of the service and should be able to update information accordingly. However, this is also the biggest hindrance when it comes to devolved authorship.
Service staff are embedded with the jargon and structure of a service. It's what they use day in day out. No matter how many times you mention plain English, web writing guidance, page tree structure or anything else to do with the way you want information to appear, they will always fall back onto what they know (with few exceptions).
This ultimately makes life difficult for any comms team who have to manage this.
I don't have definitive answers on what should be done to correct this, if I did I would be earning a fair bit more than I do now.
Who should update the site?
There is often a gut reaction to this question by going straight for devolved authorship. Build up a network of web authors who are responsible for their own little bit of the site.
If using this approach, you are putting your fate in the hands of people picking their own who you then have to train and guide through the process of adding content. Sometimes it comes up trumps and you get someone who has a knowledge of the web, or who picks up on the principles quickly and is eager to learn.
At other times this is not the case. You find people uninterested, almost hostile, at being given this new work to do as well as their "normal" job. If your editors are not engaged with the project and what you want to achieve then it can only fail.
An alternative is to have a team who's job is to update content all day, every day, based on requests from services. This is safer, as you have a dedicated team who know the place inside out, are clued up on editing, plain English and corporate style and can drive the site content exactly how they want.
Knowledge and boredom are the two key issues with this approach. Updating content all day, every day with no time devoted to development and improvement means that editors can quickly become bored and lazy - leading to mistakes. Secondly, corporate editors may have knowledge of updating websites, but not of the services they are writing about. Which could lead to gaps in information.
A third option is one we have discussed here (thanks to Mark) but I don't know if anyone has adopted this approach. Has anyone considered using customer services staff to update the website? They speak to people all the time, know the information people ask for, know how to answer questions. They are a valuable communications tool with a good "general" knowledge of the organisation.
Who is in charge?
A corporate web editing team is always needed in my opinion (not just to justify my existence). No matter who updates the information, someone has to police it. Having to "approve" all updates to the site I think is a reasonable mid point between doing it all yourself and letting everyone go crazy on their own.
You can send inadequate information back, fix minor errors where necessary and act as the go to point for people with questions. A team dedicated the the site will have a good knowledge of what is on the site (especially useful when the site is huge) and how it works (cms, plug ins, form building etc)
How many editors should we have?
This is dependant on the size of the corporate team managing them. The bigger the web team, the more editors they can handle. I'd ideally say that 2-3 per major service (recycling, housing etc) would be plenty. This is just my opinion though and it could be wrong.
I would rather have a few editors willing to learn, work and that can be trusted than hundreds who update less often and make mistakes.
Repetition
This is always a problem with devolved authorship. There can be an overlap of information (housing - benefits - council tax anyone?). If you restrict (through work flow) who can edit parts of the site then you can combat this, but you can get people needing to edit information not in their "area".
Give everyone access to the majority of the site, after all, a team should be there to ensure that the updates are done properly.
Also, to avoid repetition, make editors responsible for classes of information, not for services based on an internal structure. As an example: an editor can update benefits information and link it back to both housing and council tax, not just update the information for a particular benefit.
To conclude...
It shouldn't go on just to tick a box, but only if it is RELEVANT to users. My suggestions are as follows:
- Treat editors as individuals with various levels of ability. Be flexible to accommodate this
- Make web editors provide a case for putting info online, a "form" (that replicates the info you want) does this. If you can fill it in, it goes up, if not, no need for it
- Learn to say no
- Pick editors carefully, look throughout the organisation and discuss with services before letting them make their own choices.
- Keep editors informed, make them feel part of something.
- Know your site and your CMS inside out - you will be the "go to" point if people get stuck.
