Findability

Teams kept building features nobody used. The people who built them knew exactly where everything lived, so the work looked finished. Someone opening the product for the first time never reached those screens and concluded the product couldn't do the job. Two people described the same product in opposite terms, and both descriptions were accurate to the person giving them.

The gap usually surfaced in support tickets first. A request like "please let several people edit a document together" would arrive ten times a month for a feature that had shipped six months earlier. Support would reply that it already existed, without being able to explain why the same request kept coming. The feature was on the release notes and absent from the user's product.

Calling that a bad user experience didn't help anyone fix it. Nothing was missing, and nothing was hard to operate once you got there. The trouble was everything before that point, and naming it settled the argument about what to change. What needed work was the menu label and the placement, not the feature.

Findability is decided along the path between the moment someone forms an intention and the moment they reach the place where that intention gets carried out. The quality of the feature doesn't set the score. The length of the path and the accuracy of the signposts do.

Four things hold that path together.

1. Information architecture (IA) — the skeleton that decides how content is divided and grouped. Split menus the way the team builds and they stop matching the way people work. If permission settings sit under an admin menu while share links sit under a document menu, anyone who needs both bounces between two places every time.
2. Labeling — the names on menus and buttons. Internal vocabulary leaks into the interface constantly. If billing details live under a menu called Workspace management, someone trying to change plans never opens that menu at all.
3. Navigation — the machinery for moving between screens. The interface has to keep answering where you are now and what sits one level up, or people stop exploring. Go three levels deep with no way back except the browser button, and a person who guesses wrong once stops there instead of trying a second branch.
4. Search — the remaining route when structure and naming have already failed. Search only works when the person knows the right word. When the product's name for something differs from the word the user reaches for, the results come back empty.

Break any one of the four and the path breaks. A precise label three levels down still loses people before they arrive, and a top-level item with an unfamiliar name gets scrolled past. This is why findability work rarely comes down to one change. Moving an item usually means renaming it too, because the name that made sense inside a settings menu reads differently in the top bar.

The word comes up in three kinds of rooms.

First, deciding where a new feature goes. Which menu something lands in looks like a matter of taste, and it moves feature adoption more than most feature work does. The same capability placed in the top navigation versus buried in a settings screen can differ several times over in the share of accounts that ever try it.

Second, diagnosing low usage. If eight percent of accounts use a feature, there are two explanations: nobody needs it, or nobody knows it's there. The first calls for retiring it and the second calls for moving it. Since the two responses point in opposite directions, confusing them produces a confidently wrong decision. One way to separate them is to look at repeat use among people who opened the feature even once. If sixty percent of them keep using it, the need is real and the only remaining problem is that everyone else never arrives.

Third, choosing a research method. A findability suspicion can be checked before any screen is designed. Tree testing hands people menu labels with no interface and asks them to find their way; a first click test shows one screen and records nothing but whether the first click lands in the right region.

"The feature isn't missing, the findability is bad. Let's move it before we build anything."

A judgment that repeated requests come from placement, not from a gap in the product.

"This menu name kills findability. That's a word only we use."

A flag that internal vocabulary shipped to users.

"Search covers it, so findability is fine."

An admission that search is patching a broken structure, and it usually draws an argument from whoever has looked at the query logs.

At Pagedeck, Noa raised this about document export. Three months after launch, four percent of accounts had used it, while requests to build that exact feature arrived every week. Noa pulled up session replays of the people who had written in, and six of the eight opened the three-dot menu at the top right of a document and closed it again. The feature lived somewhere else entirely, inside workspace settings in the left sidebar.

Noa moved the item into that three-dot menu and renamed it from Export to Save as PDF. Nothing else about the feature changed — same formats, same output, same code. Six weeks later usage was at nineteen percent and the requests stopped. That was also when Mia deleted three improvement items for the feature from the roadmap. It had never gone unused for lack of capability, so there was nothing to improve.

The most common belief is that adding a search box solves findability. People can't find things, so give them a tool for finding things — the reasoning is easy to follow. But search only works for someone who already knows what the feature is called. For a person who doesn't know such a feature exists, an empty search field offers nothing. Bolt search onto an unchanged structure and the query logs stay quiet, which the team then reads as evidence that no problem exists. The people who would have searched are the ones who already gave up.

The opposite mistake is just as common: surfacing everything on the first screen so nothing can be missed. With thirty menu items, all thirty become invisible, because a list long enough to require scanning gets skimmed rather than read. People find in a nine-item menu what they miss in a twenty-five-item one. Raising findability is less about showing more and more about making the thing that matters right now stand out.