In recent studies on how employees in a range of companies use their intranets, an important guideline emerged: intranets should provide a dedicated search box for finding phone numbers and other employee directory information. Preferably, this staff directory box should appear on every page of the intranet, and it should definitely appear on the top levels of an enterprise portal and on the main intranet homepage.

That's one usability guideline.

At the same time, one of the most established usability guidelines for search is to provide no more than a single search box on the homepage. Competing homepage search boxes are confusing, and advanced search should be relegated to a secondary position inside the site to avoid seducing users away from the simple search, which they're more likely to use correctly.

That's another, conflicting, usability guideline.

And a conflict it is. Our own usability testing of intranets, for example, revealed serious problems when intranets had multiple searches: users often used the wrong search without knowing it. To the users' mind, search is search, and if they type something into a query field and hit return, they expect to find what they're looking for. They often don't realize that the same action can have different outcomes depending on subtle details, such as the difference between two search mechanisms. We thus have two guidelines:

  • Two search boxes. The first is for full-text queries, and the second for searching the employee directory
  • One search box. One, I say. What part of "one" don't you understand?

Considering Basic HCI Principles

When in trouble, appeal to a higher authority. In usability, this authority is provided by the basic principles for human-computer interaction -- fundamental insights that have proven sound over more than twenty years of studies and research.

Unfortunately, both search box guidelines are supported by basic principles.

The two-search guideline is supported by the principle of providing accelerators for frequent actions. We know from our research that looking up colleagues in the employee directory is one of the key intranet killer apps in many companies. This action is performed so frequently that a shortcut seems in order.

The one-search guideline is supported by two strong principles: simplicity and consistency. Simplicity says that fewer commands mean less potential for users to mess up and choose the wrong one. That's why the Macintosh mouse has only one button. Consistency says that the same action should have the same result, and yet typing text into a search box and hitting return would have different outcomes depending on which box was used in the two-search design.

Resolution: Examine the User Experience

It is very common to have conflicting usability guidelines. They are called "guidelines" rather than "specifications" for a reason: they are necessarily fuzzy because they relate to human behavior.

Interface design requires trade-offs. The challenge is in knowing how to balance the conflicting guidelines and in understanding what is most important in a given situation.

In the employee directory question, there are two arguments for why the new two-search guideline is correct: empirical evidence and theoretical reasoning.

When in doubt, you can always run a user test. We've tested many intranets with separate employee directory boxes, and uniformly found that this design worked well.

It's nice to have empirical validation for a user interface, but ultimately it's not very satisfying if you cannot explain why something works. Granted, you may have resolved one issue, but your skill at analyzing future design dilemmas remains unchanged.

So: what is the theory that explains why employee directory search works?

The consistency counter-argument is a canard. Searching an employee directory is not truly a "search" in the human way of thinking. As users see it, search is when you type in a word and find documents that contain that word. In using the employee directory box, you type in a name, not a word. And you find a person, not a document. Because these actions are very different, there is no expectation that the two boxes should behave the same.

Of course, any programmer reading this will protest, "but a name is a word" and "finding records for people in the database is a query for a set of objects that's no different from document retrieval." Correct on both counts: Deep in the guts of the machine, searching the employee directory and searching a document repository are indeed very similar, though the database implementations might differ. What matters, though, is not the implementation, but the user experience. And, to the user, there is a world of difference between people and documents. The two are not equivalent classes of "objects." People are your colleagues -- live human beings. Anyone can tell the difference between Joe in Accounting and an accounting memo.

There is something to the simplicity counter-argument: an extra box does take up pixels, which are in short supply on a homepage. But simplicity's most important aspect does not work against employee search. Users don't have to spend time worrying about which query mechanism to use for different searches, for the simple reason that they don't think of employee search as a search. (Which is why you should label this feature something other than "Search," such as "Find Employee.")

Clarity Is the Key

As we have seen in testing intranets, using one search to find documents from the document repository and another search to find answers in the knowledge base is a big problem for users. Most people won't know which is which, and they'll waste much time trying to puzzle out the difference. But, when you want to find Mary's phone number, you don't think of it as a document retrieval operation. You think of it as looking up Mary in the employee list. For both needs, the action to take is clear, so users have only one command to consider in each case. Exactly the outcome the simplicity principle aims to achieve.

The basic human-computer interaction principles sound obvious and reasonable, but as this example shows, their interpretation requires subtlety. The usability field is one in which empirical observation and theoretical analysis reinforce each other. Because the theory is so weak, analyses get better as you continue to supplement theory with empirical experience. And, when you know the principles and guidelines, your empirical observations get richer because you know what to look for.

More Info

Report with 113 intranet design guidelines for intranet search based on usability tests of a wide range of intranets. (See also report with 73 guidelines for employee profiles and team info.)

Recommended employee search design pattern.

Other issues in search are covered in the full-day training course Information Architecture 1: Structuring and Organizing Web-Based Information.