I have spent the past month tackling the sprawling Web Services Wiki. It felt significantly longer, especially as in the interim our department changed name, resulting in what is now officially the Digital Marketing and Communications Wiki space. Here is how I got on:
Our Wiki pages had the following problems:
- they run to thousands of pages
- they host a sizeable amount of out of date, irrelevant or in some cases inaccurate content
- they can be difficult to navigate and find information.
My challenge was to:
- identify our priorities for our Wiki
- provide an Information Architecture (IA) design
I arranged several meetings with the team for my user research. The following principles and priorities were agreed upon:
- the Wiki must be used to document what we’ve done so that people can use the information again
- the Wiki needs to be structured properly and clearly
- the team needs to create proper instructions for governance – where to put content, how to put it together
- clear division must be created between project documentation, user guides and technical documentation.
I had an initial card-sorting meeting with the team to flesh out a first draft of a structure, and began organising the Wiki along those lines. Further conversations with colleagues and fresh iterations refined this structure, seen below, further.
We also defined a lifecycle of content which outlined how content is uploaded and maintained
Work like this is never finished, but I feel further refining of the Wiki will emerge organically from how we use it. In future we need to consider the following:
- how we arrange user guides – into areas and topics?
- are we writing content with future audiences in mind?
- are we using tagging and naming conventions which will make the content easier to find?
- a colleague suggested that instead of categorizing work as Projects we should think of work as Products and Services - would this terminology be more useful?
The problems identified with the Wiki are still issues, but as a busy team we are never likely to have the time or resource to exhaustively review and edit it in its entirety. It is more important that we use an agreed best practice in our future governance of the Wiki to ensure it works for everyone.
For a more detailed look at how I went about this work, see the documentation I created on the Wiki itself.