Boxes and Arrows: Stories by John Ferrara

Strategies for Improving Enterprise Search

John Ferrara — Tue, 11 Sep 2007 19:27:08 GMT

It's common for enterprise website developers to implement search engines with out-of-the-box functionality, point it at their content repositories, and then just leave it at that. Search is becoming something of a neglected orphan, in part because packaged search products are relatively easy to implement, and then even more easily forgotten.

Unfortunately, the results are too often plagued by problems. You know something's gone wrong when a perfectly clear query returns results that are not only irrelevant, but seemingly deranged. Pages with a logical relationship to the initial request compete for placement among what Jared Spool fittingly calls "wacko results."¹ The majority of participants walking into my usability tests report they don't trust embedded site search to help them find what they're looking for.

Quality search results only come about through applied effort, requiring in particular the skills of an information architect.² And IAs must be ready to go well beyond their traditional front-end role, digging into the functional backend and source data of the search engine. This article outlines how we can bolster findability and win back users' confidence.

Conceptualizing the Task

The results of any given search are impossible to predict with precision (short of having tried it before). That's because five distinct variables combine to determine its outcome (Figure 1):

Search engine. The algorithmic gears that parse the query and assign pages relevance.
Content. The documents searched.
Index. A catalog of the locations of every word in every document. This is what allows Google to miraculously find 5 billion instances of the word "the" in 0.2 seconds.
User input. The keywords and other parameters the user submits.
Results display. The way the data returned by the search engine is presented.

Figure 1. Five variables that determine the success of a site search.

Critically, the search engine isn't the only factor that determines the outcome, so search can't be seen purely as a technology problem. It's important for organizations to realize that their investment in search doesn't end with the product's implementation; the most successful approaches will go further to include strategies addressing all of the outside variables.

Strategies

Several engine products allow you to tweak the search engine's algorithm itself, but I don't recommend it. That would be like doing brain surgery to fix a speech impediment—whether or not you solve that problem, you'll inevitably cause a great many more. Changing the algorithm affects all searches, including the ones that already work just fine. So it's easiest to keep it stable and modify the factors surrounding it.

Taking the search engine as a constant, then, there are four variables that affect the quality of search. Strategies for improving each of these are proposed below.

Strategy 1: Make the Content Machine-Readable

Search engines can provide better results when they're given better content. The trick is to provide a basis for inferring the content's meaning.

Structural Markup

The XHTML structure of pages is relevant to the IA, because content that is more machine-readable will be easier to find using search. Pages should extensively use the correct semantic elements: <h1> through <h6>, <p>aragraph, <q>uotation, <caption>, and so on, as well as semantically named "class" attributes. This will help the search engine compare the usage of terms among pages, to distinguish the central topic of a page from peripheral concepts (Figure 2). While IAs typically don’t mark up individual pages, they can influence the process by specifying template-level semantic elements in their wireframes and participating in periodic content reviews.

Figure 2. Structural markup explains that Jupiter is the central topic of page A, while in page B it's just one of several subpoints on observing planets.

Standard Meta Tags

Most websites use keywords and descriptions in meta tags, but not often as part of a larger strategy. The first step is to create a controlled vocabulary, a standardized set of keywords.³ If you tag them as "teachers" over here, but "professors" over there, the search engine will have a hard time understanding why they're the same thing. The keywords should also reflect actual terminology from the page itself (especially headings) and be reinforced in the description tag.

More Metadata

Go beyond keywords. Tags that describe the target audience groups, the sector of a financial service, or the cuisine of a recipe page provide more ways to compare and contrast the content; search engines will read as much meta information as you give them. There is a practical limit to how much you can do, which makes user-defined tags well worth considering.

Ontology

Humans know that pugs are dogs, and dogs chase cats, and cats play with yarn, but these relationships are lost on computers. An ontology is a list of concepts linked by the ways they relate to one another (Figure 3), helping the search engine grasp the content's meaning. If your search product supports ontologies (several do), this can significantly improve the quality of the results.⁴

Figure 3. An ontology explains the relationships between concepts.

Strategy 2: Index All of the Right Data

Indexes have made searching remarkably expedient, but the way they're built has a lot to do with the quality and reliability of results. Proper indexing requires taking a hands-on approach, and the IA has an interest in working with the development team to influence it.

Ignoring Unnecessary Content

