A few years ago, I was on a design team building an internal knowledge system for a large financial services company. The system supported customer service representatives and financial advisors in call centers – professionals who needed to access accurate regulatory and procedural information while on the phone with a customer.
It was a large system. Thousands of articles covered procedures, policies, tax guidelines, fund information, and compliance requirements. The primary way to find anything was through search.
The feedback we kept hearing was that the system was hard to use. People couldn’t find what they needed, it took too long, or they ended up on the wrong article. The instinct on the business side was to improve the search algorithm, making it smarter and returning better results.
Before we did any of that, we wanted to understand what was actually going on.
What the data showed
We had access to tens of thousands of search queries entered in a single month. We sampled from that pool and began analyzing what people typed, what they were actually looking for, and how often the system returned useful results.
What we found wasn’t really a search quality problem. It was a mismatch between how the system expected people to find information and how they actually wanted to.
Many users didn’t have a specific query in mind. They didn’t type precise keywords because they didn’t always know the exact term for what they needed. They were looking for something closer to orientation, a way to see what was available in a topic area before narrowing down. They wanted to browse. The system offered only a search bar.
This was also evident in the heuristic analysis. The system had very limited browsing paths. If you didn’t know exactly what to search for, you were stuck.
What we did about it
We ran card-sorting sessions with users across different work groups to understand how they mentally organized the information they used daily. The results were revealing. The system’s content categorization didn’t align with how people thought about it. The labels made sense from a content management perspective but not from a task perspective. People grouped information by what they were trying to do, not by category.
We also conducted contextual research, sitting with associates and observing them use the system while performing real tasks. What stood out was how much they improvised. People had developed their own workarounds, such as bookmarking specific articles, keeping notes on their desks with topic paths, and asking colleagues instead of searching.
Based on all of this, we restructured the information architecture from the ground up. We introduced topic browsing, which let people drill down from broad categories to specific content. We redesigned search results to include clearer descriptions and filters that aligned with how users thought about their work, not how the system organized its content. We broke long articles into scannable sections with in-page search.
The solution wasn’t a better search algorithm. It was recognizing that search alone was the wrong model for how these users needed to access information.
Why I keep thinking about this now
Most enterprise AI assistants being built today are chat-first. You open a window, type a question, and get an answer. The design assumes the same as our system: that the user knows what to ask.
In high-pressure, time-sensitive environments such as customer calls, clinical settings, compliance workflows, and operational troubleshooting, people often don’t arrive with a fully formed question. They have a situation. They need to orient before they can retrieve. They need to understand the broader landscape of what’s available before they can determine what’s relevant.
That’s not a failure on the user’s part. It’s a well-documented information-seeking behavior. Browsing isn’t what people do when search is poor. It’s what people do when they’re still figuring out what they need.
The challenge with chat-based AI interfaces is that they reduce everything to a single mode: ask a question, get a response. There’s no equivalent to scanning a table of contents, drilling into a category, or seeing related topics side by side. If you don’t know the right question, you don’t get the right answer, and you often don’t even realize you’ve missed something.
The parallel has limits, and that matters too
I want to be honest about where this comparison breaks down. The system I worked on was a curated library – thousands of articles written and maintained by people, with a defined structure we could reorganize. AI assistants don’t work that way. You can’t card-sort an LLM’s knowledge base. You can’t add a browsing menu to a model that generates responses on the fly rather than serving them from a fixed collection.
I’m not saying the solution is the same, but I believe the core design challenge remains: how do you help someone who doesn’t yet know what to ask?
Some interesting approaches are starting to emerge. Systems that surface the scope of what they know about a topic before jumping to an answer. Interfaces that suggest related areas alongside a response so the user can see adjacent territory. Progressive disclosure that helps people narrow down rather than expecting a precise query up front. None of these are fully mature yet, but they’re all working on the same problem we were working on – giving people a way to orient before they retrieve.
The teams building AI assistants for high-stakes, real-time work environments will run into this. Some already have. The model gets most of the attention, and the interface is designed around the model’s strengths rather than around how people actually search for information. The browsing problem I found in those search queries years ago remains largely unsolved. It just looks different now.
