Research has revealed that professional knowledge workers spend up to half of their productive time on searching and in many cases they do not find what they need. This is especially true for users of technical documentation, meaning that a lot of productive time is wasted on people searching in vain.

Furthermore, the work space is challenging since the amount of information available to search is ever increasing and the time a knowledge worker has to spend on searching is in many cases decreasing. It is known from information science that findability is one of the prime concerns for professional workers when selecting an information source, thus they prefer information sources that give them reliable information at a low cost. The internet and social collaboration media has profoundly introduced new possibilities for users to get answers, allowing humans to be more efficient in finding information.

This blog post will introduce you to information seeking behaviors among users. The current article is based on Jonatan current viewpoint and does not necessarily mean that each statement is grounded upon academic research or empirical evidence. A follow up post will explore how to design for findability using a design methodology and architecture called SeSAM.

Why should I care?

Knowledge workers are sometimes users of technical products. Your business may be at stake if your company products documentation is difficult to use and especially difficult to find information in. When your competitors provide user manuals that are easy to search, your company might face the consequence of losing its business. This risk is increasing as the Google generation will soon be in charge as decision makers. Technical communicators have an opportunity to design documentation that becomes a business asset. But to do so you must understand the information seeking behaviors of users to know how to design manuals with high findability. So how do you design for the searching user?

In short, users perceive an information need due to a perceived uncertainty of not being able to make sense of how the process of using the product turns out. Users are active and goal oriented, trying to find an answer to the need to reduce uncertainty. Technical communicators must provide answers and make them findable. In the same way as a person is looking for a suitable travel or book to buy, browsing a travel agency site or book store on internet that provides rich search mechanisms to narrow down the current need, users of technical products should be provided with the same type of search capabilities when searching for an answer, where an answer is equal to a certain book or travel. To provide user manuals designed on the book paradigm, meaning that the only search user interface is an arbitrary static hierarchy of titles - table of content - like in a PDF or on-line help, is a dead end in future.

User focus is to solve a problem, need or requirement

Human beings are goal driven. There is an intention behind each human act (spoken or non-spoken). Users of technical products are also goal driven; they want to get things done. That is why humans are using technical products, for example office software or industrial hardware. Because they have found out that a product is the best way to solve a need, problem or requirement they are facing in their daily work and leisure context. They recognize a need, decide to do something about it when the pain of not solving the need is greater than the pain of finding and implementing a solution. The primary goal of any user when interacting with a product is to solve the need as fast, efficiently, reliable and securely as possible, not do tasks with the product because they are fun to do. Users generally avoid doing something that is not contributing to solving the need.

User perception about technical products

Humans have knowledge about all sorts of things and events, represented as a schema (according to some cognitive scientists). We know how a typical restaurant visit is like: that it includes a waiter, a table, and that you must order and wait for food etc. Many of us do have a schema representation of a typical technical product. This schema says that technical products are means used to solve a need, something I denote the primary goal of a user. The schema also tells us that a human often must interact with the product to make it solve the primary goal, that is, a user has to do various tasks throughout the products lifecycle. These tasks are done to reach, something I denote, the secondary goals. A number of secondary goals must be reached to solve a primary goal.

The product schema may tell the user that there are different types of secondary goals for example that the product must first be installed, configured and tested before it can be used to solve the primary goals. At some point the user must do maintenance on the product. A schema may also tell us other things such as that a product has certain performance and limitations and that is can be customized to suit various operating environments to solve different user needs. A general product schema is constructed from our experiences in using products, which means that there no such thing as a common unified schema model that all users share. Experienced users have several schemas for different types of products. Some have a vague general schema invoked when thinking about any technical product.

Now, when users see or interact with the user interface of a particular product, the product schema is invoked and "filled in" as the user constructs a mental model about the current product. The mental model tells the user a lot of things, for example what specific primary goals the current product can solve and what specific tasks must be done to solve the secondary goals. Users try to employ a strategy from the mental model on how to interact with the product to reach both the primary and secondary goals. Some product user interfaces can communicate its use to some extent, which helps the user to construct valid mental models and make correct decisions.