Search engines will automatically index the entire content of a page, regarding everything as equally important. This is a problem because the navigation, for example, will contain terms that are specifically relevant to the siblings, parents, and children of a page, and not to the page itself (Figure 4). There are several methods of excluding this content; the important thing is to make sure that it's done, because this is one of the most common reasons why searches return bizarre results.

Figure 4. A search for "Neptune" may return results that include this page about Jupiter because the term "Neptune" appears here in the navigation.

Getting All Resources

Users reasonably expect a search to return all of the website's relevant publicly available documents. Unfortunately, many search products can't index .pdf, .doc, .xls, .ppt, and similar files, and you can forget about content locked away in audio or video files. The best fix is to convert application files to XHTML and provide transcripts or summaries of multimedia files. This can be a big job, so you may want to initially convert just the most commonly accessed documents.

Strategy 3: Make the Most of User Input

It can be difficult to figure out how to phrase a query. Users have to express what are often complicated concepts in that particular set of words that a given search engine will like. It's important to make the most of what users submit on their first attempt, because they're much less likely to make a second.⁵

Query Expansion

All contemporary search vendors offer some type of query expansion, where the search engine automatically looks for words related to the ones the user actually entered (Figure 5). Word stemming, which searches for different forms of the same word, is usually enabled by default. However, the thesaurus, which searches for equivalent and related terms, requires manual work.⁶

Figure 5. Searches shouldn't only look for the terms as the user entered them, but for related and alternate forms of those terms.

You can go overboard defining synonyms, but the problem is usually too little (by which I mean "none at all") rather than too much.⁸ Search logs are the best resource for discovering synonyms, related terms, and common misspellings. Set up ongoing reviews to add terms that users actually submit to the thesaurus, drawn from the wealth of data that's freely available in the logs. The number of successful first attempts will rise dramatically over time.

Syntax Conventions

Users should be able to submit searches in whatever way they learned to write them. Unfortunately, search engines have different syntaxes for the standard operators (And, Or, Not, exact string). You can't rely on a help file—it's one of people's least favorite things to read. The parser should instead be scripted to accept all common syntax conventions, so the user doesn't have to guess. It should also use "And" as the default operator, which will appropriately limit the results downward as more terms are added to the search.

Assisting Query Formulation

Suggestion functions provide users with a list of similar queries that other people have tried as they type. This makes a lot of sense, since it can be difficult to put a complex idea into words or to recall the precise name of an item. Stellar examples of suggest functions include Google Suggest, AllTheWeb, and Apple's website.

Strategy 4: Build the Results Page Around the User's Needs

The results page should be designed to help users find matches for their interests as quickly as possible. This is closer to the IA's typical interface design role, yet it's still uncommon to see much more than the vendor's out-of-the-box functionality on search results pages.

Showing Relevance

Sometimes a search engine will return the right results, but the user will fail to recognize it. Users need to see why results are relevant to their searches. There are two simple ways to do this.

The first is to show a text excerpt from the page that contains the terms from the user's query, instead of the <meta>description field. The description may vary greatly from the user's entered query—especially on long pages—and it may not be at all clear why a particular page was retrieved. Instead, an excerpt of the actual content that matches the search will directly explain why a user might want to click through to that page.

The second way to show relevance is to bold the terms in the excerpt that match terms in the user's original query. That will help the user to quickly scan the page for the results that have the right words in the right context (Figure 6).

Figure 6. Excerpting and term highlighting allow the user to understand how each result relates to the query, and quickly identify the ones that are most relevant.

Best Bets

Despite all optimization efforts, search engines sometimes still miss strong associations that are obvious to people. In cases where particular keywords should be returning specific pages, it can be helpful to include a list of manually specified "Best Bets," triggered by business rules (Figure 7).⁸ This reintroduces the designer's influence into search, smoothing out irregularities in the reliability of automated results.

Figure 7. Best bets allow the designer to force particular pages to be returned when the user's query contains a specific string.

Conditional Content

Taking Best Bets one step further, consider including contextually appropriate content in the search results page when a string in the user's query indicates the user probably has a particular interest in mind. For example, a user searching for "extrasolar planets" on an astronomy website might appreciate a results page that includes a list comparing the properties of all planets discovered beyond our solar system.

Conclusion

