Technique 5.1: KCS Article Structure

Articles Contain What's Reusable

A well-defined and simple article structure is a fundamental element of KCS. Knowing where to look for, and where to put, specific types of information improves efficiency and usability for humans and machines.

Articles capture what we have learned in responding to a request. 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.

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 incident management system.

Leaders should note that structuring KCS article content requires a change in behavior for the knowledge worker. There is a learning curve as 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 we promote and create new habits. The time invested in coaching to get over the learning curve pays off by the time saved in the improved request-resolution process. Once the Solve Loop activities become second nature and we capture our collective experience as articles in the knowledge base, reuse quickly increases and create activity decreases.

The KCS article contains the reusable parts of the experience, not requestor-specific or proprietary information.

Establishing a 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.) A simple, single structure works best. 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)

One of the key differentiators of KCS is capturing 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, each in its own section.

These are the four common sections 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 entities 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 (more on this in Technique 5.2: Article State).

Here again we must reiterate the "keep it simple" idea.  Resist the temptation to over-engineer 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.  It is tempting to make it everything it could be in anticipation of the many ways we might use it.  Don't do it!  Use the principle of Demand Driven. Design it to be good enough to start and then plan to iterate on it: improve it based on experience.

KCS seeks to create content that is good enough to be findable and usable by a specific audience.

Developing a Content Standard

How much structure is enough? How do we communicate across the organization so that everyone captures the appropriate information in a predictable format? This is the purpose of the content standard. This formal document or template built into the technology help fields describes decisions made about KCS article structure and content. The content standard should be developed and owned by the knowledge workers: the people who use the content everyday.  The content standard design should be done by a cross-functional team made up of people who will be using it to create KCS articles.

Through years of KCS deployments, the collective Consortium experience indicates that about 70-80% of the content standard is the same across large or diverse companies or organizations, while 20-30% of the content standard is tailored to a specific knowledge domain or division. Different groups may use different content standards, but they must be careful to keep enterprise-wide considerations in mind.

The content standard defines how we interact with knowledge articles to promote consistency. The content standard needs to cover a broad set of elements, including the following:

• KCS Article Structure, Definition for Each Field —a list of article fields with definitions for each.  Including issue, environment, resolution, cause, and metadata
• Good and Bad Article Examples—the contrast between bad articles and good articles reinforce the concepts and intent behind the field definitions
• Metadata Definitions—a list of the article attributes and the meaning and implications of each as well as how each metadata element is set (automated or manual)
• Article Confidence—as defined in KCS Article State
• Article Audience—who gets to see what as defined in KCS Article State
• Article Governance—mechanism for compliance based articles, defined in KCS Article State
• Templates—if we are using more than one template, a list of templates available and criteria for the use of each as well as directions for filling the fields out in each template 
• Style Guide—describes the preferred writing style for articles
• Supporting Material—format and criteria for references and links from articles
• Vocabulary—preferred terms aligned to the audiences' context and level of expertise, voice, standard for environment statements; platforms, product names, releases and versions; supports trademark protection
• Multi-language Considerations—writing guidelines that ease translation effort, may promote International English
• Multimedia Considerations—criteria for deciding what type of content and for what audience multimedia is appropriate 
• Quick Reference Guide—one- or two-page reference guide with hints and tips on how to write good articles (aligns with the content standard as a whole and especially the Content Standard Checklist).  See below for examples.

Multi-Language Considerations

The majority of Consortium Members operate in global, multi-lingual, multi-cultural environments. Both the markets for revenue growth and available talent and resources are in emerging markets where the language and culture are different from those of the home office.   Many companies in the high tech sector have standardized on English as the language for business, even though they are based in non-English speaking countries, serve markets, and have employees in non-English speaking parts of the world.  This presents some challenges when it comes to sharing knowledge on a global basis. 

KCS offers some relief in the area of multi-language support. If an organization adopts the recommended approach of "complete thoughts, not complete sentences,"  this creates the following benefits in a multi-language environment:

• Complete thoughts are often easier to comprehend than complete sentences
• The KCS structure gives meaning and context to the words and phrases in the article

The use of machine translation has increased dramatically over the past few years.  It is not perfect but it is gaining acceptance as sufficient for support content. Following are some examples of how companies are leveraging machine translation:

• "Just do it" - Use machine translation for all support content in the knowledge base and translate it into selected languages. Intel uses machine translation to offer their self-service in five different languages
• "Demand driven" - Limited machine translation; only articles that have reuse get translated
• "The hybrid" - A hybrid approach of machine translation with a manual post edit for reused articles
• "Side by side" - Microsoft has found that offering the original article along side the machine translated article greatly increases user's confidence and therefore use of machine translated articles

Consortium Members have access to years of conversations and presentations about knowledge translation and strategy (login required).

Multimedia as Content

For certain audiences and for certain types of knowledge, multimedia proves to be far more effective than text.  Many Consortium Members are including pictures or screenshots, animation, voice and short videos as knowledge articles or as a resolution in 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 accessibility requirements. As organizations design for self-service success, multimedia formats can be very beneficial in speeding resolution and improving the user's experience. 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, and the "flag it or fix it" process, may need to be adjusted to accommodate multimedia content. 

Consortium Members can find more information and an approach to incorporating video into KCS strategy in the KCS and Multimedia section of the Members-only wiki (login required).