Know Where to Search:<br />Why Content Over Context Is Stifling Your Knowledge Base

In a previous life I once led a proof-of-concept and implementation of new performance monitoring software. Throughout this process, I became the company’s de facto subject matter expert.  Along with administering this newly deployed application, I was responsible for training and developing knowledge content to assist others. I wrote KB articles, held bi-monthly training sessions, even developed some web videos showing off features and common use cases. The net effect of this? After a brief period of usage, our tech’s engagement took a nosedive, everyone came to me with questions (“Why didn’t you read the KB?”), I became even more of an expert (out of necessity, not by choice), and eventually administering and using this application easily became one-third of my job. The lessons I learned from this lack of adoption and failure to produce an effective knowledge base did not come easy, but they have been invaluable since. I’ll share the key takeaways I had from this experience.

Of course, it would be erroneous to think lack of adoption is solely guided by whether or not you have a good KB. There are and were other factors at play. But producing information that is not readily digested does have an effect. So, what happened? What happened was that I focused too much on content (the words on the page) versus context (who my audience was and how to best enable them to find relevant information).

Lack of adoption is not solely guided by whether or not you have a good knowledge base.

At the time, I felt my KB articles were thorough and detailed and covered all of the important points I’d want techs to know. Looking at it in hindsight, the information came across as dense, bloated, and not easily digestible or searchable. How often have you had someone come to you with a question readily answered in a previously published KB article? Of course, when you tell them—or better yet, show them—you probably have to scan the article as well to find the entry in question (and you wrote it!). Imagine what they’re going through.

To consider this situation in another way, let’s do an experiment: tell me right now what the PSI tire pressure your tires need to be at factory level. Some of you live in an area deeply affected by the weather where this knowledge is a necessity and so comes from memory. I am not one of those people. I’ve just had bad luck with tires I guess and now know it off the top of my head (it’s 36 PSI). But why have I been able to commit it to memory? I don’t remember the page number in the manual that tells me this info. I don’t read the tire well (though that would probably prove my eventual point also). But I do know how to search, and luckily my owner’s manual makes it very easy to find the reference page in question. Your knowledge base should be the same way.

In far too many examples, I see people focus solely on the content of their KB articles. While this is certainly important (we need to be accurate), I would argue that stopping to think about how people are going to find this information (Titles? Tags? Versions? Metadata? Wikis?) is just as, if not more, important. After all, how can you utilize something if you can’t find it? The amount of effort required to make use of something, no matter it’s eventual value, will directly affect its adoption. Your KB articles might be awesome, but if it takes an arm and a leg to access them or search for the most popular items, you’re doing yourself and your users a disservice.

OK, but what changes can be made? After re-reviewing where I had mis-stepped, I came up with this list of things to keep in mind:

1. Don’t answer everything. Break things down into component (but easily found/referenceable)
   parts. KB articles should be unique and succinct. KB articles might be loosely or not-so loosely related to each other or follow a natural progression, but they should be short. There should also be a point in every article where “post this” or “if you have any further questions” directs them to contact support, and then boldly provide that contact information. You’d never do a surgery after reading an anatomy book, and your KB articles shouldn’t encourage your users to self-diagnose or fix complex things. These are knowledge base articles, not owner’s manuals.
2. Utilize metadata, and make sure that is searchable and accessible. I wrote an article for HDI (Data vs Metadata: Design and Use Context to Find ITSM Answers) speaking about the importance of good metadata structure in ticketing systems. Knowledge base systems are no different. Good tags, subject/category hierarchies, and version control are essential to an effective KB.
3. Be explicit about the gotchas. Often-times when I see KB articles they’ll contain good stuff, but the one thing you have to get right, the, “You must sign into the laptop before it leaves our network if you’re shipping it to a remote user for the first time” clauses are treated just like everything else. They are not. Don’t hide these three bullets down in a general section after four paragraphs of previous KB information. If it is something that must happen for success, you must be explicit about it—. bold, highlighted, boxed text, whatever it takes. You need a visual indicator to point out the small but vitally important details.
4. Remove old content. You need a review process. This is different from a publication process (though you probably need that as well). But on some cadence, you need to see what’s being used, what is still relevant, if things need to be updated, and what should be removed. Your system should be a living, breathing knowledge base, not an antique bookstore.
5. Consider a community approach or branching. This one is a little more controversial. I include it here because I think there are enough lessons to be learned via version-control sites like Github that warrant taking a second look. The effectiveness of Github is not just the explicitness and ease with which you can find data (the underlying code), but also that you can open this up to community driven iterations and allow branching off of the mainline for specific use-cases. Perhaps there is a master approved KB, but from that you allow individual departments to augment (branch) as needed. Maybe the requirements for your SecOps department are different than your Finance department, but you don’t want to have to manage everything under the sun, so allow them to self-govern. Be forewarned: you’ll want clear governance over the rights and responsibilities of these branches. Don’t enable the Wild West. But you also can’t know everything, so setup guardrails and let people drive in a governed fashion.
6. Know your audience. Will this KB be internal to IT or external to your customers? What’s the average technical level of the person reading it? Is there sensitive data within the KB? Should this particular KB not be searchable, or only searchable by a certain audience? Do different areas of the business consume information in different formats? All of these questions should be considered when developing knowledge bases.
7. Collect data. You need regular and accurate reporting off the usage of your KB articles. Is it being used internal or external? Is there a bell-curve to its usage? What’s the average lifecycle per KB? Does your consumption change with roll-out of new software or projects and, if so, how do you account for that spike and then long-tail? You should be collecting and reviewing data points like these regularly. This is especially important in the beginning because you’ll know if you’re on the right track and providing useful content versus continuing thinking everything is great like I did. Don’t assume what you’re doing is effective; have the data to prove it.

Knowledge bases are hard. There’s no silver bullet for getting them right. But if you enable people to self-serve, they will. Fostering that enablement means that your KB articles need to not only be clear, but also easily found. The prime lesson I learned from my own experience was not that my content wasn’t descriptive or accurate, but that is wasn’t easily found or digested. So, do better than I did; make your KB articles clear, consumable, and reachable. Make sure you’re paying attention not only to the creation of content, but also to its context and ease with which it can be accessed. Creating KB articles requires effort. If those KB articles are not utilized, that’s effort wasted.

Adam Rauh has been working in IT since 2005. Currently in the business intelligence and analytics space at Tableau, he spent over a decade working in IT operations focusing on ITSM, leadership, and infrastructure support. He is passionate about data analytics, security, and process frameworks and methodologies. He has spoken at, contributed to, or authored articles for a number of conferences, seminars, and user-groups across the US on a variety of subjects related to IT, data analytics, and public policy. He currently lives in Georgia. Connect with Adam on LinkedIn.