More and more, Intranets are being replaced by internal wikis. Many welcome this change, seeing the bottleneck of the Intranet publishing team as the barrier to the Intranet being an effective internal communications and knowledge sharing tool.
However, while a wiki does make content updates easier, it doesn’t solve the problems plaguing Intranets.
It might make them worse.

Why Do Intranets Fail?

Rarely have I met someone who raves about their organization’s Intranet. Usually they’re out-of-date, hard to navigate, look awful and have conflicting information (e.g., Page X says to contact IT, Page Y says contact building security). The reasons for these situations have nothing to do with the publishing process, but a lack of a central authority knowledgeable in Web communications.
Content Not Written for the Web
Often, a subject matter expert—HR, procurement, IT—writes Intranet content. Despite this person’s best efforts, they aren’t trained in information architecture, usability and writing for the Web. The result can be exhaustively-detailed, impenetrable content that no one will bother reading.
Or, the structure is centered around that organization’s operations, not the types of information someone would be looking for.
Poorly Formatted
Beyond what is written, formatting may vary. One author may use headings in UPPER CASE while someone else prefers underlined.
One may prefer inline links while another uses “click here while a third lists all links at the end of a page. All of this leads to an inconsistent experience and confused user.
Lack of Updates
A common problem is that once a page is written, it’s considered “done” and never given a second thought. This situation is especially true when a manager asks someone to “just put it on the Intranet,” where it may be referenced once and then forgotten. But even as the page falls out of date, there are links to it and it shows up in searches, leading users to think it’s current.

Wikis Have Their Own Problems

A wiki does not solves any of these problems. In fact, it introduces new ones.
Guarded Authorship
Since wikis can be edited by anyone, some authors want to prevent changes. When they find they can’t, there can be a real mess when someone makes a change that the original author doesn’t like (or sees as a threat) and an Undo/Redo battle begins.
No Information Architecture
Also, wiki content is not written with an information architecture in mind. So, there is no “HR Section” or “Forms Portal.” While one can tag a post or assign it to a category, I have found these functions are poorly understood and rarely used. This can lead to many pages covering the same topic since an author may prefer to create a new page rather than add their content to existing page.

So What To Do?

There must be at least one person—if not a small team—that manages the wiki and spreads Web communications best practices to users.
A good wiki needs an Editor-in-Chief. This may sound contrary to the ideals of a wiki, but the Editor is not there to correct or revise content, but clean the content up. The Editor would apply writing for the Web principles, tag pages and make sure they were added to categories and communities.
The editor would also find duplicate information and work to integrate the information together.
Writing for the Web Training
Hopefully, the organization is large enough to have Web editors. A wiki is just another website in terms of how it is used, so applying writing for the Web principles is vital. Try to have trainings, sessions or even informal chats about how to write for a wiki, how to link, when to create new pages, and so on.
Every wiki technology is unique, but each allows you to apply metadata to a page, be they tags, belonging to a category, or keywords. These allow a page to have a relationship with other pages covering related topics. For example, a page on YouTube should be related to videos as well as social media.
While the Editor-in-Chief can make sure pages are properly tagged, users should understand that no page can exist on its own. Each page must be tagged or belong to a category. This prevents orphan wiki pages.
Contests to Find Data
As a way to test the wiki’s ease-of-use, establish a contest where someone must find a certain number of facts on the wiki. If you find that, consistently, certain facts are not being found, that should be a clue as to what pages are likely not properly tagged or aren’t using Writing for the Web principles to make text easy to read.