The intranet users everyone ignores – publishers
This post is the result of listening to some of the comments made in the discussion sessions at IntranetNow on 13 October. Several of the presentations highlighted the importance of undertaking user testing with real users, preferably with video recording. There were also references to the benefits of using personas as a way of segmenting user needs at the outset of an intranet launch or re-launch. There was a mention of empathy mapping, which I am only just getting around to using, but it seems to be potentially a very useful tool. So far, so good. But there is one group of very important users that is never taken into consideration.
Publishers! An intranet without content has no value. An intranet with outdated content or incorrect content has an even lower value then zero because it then becomes dangerous. Time and time again I hear questions raised about how publishers can be incentivized to contribute in the same breath as a comment about the challenges of the publisher interface. In the case of a website there is often just a small team of content publishers who know the CMS inside out, including all the short cut keys. An intranet has a mix of publishers which may include
- Publishing content on a regular basis which has a consistent structure and format
- Publishing content that they have no idea about what it is about because their manager does not want to be a publisher themselves
- Reviewing and revising content where the person who should be doing it has left the organisation
- Publishing content that is for the team/department they work for
- Publishing content about the team/department for the wider benefit of the organisation
- Publishing content on an ad hoc schedule and to various different formats
- Creating new types of content
- Publish content in a language that they may speak but cannot write with the same ease (English is easy to speak but a challenge to write well)
All of these requirements need a careful combination of training and user interface design, and it’s the user interface design that rarely gets much attention. Even with initially good training a poor publishing UI (welcome to SharePoint!) will inevitably take its toll on publisher enthusiasm and quality management. In a number of recent projects I have persuaded the intranet team to work up some publisher personas along the lines of the examples above. All too often I find that they have relatively little knowledge of the varieties of publishers and have not specified the user interface on the new intranet, just taking whatever the IT development team think is a good generic interface. I think it is time we gave the publishing process much more attention throughout any intranet redevelopment project, especially where the reason for the redevelopment is that content quality is poor. We may be fixing the wrong problem.