Technique 5.1: KCS Article Structure
Overview
Content Health begins with the article structure. A well-defined, simple structure is a fundamental element of KCS. A consistent structure contributes to both findability and readability of articles. The goal of KCS is to capture the organization's collective experience, or knowledge, in the form of articles.
Articles capture what we have learned in responding to a request. The article content is the reusable part of the experience and should not include information that is specific to the requestor such as company names or contact information for people, entitlement, or specific locations. That information should be kept in the system of record for interaction. For support organizations, this event specific information is kept in the case or incident management system.
KCS articles are more than just the question and the answer. The article connects the requestor's context with the responders experience and resolution and information that is valuable to the organization.
KCS is a modular approach to knowledge. Ideally, KCS articles are a page or less in length. A given situation may use multiple articles to get to the resolution. KCS articles often contain links to other other articles or more reference information that already exists in other databases.
Establishing a Good Format or Template
The right structure ensures that KCS articles in the knowledge base are findable and usable by the intended audience. Identifying the intended audience is important because the audience defines the context for the KCS article. Ideally, the audience we are serving should be involved in creating and giving feedback on the articles. Unfortunately, not many organizations actually enable this.
KCS seeks to create content that is good enough to be findable and usable by a specific audience.
One of the key goals of KCS is to capture the context of the issue: the description of the needs and perspective of the requestor, in their own terms. To achieve both broad reuse and relevance, the reusable context for a given situation is contained within the KCS article, in its own section.
We have found that a simple, single structure works best. And, this same structure can serve many different needs including:
- simple Q&A
- technical issues (both simple and complex)
- how-to questions
- process instruction
- diagnostic procedures (both simple and complex).
These are the four basic, common elements or fields of a KCS article:
- Issue (symptom, problem, or question)—the issue is described in the requestor's words and phrases—what are they trying to do, what is not working, or what are they looking for? It is helpful to view this field as belonging to the requestor (even though it may be captured by the responder). It must represent the requestor's perspective and context.
- Environment—what product(s), category, or business process does the requestor have? Has anything been changed recently, such as upgrades, additions, deletions? The environment description should be as precise as possible, with standard ways to document product names, versions, or processes. The environment will remain the same after the issue is resolved.
- Resolution—the answer or the steps taken to resolve the issue.
- Cause—the underlying cause of the issue. Cause is an optional field as it is not appropriate or necessary for some types of articles. A simple Q&A, for example, doesn't need a cause. However, for complex technical issues, a cause can be very helpful in assisting the user in determining if an article is relevant to them.
The article also contains a collection of attributes that describe a variety of things about the article called metadata. Some of these attributes are added by the knowledge management system automatically, like dates, time stamps, versions, reuse counts, and the identity of the knowledge worker(s) that created or have modified the article. Other attributes are explicitly set by the knowledge worker as the article is created and used. This includes the audience, quality, and governance attributes.
Here again we must reiterate the "keep it simple" idea. Resist the temptation to over-engineer the the structure or the number of templates or the metadata fields. Make it as simple as possible and then try it. Evolve the structure, templates, and metadata based on the organization's experience. We have a tendency to want to make these things everything they could be in anticipation of the many ways we might use them. Don't do it! Use the principle of Demand Driven or, if you like, an Agile approach. Design it to be good enough to start and then plan to iterate on it: improve it based on experience.
Leaders should note that structuring KCS article content requires a change in behavior for the knowledge worker. There is a learning curve as the knowledge workers learn to capture and structure in their workflow. They have to learn to distinguish the event-specific content (the event itself) from the reusable content (what we learned from the event). Coaching is crucial at this stage as that is how we promote and create new habits. This represents an investment. However, as the Solve Loop practices become second nature and we capture our collective experience as articles in the knowledge base, reuse quickly increases and create activity decreases. The time invested in coaching to get "over the learning curve" will be more than compensated for by the time saved in the improved request-resolution process.
The KCS article contains the reusable parts of the experience, not customer-specific or proprietary information.
Details on the Resolution Field
The resolution contains the answer to the question, a workaround, or a fix to the problem. If the resolution contains a multi-step procedure, it improves article readability if we number the steps.
Sometimes the resolution requires authorized access, special tools or skills that the user or audience may not have. If the audience for the article does not have the access or resources to complete the resolution, the resolution should provide instructions like "contact your support center for assistance in resolving this issue." The support center should have access to a restricted field in the article (which the user cannot see) that provides the steps to resolve the issue. It is a good idea to have an article that the user can find to indicate the issues known. Including guidance for obtaining service in the resolution field of the externally visible article can help the requestor contact the support center and provide relevant information to the responder to minimize diagnosis.
Adding an "Internal Resolution" field in the knowledge article provides a place to capture a resolution that requires assistance. The "Internal Resolution" field is not visible to requestors even on externally visible articles. This is a technology requirement for your knowledge management tool. If we don't have that capability, we can create a separate article that is flagged as "internal use only" and linked to the externally visible article.
Details on the Cause Field
As we mentioned above, the Cause field is optional as not all issues have a cause (or the cause may not be known). For example, "how-to" articles never have a cause, unless you'd like to point out that the requestor didn't read the instructions or manual.
If the cause of an issue is known, it should be added to the knowledge article. This can be used to distinguish between two knowledge articles with the same issue description which are actually two different problems. For example, an issue of "I can't print" may be due to the printer being out of paper, out of ink, paper jam, or a number of other potential causes, each requiring a different resolution. When searching the knowledge base and multiple articles are found with similar issues, the cause within each article can be used to verify which problem exists for this reported issue.
An additional strategy of value to consider is to add an additional field related to the Cause field, called "Cause Test." In the "Cause Test" field will be the procedure or description of how to validate the cause. The requestor or responder can then use this test to confirm that the issue they have matches the knowledge article and will then have confidence that the resolution will address the issue. For example, a cause of "out of paper" may include a cause test describing how to check the paper level in the printer.
Multimedia as Content
Throughout this document, we have talked mostly about KCS articles presented as text. However, for certain audiences and for certain types of knowledge, multimedia proves to be far more effective than text. Many of the Consortium members are including pictures or screen shots, animation, voice and short videos as knowledge articles or as resolution to an article. Visual images can bridge language gaps and overcome translation issues. Voice and audio clips are also increasingly common, both for ease of comprehension and for compliance with increasing regulatory requirements for accessibility. As more organizations pursue self-service, multimedia formats can be very beneficial in speeding resolution and improving the user's experience. But again, it depends on your audience. The nature of the knowledge should dictate when and where multimedia makes sense.
The KCS methodology and processes remain the same, but the knowledge base and delivery tools may need to be adjusted to accommodate multimedia content.