A user can probably perceive the mental model to be clear or vague. Novice users are probably only capable of constructing a vague mental model. When learning to use a new product, users often try to understand a product by reference to what they already know about similar products. They assimilate old knowledge when building new knowledge to make sense of the world. Many experts probably perceive their mental model to be clear and rich. A user can probably also be confident or uncertain about the mental model, meaning that a user may know that they do not know or they know that they know. Furthermore, users also display a certain personality when using the product. A user can be a systematic non-risk taker or an irrational risk taker.

User strategy and behavior to solve a need using a technical product

How du users use a product to solve a need? Users are active and goal oriented. They are active in a sense that they constantly try to interpret the world around us to make sense and meaning from what they see. They are goal oriented since their focus is to reach a primary goal as safe, efficiently, securely and easy as possible. The general product schema tells us that we must do tasks. Users are then focused on doing real tasks to reach real goals. The product interaction starts out from wanting to reach a secondary goal to then solve a primary goal. Here it shall be noted that there are cases where users do only know and care about the secondary goal, especially for large complex industrial products, which means that they do not know about what primary goals a product can solve.

How confident the user is about the mental model probably affects the behavior since users are "energy calculative" and tries to find the path of least of effort. If a user is uncertain about the mental model and how to do a task, the user would probably not start to try the product out since the consequence could be a waste of a lot of energy before the goal is finally reached. And, users do calculate the risk and consequences of doing something wrong. Users do not try if they perceive a risk of damaging equipment or even worse, injuring humans, due to doing a task wrong. Then it is better to first get a confirmation on the strategy, by finding additional knowledge about how to do to make the strategy more solid. If the user is certain about the mental model and strategy, then the most energy saving behavior is to start to follow it since putting effort on doing something else, like reading about a task, is a waste of energy.

But many users strike out into the unknown, they try a little to see if they maybe are successful. Users stick to what they know and are often not interested in learning new things; especially not to learn task that are not in the current focus, meaning tasks that maybe needed in future usage situations. This is especially true for products providing an undo possibility which many software offers. Users try since they know that they can revert to a previous state, without causing any damage.

When do users experience a problem and what do they do?

A problem shall here be seen as a situation where the user cannot perform a secondary goal task in a straight forward manner using the mental models and existing skill set. Such a problem occurs for a number of reasons. As said above, a user can perceive the mental model to be clear or vague and the user can be certain or uncertain about the mental model. And, the user can be irrational or methodical.

But the perceived model can also be more or less in accordance with the product design. A methodical user that  perceives the mental model to be clear, that is in accordance with product design, where the user is certain about it (knows that it is correct) usually means good performance. An irrational user that perceives the mental model to be clear, that is not at all in accordance with product design, where the user is certain about it (do not know that it is incorrect) usually means bad performance. This type of user is trying to do a task and fails because the user is not following any of the possible paths required to use the product successfully. A user is making wrong decisions and end up in a situation fully occupied in trying to make sense of what is going on in the interface. Here the user is putting a lot of cognitive effort in problem solving and decision making. The user gives up when all possible problem solving solutions are tried and decides to find external help.

A methodical non-risk taker that perceives the mental model to be vague, that is or is not in accordance with product design, but the user is uncertain about it (not sure whether it is correct or not) has a certain implication. The user does have a goal to do something but decides to acquire more knowledge to either confirm a belief or construct a new mental model. They are uncertain about how to interact and are not willing to try, so they decide to get external help even before trying to interact with the product.

Here, minimalism comes into play. How do users, that are certain about an incorrect mental model or uncertain about a vague model, correct or construct a mental model? These users decide to step out from a situation where a secondary goal is reached for to seek help. Minimalism says that many users are not willing to invest in a lot of reading to learn how to do. They prefer to learn by doing and exploring, meaning that they acquire a valid mental model and in turn a schema by acting. That is why minimalist documentation shall encourage the user to explore the product in their own instead of guiding the user through detailed step-by-step instructions. And, provide error recognition and recovery information since it is likely that the user will err as a consequence of discovering the product.

This is especially true for products that are a paradigm shift on how something is done, like when the word processor was introduced. In this case a user probably has a clear mental model about the previous technology and assimilates it when constructing a new mental model where the new model in many cases becomes incorrect due to the differences in technology. A remark here is that many users of today do not even invest time in exploring the product. They probably prefer just the detailed step-by-step instruction needed to solve a problematic situation and do not care about learning, since our modern hectic world do not allow us to spend time on learning on our own. Here, the piece of instruction must be very easy to find. 

