April 16, 2014
How Do We Predict User Questions?
Many technical communicators struggle to define what type of information should be put into different types of manuals, and how it should be organized. At the same time, they’re faced with pressure to escape the book paradigm; the traditional book-like manual that is leaving customers frustrated in their inefficient pursuit of information.
Research within human-computer interaction and information science has shown that users often prefer alternative information sources to the traditional book like manual— whether the manual is online or paper based. One explanation is that users have difficulty finding information when it is organized in a static arbitrary structure, which doesn’t appeal to the logic of the user.
I receive many questions from technical communicators on how to design technical documentation so that information becomes easy to find. In previous articles from the Designing for the Searching User series, I make the case that technical communicators are answering user questions, and that instead of organizing information into books, we should provide search aids to make answers easy to find.
So how do we know what questions users ask, and how do we know which facets to use in order to build a web knowledge base, as in figure 1 (built according to principles described in part 3)? This article, part 4 in the Designing for the Searching User article series, addresses this question by describing how to predict user questions.
Figure 1: Example of a web knowledge base that mimics a human dialog, allowing users of a dishwasher access to predicted user questions. The user has searched for "Salt," and filtered the result list using the facet taxonomies
What Does it Mean to Predict Questions?
The traditional way of designing user assistance is to organize all the knowledge that users are required to possess for product use, with the exception of the knowledge we assume users already have, into the static structure of an on-line or paper, book-like, manual. We generally tend to assume that the user lacks knowledge on how to perform the tasks at hand. Thus, we try to find out which tasks the user is trying to accomplish, and then write the instructions on how to perform them. Such an approach explains why the traditional book-like manual mostly contains instructions.
Conversely, the design approach I describe in this article, (to predict user questions, aka dialogism), assumes that the user is active, and very often begins product use on the basis of existing knowledge, as minimalism has taught us. When stuck, users ask questions, and seek answers. This view assumes that users ask many different types of questions, and that a minority of them are actually task oriented. So, technical communicators are answering user questions.
But the reality is that we cannot answer every single question that users will ask - for that we would need a time machine. Since we work in pre-release mode, before the product has been launched to the market, no user has asked any questions yet. As a consequence, we must predict the questions. A single user would probably not ask all predicted questions. But the larger the user base, the more probable it is that some of the predicted questions will be asked by at least some users.
When predicting, we must try to be as accurate as possible. Some predicted questions are probably never asked, but I argue that we can predict the majority of the questions users really ask. To do this accurately, we need an architecture and a design methodology to guide us. Before I go into the details, consider the following example as an illustration of the principle.
An Example of What it Means to Predict Questions
Imagine a restaurant where a lot of customers are asking how long it takes to prepare various dishes. For example, "How long does it take to prepare meatballs and spaghetti?" If this happens to be a common recurring query within certain types of restaurants, it’s possible to define it as a type of question, such as "How long does it take to prepare [a dish]?"
Now imagine a new restaurant nearby, and its owner who wants to answer common questions on the restaurant web site. To predict how many questions of the type "How long does it take to prepare [a dish]?" customers will ask in this new restaurant, we need to know the amount of dishes that the restaurant can serve.
If the restaurant can serve 10 dishes, like pizza, tomato soup, etc., we can predict that there will probably be 10 specific questions: "How long does it take to prepare pizza?", "How long does it take to prepare tomato soup?" etc. To predict a question means to define a type of question, and then replace the variable "[a dish]" with one of the possible dishes.
How do we Predict User Questions?
Figure 2: Three steps to predict user questions
Imagine yourself a technical communicator who is responsible for documenting a product in a product development project. You have decided to predict user questions. Where do you begin? I will use the SeSAM (Search Situation based Architecture and Methodology) to guide you through the first three steps, (as in figure 2).
First Step: Decide Question Types
The first step is to decide which types of questions to use as a base for predicting questions. SeSAM includes a great number of pre-defined question types which you can start from. The SeSAM pre-defined question types are derived from a model of product usage behavior and information-seeking behavior. The model is based on academic research (using models and theories from information science, human factors, human-computer interaction, etc).
Examples of question types are "How do I [task] a [result]?" or "Where is [UI element] located?" I will return to the nature of these question types in upcoming articles in the series.
You could probably imagine other types of questions besides those pre-defined in SeSAM; some more relevant than others. You could let support engineers, sales people, etc. review the types of questions you aim to answer in the project. The result of the first step is a list of question types.
Second Step: Identify Product Variable Values
Each question type includes one or several product variable(s), such as [task], and [UI element]. The second step is to identify the values for each variable, specific to the product. According to SeSAM, you start to identify values for variables in certain question types. This is because you must know these values in order to identify values for other variables, stated in other question types. Thus, there are relations between variable values. For example, the user is clicking on a number of [UI element] within a [task].
The product and its design— such as the number of functions, available icons in the product interface, etc. — impact how many values you end up with. One important aspect to remember is that the question types and their product variables are not product specific, while the values you model for each variable are. The result of step two is a list of values (which can be organized in a hierarchy) for each variable.
Third Step: Predict User Questions
The third step is to predict a user question by replacing a product variable in a question type with the corresponding variable value, (see figure 2). Thus, the number of identified variable values impacts the number of questions you predict for a given product.
An example of variable values is icons in the product interface. Consider the question type, "Where is the [UI element] located?" If the product interface includes 50 UI elements, (such as "print icon", "save icon," etc.), you will predict 50 questions; such as, "where is the print icon located?" or, "Where is the save icon located?"
Creating a matrix helps you keep track of the question types, the variables and their values, and the predicted questions in a project. Each cell equals a predicted question in such a matrix.
The results of these three steps are the question types, the product variable values, and the predicted user questions. The question types are not shown to the user. Rather, they are meant as a design aid for the information architect to predict user questions.
These product variable values play a central role, as they are used not only to predict user questions, but also to classify answers and build facet taxonomies used to build web knowledge bases that mimic the situation assessment dialog, as in figure 1. The relationship between variable values also allows us to establish links between answers, helping a user find answers to follow up questions (referred to as bottom-up navigation). I will return to these matters in upcoming posts.
Traditionally, technical communicators need to make a lot of design decisions, (for example, this document includes 46 decision-prompting information design questions), when defining what type of information end users need, and how to organize it in a book-like manual. However a predictive design approach - dialogism - means that fewer design decisions need to be made, which saves valuable time.
When predicting, the technical communicator becomes as user-centric as it is possible to be. With the SeSAM approach to documentation, instead of managing a couple of user manuals for a given product, you manage many hundreds of user questions.
There are many aspects to consider when predicting user questions and writing answers. We must assume a certain knowledge level, which means that we assume the user knows, (or must know, to be enabled to use the product), the answer to some of the predicted user questions.
You might wonder – is it really possible to predict user questions? It is possible, and this is what SeSAM and exFinder are all about – allowing you to design for Findability.
Contact me at email@example.com if you are interested in a webinar about SeSAM and exFinder. And stay tuned for the next article in Designing for the Searching User article series, written by Excosoft information architect Jonatan Lundin.
Want more now? Click here to read additional articles from our bloggers at Excosoft.