Once you have recognized the patterns of behavior and usage that indicate that a reorganization of content may be necessary, what must you consider before tackling such a project?
Once you have decided that a redesign is necessary and have considered any new techniques you want to use, how do you go about making these changes? The one thing you don’t want to do is to just jump in and start making ad-hoc changes in the existing wiki.
Set-up a “sandbox” area of the wiki, or better yet, a separate test bed wiki, where you can import some of the existing data and experiment with your ideas. Move information around, add categories and tags, build navigation schemes, etc. But, do it in a secure location where only a few people have access and where your activities will not affect the current wiki.
As you try out new ideas, make sure to test them. Once you are satisfied, gradually open the test-wiki up to a wider audience of trusted users and gather their feedback and input. Make more changes, then test and refine until you are confident that the changes you have made will both continue to meet your business needs and improve the experience for users of the existing wiki. Don’t change for the sake of change – whatever you do must be done with the aim of both meeting the needs and behavior of the existing community and attracting new users.
It may not always be necessary to try out your redesign on a sandbox first. It depends on the scale of the redesign and the nature of the material. If you’re just tagging pages and then using the tagging to design a structure, then you’re not materially affecting the content. It’s metadata. So you could build it on the live wiki, which is a more direct, quick way of getting user feedback. If you’re contemplating moving large amounts of data, then you could create the new “parent” sections on the live wiki and move just a few key pages into them. Tell people to take a look, and see what the fallout is.
You could treat it as an “agile” project: do a bit, then try it out. Iterate and improve constantly, making sure you have a plan but being ready to change the plan as you go along.
Why? Because it’s a bit scary and off-putting to think of it as such a large project – both for the wiki-gardener and for the wiki consumers. Bite-sized chunks may be easier to deal with
In short, any redesign must be as carefully thought out as the original wiki implementation. Consider why you are doing the redesign and what problems you are trying to solve, then test each potential solution.