October 9, 2014

Why is it Important to Design for the Searching User?

In the Designing for the Searching User series I discuss how to predict user questions, and how to make answers findable. But equally important, is to discuss why we are doing this in the first place, and what it actually means. This edition to the series is devoted to addressing these questions, and to supplying technical communicators with some solid arguments for why now is the time to change our approach to user experience design.

So, why is it important to design for the searching user?

Because if we don’t, us technical communicators will be out of a job. Moreover, certain types of companies may go out of business if they doesn’t invest in new ways of meeting the quickly evolving demands of users and customers— who nowadays expect to receive answers as quickly as they can supply a question.

If we as technical communicators continue designing according to the book paradigm, we face the risk that our employer will cut back on technical documentation budgets in favor of other, more efficient solutions, such as social customer support, or virtual assistance.

It’s important to defend our positions as technical communicators because the rise of “competitors," such as social customer support, (like Zendesk, Lithium, Freshdesk, and Humany to name a few), is growing at an alarming rate. And if competitors can offer a better user and search experience, you and your company risk being outperformed, even if you provide a better product.

Bottom line: to stay competitive in our field of technical communication, we must embrace change and design for the searching user of today.

But why aren't users using the user manual?

Users with questions related to product use are well aware of the plethora of information sources they have to choose from. Research has shown that users avoid traditional book-like manuals, which are often not their first, second, or even third choice. This is because users often find the manual difficult to navigate.

Research tells us that users tend to select the most accessible information source— most often, a fellow human being. Contrary to popular belief, Google is often not the first choice.

However, if a physical human is not around, Google may become the searching user’s preferred option.  Google is technically not an information source, but rather a filter assembling a list of information sources deemed relevant to a given query. But the fact that Google sorts information sources by relevance does not necessarily mean that users apply the same relevancy judgment criteria. This has to do with something often referred to as pertinence, precision, and recall, which I'm not going to address here.

If the manual you’ve designed never "makes it to the top results," according to the user's relevancy judgment, it has a slim chance of being used at all. And even if a user does engage with it, they are bound to get frustrated by how difficult it is to find what they need. This drops the manual even lower on the list of preferred information sources they’ll consult the next time they have a question.

Bottom line: to make technical documentation rise in popularity and usability, we must design for attractiveness—so that it gets selected when, for example, listed on Google results page. 

How do I get started designing for the searching user?

Designing for the searching user means much more than simply adding new metadata to your legacy book-like content, chopping it up into topics, and making it available in a dynamic browser environment.

It starts by understanding users and their behavior. Users are active and goal oriented. When they see your product, they form a mental model which tells them what your product is all about.

A mental model is formed via the assimilation of prior knowledge and experience. If a user feels certain about their imagined model, they start to act. Even if they are uncertain, they may well try and see what happens when they act, so long as they judge there to be no risk of unwanted consequences (such as damage or injuries).

If the self-created mental model a user consults is not in accordance to how the given product was designed to be used, the user winds up asking questions. There are many types of questions users ask, as I've outlined in part 5 of Designing for the Searching User.

Bottom line: technical communicators must have an understanding of user and information behavior before they can begin to predict user questions, and write the appropriate answers.

How do I make answers easy to find?

To make answers easy to find, I claim that the user interface of a user manual must engage in a human-like dialog with the user. This is because we find the dialog we keep with fellow human beings to be the most accessible way of finding an answer. One reason why online forums and social customer support centers are growing in popularity is because they mimic the human dialog— containing both the relevance and situation assessment dialogs .

Mimicking the human dialog in technical communication entails reconsidering the way we write titles and design taxonomies, since they are the central components that maintain the dialog. Packaging answers in a static book-like structure, on the other hand, is a dead end, as such a structure cannot maintain a dialog.

When a user arrives at a Google search results page, for example, they may become unsure about the relevancy of the found page. If this were to happen in a human-to-human dialog, the user would react by asking a relevance assessment question, aka a follow up question, such as, "What do you mean by ____?”. Mimicking the relevance assessment dialog provides the user with a larger context, enabling them to assess, for themselves, the relevancy of a found page.

Follow up questions initiate a chain reaction of questions and answers. To accommodate this, we need to make sure that follow up questions and their answers are easy to find. In technical communication, I find the concept of "related topics" as a means to providing answers to follow up questions.

Bottom line: answers are easy for a user to find when they are provided within the context of a human-like dialog.


Figure 1: Technical communicators must find new approaches to designing user assistance. Dialogism, which is based on the dialog between an expert and a user, is one such approach. 

The big bottom line: it's all about dialogism

In this post, I discuss why we should design for the searching user, and what it actually means. This could be one way of demonstrating our value in our company.

The technical communication design approach I promote throughout the Designing for the Searching User series is something I refer to as dialogism. Fundamental parts of dialogism include the situation assessment dialog, and the relevance assessment dialog. Faceted search and navigation can be used to mimic the dialog when designing user assistance, as outlined in part 1 of this series.

Designing according to dialogism will ultimately change what we technical communicators are. We will no longer be what we used to be.

SeSAM is a methodology for designing according to dialogism, or for the searching user. Contact Information Architect Jonatan Lundin at jonatan.lundin@excosoft.com to learn more. 

Explore previous editions of the Designing for the Searching User article series via the links below, and stay tuned for upcoming ones! 

Previous series editions: Part 1Part 2Part 3Part 4/Part 5/Part 6/Part 7

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
  • User Experience

Latest posts

More from Blog & News