This article introduces just some of the steps that you can take to improve the overall search experience on your site. The reliability of enterprise search needs significant improvement to reestablish user confidence, and IAs should take the lead. To get there, a product's out-of-the-box functionality must not be seen as the end, but as just the beginning.

REFERENCES

¹ Jared Spool: "BBC Reports Users Lose Patience with Poor Search"
² Lou Rosenfeld & Peter Morville, Information Architecture for the World Wide Web, pp 136-137.
³ Fred Leise, Karl Fast, and Mike Steckel: "Creating a Controlled Vocabulary"
⁴ Tim Berners-Lee: "The Semantic Web"
⁵ Jared Spool: "People Search Once, Maybe Twice"
⁶ Christina Wodtke, Information Architecture: Blueprints for the Web, pp. 137-140.
⁷Lou Rosenfeld & Peter Morville, Information Architecture for the World Wide Web, pp. 188-189.
⁸ Chris Farnum: "Tuning up Site Search"

Search Behavior Patterns

John Ferrara — Wed, 30 Jan 2008 17:10:22 GMT

A search engine on an organization’s website or intranet is often built to support an overly narrow model of user behavior, which goes something like this:

User types in a search
Search engine gives back matching results
User reads the results and picks the best one

Simple. Better still, it asks very little of the user interface—only that it provide some way to submit a search, and some list in response.

However, such simple models overlook the fact that humans are complex, convoluted, capricious, mutable, moody, multifaceted beings with broadly differing backgrounds, competencies, and frames of reference. (1) In practice, this can make the requirements for search interfaces quite a bit more complicated.

The good news is that while users vary widely in the ways they search, their behaviors follow a limited number of identifiable patterns. By examining the factors that cause variability in user behavior and considering personas that illustrate those variations, we can identify common search behavior patterns and the interface affordances that support them.

Factors that affect user behavior

Search behavior is the result of interplay among several independent factors the user brings to the search operation, six of which are described below. Designers have no more control over these than they have over the color of the user’s hair.

1. Domain expertise
User behavior has a lot do to with a user’s familiarity with the subject on which he or she is searching. When searching outside a domain of expertise, people will be less certain where to start, use less precise language, and have more difficulty evaluating search results. By contrast, experts in a field generally know what verbiage will work best, and so generally get better results, from which they’re better able to discern the most useful documents. (2)

2. Search experience
Users who have a better understanding of the breadth of a search engine’s capabilities have more ways to go about finding information. If you know how to use Boolean operators, exact strings, filtering controls, and have proven strategies for exploiting search, then you have a much richer toolset at your disposal. But search experience also isn’t an absolute requirement for success. We have seen that users who are short on technical know-how but rich in domain knowledge can often get by. On the other hand, technophiles can have great difficulty finding information in an unfamiliar body of knowledge.

3. Cognitive style
User behavior is also influenced by the way users assimilate new information. Researchers like Nigel Ford and his colleagues have proposed a number of schemas to describe cognitive style, but for the purposes of search it makes sense to think of it as a spectrum ranging from global to analytical thinking.

Global thinkers first try to build a broad level of understanding across related topics.
Analytical thinkers dive right into a single topic and research it thoroughly to resolve a specific problem.

Most people lie somewhere between these extremes, sporadically using either cognitive style but tending more often toward one. (3)

4. Goal type
Search goals will vary from one query to the next, and may be broadly classified into three categories as outlined by Andrei Broder in his article “A Taxonomy of Web Search:”

Navigational searches are efforts to reach a particular location, such as an intranet’s timesheet application.
Informational searches seek out any documents relating to a topic, like a description of employee benefits.
Transactional searches occur when the user primarily wants to accomplish something online, like changing her benefits elections.

5. Mode of seeking
The extent to which users understand what they are trying to find determines their mode of seeking. The level of understanding can range from known items, where people know exactly what they need and how to describe it, to much more exploratory searches, where they have only a loose concept what they want to find. (4) Furthermore, as Marcia Bates pointed out in her oft-cited 1989 paper “The Design of Browsing and Berrypicking Techniques for the Online Search Interface,” information needs are often unstable and may evolve as a user learns more about a subject area.

