Skip to content
13 min read

Improving Enterprise Search Experience: Six Paths, Six Surfaces

Every architectural decision in a search system eventually shows up as a pixel, a state, or a piece of microcopy. Here is what each of the six paths looks like from the user's side of the glass, with the research to back it.

Complexity is a design problem
Photo by Hal Gatewood on Unsplash

In the last piece I laid out six paths for improving enterprise search in the AI era. Every one of them was a decision about architecture, resourcing, or measurement. None of that is visible to the person typing into the box.

So, what is visible to the user? They experience latency, a set of interface states, and interface copy. Your hybrid retrieval pipeline with reciprocal rank fusion and a cross-encoder reranker is invisible if the results page still shows ten blue links with no explanation of why these ten. On the flip side, an incomplete index can feel competent if the interface is honest about what it does and does not know.

Two research programs are doing the most useful work on this problem right now, and they approach it from opposite ends. Baymard Institute benchmarks at scale, scoring 170 or more sites and apps against a fixed set of search guidelines. Nielsen Norman Group runs small-sample moderated studies and watches individual people fail in real time. The numbers tell you how widespread a problem is. The sessions tell you what it feels like. You want both.

Here is each of the six paths again, from the user’s side of the glass.

1. Complexity Is a Design Problem

The first path was about resourcing honestly and scoping narrowly. Both of those are UX decisions dressed up as program management.

What are the stakes? In its 2026 search benchmark, Baymard reported that desktop sites fail to deliver a satisfactory search experience 46% of the time, mobile sites 58% of the time, and apps 64% of the time, leading to an overall failure rate of 56%. Consider this alongside another key insight from their studies: roughly 50% of users rely on search as their main tool to locate products. Translation: Search is not a niche feature, serving as the primary entry point for half of your users, but a large majority of organizations continue to fail or are perceived to fail at it.

Scope is a design artifact, and users should be able to see it. A search box with no visible boundary makes an implicit promise to cover everything. When the corpus covers HR policy and engineering runbooks but not the CRM, the box does not say so, and every miss reads as a failure rather than a limit. Name the scope in the interface. Use a search field’s placeholder text to direct users how the search is scoped, they can search by product, brand, or condition, for example. In an enterprise system the equivalent is telling people which content domains are in the index and which query styles the system actually handles.

Latency needs a designed experience, not a spinner. Hybrid retrieval plus reranking plus generation is slower than a lexical query execution. You need to make the wait legible. Stream the retrieval results first and let the answer resolve above them. Give the user something to read at 400 milliseconds instead of nothing at three seconds.

The empty state is only a first time experience. Most enterprise search interfaces show an empty box and nothing else, which quietly asks every new user to guess the system’s vocabulary and capability at the same time. Seed it with recent queries, popular queries by team, and a few examples that demonstrate range.

Then check that anybody sees it. NN/g’s study of Google AI Mode found that its welcome page carried genuinely useful guidance, including prompt suggestions and advice to ask detailed questions, and that not one participant ever laid eyes on it, because reaching that page required a path nobody took. Their conclusion is the one to steal: explanatory text is only useful if people see it. If your onboarding lives on a page users skip, you have not onboarded anyone.

2. Patterns Users Already Know

The second path argued for using established patterns rather than inventing. The nuance here is that patterns are only “free” when the user has already learned them somewhere else, and that the failure modes are extremely well documented.

Autocomplete is intent shaping, NOT typing assistance. Users do not need help typing. They need help discovering that a concept exists in your vocabulary. Baymard’s work on autocomplete found that only about a fifth of sites implement the full pattern correctly. Their most transferable idea for the enterprise is to scope suggestions. A suggestion dropdown reading “PTO carryover” is weaker than one reading “PTO carryover, in Policies.” The second provides insights into your taxonomy while a user is typing.

This connects to a longstanding NN/g concept that deserves more attention in enterprise work: keyword foraging, the search before the search, where a user runs preliminary queries just to discover the correct term for what they want. Every enterprise runs into this problem at scale, because every organization has internal names for things that new employees, contractors, and customers do not know. NN/g’s finding is that generative AI genuinely helps here, since users can describe the thing instead of naming it.

The natural language box needs a control surface. This is the correction I made in the last piece, and it is fundamentally an interface change. Baymard’s retail examples show exactly what good looks like. At Macy’s, a query for a blue shirt returns results with the color filter already applied and visible. At Sephora, a query for thirty dollar shampoo applies a twenty-five to thirty-five dollar price band, slightly relaxed on the sensible theory that a shopper asking for thirty dollars will accept twenty-nine fifty. In both cases the system’s interpretation is rendered as a filter the user can see and toggle rather than as invisible logic.

Implement this directly. When a user types a multi-constraint request into an enterprise system and the retrieval layer decomposes it, render each interpreted constraint as a chip above the results. Let the user tap one off. Let them see that “last quarter” became a date range and that the range is wrong.

Design the results page around query type, not templates. Baymard’s failure rates by query type were in the previous article. What matters here is that each type wants a different response. What is the query intent? An exact match on a part number or document ID should resolve to the record, above the list, with an obvious way back to broader results. A product-type query maps to a document class, and the right answer is often a filtered view rather than a ranked list. A symptom query needs the answer layer, because the user cannot name what they want.

Facets are a map, not a filter menu. Show counts. Never show a facet value that returns zero. Keep applied filters visible in one place with single-action removal. Unglamorous, still the most commonly broken pattern I encounter in audits.

3. Trust Is an Interface Behavior

