February 19, 2014

Should the Answer to a User Question be a Short or a Long Topic?

A user asks questions when stuck in product use. Displaying information-seeking behavior, they search for answers; and it’s you—the technical communicator—who is responsible for providing them with one. But then you get stuck as you ask yourself: how long should the answer be? As the question of topic size, (as in a DITA topic), continues to be controversial in the technical communication community, we also need to ask ourselves how the size of an answer relates to the size of a topic. My conclusion is that users prefer short answers. Why is this? And how do we make short answers findable? This post, part two in the article series Designing for the Searching User, provides insight into how to design next generation technical communication.

Users Prefer Short Answers

Users ask various types of questions. A question is either detailed or broad. When it comes to detailed, low-level questions, such as "What is the product weight?", only a short answer is relevant. But for broad, high-level questions, the answer can be either long or short. This post will focus on answers to broad questions, such as "How do I install product X?"

One could argue that the length of the answer provided depends on the user’s knowledge level. The less preexisting knowledge there is, the longer the answer should be. However, I would argue that users of technical products prefer short answers, (no more than roughly 200 words), regardless of knowledge level, and regardless of whether the question is broad or detailed. Why? Because of the nature of human communication.

But you say: If a novice product user asks, "How do I install product X?” they will probably require more than a 200 word explanation to understand how to install it. Such a user will likely prefer one big answer, if they could be assured that the answer would consist of many small sub-answers, sorted and presented in a logical order, in intuitive anticipation of their needs.

But it’s impossible for a technical communicator to craft a long answer that fits everybody perfectly — because what is relevant content to one person could be irrelevant to another, due to, for example, difference in knowledge level, intended product use, etc. Also, it is impossible to publish a unique answer for each individual user—no matter the profiling support you have. Considering this, the longer the topic is, the more difficult it is to craft a topic which is relevant for everyone. And, the searching users do often believe that the long topic they find is not the perfect answer.

Consequentially, I argue that users prefer short answers in user assistance. Particularly if the user assistance environment is capable of providing a rich context, (is capable of clearly indicating which question an answer is answering), and if it gives the user the opportunity to easily find answers to chained questions in order to dig into the details. When I say that an answer needs to be short, I’m referring to when a short text, (including other multimodal expressions), is displayed on a screen or a page without other answers displayed below or after it. But, as we shall see, an answer does not consist exclusively of a piece of text that answers the question. The context, including links to follow up topics, makes up a firm part of the answer, like two sides of a coin.

Why Do Users Prefer Short Answers?

Consider the dialog I introduced in part one of this article series where the novice user asks the expert a broad question. The expert responds after having assessed the situation. Have you ever seen an expert answer a novice with an uninterrupted 2 hour long speech (which would equal a long topic)? Usually, the expert responding to a question provides a short answer and then waits for the reaction to gauge whether their answer was in line with what the inquirer wanted.

This is due to that many users are unsure of the nature of their uncertainty when stuck in product use, which means that they are having difficulties knowing what to ask. Such indecision leads to trouble in assessing the relevance of something they find, especially if the answer is large in terms of words.

There are several reasons why users prefer short answers. Let's look at three of them.

Users …

  1. Want to quickly judge the relevance of an answer. When users are stuck in product use they form a "mental explanation"; or pre-formulated idea, regarding the source of a problem, or possible solution, etc. This mental explanation helps them make sense of the "big picture". As users seek answers to solve the problem, they land on a piece of text. Before deciding whether to read it more carefully, they judge the relevance, to quickly verify whether or not it confirms their mental explanation. If it does, they are on the right path. If it doesn't, they may re-evaluate the mental explanation or re-formulate the question. Judging the relevance of a short text requires much less energy than a long text, especially if the user assistance environment provides a clear context for the short answer. And, it is easier to provide a clear context for short answers than for long ones.
  2. Want to be in control. Users want to be able to quickly change the direction of how the seeking process unfolds to not get lost. Users, especially novice users, want to decide for themselves which path to pursue to move from the big picture to details. Short answers are perfect for this; if the user judges it to be irrelevant, they can quickly move on— especially if the user is given the opportunity to easily find answers to chained questions. A long answer, on the other hand, may drown the user in irrelevant details, before they have grasped whether or not it confirms their mental explanation. The user may feel forced to skim a long text that seem to answers several questions, since the answer to a particular question may be buried in it; something the user cannot know.
  3. Don’t want to pay attention for a long time to the same thing. Our attention span has probably decreased due to the web. There are so many pages to explore out there, so why would someone read a long text when they might find something more useful a few clicks away?