There are probably several types of incorrect mental models. A user may have a goal to do a task that is possible to do (like printing a document) but the strategy on how to interact with the product is not in accordance with the product design. Or a user may have a goal to do something that the product is not supporting (like when a user is trying to export XML which is not possible). In some cases the users may find ways of successfully use the product that the product designer never thought of. A product may also include possibilities to solve primary goals that the user is not aware of.

What happens when the user decides to get external help? The user senses a gap in knowledge which leads to an information need. Users start to search for information to bridge the gap. The user is located in a search situation. Users formulate a third goal strategy which is to find information to resolve the problematic situation. Users form a "mental question" that is related to the secondary goal and in turn the primary goal they are trying to accomplish. They are focused on finding the answer to the current need, not just ad-hoc read what-ever type of information.

Users display an information seeking behavior. Some users are broad scanners, some are deep divers. But nevertheless, users are "energy calculative", meaning that users employ a search strategy where they do not spend too much energy on searching before giving up. The amount of energy a user is willing to put in to use the product and search for information is probably proportional to the need of solving the secondary or primary goal. But, to search in a big PDF having a table of contents on many pages where content is organized in a product centric way, require a lot of energy which many users are not willing to put in.

Users possess a search vocabulary used when formulating the mental question. The search vocabulary and mental question is probably built up from the current mental model and the general product schema. From the information science literature, it is known that human do have difficulties in expressing or vocalizing the information need. It is unrealistic to ask the user to say exactly what he or she needs to know since it is the lack of knowledge that brought him or her to ask the question and use the manual. Users frequently cannot define what they want, but they can discuss why they need it. That is why the solution is not to provide a key word box and let the user enter the key words to search for. Users do in many cases not know the key words to use or they use the wrong ones.

There are probably many "faulty" search situations. Users are maybe trying to do a task in pursue of a secondary and primary goal that the product is supporting and end up searching for a completely different task that is also possible to do, believing that the task they found corresponds to what they are trying to do. Or users are maybe trying to do a task in pursue of a secondary and primary goal that the product is not supporting and end up searching for a task that is possible to do, believing that the found task corresponds to what they are trying to do. These situations occur since the user denotes things and tasks differently than what the product designer denotes the same entity. Users are also in many cases so focused that they miss obvious information that would solve their problem.

When users approach an information retrieval system, such as a PDF; on-line help or a wiki, they must formalize the question to be suitable for the system in question. This implies to re-formulate the question. Initially the user might ask "Why is the task X I'm trying to do not possible?". Such a question must be re-formulated to "Is it possible to do X?".  Furthermore, there could be a time constrain in a search situation. Many times a user is in a hurry or feels that information must be found quickly to avoid damage or injury.

How does a user find help? Who can answer?

First of all, who can provide the answers? The user interface can answer many questions since it sometimes can communicate its use (affordance). But a product interface that cannot communicate its use means that someone else must provide the answers. There are in practice two parties that can answer user questions: other users and the community of individuals that represents the manufacturer. Let’s look at these two parties.

Users often turn to others users, like colleagues, friends etc. Another user is anyone who is perceived to have the answer. Social media has a huge impact since now the whole world of users is reachable.

How do technical communicators fit into this new social media collaboration paradigm? That is a question without any answer yet. To me, a manufacturer of a technical product has a responsibility to provide answers. At least a responsibility to answer all questions addressed to them. A manufacturer can take on a predictive or reactive approach to answer the questions that arise for a specific technical product. In a reactive approach, questions are answered as they arise, which the support department is responsible for.

In a predictive approach, technical communicators are predicting user questions (or that is what technical communicators should be doing) and preparing the answers before the question is stated. This approach is possible since technical communicators often work in a pre-release mode. But we can’t predict all possible user questions in advance. Simply because there are a number of uncertainties. We cannot know the intentions of the user; what they are trying to do with the product. We do not know the mental models and knowledge of each individual user, so we cannot know exactly which questions user will ask. We cannot know which questions other users will answer. We cannot know which questions a user turns to another user or the manufacturer to ask for an answer. This means that some questions have to be answered post-release.