The third path was about simplifying the transaction and earning trust in an answer layer. This is where the UX work is heaviest, because a generated answer changes what the interface is being asked to do.

A results list is self-evident. The user scans it, evaluates, and clicks (or doesn’t). A generated answer asks the user to believe something. That is a different transaction and it needs to be handled differently.

Citations belong at the claim level. A paragraph followed by four source chips is decoration. NN/g’s AI Mode study found that participants appreciated having sources, and that the sources did not solve the underlying problem: Most users of an enterprise system will not be experts in the documents that are being summarized.

The design implication is that citation is not a trust badge, it is a verification signal, and it only works if verification is cheap. Inline attribution at the sentence level lets a skeptical reader check one claim without reading four documents.

Evidence should be one action away, and it should land in context. When a user opens a citation, take them to the passage, highlighted, with enough surrounding text to judge it. Do not open the document at page one. A snippet that does not show why a result matched is the list-view version of an uncited claim.

Length is a usability failure. This is the finding I would put in front of any team about to ship an answer layer. NN/g watched participants receive long, poorly formatted AI responses and respond by skimming, skipping to the bottom, or abandoning the tool outright. Their recommended fixes are unfashionably basic: subheadings, bold text, bulleted lists, and collapsible sections so users control how much text is on screen.

Design for a “I do not know” state. Most systems have no visual language for weak retrieval, so they generate fluent prose anyway. Give abstention a designed state with the same visual weight as an answer: what the system looked for, why confidence was low, and what to try instead. A system that declines credibly is trusted more the next time it answers.

Capture feedback beyond a thumbs-down. A thumbs-down tells you a user was unhappy and nothing else. Offer two or three reasons at the moment of dissatisfaction, wrong information, missing sources, not what I asked, and you convert a mood into a diagnosis.

4. Evaluation Needs Human in the Loop (HITL), and its own Interface

The fourth path replaced faith with measurement. Offline metrics like nDCG and MRR answer whether the ranking is good. They do not answer whether the person finished the task.

There is no reason a search team cannot maintain a scored rubric for task completion, specific to your own system and intents and evaluate it quarterly.

Moderated testing has real value. It can add insight to the experience and help clarify why users bypass onboarding pages, or how response length impacts task abandonment. Small-sample moderated testing is not an inferior version of analytics. It answers a different question.

Instrument success at the session level, not the query level. A query with a click at position one looks like a win and can still be a session where the user gave up and asked a colleague.

Build the judgment interface, not just the golden set. Relevance judgment programs stall because judging happens in a spreadsheet, which is miserable. A small internal tool showing query, result, and a three-key rating is a weekend of work and it is the difference between a golden set that gets maintained and one that ages out in a quarter.

Poor relevance is usually a content problem, and content problems are visible in the interface. If your snippets read as fragments, if titles are file names, if summaries begin mid-sentence, your chunking is bad and the user can already see it. A results page is a very effective content audit if you choose to read it as one.

5. Your Analytics Are a Research Panel

The fifth path was about using search data. The UX framing is that search logs are the largest continuously running qualitative study your organization has.

Read reformulation chains as usability findings. Review query chaining at the session level. Taken individually from a log firm three queries could appear as ordinary searches. Read as a chain, they could provide insight into usability issues: wrong vocabulary, no bridge from problem description to solution, no correction from the system.

Design the zero-result page as a recovery experience. Telling users to check their spelling or try broader terms mostly does not work. What does work, according to Baymard in their testing, is concrete paths: related categories, alternative queries generated by the system, personalized or recently viewed items, and a direct route to a human. That last one deserves emphasis in an enterprise context. A user on a zero-result page is in the highest-risk group you have, and the cost of routing them to a person is far lower than the cost of them concluding the content does not exist.

Watch the high-result, no-click queries. Four hundred results and no engagement looks healthy on a dashboard and is often worse than zero results, because the user cannot tell whether the thing they want is absent or just buried.

Mine your logs for the queries your system was never designed to answer. Users will type policy questions, process questions, and “how do I” questions into whatever box is in front of them. It is very likely the single largest untapped category in your logs.

Make permissions legible. In a system that synthesizes across silos, access control has to be enforced at retrieval time. It also has to be communicated. When results are withheld, say that some results are not available at the user’s access level and offer a request path. Silence produces two bad outcomes: users who conclude the content does not exist, and users who conclude the system is unreliable.

6. When the User Is an Agent, the Human Still Needs an Interface

The sixth path was about designing retrieval for agent consumers. The UX consequence is not that the interface disappears. It is that the interface moves and the consequence is that the human never sees the queries, only the synthesis.

Show the work, collapsed by default. What did the agent search for, how many times, and which passages did it actually use. Most users will never expand it. The ones who do are about to put your answer into something consequential.

Make the agent’s queries editable, not just visible. If the agent decomposes a request into five retrieval calls and one was wrong, let the user correct that call and rerun rather than restarting the conversation.

Permissions must be evaluated per call and reflected in the answer. An agent acting for a user is constrained by that user’s rights, and the answer should indicate when synthesis was performed over a partial view.

The Seams Are the Feature

The thread running through all six is the same one I ended on last time. The systems that earn trust are the ones that let people see the seams: what was searched, what was found, how it was interpreted, what was withheld, and what the system does not know.

Polish that hides the mechanism is not sophisticated. It is a bet that the system will never be wrong, and that bet loses roughly as often as the retrieval layer does.

Show the work. Users are far more forgiving of a system that is honest about its limits than of one that is fluent about its mistakes.

Sources