6. Situational idiosyncrasies
To add a final layer of unpredictability, search behavior can vary for the same user with the same task, due to idiosyncrasies in external pressures, working context, temperament, or mood. For example, a user who is nearing a tight deadline is likely to behave very differently than a user who is just leisurely exploring the same topic out of general interest. People can also approach search tasks differently simply if they’ve had a bad day, feel tired, stand to make money, or feel especially engaged in a topic.

Personas

Grounding abstract ideas in concrete personas can help bring all of these factors to life. Personas are descriptions of typical users that illustrate key attributes that are relevant to the design of a website or online system. An understanding of the motives underlying user actions, like those detailed above, provides a great starting point for authoring personas.

For instance, the hypothetical people described below each illustrate different areas of domain knowledge, and represent a spectrum of search experiences and cognitive styles. They will be used to relate the factors above to the common search behavior patterns that follow.

Andrea is a technical wiz who is completely comfortable with search engines. She is a project manager for a mainframe manufacturing division of her company. Her cognitive style tends to be analytical.
Dmitry has moderate technical know-how. He works in the benefits administration division of his company’s HR department. He learns new information globally about as often as he does analytically.
Kazue is generally uncomfortable with technology, but is a recognized expert in her field of instructional design. She tends to be a global thinker who prizes an understanding of the big picture.

Patterns of Behavior

Despite the large number of variables tugging user actions this way and that, they translate into a relatively small number of common patterns of behavior. In my work, I’ve observed six broad patterns, described below with recommendations for accommodating each.

1. Alternating between search and browse
When searching, users will often select a result that is closest to the topic they have in mind even if it isn’t a precise match. They’ll then follow the links on that page to find their target information. A global thinker like Kazue might do this if she were exploring an information goal outside of her domain expertise. Unable to formulate the search phrase precisely right, she would need to trust the results returned by the engine. Finding that they’re promising but not quite right, she may switch to browsing before returning to the results page.

In effect, searching and browsing can function as a single behavior, with many people moving fluidly between both. These users see no distinction between the two, since both work in support of a single information seeking task. This means that improving the quality of a site’s navigation will necessarily also make searches more successful.

Design recommendations:

Support robust cross-linking on each page, so that when users reach pages that are near matches they can easily get to the best matches.
Include conventional hierarchical cues like breadcrumb trails and contextual navigation, as well as nonhierarchical, associative links among topically related pages. (4)
Don’t let pages come to a dead end, without any links to other resources on the site.

If Kazue is able to easily cross-link among related pages, this hybridized searching/browsing behavior will be more effective.

2. Minimizing the results set
Users sometimes measure the success of a query primarily by the number of results it returns. If they feel the number is too large, they add more terms in an effort to bring back a more manageable set. Given her understanding of how search engines determine relevance, you’d expect Andrea to do this if she needed to quickly locate a known item within her domain expertise, like “mainframe manufacturing.”

Design recommendations:

Allow users to filter the search results by categories, so they can reduce the number of results while making them more topical.
Include a numeric count of the total number of results returned for the query and the total number for each category.
Use “and” as the default operator rather than “or,” so the number of results narrows instead of growing as the user adds more terms.
Don’t confound this behavior by truncating the total results set at a round number like 100 or 500; this makes it difficult for users like Andrea to gauge the quality of her query.

Fig. 1: Filtering mechanisms help users narrow down searches that brought back too many results.

3. Surveying quickly
Some users scan through the results quickly, and if none of the titles strike them as an ideal match, they may proceed several pages deep into the results set. I’ve seen these users go to the fifth or sixth page of results without hesitation, then go back to the initial results to look more carefully or submit another query.

For instance, Dmitry could do this to hedge his strategy if his task isn’t fully defined. Hopeful that something will just pop out at him, he may do a quick scan of the first few pages, then fall back to another strategy if that doesn’t work out.

Design recommendations:

Ensure that result titles are comprehensible at a glance, including application files like PDFs and Word documents, which often return cryptic file names by default.
Highlight the terms that match the words originally submitted to help people scan the titles and descriptions more easily.
Allow users to change the number of results shown per page to avoid navigating through too many paginated results.

These changes will allow Dmitry to evaluate pages more efficiently and successfully.

Fig. 2: Search engines often return cryptic file names for application files like PDFs and PowerPoint slideshows.

4. Making immediate judgments
Other users look only at the first few results before deciding whether the query was successful or not. Finding nothing, these users may then resubmit the query or give up on search altogether.

