Search is a player, not a bystander in meeting business objectives
In this case, the search goal may be to help customers find the right answers effortlessly so that they can resolve their issues and get on with their jobs. With the goal defined, you now have criteria for selecting the right ideas. For example, user research reveals that many people are looking for the operating hours of branch offices. You realise that this information is in a PDF document. It means people must first know that the information is in a PDF document, then download it to their computer and finally locate the operating hours for the specific branch. Will this experience help meet the search goal? No. A good goal-aligned solution could be to extract the information from the PDF document and offer it right in the search results snippet. Simple, quick, and effortless—this is what one would expect with GenAI. "Help people find stuff" is not a search goal, nor is “Improve the accuracy of search.” These vague statements don't explicitly state the business's expectations or value. You can define a good search goal using the format: _Search shouldGoogle gives a direct answer in response to the query: GDP of Cambodia.
In _Designing the Search Experience_ authors Tony Russell-Rose and Tyler Tate introduce the concept of “search modes” to counter the commonly held assumption that search is just about finding something. They state: > Defining the search problem as one of findability alone is a common misconception. Moreover, it unnecessarily constrains our view and limits opportunities to look beyond information retrieval and on to broader information needs and goals. An online shopper, for example, whose goal is to understand the options available in choosing an affordable home entertainment system, has needs that go far beyond pure findability. And likewise, an engineer, whose goal is to manage the risks associated with component obsolescence, has needs that go far beyond finding information (p. 71-72) Search modes tell us that users have different requirements when looking for information. They use search to find information and explore, compare, analyse, monitor, etc. This insight is essential to designing compelling search experiences. There are four common types of search behaviours. Described using character portrayals or personas, these are: 1. Assistant 2. Explorer 3. Analyst 4. Executive Search personas
### Assistant Just the answers. Examples: - Do I need a visa to enter Myanmar? - How many pounds in a kilogram? - What does this transaction code mean? ### Explorer The breadth and depth of options. Examples: - Where do I advertise for Java developers? - What are the restaurants near me? - What are my employment benefits? ### Analyst Making the right decision. Examples: - Does that company sell ‘fair-trade’ coffee? - Which is the best phone to buy for Dad? - How does the Nissan X-Trail compare with other cars in its class? ### Executive Trends and insights. Examples: - How have sales fared since the apology for faulty software in our cars? - How many cases were opened this year, and how many were closed? - Which areas in Singapore have the highest yield for office rentals? These personas offer a lens through which you can better understand user needs and behaviours. But first, you must invest time and effort to study your users. Meeting your users to learn first-hand what they do and why, how they work and the bottlenecks they face will open your mind to ideas that will help design effective search experiences. After your study, you should be able to answer two crucial questions: 1. Is there a dominant search persona at play? 2. What are the top search tasks? A dominant persona emerges when many users exhibit behaviours similar to one of the four personas we described earlier. For example, if you find many users trying to get overviews and trends, you see signs of an 'Executive' persona. Knowing the dominant persona will help surface the right ideas. Continuing with the 'Executive', they favour dashboards and charts over documents and links. After you’ve identified the search personas (both dominant and minor), you need to define the top search tasks for each. A** top search task** is a task that matters a lot to many users. For example, the dominant persona on a bank’s self-support website will typically be an ‘Assistant’—find quick answers. A top search task may be to find the location of the bank’s branches and their operating hours. A search task embodies a job a user is trying to get done. Searching is not the goal but a means to accomplish a job. The person looking for the ‘GDP of Cambodia’ will perhaps use the data in a slide deck pitched at investors. The job-to-be-done is to get investment, not download the GDP data. Similarly, the job-to-be-done for the person looking at the bank’s operating hours is perhaps to pay for an overseas purchase, not to find the ‘contact us’ page. Knowing the job-to-be-done will help in designing effective search experiences. Incidentally, the Job-to-be-done, or JTBD for short, is a popular marketing and product development strategy championed by Clayton Christensen, an acclaimed professor at Harvard Business School. Interviewing users, especially along their decision-making journeys, often identifies the JTBD. The journey reveals the many jobs that users try to complete and how they choose among alternative solutions. For example, a person looking for GDP data on Cambodia can get the information from several sources, such as journals, databases, or personal contacts. The choice of a particular source reveals the person's criteria for getting the job done. It could be the speed of finding and copying the information into a slide deck. Once the the job-to-be-done is identified, you can write it down using the form: - When I… - I want to… - So that I can… For example: - When I want to pitch to investors - I want to use data to convince them of market opportunities in Cambodia - So that I can get financial investment for my project You can also add some criteria of success, such as: - Ease of finding the right data - Ease of making changes to the data - Ease of copying data to a slide deck I would like to point out that a study of search persona and their search tasks expressed as JTBD statements will reveal many gaps in the quality of the available content. For example, a JTBD may suggest presenting a country’s GDP information as a graph on search result snippets. However, the content may be in data tables inside PDF documents. In this case, the right thing to do is to figure out an automatic way to extract the data table and build the graphs. Yes, this may be a lot of work to do, but creating a culture of designing compelling search experiences is essential. Next up: designing search interfaces that cater to dominant personas and search tasks. # 3. Interface The interface is the most visible element of the search experience. Most people know what a search interface looks like, and more often than not, it's one interface in particular. The image 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, which 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 show a map highlighting rental yield across the country, like the one below?  Rental yield visualisation from richblockspoorblocks.com If you notice, the rental yield search task belongs to an ‘Analyst’ persona. 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 comprehensive, 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 rapidly enhance 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’, which it exploits for certain classes of queries. Google’s knowledge graph showing data on Barack Obama
If Google can perform this miracle by sieving through mind-boggling amounts of information, 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 this taxonomy to look at modern search interfaces and how they might work in an enterprise setting. ## Input The search bar is the most recognisable input feature. It’s where users express their intent through a search query. However, this query is not a command but more like a conversation. The user gets some suggestions for their query. Based on the suggestions, the user may choose to modify the query. The process repeats until a negotiated query emerges. The eventual outcome, therefore, depends on the quality of the suggestions. You can leverage many opportunities to offer quality suggestions in an enterprise setting. 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 renting 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. Imagine if all search interfaces in the enterprise leveraged local knowledge to offer relevant query suggestions - what a boost in productivity such a design could achieve. The search bar is no longer the only way to express a query. Devices like Amazon’s Echo and Google’s Assistant show you can use voice or text messages to start a search conversation. New AI-enabled search experiences like Perplexity offer multimodal input capabilities using text, documents, pictures and sound. 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. ## Control 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 entire catalogue. But then you spot a dimension or facet called “Item weight” and suddenly realise it is a feature 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. Amazon’s faceted interface
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”. ‘Item weight’ 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 discuss metadata in another chapter. But for now, if you use local search and gather the correct metadata on a collection-by-collection basis, you can offer high-performing, faceted navigation interfaces across the organisation. ## Informational There are many informational components out there. We will focus on two that are useful in an enterprise context: 1. Results snippets 2. Answer snippets ### Result snippets Only three items were shown on a search results snippet for a long time: the resource's title, description, and URL. But this practice is ending, and thankfully so. The argument for its 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**. A bank’s rich snippet for branch offices
Going by the above argument, each content type or collection can have a unique rich snippet designed to market its relevance. Imagine how effective a 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 Answer snippets respond to direct, factual queries such as “Who is Barack Obama?” or “What is the capital of India?” They appear above the search results list and cater to the ‘Assistant’ persona, who demands fast, direct answers. Answer snippet
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 of collecting and integrating these answers with the search index. With such a system, 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) Many users want quick facts and answers, so Google’s Rich Answers appear on more than 25% of the queries. A similar situation can be argued to exist in enterprise settings. Therefore, offering rich snippets and answers is an efficient way to raise productivity and satisfaction levels by instantly responding to such requests. One can imagine how rich snippets will fare with GenAI in the mix. The AI can figure out the best multi-modal snippet for the result and generate it on the fly. ## Personalisable Personalisable features amplify the search experience for returning users. Three common features that cater to repeat use are: 1. **Bookmarks**: Users can retrieve frequently used results from a single place. 2. **Search history**: Let users refer to or revisit previous queries. 3. **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 some plumbing to get right, but they are worth every 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 a 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. # 4. Content If the search interface is the most visible and familiar element of the search experience, then the quality of the indexed content is the most overlooked. Good quality content is critical for creating amazing search experiences. The challenge is first being aware of the correlation. Search still has a ‘magic box’ appeal to many in the enterprise. They feel that search should work with any content. Again, they cite Google as an example. Little do they know that web publishers these days work hard to create good quality, web-friendly content so that it can rank high in Google search results. For example, Google rewards pages that follow good HTML markup practices, such as using the \Content enrichment pipeline
With the advancement of machine learning, it is now possible to extract names, places, dates and times from unstructured text. One can even create and assess the sentiment of the text. The discipline of **text analytics** is now a deep and mature practice. ## Worked example Let’s say we have a news collection (shown below). Now, let’s also assume we researched and found that users are looking for specific things, like TV shows, celebrities and companies. The source format is too flat to answer such queries, so we need to enrich it. | Metadata | Value | |------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Id | 03597bc6-d4fa-43c2-89e0-31fa0fab3997 | | Title | ‘Late Show with Stephen Colbert’: When it debuts, and why we (and Stephen) can't wait | | Content | Tuesday night brings the long-awaited debut of \"The Late Show with Stephen Colbert,\" as the host drops his \"Colbert Report\" persona, and welcomes his first guests, George Clooney and Jeb Bush, and musical director Jon… \r \nThe debut of \"The Late Show with Stephen Colbert\" finally arrives Tuesday night, after what seems like an eternity of Colbert teasing us with clips…Search results for the query: “obama meets indian pm”
In the screenshot above, the user gets the profile pictures of the two leaders with their full names. The search results use these names to query the collection and, therefore, get more relevant results. The filters on the left offer the user semantic handles to refine the query. How is all of this done? Here are the steps that the search tech takes: 1. Processes the query to identify named entities such as people and places mentioned (text analytics). 1. Looks up the acronym 'pm' against a taxonomy to find its expanded form. 1. Identifies the entity 'indian pm' as a person and looks it up in the taxonomy, which returns 'Narendra Modi'. 1. Does the same for the person 'obama', which actually returns two results 'Barack Obama' and 'Michelle Obama' (the user is given the option to select the correct Obama). 1. Modifies the search query to include the names of the entities involved to return relevant results. 1. Looks up the entities 'Barack Obama' and 'Narendra Modi' in DBpedia to get their photos. 1. Creates filters based on the taxonomic terms they are tagged with. Finally, search usage is analysed to check what queries are used and to refine where necessary. Imagine if the search tech could work magic for each top intent in your team, department and organisation. People will be more efficient in their jobs and more happy in their lives. ## AI-powered search stack With large language models (LLMs) and GenAI all the rage these days, how does this impact the search stack? LLMs are trained on the internet, not on enterprise content. We can't use vanilla LLMs to offer enterprise search. We must add enterprise content with all its access rights and other requirements to the LLM. That is what Retrieval-augmented generation (RAG) offers. RAG methods use all the benefits of LLMs and GenAI but apply them to specific resources, such as enterprise content. However, LLMs generate responses based on probabilities, which can sometimes lead to imprecise or irrelevant answers. They might "hallucinate" information that sounds plausible but is incorrect. A formal taxonomy helps in grounding the results. High-quality enterprise content will give better RAG results. Therefore, though the LLMs and GenAI can play the taxonomy and text analytics roles themselves, having a formal taxonomy increases the accuracy and efficacy of the results. # 7. Governance Many, especially business executives, are surprised that enterprise search requires constant effort and maintenance to stay relevant. Just like critical organisations, search needs governance. Why? Because user needs change, business needs change, and content changes constantly. Without governance, search performance will gradually decay. Search governance ensures that search remains relevant amid these changes. Governance usually includes: - Roles and responsibilities - Policies, guidelines and procedures ## Roles and responsibilities There are many roles to play in search governance, depending on the scale and importance of search in the organisation. These are roles, not full-time positions. Usually, one or two people can play many roles. ### Search manager - Developing and delivering an enterprise search strategy to meet business objectives - Overseeing and reporting on all search budgets - Overseeing all search deployments and ensuring search standards are met - Managing relationships between search technology providers and the organisation's IT team - Overseeing and reporting on overall search performance ### Search analyst - Gathering user requirements - Gathering content requirements - Defining search outcomes - Reviewing search analytics - Defining content improvements ### Search frontend engineer - Developing search frontend interfaces - Developing rich snippets - Developing search visualisations - Developing search dashboards ### Search backend engineer - Acquiring, designing and building backend search technologies - Configuring and integrating technologies for specific search projects - Acquiring or building search connectors to content collections in different systems - Designing and implementing access and security parameters - Designing disaster management parameters ### Search relevancy engineer - Analysing search logs to identify gaps - Tuning search ranking parameters to improve relevancy - Building interventions to improve search relevancy ## Policies, guidelines and procedures Policies are high-level compliance statements (e.g., records should have metadata). Guidelines describe good practices. Procedures show how to carry out key activities. Policies connote rigidity. If you are starting with enterprise search, you want fewer controls. It would help if you opted for a lightweight approach to governance rather than a heavyweight one. It is better to start with simple guidelines and procedures to start search thinking. For example, focus on key search tasks, analyse search logs every week, etc. “Think big, start small, scale fast” is an approach that Tom Reamy, Chief Knowledge Architect at KAPS Group, advises to build corporate taxonomies. It seems the same method may apply to developing a search governance. Yes, you need to know the big picture and the assumptions that come with it. But it would be best to start small and scale fast so that you don't allow the sceptics to reject this new thinking on search. # Conclusion Thanks to LLMS and GenAI, there is renewed interest in enterprise search. But if history offers any lesson, it is that relying on a magic box always disappoints. We have decades of research and findings on how to make enterprise search work, and we must use them to create user-centric search experiences that delight users. Yes, LLMs and GenAI not only help in fixing search but offer a whole new set of experiences. Let me describe a proof of concept (POC) we did for a banking client five years ago when we had the old machine learning models. We built a search app to answer queries on credit card usage in SE Asia. Here's a use case of the app: - A bank executive sees a QR code on a TV in his room. - He scans the QR code with his mobile phone. The screen on the mobile phone reveals a Siri-like voice interface. - Executive: "What is the credit card usage for this month in Myanmar?" - The app shows a graph of credit card usage across the last six months. - Executive: "Compare this to the numbers in Vietnam." - The graph now responds to show two line charts. - Executive: "Zoom in to the May-Jun period." - The graph is updated to reflect the May-Jun numbers. - Executive: "OK, send a picture of this to my email." - The screen on the app says: Picture captured and sent to your email". Yes, the POC could only understand a small set of commands, and it could not reply in voice, but you can imagine the kinds of experiences we can build with today's LLMs and GenAI capabilities. We hope that the material in this book helps you to build search experiences that delight users. It is high time! # Acknowledgements The first draft of this book was made many years ago when PebbleRoad spun off a company specialising in enterprise search. The company did not take off - people told us it was too early in the game - but the knowledge remained. Now that LLMs and GenAI are boosting enterprise search, we decided to publish it again and update it to reflect the AI trends. I want to thank Patrick Lambe and Martin White for their help and support in vetting the earlier drafts of this book.