How we rebuilt search for the way teams actually work

The brief

The mandate was simple to say and hard to do: one search, every workspace. Tasks, docs, comments, and files all had to come back from the same box, ranked the same way, without slowing any single page down.

We had tried a smarter search before and watched people ignore it. The lesson from that attempt was blunt: a search box is only used if it is faster than browsing. Anything slower gets skipped on the first busy morning.

Constraints first

So we started with constraints instead of features. Before writing a single query we agreed on one latency budget, one index for every content type, and a fixed set of ranking signals. Everything downstream had to fit those terms or it did not ship.

Constraints feel limiting for about a week. After that they are the reason a new content type ships in an afternoon instead of a sprint, because most of the decisions are already made.

Signals over strings

The single most important rule is that results never rank on text alone. They read signals. A task does not come first because it contains the word; it comes first because it is recent, it is yours, and it lives in a project you open every day.

• Recency, not dates. A task touched this morning outranks one from last year, so fresh work surfaces with no manual pinning.
• One ownership signal. Work assigned to you or written by you gets a steady lift, so your own items stay near the top.
• Per-workspace weights. Relevance is tuned too, learned once per workspace instead of guessed for everyone.
• Typo tolerance. Misspellings and partial words resolve in one place, so nothing fails on a stray keystroke.

If people type three letters and press enter without looking, you have search. If they scroll the results page, you have a list.

Ranking, not filtering

The second rule is that we rank, we do not filter. Search returns one ordered list you can trust, not a dozen checkboxes that quietly multiply into empty results pages. You can read the full reasoning in our engineering notes.

A filter is a hint to the ranking, not a wall around it, so a narrow query still finds the obvious result. That single choice is why search has grown to cover twelve content types without the results page collapsing under its own options.

Shipping it fast

The last rule is the one teams feel the most: every result arrives fast. Keyboard navigation, previews, empty states, and the latency budget are done before a feature is considered done, not filed as follow-ups that never come.

That is the whole trick, really. Make the fast path the easy path, encode the hard parts once, and hand people a box that already knows their work. Do that and your team will search its workspace, not scroll through it.