Back in the early 2000s (so let’s say a decade ago), the wiki trend emerged (think Wikipedia). Companies created wiki sites left and right, either internally for employees or externally for customers. And why not? It worked as a resource for everyone. People could collaborate and make changes to the content in a matter of clicks. And best of all, many of the wiki applications came FREE! Out of the over 43 wiki applications, about half are free, including the software Wikipedia runs on – MediaWiki.

So now it’s ten years later, and while social networks are the new trend, wikis are still commonplace. Partly because wikis involve a sort of social aspect (what with the collaboration and all) and partly because of how easy they are to use. The question is, though, what kind of shape are these wikis in now? Does the content make sense, and can readers find what they’re looking for? Or is it more a miscellany confusing the reader and leaving them dizzy from clicking?

If you have no one devoted to wrangling in the wiki content, then the answer is probably the latter.

A common example of this is software companies using a wiki to host their user documentation. The developers create the product and are then responsible for publishing its documentation to the wiki – which is a recipe for disaster.

Instead you need a writer devoted to the wiki, and here’s why:

So your developers can develop.

And by “developers” I mean the people asked to create content for the wiki IN ADDITION to creating products for the company. You don’t want your developers spending time pining over what words to use or if their words make sense. They should be spending that time innovating the product. AT MOST developers should send a brain dump of information over to the Wiki Wrangler so he or she can make sense out of it. With a brain dump, developers aren’t as worried about looking foolish with their grammar, so you tend to get more content out of them, and they tend to spend less time writing it up. A win-win. In the end, you get a wiki written in a single voice that users can follow.

To keep your content clean like a bonsai tree.

If having one person (or a small group of wranglers) edit all the content before it goes into a wiki is asking too much, at least have a Wiki Wrangler to regularly check over the published content. It becomes their job to cultivate the wiki like a bonsai tree, creating the wire frame for content to cleanly grow from, pruning the pages to keep the organization tight, and trimming content to make sure it doesn’t go off on tangents. The more cultivated a wiki is, the easier it is for users to quickly find what they’re looking for and the fewer clicks they’ll need to get there.

To give your users someone to vent to.

As someone who’s been the sole writer and wrangler for a software company’s wiki, I see this as a necessary evil. While answering emails from the user-base came be tedious, it can also be very beneficial to both the quality of the content and the user experience. Users appreciate knowing their questions/comments are read.  And if one person is reading through the emails, it’s easier to find trends in the user experience. What topics are users getting hung up on? Where’s the pain point? All questions that can be answered when you have one person focused on the wiki.

Wiki Wranglers don’t always need to be full-time employees, though.

Just recently I did a project for a leading BPM software company that worked their way into the Leaders Quadrant of Gardner’s Magic Quadrant for BPM software. I did an inventory of all the pages they publish on their wiki documentation site and delivered a report of my findings.

I went through the content on each page and grouped the pages into four categories: Delete/Deprecate/Revamp/Condense. The Delete group were pages they could live without since the content was already elsewhere, the Deprecate group were pages they could stop worrying about because the feature was on track for deprecation, the Revamp group were pages that just needed to be cleaned up to match the Style Guide, and the Condense group were pages they should condense into broader pages.

See, the problem this company had was too many pages, which to me is the best kind of problem. They had the content to play with, they just needed to bring it all together so their users weren’t clicking all over the place and landing on pages with three lines of content they already knew about. Their wiki bonsai was in dire need of a wire frame and massive trimming.

By condensing their pages into broader topics, each topic page could work as a one-stop shop.

Users could search for a general term and get a broader topic page as the first result. Once they click on it, not only will they find the content they need (either through the Table of Contents or using Ctrl-F), but they are also free to discover the other content related to their query.

Through my inventory project, I was able to find about 115 pages that could be deleted and 443 pages that could be condensed down to about 40. In the end, I found an organized way for them to go from about 900 pages to 200 just by wrangling in the content they already had.

The thing to keep in mind is users don’t mind scrolling . . . it’s the clicking around that makes them crazy.

Get yourself a Wiki Wrangler, if not full-time, at least for a yearly review. Your users will thank you.