Ask HN: Why do non-techies simply not "get" the idea of a wiki?
It's like "Let me Google that for you"
So we've moved the holiday booking system to the wiki. Now people can say when they're away on site, working from home, sick, or on leave. The leave days can be booked in advance and then confirmed by their line manager. At a glance we can see who is in, out, available or away, and the system is really helping our planning. Suddenly everyone knows when someone is on site and might need support, or on leave and unable to help. The non-techies have themselves said, when shown it, that it's really useful.
But the non-techies just don't "get it." They won't update the wiki, they still don't look at the wiki, they never add information to the wiki. Instead, they insist on sending things by email. Then in a few weeks time people are asking, and we have to trawl through email systems to find the information.
Except we (the techies) don't, because when we get information we put it on the wiki. Then when the non-techies ask us anything we can say "Have you checked the wiki?"
And they still don't get it.
Where is the mis-match? How can we make a wiki as accessible/understandable as a Word document?
How can we help the non-techies attain enlightenment?
Can the non-techies attain enlightenment?
56 comments
[ 3.2 ms ] story [ 135 ms ] threadThe thing is that to the rest of the organisation there are probably the following problems:
- they don't know what a wiki is, and they don't much care. Even though they use wikipedia they don't necessarily grasp the concept behind it: They just see a single entry, happily oblivious to how it got there.
- they don't want to learn what a wiki is, unless it directly helps them in the short term.
- They have ingrained ways of doing things. Changing people's behaviour is like changing direction of a supertanker: It takes a lot of time and effort.
The solution is to keep pushing it, paying attention to the following:
- Make it worth people's while in the short term. Reading your post it sounds like you may already be well on the way here.
- Make it easy. Usability should be top-notch, and there should be help available everywhere. If it's as simple as a mac it will be much easier to turn people around.
- Make sure that some things can only be done in the wiki, forcing people to do it. Don't put people's e-mails in the wiki, force them to do so themself.
You need to take the 'facebook approach.'
A lot of people HATED the new facebook design when it originally launched. I'm sure you remember, there were groups with millions of members saying "bring back the old facebook" and complaining about everything.
Months later everything has calmed down, for the most part people like it and the change needed to happen. Facebook needed to make the change to implement new features, design elements, etc.
They'll be mad at first but eventually get over.
How do you distinguish the case where you do something unpopular, refuse to change it to conform to your users' wishes, and are wrong?
I second this point. Essentially, you don't want to be in the position of doing for your users what they "should" be doing themselves. While it sounds like you are there to support your users, you can support your users better with a bit of cooperation. From my experience with non-techies and wikis, I don't think it's a problem of not getting it so much as a problem of making it easier to learn how to use the wiki than continue not using it.
(I know, I know the idea of a wiki is a collaborative one, but you must take baby steps, especially in a large organization.)
- Duplicate work; as long as the wiki doesn't replace existing processes, placing things there is simply additional work. Moreover, because it's additional, there's no guarantee that any desired piece of information will exist in the wiki.
- People don't like not having an "owner" to a document, especially regarding private edits and such.
- Wiki's make you search for a topic (i.e. they require work), whereas email threads are pushed to you by others motivated enough to CC. Unfortunately, my motivation in tracking an issue will never be the same as the person directly affected by the issue.
- Mostly, however, wiki's don't provide a substantial functionality improvement to what I'm now going to dub the "enterprise wiki": i.e., Word documents on a shared drive. Here, Windows provides structure (well, technically Solaris does, but it's accessed by the user via Windows Explorer), while Word provides the standard document editing interface (although we do work with many document types).
The main drawbacks are terrible search, manual (and content limited) revision control, and an inability to track updates.
The main upsides are a rich editing environment for documents (compare Word to a textarea), support for any document format (don't like doc files? Use something else), and the opportunity for private collaboration & edits without implementing temporary ACLs (i.e., copy a file to the local drive, and email back and forth until publishable).
Personally, I think wiki's are great for collaboration between a heterogeneous, dispersed population. However, at the large corporation where I work, Word + Explorer is a ironic example of the worse-is-better Unix approach (many tools, barely working together) clearly beating the wiki/web-based Monolithic design.
Wikis are for text that people want to read and change, regardless of its source. This makes them ideal for Wikipedia but inherently out of tune with the big-corporate environment, a large crowd in which people prioritize based on who is talking to them. A boilerplate memo from the generic HR-department address can be skimmed very quickly; an email from HR addressed solely to you might need to be read; an email from the HR rep who has been assigned to your team might need a more careful reading and perhaps an acknowledgement; even a boilerplate email from HR might need careful attention if the author is someone you befriended at the company Christmas party.
You don't want an automated alert every time your boss's assistant reorders the columns on the weekly report. Ideally, your boss will only call your attention to the report when it is important for you to read it. That's part of the boss's job -- to protect your attention so that you can spend your time being useful instead of rooting through irrelevant wiki documents! And how is the boss going to direct your attention? Email. And while she's sending email, what's wrong with just pasting the information itself right into the message and saving the recipient some additional clicking?
Put all that stuff on the wiki and file off the TOs and FROMs and datestamps and you might as well just label it BOILERPLATE, because nobody's going to have the time to sort through it all. Even a genius super-librarian can only help so much, because the social context of email (its timing; the number and identity of the CCs, the history embedded in all the quoted emails that extend far down the page, etc.) is hard for a librarian to capture, let alone convey in wiki form. And, no, the version history does not help much. (Deriving people's motivations by reading their diffs is a techie art, not a liberal art. And emails carry a semi-reliable record of who has read the message as well as who has helped to write it.)
(A minor note: You left out Powerpoint in your description of the "enterprise wiki". It's pretty important, and for more than just stupid effects-laden bullet points. I worked in an engineering firm. All of us were capable of understanding wikis. I never tried to set up a wiki, though, because people communicated in charts and graphs, and at the time I couldn't find a wiki whose chart-and-graph workflow was anything short of "excruciating". The state of the art was to mail out arguments that consisted of stacks of graphs with commentary, rendered as Powerpoint docs.)
Have you trained the non-techies in using the markup language?
We use Atlassian's Confluence. Confluence is a nice collaboration tool built on wiki concepts. Us techies used a wiki prior but Atlassian's almost-a-wiki-but-not-as-scary-as-one is now so popular that it is a major issue when Confluence is down. It is pretty much company-wide now and updated almost every minute.
Yes, it's not free (or Free) and is made by a pretty established company, but it's a solid product, Wiki enough that if you want to get into it, there is a lot fo customization and detail that you can do, but at he same time friendly enough that if you don't care, you can just use the WYSIWYG editor to make your point. It also integrates nicely with JIRA, although I doubt that's used by much of the HN crowd.
As for getting people to use it, my team made a rule that if you sent us a question that (in our opinion) belonged in the wiki, we'd answer it there and send you back a link. After a few weeks of doing that, people just stopped asking and went there first.
The idea of user-editable content isn't the problem. But wikis are an unknown quantity and a slippery concept for non-nerds to grasp. There are no affordances, no guidance, no structures to help orient people[1], and while wiki syntax is awful that's only a contributing problem.
It's like if a carpenter/handyman/car repair guy handed you a smooth, featureless egg-shaped object and said "This is a Ziki. You can do everything with this tool. Now, check my tire pressure."
Even if you knew how to check tire pressure in general, you'd be SOL.
Second issue is that people use wikis for things other than collaborative documentation, just like people use blogs for project management (just because they're easy to install), and that's not helping the adoption problem.
[1] I don't mean the document tree, either. People are used to structured content.
Is probably what goes through the non-techie's mind.
Use terminology they are familiar with; "the online notice whiteboard" or something.
At first we implemented a wiki. The techie guys on the team saw the long-term value of it and filled it in dutifully, however, many people simply didn't "get" the idea. The wiki ended up stagnating, as only a handful of people used it. The non-techie guys would inevitably ask about what was currently happening, of which the answer was already posted on the wiki. People just never warmed to it. Knowledge management and communication should not be a struggle, or else it will fall by the way side.
The solution was to step away from a wiki system (MediaWiki) and towards something else (Basecamp). Basecamp fitted in with how everyone used the net. Message threads that were relevant to people were sent to their inbox, they could reply to from their own mail account. Milestones are clear - tasks are clear. It's just usable and seamless.
A wiki has a perceived barrier of entry. It's a lot to take on at once for a non-techie. Using the systems which are currently in place, (eg email, a homepage/dashboard setup) to disseminate info will go a long way, rather than fighting an uphill battle of getting people to understand #REDIRECT [[pagename]]
Nudge 'em to explore, and then go to the next step by telling them they can edit all and everything, and add new pages.
The basic thing is the following: you can only trust data from those software where users have no way of avoiding entering the data. Example: ERP. The truck is waiting there, you need to print a shipment note because the damn truck won't take the goods without it, and the system won't let you print a shipment note before you put in all the data that lets the system amend the stock levels, mark the sales order as shipped etc. Such as system can enforce data entry, you find the data you need in such a system.
Similarly, e-mails are reliable, because if you want to communicate something to another person that's too long for a phone call, you have to send an e-mail. So you will find the information in your e-mails.
But what enforces entering data into a wiki? Just rules won't work.
It works.
(in their brains, I mean)
Think of how long it took you to learn the value of good commenting... That's about how long it will take to teach people why they should document their business practices on a wiki.
You'll be getting them to use vi to enter expenses claims next.
Work on getting it mentioned in performance reviews. If 'non-techies' start to have their bosses poking around asking questions about "so why do I keep hearing that you refuse to use the wiki?", that'll help.
I mean, really. A wiki is about as technical as a whiteboard... they're just being lazy. No one's asking them to make beautifully formatted pages, just get the stuff in there because _that's how we track it_... it's part of their job. They need to realize it.
- Wikis require a heroic effort to keep organized. Most people, when faced with creating a new category, or even a new page would rather send an e-mail and forget it. The fact that you have to not only post something, but also decide where it belongs makes the job of posting feel much harder. "You mean I have to categorize my content before I post?"
- Wikis require more cognitive effort on the part of the poster. With e-mail or a message board, you can essentially dump your brain and hit send. With a wiki, you have to integrate your post, not only into the organization, as I mentioned above, but also into an existing post(s). "You mean I have to read and understand other content before I post?"
- Most wiki markup is based on the ideas behind the semantic web and should remain readable and understandable even in markup mode - unfortunately, people don't like to cede control of the way their document looks. I have seen non-techies spend hours jumping through HTML/WYSIWYG hoops simply to achieve a particular look - not realizing the nightmare of editing such a page (think word generated HTML pasted into the page). "You mean I have to sacrifice my format before I post?"
- Finally most wiki software doesn't have a easy to use e-mail notification system. Many times you have to manually "watch" a page instead of just watching the whole wiki or a whole category. When you do get an update e-mail - you have to actually go to the wiki - no hitting reply - this again interrupts cognitive flow for a lot of folks. "You mean I have to keep track of all the changes myself?"
I love wikis, and certainly think that they can increase productivity - but they require a greater cognitive effort on the part of the poster, and a lot of folks are unable to make the short term sacrifices to achieve the long term gain a wiki can offer.
We use Microsoft's Enterprise Information Management at my work. It was rolled out about a year ago and is now primarily used as a replacement for storing files. I started playing around with it and discovered, to my delight, that there's a built-in wiki feature.
There's a huge place for it in our daily operations. It could save thousands of hours in the long run if we got only a few people to contribute. The problem is that second part: How do you get people to contribute?
Here's my strategy:
1. Privately create lots of stubs beforehand along with an intelligent structure for linking them together. Also add tons of how-to articles (because for non-technies, obvious isn't so obvious)
2. Add pages that show how people could actually benefit from it
3. Brief our management, stressing the benefits, and ask for them to push it within their organizations
4. If all goes well, people will slowly start adding information. If even 5% of the employees contribute, it will quickly reach a tipping point and then explode in popularity.
5. I'll continue to add and edit articles on a daily basis for the next few months regardless of the initial reaction
6. Gradually make it the go-to point for certain types of information, forcing people to use it and see how useful it can be
I'm at step #2 right now. I'll have the opportunity to brief the management in about three weeks.
Also, I'm going to call it a "collaborative notebook" as that encompasses how people can benefit from it much more than calling it a wiki or knowledge base.
The thing I've found is that even just telling people what I'm doing in basic terms is unclear. They hear "wiki" and go "wiki wiki wiki" and then nod their heads when I'm explaining things to them.
What I've realized is that its not their fault if they don't understand what you're doing. Its your fault for not explaining it to them in a way that makes it clear.
We'll see what happens... wish me luck.
I'm technically inclined but I shutter at the idea of having to write anything in a Wiki, because the syntax is so unintuitive and annoying. I seem to recall adding line breaks, and it NOT showing line breaks on the preview. It was one of the use user experiences I've ever had: some fucktard decided that hitting "enter" wasn't enough to add a "<br>" to the content, so I have to go and dig through documentation to find out how to do it. Pisses me off thinking about it.
There was a time once, when I was paid to work on Socialtext... but I'll spare you.
Let's just say that Socialtext is not the usability professional's answer of choice to MediaWiki.
Also, I like to shill Perl whenever possible. :)
For example: well them they can't go on holiday unless they book their holiday days into the wiki.
Also, overtime. Do people at your work get paid overtime? If so, make the system so that they don't get paid it unless they put their overtime hours on the wiki.