Month: August 2021

My small-but-mighty team and I are well into the project of starting up a new knowledge base. The first big question was ONE WORD OR TWO??? Knowledgebase or Knowledge Base. We’ve settled on two words because that’s what TeamDynamix uses, but opinions are definitely divided on the matter. I’m personally quite firmly on both sides of that fence myself…

Last week I “promoted” my two student workers to Approvers – so now they can not only draft articles but also approve and publish them. We’re working on a style guide (I’ll share when we have something people might be able to understand), and we’re developing a topic/category structure so that clients who browse rather than search have a hope of finding what they need (or to catch people who search and land on something almost right so that they can find similar things). All of this preparation and foundation is of course with the goal that before too long we’ll be able to open up authoring/editing/approving to lots and lots more people in the department, and they’ll be able to make easy and wise choices about where to put their content and how to present it effectively.

We’re also adopting a lot of the KCS philosophy, which means that basically everyone can submit articles or flag existing articles for editing, and ideally techs will turn to the KB for nearly every question responses (our motto is: Find it, Flag it, Fix it, Add it). Then content experts will be able to approve/publish articles. Basically, just like with library research guides, I want as few bottle necks as possible in the process of producing reasonably standardized self-service tech support articles.

We’ve come up with a set of initial priorities for content:

• High-traffic, client-facing, self-service content, especially:
  • Whatever will be needed for new students/faculty/staff for Fall Term (connecting to the wifi, getting MS Office on your computer, etc)
  • How to get your computer connected to our cloud back-up system, the VPN, cloud storage drives, and other core systems that basically everyone has to do all the time
  • Mac/Windows OS update information
• Whatever we find ourselves typing frequently into responses to incoming questions to the Helpdesk (since KB articles can be attached to responses to tickets)

I’ve also talked to a few people who are interested in adding content, and we’re all trying to work out how to decide where to put all the different kinds of content people need to get out there for clients. For now, here’s how I’m thinking about the distinctions between what goes in the KB vs what goes on the WordPress-based campus/department website:

• In the KB
  • “Live” content – things that will be constantly updated
  • Content that needs to be restricted by audience in any way (we’re defaulting to fully public KB articles, but there are plenty of audience restrictions available as needed – WordPress audience restrictions are also available to us but are less granular)
  • Content that people will want to easily embed in answers to questions/tickets
  • Content that we want to have easily linkable from the pages where we have clients open tickets
  • Content that we think people will find primarily via search, especially Google search. The KB seems to be able to boost search results based on titles, article summaries, tags, and initial paragraphs of text, so we have a lot of options for catching people who are searching for guides.
• In the campus website
  • More high-level, stable descriptions of services/policies with pointers to the KB for specifics
  • The “why” instead of the “how”
  • Things that need more stability (things presented at conferences, etc) where there’s some expectations that redirects and archiving could be possible compared to the more ephemeral/evolutionary nature of a KB article that will be updated regularly

We’ve also worked out naming conventions for KB articles based on how we think clients will discover content and how techs can find articles to attach to ticket responses. And we’re feeling our way toward conventions/styles that we think will be as sustainable and consistent across all authors while still allowing for as much flexibility as possible so that content experts don’t feel hamstrung by too many rules or too few styling options.

Then there’s a scope question for the KB: how comprehensive do we plan to be with our content in this system? We do NOT want to recreate either Google or vendor-supplied support sites. We want to augment those things by either pointing our clients to vendor-supplied support sites or adding local context to Google result list. And coming from an information-management background, I’m very interested in developing a curated set of publicly visible support articles. But exactly what fits into this “curated” set? How aggressively will we weed the “just in case” or “previously useful” articles? How will we strike a balance between answering as many questions as we can for people who search through our content vs restricting our search result lists (or category browsing lists) to only the most current and relevant topics? We’re still feeling our way to the proper balance for these things, for sure.

I’m also thinking through the cultural pieces of launching this new thing.

• Some parts of campus are pretty used to going elsewhere for information, so when should we move their content into this new place? Which new content will help drive eyes to the new space vs which content will languish in the new space because people will keep looking for it elsewhere?
• What about the techs who have created information in previous information repositories? How can we honor the work that they’ve done while also transitioning to a new location that has affordances that privilege different rhetorical strategies? I certainly don’t want to make anyone feel like their hard work in a different system is somehow bad or wrong just because information seeking and/or information presentation options have changed.

So, 6 weeks into my new job, and a month into this project, we have a pretty solid foundation and are turning our attention to adding as much content as we can. Things seem to be going well! But there are miles to go before we have anything like a mature knowledge base.

Comments closed