To Wiki or Not to Wiki? That Is the Question.

We’ve all heard of Wikipedia, the free encyclopaedia, written collaboratively by the people who use it. They create, update and moderate content that is accessible to everyone who has internet access. Wikis can also be excellent tools when applied to business. There are a variety of proprietary and open source solutions available, but for what use cases are they best suited?

 

 

It is said that using a Wiki is probably the easiest way to co-create a post and present information by replicating the Wikipedia model, but it is not the best way to discover and use content or share knowledge. 

 

Jacob Morgan, from the Future of Work community, said in an interview he gave for our blog: ”The most efficient way (to get people to use new software) would be to present it to them so they see what the value is to them.“

Many Wiki projects implemented at work are not used, because employees don’t see the value, or use it in ways that Wikis are not well suited for.

 

Why is that?

 

In our fast paced world competitors are releasing new features, your market is changing and we need to gather information and integrate it with knowledge dynamically in real time. Wikis are not the best solution for that. They are built for smaller amounts of well structured, short form content that requires little change. This is perfect for Wikipedia-like websites, user guides, and collaboration of small teams on a particular topic. Not so perfect for dynamic enterprises, improving technical support, sharing content across teams, document management and encouraging reuse of information.

Wikis are not great for quality assurance

 

The availability of content stored as Wikis raises concerns in regards to its freshness and quality. There are many questions to consider, such as “Who is/are the author(s) of each page?”, “What is their expertise?”, “Has the page been approved by an expert?”, “Is it made obsolete by other more recent content?”

 

 

These questions result in the author of the content being constantly distraught via e-mail or in person “just to be sure that this is correct and most recent information”. If the author is made to answer the same question again and again, what’s the value proposition of the Wiki? Your employees are clearly showing that they don’t trust it, and you are losing valuable expert time.

 

Employees need to know that the content is accurate and find related content

 

Official content needs to be created or verified by experts or those with the authority to publish it. It is important to identify authors including their expertise so each employee looking at the content knows who is the person responsible for that content and why they are considered an expert. Most Wikis either do not have profile pages or if they do, they do not include expertise specifically.

 

Information also exists in many forms. Any particular Wiki page may contain similar or duplicated information that is in other pages, documents or articles stored somewhere else. Related content is not addressed well by Wiki’s that often rely on links that are added manually.

 

When a client or someone in another team needs information and access to expertise they want to find official, and most relevant information related to a theme regardless of where it is (e.g. in a file, or document or Wiki page). When they find it quickly and can also see the experts relevant to this content this is true scalability.

Many perhaps don’t know that since Google introduced Knowledge Graph, Wikipedia visits have dropped considerably. Google recognised that very often, people just want a direct answer to their question - they don’t want to read tonnes and tonnes of content, and Google found a way to give direct answers by extracting key content from sources such as Wikipedia and showing it as a result. 

 

 

In this case, it recognises context, that by “tall” we mean height and provided us with the reply extracted from Donald Trump’s Wikipedia page. 

 

If this is something that we’re used to in everyday browsing, it’s apparent why offering long documents instead of short replies (where possible) just doesn’t work anymore.

 

At work, there are various aspects of contextual information (answers, documents, procedures, files, articles) we need to do our job, and we don’t want to spend more time than we absolutely must to acquire that information. Sometimes we are looking for insights about the information from domain experts, this is where knowledge sharing comes in.

 

This way, people who are searching for knowledge spend less time searching for it, while people who created that knowledge get fewer messages and shoulder taps and can focus on doing their work.  

Wikis are not a bad solution, they are just not fit for every use case. They are great for collaborating on a page or a chapter of a book in a structuring manner for smaller teams, or collaborating on technical documents like API documentation. 

 

If you are looking for a software solution that will allow your clients or employees to find answers easily, to discover knowledge which is proactively suggested to them, or to make sure that the answers they have are up to date and accurate, then Wikis are probably not your best choice.