May 14, 2014

What Types of Questions Do Users Ask?

A core skill required of technical communicators is the ability to determine what type of information end users need in order to achieve a particular purpose. Many technical communicators, including myself, struggle at times with figuring out what information to write and how to organize it. See for example a recent discussion on LinkedIn.

In my previous article , I discussed the principle of predicting user questions and introduced the concept of question type, which serves as a fundament to knowing what type of information to write. But what types of questions do users ask?

In this article, part 5 in the Designing for the Searching User series, I walk through a typical user scenario to illustrate how to outline the types of questions end users ask from the perspective of the searching user. But before we dig into the question types, let's take a look at the big picture.

The Big Picture

We perform a lot of activities in our daily lives. Each activity is propelled by a goal which we pursue to satisfy an underlying need. In the context of work tasks, a goal is related to our work role and responsibilities in a given business; for example to create, automate, protect, control or optimize something. As technical communicators, our work task goal is to "Write and deliver usable documentation".

We map out a plan of how we might best carry out the work task before we act, which means that prior to action we already have in mind what we need to do and what we need to know in order to do it.

If we decide to use a product to help us reach our goal, we must first find one. So then our work task goal is to "Evaluate products and select one". When, for example, a technical communicator has purchased a product the goal becomes "Install it and write documentation".

The user needs knowledge to be able to carry out their work task and reach their goal. If they are comfortable with what they know, they act without having to search for information first. If they are for some reason uncertain about what they know, they may not act.

The user needs information to reduce uncertainty. If the user realizes they need information, they end up forming another goal: to find information. An information need is expressed as a question.

All questions that users are predicted to ask are assumed to relate to the ability of a product to satisfy their given need, whether their questions are assessing the ability of the product to accomplish just this, or whether they are focused on figuring out how to make it work. Here, I assume that it is possible to define question types that are generic in the sense that they are not product or user specific.

Questions About the Relevance of a Product

Imagine a user who has the goal to "Evaluate products and select one". Somehow, the user gets to know that your company has a product. The user's goal is to verify whether or not your product is suitable for meeting their particular need. Here, we must assume that the user has basic preexisting knowledge regarding the typical range of products in the market, with a sense of what they can do and how they are generally used. The user may have previous experience with products that are in competition with yours, and based on this experience they judge that your product qualifies as a candidate for solving their need.

But the user lacks a certain piece of knowledge and becomes uncertain about what your product is all about and whether it is really the product they think it is. The user may have a hunch, but seeks confirmation. The first question type is therefore, "What is the purpose of [product]?". If your product is called "Software X", thus the variable [product] has value "Software X", then the first user question is, "What is the purpose of software X?"

Follow Up Questions

The answer to the previous question reveals what the product is particularly used for and thereby provides the user with confirmation that your product is in fact what they thought it was. For example, Software X is a content management system and offers the possibility to "create, manage and publish technical documentation as PDFs".

The answer "Create, manage and publish technical documentation as PDFs" presents in fact the values of two variables I refer to as [task] [main-result], (for an introduction to variables and values, see article 4 ). The main purpose of a product is to offer one or several different [task] [main-result] possibilities.

But still, the user may not be totally convinced that your product is the best alternative, and thus ask follow up questions in order to be really sure, (which was the original goal). The aim of follow up questions is to obtain more knowledge about the possibility to [task] [main-result]. Examples of such question types are "How is [task] [main-result] achieved on a general level?" or "What must I do in order to [task] [main-result]?".

Some users want to learn the basic principles of how a given possibility is achieved by testing out a trial version. Thus, answers designed as minimalist guided exploration cards may work well in this phase.

Questions About Detailed Possibilities

A user who knows what a product can do on the general level may not know whether their desired possibility is available. Since the user need is situated in a specific business context, which imposes requirements and limitations, users want to know if the product can be adapted to the user situation. Thus, users ask "Is it possible to [task] [result]?" or "Can I [task] [result]?".

Users ask such questions since they know that most products are designed to offer alternatives to how the main possibility may be crafted. Offering such usage alternatives makes a product possible to sell on a diverse range of markets and to many different types of customers.

For example, a user who knows that a content management system is used to "Create, manage and publish technical documentation as PDF" (the main possibility) and how PDFs are generally produced in the system may ask, "Is it possible to reuse XML topics?"

Follow Up Questions

When reading an answer which reveals the possibility to reuse XML topics, the user might ask follow up questions regarding this possibility in order to understand it in more detail. For example, "What is [task] [result] all about?" or "What is the result of [task] [result]?". For example, "What is the result of reusing XML topics?".

Being knowledgeable on an overall level regarding the possibility to reuse XML topics may lead to detailed follow up questions, such as, "Is it possible to [task] [result]?" For example, "Is it possible to reuse the same XML topic several times in the same master document?" So, in a sense the whole question cycle regarding what is a possible repeats, only on a lower level.

Questions About How to Perform a Task

As technical communicators we focus on user tasks, which is a good thing. But how do we know what task to write? I argue that the instructions we write serve as an answer to the question "How do I [task] [result]?".

Before deciding whether to act, a user must be confident that the result of the task is possible to achieve.  A user who knows that it is possible to reuse XML topics (the [result]), but doesn't know how to perform (the [task]), asks "How do I reuse XML topics?"

Now imagine a user who already knows that it is possible to reuse XML topics, as well as how to do it. However, the given product does not support reuse of XML topics. What happens? The user struggles and fails to achieve the task. In such a situation, the user would be compelled to ask, "is it possible to [task] [result]?" Thus, questions regarding the possibilities of a product are not asked solely when evaluating a product before purchase.

Conclusion

There are many more types of questions users ask, for example, as a consequence of trying to perform a task but failing to execute it. A user might not find a particular icon in the interface and ask, "Where is the print icon located?" Thus we define a question type as "Where is [UI element] located?" But, to delve into these question types is a topic for another day.

This blog post is based on an academic conference article titled "Towards a normative conceptual framework for information-seeking studies in technical communication." I am presenting this article at ISDOC 2014.

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 jonatan.lundin@excosoft.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

Did you miss previous articles in the series? Read them here: Part 1Part 2Part 3Part 4

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

Categories

  • Excosoft
  • Information Design
  • Info Tech Trends
  • User Experience

Latest posts

Looking Back on 2016

December 29, 2016

Skribenta 5 Now Released

December 12, 2016

More from Blog & News