Hi, I’m Todd Burry, co-founder and Chief Product Officer here at Vanilla. Welcome to my monthly blog!
We’ve been at this for about ten years now and have worked hard to create software that’s simple and straightforward to use, with a lot of functionality under the hood. But as you probably know, getting to simple is complex. I’m writing to give users a peek behind the curtain, so you can understand the decisions that we make and why we make them.
But first, some background. When customers come to us, we need to know more about them than just the specific features they’re looking for in their community software — in our effort to provide our customers with excellent functionality, we want to know their story. The key to achieving top notch functionality is understanding how our clients perceive themselves and the stakeholders within their communities, so that we can build on their unique positions and forward their stories.
Let Us Tell You Our Story
We know how important our clients’ stories are, so it seems like it might be useful for us to reciprocate. I hope that by explaining our story and how we’ve developed, our users will get to know not just what Vanilla can do, but how and why it has evolved the way it has. In future posts, I’ll explain different software features and tell you how, and more importantly, why things run the way they do.
Vanilla started as an open-source hobby in 2005 that got really popular. Our original software was developed in order to host a community of web developers and designers sharing ideas and interests. We had created an intuitive, sleek software and we realized that other people might be looking for the same thing too. In that sense, we were our own first customer. The original Vanilla was unobtrusive compared to other community software, which was confusing to non-tech people and bloated with too many features that were too difficult to use; to this end, we made sure the business of the community, rather than the platform, was always in the foreground.
In 2009, we decided to take the plunge and formed a software company as the next evolution of that original project. Today, we host some of the largest communities on the Internet.
But our original ideal still guides us and even inspired our company’s name. Vanilla is the most popular ice cream flavor, not just because it’s delicious, but because it’s simple and familiar; it’s the unvarnished archetype of ice cream. That’s what we aim for. Of course, our software is quite sophisticated under the hood and has an array of business features, but we still wanted those using the software to feel comfortable with it. That’s why we’re proud of the “plainness” of our software. Whatever is added to Vanilla will call attention to the client brand and community, not us.
Every community has a mix of questions, answers, best practices, troubleshooting, and a healthy dose of off-topic banter too. While every community has these things in different proportions, they usually add up to a ton of content. I’ve been thinking a lot lately about how we can reduce some of the noise in our communities and better unlock the value of their content.
One of the most salient features of customer communities is knowledge sharing. We strongly believe the best way to leverage this knowledge is via a knowledge base that works for, and in conjunction with, your community. And so we’ve developed “Vanilla Knowledge”, a new knowledge base feature that I want to introduce to you.
Knowledge bases come in various forms but the underlying concept is always the same: a knowledge base is a collection of information. Simple enough, but here’s the important question:
How do you efficiently get knowledge in and knowledge out of that knowledge base?
To answer that question, we’ve looked at a lot of software out there and saw there are generally two forms of knowledge bases: guides and help centers. I’ll give you a quick overview of both.
Guides are little online books and are meant to be read more or less in order from beginning to end. Guides are the instruction books you get whenever you get a new phone or vacuum cleaner. Anyone who works in software is familiar with these because almost all software documentation takes this form. You can find guides in many places on the internet (Github, for example), but you can also think of user manuals, quickstart guides, or even recipes. For most products, you would be lost without a guide of some sort.
Unlike guides, help centers consist of articles that have no natural order and are loosely categorized by topic. While they may be presented in a logical order (such as in an FAQ), each element should be comprehensible on its own, even if the user hasn’t read the previous elements. Help centers are meant to host a ton of articles; they contain more information than anyone could read in one sitting. These types of knowledge bases are best accessed through search, similar to how a library catalogue used to work back in the day. Today, you can think of the Internet as a big help center where you use Google to find pages on whatever topic you’re interested in.
In both cases, each element is indexed primarily by its content using key terms.
Guide or Help Center?
Which kind of knowledge base do you want for your community? Well, we believe the best answer is, in fact, both.
To understand why the best knowledge base is a combination of both guides and help centers, we need to go back to the question that we originally posed: how to get knowledge in and knowledge out in the most efficient way possible? This question challenges us to look at the knowledge base from the two basic functions that it performs: knowledge in, and knowledge out.
Let’s start with knowledge in. To determine the best and most efficient way to add knowledge to the knowledge base, we must consider two primary factors: a) the creators of the knowledge, and; b) how users look to consume the content.
It’s important to consider the creator of the content because the experts who write software fixes, for example, may not be an expert in organizing information — and they shouldn’t have to be. They should be able to write an article and submit it to the knowledge base without worrying about where it fits.
I’ll give you an example from my own personal experiences. I’ve written a ton of articles on software fixes in my lifetime — but surprisingly, this was the easy part. The biggest challenge is actually figuring out where to add this information once it’s written; do I add this information to an existing guide, or make it a stand-alone article and hope that it can be found?
The existing guides might not have a natural and logical spot for my solution to fit in; I mean, I could simply tack it onto the end, but it wouldn’t be easy for someone else to locate. Further, even if I put it somewhere that makes intuitive sense to me, it may not be intuitive for the person who needs the info.
Worse still, I might not even bother to write down a solution that I’ve spent hours working on, simply because there’s nowhere to put it. The linear form of guides just isn’t suited to being updated in a way that preserves the logic of its order. The other problem is that you want guides to be easily digestible. If you keep adding to a guide, it can become so long that it scares people off.
That’s why you also have to consider how your users are looking to consume the content. If you chose to address every problem in your ‘getting started’ guide, you’re bound to disappoint your users. You don’t want the first thing that new users (or, even worse, prospective customers) see to be a long section of fixes and troubleshooting instructions. Those are better suited for help centers.
My point here is that it’s hard to add things to a guide without making it less useful. That’s why a combination of guides and help centers are the best choice for adding knowledge to the knowledge base: it’s easy for those who create the content, and it’s easy to find and consume for those looking for solutions.
Again, I can speak from my own personal experiences here. At Vanilla, we’ve used both types of knowledge bases and have learnt what works best for getting knowledge out.
The first knowledge base we used was a wiki for our documentation, best practices, and frequently asked questions. Ultimately, we found that it was too unwieldy; it had a big ol’ list of documents down the left side that you had to hunt through to find what you were looking for. Just picture rifling through a giant filing cabinet — that’s the mental equivalent of using this knowledge base — documents flying around, papers all over the ground, everything in shambles. We’d know what document we wanted, but might not remember whether it was placed in the folder meant for our customers, developers, or sales staff.
Because it was so hard to use, no one ended up using it.
So then we made the move to use Google Docs, expecting that we could just rely on the search function to locate what we needed. What we found was that having all of our documents in one repository made searching less useful. A search would return too many results because it mixed our business documents with our makeshift knowledge articles, so you still had to sift a bunch of irrelevant material to find what you needed. Worse still, multiple drafts of a document might show up, making it difficult to tell which one you wanted.
From our own experiences, we concluded that trying to make a knowledge base cater specifically to either guides or a help center would mean that something would always be missing. So when we decided to create a knowledge base companion for our software, we knew that we had to have a combination of these functions.
With guides, we can read straight through or search using a table of contents, an index, or keywords. While guides are usually meant to be read in their entirety, searching can be useful if you are familiar with the subject and need to refresh your memory. Guides are great for getting new users acquainted with your product — they give users something to read when they aren’t sure where to start.
And then there is the power of search. Search is almost always the best way of getting knowledge out of a help center, and we’ve made it easy for anyone to write an article and get it into the help center, where it can easily be accessed via search. While many help centers are categorized according to topic, most people just want to hit the search bar and find a quick answer to the specific question they have in mind.
We created a single place that has a collection of guides and a help center for answering all types of support issues. That way, new users who need to learn something from top to bottom can read a guide, but users who just want to know one specific thing can visit the help center. And of course, users can also search both to find what they need.
Our knowledge base emphasizes the search function. Users overwhelmingly prefer searching for an answer to their questions rather than navigating through a list of categories. We want it to be easy for them, so we put the search bar in the center of the page, not up in a corner.
The help page is often a new user’s first experience with a site (especially if they’ve been brought there from Google), so it’s important to make the right impression. Presenting the user with a long list of categories to wade through is not especially inviting. A search bar says, “Tell me what you need and I’ll give it to you right away.” In short, Vanilla Knowledge has been crafted in the same way that our community software was created over ten years ago; with simplicity and with the end user at the top of mind.
Community And The Knowledge Base
Naturally, it was especially important for us to create a knowledge base that works for communities because your community generates some of the best content you may have. So we created a workflow for getting community contributions into the knowledge base. As you know, one of the many contributions community members make is providing questions, answers, and solutions for one another. By including these contributions in the knowledge base, you can improve the overall value that your knowledge base has for a number of reasons.
The first reason is that when great community content is added to the knowledge base, it will always be easy to access. Unfortunately, this isn’t always the case with community; the temporal nature of online communities makes only the newest and most popular content easy to find and access, and even if older content is still valuable, it gets pushed back to make room for the new. By converting community contributions into knowledge base articles, you are able to morph these short-lived posts into long-lasting, high value content.
The second reason why including community content in your knowledge base improves the overall quality is because of the unique viewpoints that these articles offer. Community members often have a different perspective than internal staff and come up with ideas and solutions that you may not have anticipated due to the natural biases and blindspots of being inside your own business. Including contributions from different perspectives not only enables your knowledge base to grow efficiently and organically, but it also allows your knowledge base to truly be a wealth of knowledge.
The third and final reason why adding community content to your knowledge base is valuable is because it recognizes and acknowledges the contributions made by individuals who care about your brand. In essence, it memorializes that community member’s contribution and allows you to credit that member in the knowledge base article; this gives the member tangible proof that their contribution is valuable and appreciated. Crediting the members also increases their social capital within the community. What’s more, including community posts in your knowledge base is a great way for community managers to strengthen their bonds within the community.
A Knowledge Base For Everyone
In keeping with our Vanilla namesake, we designed our knowledge base to make things as easy and as plain as possible for your customers by removing every possible obstacle and distraction. We’ve included guides to help them get started using your product, and have also included a help center so that their questions can be answered as quickly and as accurately as possible.
We’ve also designed our knowledge base so that it’s easy to use for your staff. There’s a place to write documentation and a place to store knowledge that organically develops from your community and anyone else in your organization.
We put a lot of thought into our new knowledge base. I hope I have given you a deeper understanding of how knowledge bases work and the reasoning behind our implementation. I hope we’ve given you some insight that you can draw on as you populate your own knowledge base.
Til next time,