Andrea, the analytical thinker, would be discriminating about a result’s relevance to a narrowly defined informational goal. Confident in her expertise, she would also be quick to conclude that search is flawed if it cannot return a good match in the first few listings. This behavior requires that the best match be returned as close to the top of the list as possible.

Design recommendations:

Optimize results for the most commonly submitted queries. Working from the search logs, try out each of the top queries and evaluate the quality of the top results returned, then optimize the content of those pages to improve their ranking.
When pages cannot be further optimized, include a manually generated “Best Bets” sidebar to force those matches to appear at the top. This gives the page a second chance to hit the specific target in Andrea’s mind.

5. Agonizing over the query
Sometimes users have difficulty translating the concept they want to find into a specific search phrase. They will often rewrite the query several times before submitting it, and then focus on revising it further if the results are not as they had expected them to be.

Less experienced users like Kazue are more likely to show this behavior, especially if the task isn’t well defined and lies conceptually outside of her domain. Kazue may also be inclined to phrase the query generally enough to satisfy her global cognitive style, but fret over how general is too general.

Design recommendations:

Consider providing tools that assist in formulating the query, such as suggestion functions that present searches similar to the one the user is typing.
Consider including lists of popular searches or automated storage of the user’s previous queries, saved to a profile or cookie.

Anytime that Kazue can select a query from a list rather than originating it from scratch, she will be able to search much more efficiently.

Fig. 3: Suggest functions assist users with formulating queries when they don’t quite know how to phrase their request.

6. Pogosticking
Some users click several results in rapid succession, quickly sampling each before settling on a best candidate to meet their needs. Jared Spool has described this as “pogosticking”—bouncing up and down between choices of uncertain relative value. This is the kind of behavior that Dmitry might resort to if the quick surveying behavior described for him above didn’t yield anything. Assuming that his temperament is fairly tolerant and he isn’t pressed for time, Dmitry may decide that he cannot determine the usefulness of pages without looking at them. These users need support for three primary tasks: assessing result listings, comparing result pages, and tracking work.

Design recommendations:

Again, provide comprehensible titles and descriptions on the results page, as well as highlighted search terms.
Pages can be even more effectively compared if highlighting can be extended to the display of the results page itself (as is possible with Yahoo! and Google toolbars).
Allow users the option to open results in a new browser window to assist comparison. Sites like Ask and Easy Search Live are experimenting with page previews.
Be sure to include a visited link color on the results page. This is absolutely essential for Dmitry to keep track of the pages he has already tried and rejected as he jumps to each of the matches from the hub listing page.

Fig. 4: Visited link colors help the user avoid revisiting results that have already been tried and rejected.

Conclusion

Search behavior varies with domain expertise and technical knowledge, cognitive style, goal, and mode of seeking. All of these factors will interact in complex ways to influence a user’s actions. Even then, behaviors will vary depending upon whether at that moment the user is under pressure, in a good mood, or any number of other idiosyncrasies.

The point is that the designer cannot select the behavior that a user will follow when conducting a search. This may invite the impression that the design must be overly broad, providing any conceivable function regardless of the likelihood it will be used, because we cannot predict whether it will be needed. Fortunately, users’ actual behaviors do fall into generally describable patterns, each of which has dependencies upon specific affordances of the interface. This is how designers can better cater to what appears to be chaos: make available those capabilities that best support the range of known behavior patterns for your target personas.

References

(1) James Kalbach provides an overview of literature around this topic in his article “Designing for Information Foragers: A Behavioral Model for Information Seeking on the World Wide Web.”

(2) For more on expert search behavior, see these two articles: Christoph Hšlscher & Gerhard Strube (2000): “Web Search Behavior of Internet Experts and Newbies”; and, Suresh K. Bhavanani (2002): “Domain-Specific Search Strategies for the Effective Retrieval of Healthcare and Shopping Information,” CHI 2002, pp. 610-611.

(3) See Ryen W. White & Steven M. Drucker (2007): “Investigating Behavioral Variability in Web Search,” International World Wide Web Conference 2007, pp. 21-30.

(4) See Donna Maurer (2006): “Four Modes of Seeking Information and How to Design for Them.”

(5) David Fiorito and Richard Dalton further described different types of navigation in their presentation at the 2004 IA Summit, “Creating a Consistent Enterprise Web Navigation Solution”.