March 19, 2014

How Do We Make Short Answers Easy to Find?

Current ways of delivering technical documentation-- such as via a PDF or CHM file, HTML web help, or Wiki, etc., all have something in common: content is organized in a static, arbitrary structure. In such a book-like format, the table of contents is often the user's only option when it comes to finding relevant information. It's an almost impossible challenge to design a static structure that everyone finds logical.

Many users find it cumbersome to search for information in such static structures, which is probably the main reason why they avoid user manuals. Additional search interfaces such as an index and free text-search, or even providing the possibility to dynamically filter out parts of the table of contents, do improve the user’s search experience to some extent. But, a user beginning their search from such interfaces may sooner or later end up in the table of contents, growing increasingly frustrated by the challenge of making sense of it.

Technical communicators need to move away from the book-like paradigm altogether, and provide user assistance designed to accommodate the information-seeking behavior of users. This means that answers must be easy to find on a mobile device or tablet. But, if we cannot organize information into static structures, what are our options? In part 3 of the Designing for the Searching User article series, I describe an alternative way to design end user assistance which I believe will make short answers easier to find.

What is the Information-seeking Behavior All About?

Users ask questions and search for answers when stuck in product use. Since technical communicators often work in pre-release mode, we must predict these questions. Once we have written the answers to these questions, we must make sure that they are easy to find.

I argued in part 1  that mimicking an expert-novice dialog, or situation assessment dialog, is a powerful way to make answers findable. Furthermore, in part 2 , I argued that users prefer short answers, if the user assistance makes it easy to find answers to follow up questions; similar to clicking on links in a Wikipedia article, where the linked article is opened in a new browser tab. Now, how do we represent the Situation Assessment Dialog in user assistance? Stay tuned to find out.

What is the Situation Assessment Dialog All About?

The novice asks the expert a question when stuck in product use: "How do I implement X?” Maybe the question is not clear to the expert, (which may happen as humans tend to be bad at expressing their information needs). Before the expert can give an appropriate answer, the expert assesses the situation by asking a number of follow up questions, like "Are you using product version 1.0 or 2.0?", or "What do you mean by X… do you mean module Z or module Y?"

The user responds to the expert’s situation assessment questions by replying, "I am using product version 1.0, and I’m referring to module Z". Once the expert has assessed the situation of the user, an answer is given.

The Starting Point - Facet Taxonomies and Answers

Figure 1

Figure 1: Each icon resembles a file containing the answer to a user question.The facet taxonomies are used to classify each answer, which enables technical communicators to design a search user interface that supersedes the book-paradigm.

While we cannot yet integrate human assessing capabilities into user assistance, we can design to mimic the Situation Assessment Dialog. I argue that faceted navigation and faceted search are components of the preferred underlying design approach when it comes to mimicking this Dialog.

Imagine that you have predicted and written a lot of answers to many user questions. There are various types of answers, such as procedural, conceptual, etc. Imagine that you, as part of predicting the questions, have developed a number of independent facet taxonomies and classified each answer to a facet value within each facet taxonomy.

For the sake of simplicity, the example facet taxonomies shown in Figure 1 are Shape, Size, and Color. Thus, each answer is classified to one facet value within each facet taxonomy. The icon in the upper right corner is classified as "Triangle", "Small," and "Red".

One can build a faceted navigation portal and display all the facet taxonomies at once, thus enabling the user to select any facet value in any facet taxonomy, similar to an e-commerce site. If the user selects "Red" in the color facet taxonomy, all icons (answers) not categorized as "Red" are filtered out. However, since a user could become intimidated by the presentation of too many facet taxonomies at once, we can instead disclose each facet taxonomy progressively, according to user selection. In this way we are mimicking a human dialog.

Example of Facet Taxonomies for Technical Communication

