This article is one in a series on designing the search experience.
This article is one in a series on designing the search experience.
The interface is the most visible element of the search experience. Most people have an idea in their head of what a search interface looks like, and more often than not, it's one interface in particular. It is the image that comes to mind when anyone hears the word "search". We're talking, of course, about Google.
Google's dominance of web search is unquestionable. Their interface is a cultural symbol. The year Google launched—1998—will be included in a chart of humanity's evolution. Herein lies the problem for those working with enterprise search.
While Google’s interface is ideal for search performance over web content, it is suboptimal for search performance over enterprise content. Enterprise content here includes the organisation’s websites, intranets and apps.
For example, if you run a property investment website that helps customers buy property and rent it out, how will you guide them to make the best investment choices? Would you show a Google-like listing of the 10 investment opportunities for a given area? Or would you rather show a map highlighting rental yield across the country, like the one shown below?
If you notice, the rental yield search task belongs to an ‘Analyst’ persona (see Understanding users and top tasks). Google is weak in servicing such specific search personas. And justifiably so. The web is a big place with many types of users. Google has to cater to them all. It can’t be narrow. It has to offer wide, generic results. If users have specific needs, they'll have to follow up outside Google.
However, you seldom face such Google-scale challenges in your organisation or department. You can cater to small and narrow collections. You can focus on meeting local needs. You can create custom interfaces for specific personas.
To be fair to Google, they are rapidly enhancing their search results alongside their 10-blue-links. For example, a search for ‘Barack Obama’ shows descriptive data alongside page results. Google can do this because it keeps track of a web of data, called the ‘knowledge graph’, that it exploits for certain classes of queries.
If Google can work this miracle sieving through mind boggling amounts of information, just imagine what you can achieve with known use cases and information spanning a project, department or organisation.
Search interfaces can have many features. The challenge is to select the ones that help in meeting user needs. Max Wilson, author of Search User Interface Design, offers a taxonomy of search interface features:
- Input: Features that allow the searcher to express what they are looking for (e.g., search bar)
- Control: Features that help searchers to modify, refine, restrict or expand their Input (e.g., filters)
- Informational: Features that provide results or information about results (e.g., snippets)
- Personalisable: Features that relate specifically to searchers and their past interactions (e.g., bookmarks)
Let’s use the taxonomy to look at some modern search interfaces and how they might work in an enterprise setting.
The search bar is the most recognisable input feature. It's where users express their intent through a search query. However, this query not a command but more like a conversation. The user gets some suggestions to their query. Based on the suggestions the user may choose to modify the query. The process repeats till a negotiated query emerges. The eventual outcome, therefore, depends on the quality of the suggestions.
In an enterprise setting, you can leverage many opportunities to offer quality suggestions. For example, you can use:
- The user’s profile information such as role and department
- Queries that the user previously used
- Queries that others in the project group, department or division have used
- Queries that match controlled terms in an enterprise taxonomy
For example, consider an organisation that rents out office spaces to industrial and commercial clients. When a staff member enters the term "early termination" to analyse precedents or policies relating to early termination of a lease, the query suggestions can be ranked based on the staff member’s department—industrial or commercial—thereby increasing the relevancy to the job at hand.
Just imagine if all search interfaces in the enterprise leveraged local knowledge to offer relevant query suggestions. Think about the boost in productivity such a design could achieve.
The search bar is no longer the only way to express a query. Devices such as Amazon’s Echo and Google’s Assistant show that you can use voice or text messages to start a search conversation.
It is only a matter of time before employees start demanding such experiences in their organisations. As with the search bar, the success of such technologies will depend on how well they address local, specific queries.
Faceted navigation is the most popular search control feature, especially for structured collections. The technique uses attributes or dimensions of content, known as facets, to narrow the set of results.
For example, you might be looking for a mobile phone, in which case Amazon shows you the full catalogue. But then you spot a dimension or facet called "Expandable memory" and suddenly realise that it is a feature that you want in the phone. Clicking on the link shows only the phones with expandable memory, bringing you closer to your job-to-be-done.
A faceted navigation interface continues the conversation that started with query suggestions. It presents additional terms related to the query and nudges users to make appropriate choices.
As you would expect, the closer the terms are to the job-to-be-done, the higher their relevance. This suggests that faceted navigation cannot be a generic, one-size-fits-all offering. It has to be pertinent to the collection it serves. Enter metadata.
Jeffrey Pomerantz, author of Metadata, describes metadata as "a statement about a potentially informative object". 'Expandable memory' is a statement about a phone—a potentially informative object to the user. A faceted navigation interface arranges and displays such statements, hoping to release the potential relevancy of the collection to the user.
We will go into the details of metadata in a forthcoming article. But for now, suffice it to say that if you go local with search and gather the right metadata on a collection-by-collection basis, you can offer high-performing, faceted navigation interfaces across the organisation.
There are many informational components out there. We will focus on two that are useful in an enterprise context:
- Results snippets
- Answer snippets
For the longest time, only three items were shown on a search results snippet: title, description and URL of the resource. But this practice is ending, and thankfully so. The argument for their demise is simple: every search result snippet should have the opportunity to ‘market’ its relevance to the user.
For example, how can a snippet for a bank’s branch office market its relevance to the user? Well, it can show the location, opening hours, if the branch is currently open, and perhaps the ability to reserve a place in the queue. Such a snippet is called a rich results snippet.
Going by the above argument, each content type or collection can have a unique rich snippet designed to market its relevance. Consider what this means for enterprise content.
Imagine how effective search could be if content types such as budget papers, proposals, invoices, cases, project docs, etc., used rich information to market their relevance. Imagine if data tables marketed their relevance not as Excel downloads, but as charts showing pertinent information.
Answer snippets respond to direct, factual queries such as “Who is Barack Obama?” or “What is the capital of India?”. They appear above the list of search results. They cater to the 'Assistant' persona who demands fast, direct answers.
Google’s answer snippets, called 'Rich Answers', use its vast knowledge graph to suggest answers. You could use a similar tactic in the enterprise. The first step is to understand what answers users want. Then you need a systematic way way of collecting these answers and integrating them with the search index. With such a system in place, your users can start seeing answers to questions like:
- Who is John Paul? (results from the staff directory)
- Who is on leave today? (results from the HR system)
- What projects are underway? (results from the project management system)
There are many instances where users just want quick facts and answers. It is the reason why Google’s Rich Answers shows up on more than 25% of the queries. It can be argued that a similar situation exists in enterprise settings. Offering rich snippets and answers, therefore, is an efficient way to raise productivity and satisfaction levels by instantly responding to such requests.
Personalisable features amplify the search experience for returning users.
Three common features that cater to repeat use are:
- Search history
Bookmarks allow users to retrieve frequently used results from a single place.
Search history lets users refer to or revisit previous queries.
Recommendations entice users to explore related resources they might not otherwise attempt. The recommendations are based on the user's browsing or interaction patterns.
Personalisable features can boost productivity and satisfaction levels in the enterprise. Yes, they require a fair bit of plumbing to get right, they are worth every bit of the effort.
There are many interface components and many ways to design them. Peter Morville’s Search Patterns and Marti Hearst’s Search User Interfaces are testament to the breadth and depth of this challenge. The key takeaway is that there is no such thing as a default or out-of-the-box search interface. Every aspect of the interface must be designed to meet specific user needs.