Users Prefer Short Answers if the Manual Gives them the Opportunity to Easily Find Answers to Chained Questions

Users do not stop at one question when they are stuck on a problem. This is an important fact about how humans keep a dialog. As a consequence, users prefer short answers in user assistance; particularly, if the user assistance environment gives the user the opportunity to easily find answers to chained questions

We must help the user find answers to chained questions without compelling them to jump around in the manual. The solution is to supply a search user interface that assists the user in "collecting" many short answers for the purpose of crafting their own personalized "big" topic, without losing sight of the big picture.

In exFinder we expand upon the technique referred to as "related topics". Each short answer has a classification, (tags or facets), which is shown to the user as part of the answer. When a user clicks on a certain facet, they can select a related facet value to display chained answers. The title for a chained answer is formulated as a user question, to indicate a chained question. A user can open chained answers similar to opening separate tabs in a browser when using Wikipedia, for example. This way, the user is able to build a personalized collection of chained answers, which can then be saved or published.

Inline links may also be used, which the user can open in new tabs. An interesting alternative is to expand the linked answer within the first answer when the user clicks an inline link. This is how Excosoft’s CMS product, (formerly known as Skribenta) implemented navigation back in the 80s ;(exco = expand - collapse).

How do We Make Short Answers Findable?

Putting short answers into a book-like manual is not the solution. Users are complaining over the fact that the book format is fragmented, forcing them to inefficiently jump from one location to the other. The book is simply a useless way of providing context – and context, is a vital key to understanding a short answer.

Technical communicators often believe that answers are easier to find if they "live" in topics. But a topic-focus leads us astray. When we’re aiming to align with the information-seeking behavior of users, we must focus on answers, not topics. What is a topic anyway?

Technical communicators can craft different types of topics…

  • A short topic containing a short answer to a single user question,
  • A medium sized topic containing many short answers (each answering a single user question),
  • A long topic containing a long answer to a single user question,
  • A very long topic containing many long answers (each addressing a single user question)

From my point of view, a topic should include a single short answer. In the case of certain detailed questions related to technical data, for instance, we may build a medium sized topic, containing many short answers placed in tables. I do not believe that users find topics of type 3 or 4 useful for the reasons previously mentioned.

The solution is not to publish each individual short topic on the web with a unique web URL a la Wikipedia. This is because traditional ways of making the context explicit, such as through links, metadata or even the TOC, are simply not good enough for short answers. Without providing a proper context we’re only generating a pile of disconnected answers, such as a FAQ, which does not make sense.

Technical communicators are obliged to write medium sized or long or even very long topics as a consequence of lacking appropriate information architecture and tools that are capable of providing context and give the user the opportunity to easily find answers to chained questions. If this is our only alternative, we should stick to type 2 topics and use several subtitles to reveal each individual short answer. But, which short answers to embed into a long topic remains a mystery. Furthermore, how the user would find chained answers, existing outside of the current topic, to a specific short answer embedded within topics of type 2, 3 or 4, remains a design challenge.

So how do we provide a rich context for short answers in order to make them findable? In part one of the Designing for the Searching User series, I introduced the human dialog as a fundament in designing search user interfaces which allow the user to pick up on the context while searching via the situation assessment dialog. The SeSAM architecture is the framework you need to mimic the situation assessment dialog. Watch this recent webinar for more details about how this is implemented in exFinder.

Finally, a user assistance knowledge base is useless, no matter how easy it is to get the context or find chained answers, if it does not contain the answers the user is looking for. So, of equal importance is predicting the relevant questions; something I will return to in upcoming posts in the article series Designing for the Searching User.

Concluding Remarks

A user who wants a short answer is not satisfied getting a long topic. A user who is seeking a long topic has the possibility of "assembling" such a topic themselves, by opening several chained short answers. Short answers are also preferred over long ones when a user seeks content via a mobile or tablet. Plus, when we embed answers in the product UI (embedded user assistance) answers have to be short. Thus, as you can gather, short answers are useful for everybody.


You might wonder – is it really possible to design technical communication to mimic a human dialog (that is, the situation assessment dialog)? 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.

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
  • Information Design
  • Info Tech Trends

Latest posts

More from Blog & News