To make the example above relevant for technical communication, imagine now that the Shape facet taxonomy in Figure 1 represents various file formats that a software can output. Value "Circle" equals a PDF file format, value "Triangle" equals an RTF file format, and value "Square" equals a TXT file format. Imagine that the Size facet taxonomy represents different tasks the user can accomplish with the software. Value "Big" equals a "Create" task, value "Medium" equals a "Delete" task, and "Small" equals a "Move" task. Finally, imagine that the Color facet taxonomy signifies different product versions. Thus, "Red" equals product version 1.0, "Green" equals 2.0, etc. This example implies that each task is done a little differently depending on product version. Now, according to this particular classification, the answer (icon) in the lower right corner answers the question "How do I create a RTF file when using product version 2.0?"

Putting it Into Practice - Mimicking The Situation Assessment Dialog

Figure 2_new2

Figure 2: An example of a web knowledge base that makes short answers easy to find on mobile devices and tablets, by mimicking a human dialog.

Imagine a user getting stuck when using a product. The user navigates to the web knowledge base, as in Figure 2. The user knows what s/he wants to do, but is unsure of how to express it. The user asks a mental question, like "How do I  <a task I do not know the name of>  a <file format I cannot remember the name of>?”

In our example, the web knowledge base first displays the color facet taxonomy, where the facet "Color" is turned into a situation assessment question, such as "Which version of the product is your question related to?” The knowledge base displays the product version values as selectable options, as in Figure 1. Once the user selects the product version, all answers that are not classified to this value are filtered out, and those remaining are shown to the user, (like in an exFinder knowledge base depicted in Figure 2, where the results are shown in the middle column).

When the user has selected the product version currently being used, the size facet taxonomy is disclosed. The size facet is turned into a situation assessment question, such as: "What type of task are you trying to perform? Are you trying to..?". The values "Create", "Delete" and "Move" are displayed as selectable options.

When the user selects the task that corresponds to the situation, only answers that are classified to the selected product version and selected task are shown, which are a subset of the total number of answers in the knowledge base. The search progresses until there are only a few answers left in the middle column. With a few clicks, the user finds the answer. "How do I create a RTF file?" Check out a recent webinar  for an example of a web knowledge base that mimics the Situation Assessment Dialog.


The Situation Assessment Dialog is mimicked by progressively disclosing each facet taxonomy, which is suitable when users search from a mobile device or tablet since the dialog does not require a lot of screen space.

Mimicking the Situation Assessment Dialog is not an attempt to organize content in a static structure. In fact, it is not possible to build a table of contents directly from the facet classification. Instead, the dialog shall be seen as an addition to key word search. Most users typically begin by typing key words in the search field. The returned results can be filtered by either following the Situation Assessment Dialog, or by displaying all facet taxonomies and then make any selection in any facet taxonomy (which is referred to as a faceted search). But, some users prefer to start by following the dialog without typing any key words - something I refer to as guided navigation.

When following a Situation Assessment Dialog, the number of progressively disclosed facet taxonomies, including available facet values, are dynamic and dependent upon previous selections and search terms. The information scent increases as the retrieved results and the disclosed facet values decrease for each selection, which, in effect, motivates the user to continue searching. Furthermore, as the user makes selections to narrow down the answers, they also establish the context which is vital to understanding an opened short answer.

To build a faceted navigation portal from a system development perspective is a challenge, but it’s not the main challenge, (in Excosoft exFinder, you can use DITA subject scheme maps as input). The main challenge is to predict user questions and to know which facet taxonomies to use to mimic the Situation Assessment Dialog. This is what SeSAM and Excosoft exFinder are all about – allowing you to design for Findability.


Contact me at if you are interested in a webinar about SeSAM and Excosoft exFinder. And stay tuned for the next article in Designing for the Searching User article series, written by Excosoft information architect Jonatan Lundin.

About the author

Jonatan Lundin

Jonatan is a pioneering information architect backed by over 20 years dedicated to XML documentation, and designing for findability.

Post Comment


  • Excosoft
  • Info Tech Trends

Latest posts

More from Blog & News