Searchable Is Not Enough: Search-and-Filter Combinations for Vibe-Coded Projects

A user types a keyword into your product, ticks three filters, and lands on a page that says "No results found." Then they close the tab. That is not a search technology failure. It is a filter-combination design failure: the user knew exactly what they wanted, but the product gave them no path to loosen one condition, rephrase the query, or look at something similar first. This guide is about how the search box and the filters should work together.

A note on the examples first: the used-book marketplace "Picklight Books" and the buyer "A-Zhe" in this article are fictional, invented only to make the reasoning concrete. They are not a real product or a real user. The method itself is general and applies to any product with a list to browse.

A scene that happens all the time

A-Zhe wants a copy of "Designing Design": an edition from 2019 or later, under 60 yuan, preferably from a seller in his own city, in 80-percent-or-better condition. He types the title into Picklight Books and gets more than 200 results. He ticks "same city" and "80% condition or better" and is left with 3. He caps the price at 60 yuan and the count drops to zero. He stares at the empty page and wonders: which condition killed it? The price, the city, or the condition? The page does not tell him. So he unticks conditions one at a time, and after four attempts he discovers the truth: there are only two copies from same-city sellers, one costs 68 yuan and the other is in 70-percent condition. Loosen any single requirement and something is available. But the product never did that arithmetic for him. It just handed him the zero.

What hurts most here is not the zero itself. It is a zero with no explanation. Users are not defeated by "there is nothing." They are defeated by "I don't know what to change." Plenty of vibe-coded products have this problem: the search box, the filters, and the sort order each do their own thing, and nothing on the page explains how the current result set came to be. So users guess the rules by trial and error, and after two wrong guesses they leave.

There is a quieter failure, too: too many results. A-Zhe's first search returned 200 items, and after two pages of scrolling without finding the edition he wanted, he left as well. Being searchable and being findable are different things. Search narrows the range, filters narrow it precisely, and sorting pushes the most likely items to the top. If any of the three is missing, users feel that the thing is in there somewhere but cannot be found.

The decision framework: divide the labor, fix the combination logic, then handle the empty state

Before drawing a filter panel, settle three things: what the keyword and the filters each own, what logic applies when several conditions combine, and what happens when the result is empty. Once those three are decided, the interface is just execution. Without them, even a beautiful interface produces chaos in combination.

First, divide the labor between keyword and filters. The keyword answers "what thing am I looking for"; filters answer "among those things, which subset do I want." Title, author, and publisher belong in the keyword, because they point at a specific object. Price range, region, condition, and availability belong in filters, because they carve up a result set. Mixing up the division is a common mistake: making users type "Designing Design 80% condition same city" into the search box, where one wrong character wipes out everything. Users should not be doing work that a control was built to do.

Second, write the combination rule as one sentence, and make that sentence visible on the page. The rule that goes wrong least often is: options within one group combine with OR, while different groups combine with AND. Tick "90% condition" and "80% condition" and you mean either is fine; add "same city" and you mean within that range, it must also be same-city. The rule itself is simple. What trips people up is that many products never show it: a user ticks two condition levels, sees fewer results, assumes AND, and concludes the product is broken. The selected-filters bar exists to fix this. It lists the conditions currently in effect, verbatim, so the user can see at a glance what the page is actually filtering by.

Third, the default state needs a point of view. With no keyword and no filters chosen, the page should neither be blank nor dump the entire catalog in upload order. It should answer "what would someone opening this for the first time most likely want to see": recently listed items, platform picks, or same-city results first. Any of these is fine, but the choice must be explicit, and it must be obvious that this is a starting point, not everything. A default list with no point of view looks like "we have everything" and reads like "we don't know what to show you."

The concrete work: from the input box to the result list

Start with the search box. Offer suggestions as the user types, but only suggestions that lead somewhere directly: a full title, an author name, a category name that opens that result set in one click. Do not offer sentence fragments, and do not make suggestions that only trigger another search. For typos, do not pass a death sentence: show results for the corrected term first, say in one line "Did you mean X?", and keep an entry point for searching the original term. Users mistype all the time; correcting them once is far kinder than making them retype.

Search history and trending searches are fine, but keep them restrained. History should hold only the user's own last three to five queries; trending should list terms people actually searched, not terms invented to fill the empty space under the input box. When a user opens the search box, they want to find something fast, not to admire what everyone else is supposedly searching for.

Filters come in three kinds, and each needs different treatment. Hard conditions like price, region, and availability are black and white, so checkboxes, range inputs, or toggles work, and they should take effect immediately. Soft conditions like condition grade or edition carry ambiguity of their own, so their definitions must be spelled out: what exactly does 80-percent condition mean, and do scratches count? One sentence on the page beats leaving users to guess. Sorting is not a filter, but it shares the result set with the filters, so the panel must also show the current sort order. Otherwise users will misread a sort change as a filter change.

Put a count next to each filter option when you can, telling users roughly how many items remain if they tick it. Counts do two jobs: they help users predict, and they prevent users from ticking their way into a zero they did not see coming. An approximate count is acceptable. A fabricated one is not. If "same city" claims 128 items and delivers 3, users will stop trusting the whole filter panel. If you cannot compute live counts on a small dataset, leave them out rather than inventing numbers.

The selected conditions belong in one bar at the top of the results, each with its own remove button, plus a "clear all." This is the most important line on a filter page, more important than the panel itself. When users change their mind, they change one condition, not the whole set. A product with no per-condition removal forces users to tear everything down and start over, and two rounds of that is enough to drive anyone away.

Filter state should be shareable and survivable. Encode the conditions in the URL, so a link sent to a friend opens the same result set; going into a detail page and back should keep the conditions intact. Many vibe-coded products store filter state only in page memory for convenience, so a refresh or a back navigation wipes two minutes of careful tuning. That is worse than having no filters at all, because it first gives hope and then takes it away.

Mobile needs its own treatment. A phone screen cannot copy the desktop sidebar. The usual workable pattern is a bottom drawer with a "View results" button that states the count, for example "View 24 results." Users tick conditions knowing what they will get, and one tap shows it. The worst pattern is a drawer where users tick conditions, close it, discover zero results, and have to reopen the drawer to untick things one by one.

An empty result is not the end; it is the start of a four-step recovery

An empty results page should offer four things, in order, and it is incomplete if any is missing. First, state the conditions in effect. Not "No results found," but "Title X, under 60 yuan, same city, 80% condition or better: 0 items." Users can only decide what to change once they can see what they asked for.

Second, loosen exactly one condition at a time, and show the count each loosening would produce. "Drop the same-city restriction: 14 items." "Raise the price cap to 80 yuan: 9 items." Loosening one condition at a time lets users identify the bottleneck; loosening everything at once shows a pile of irrelevant items and still hides which condition was the problem.

Third, drop the keyword and show similar items under the same filters: other books by the same author, or books on the same topic. Label these honestly as "similar items under your filters, not title matches." Honestly labeled near-misses are helpful; near-misses pretending to be matches are a nuisance.

Fourth, give users a way to avoid coming back to check manually: a restock alert, a wanted listing, or a saved filter set. A user who did not buy today has not necessarily stopped wanting the item. An "alert me when one appears" exit turns a zero into a reservation. Many small products miss exactly this step: the user leaves, the product never learns what they wanted, and when a matching copy is listed later, nobody knows to bring them back.

There is one more empty state that gets overlooked: not filtered-empty, but genuinely empty. A just-launched platform, a niche category, or a newly opened city simply has little data. In that case the page should not pretend to be large. Say honestly "this category currently has 12 books," and point to adjacent categories or site-wide new arrivals. Users can accept a small platform. They cannot accept a small platform pretending to be a big one.

Six anti-patterns worth checking against

The first anti-pattern is "more filters is better." Some builders turn every database column into a filter option, leaving users to study twenty options, use one or two, and feel exhausted before they start. Filter count should follow what users actually use: watch five real people filter, and cut or fold into "More" anything nobody touches.

The second is sort order changing behind the user's back. A user sorts by price low to high, ticks a filter, and the page silently reverts to the default sort. The user thinks the cheap copies vanished. The rule: a sort order the user explicitly chose must not change when filters change. Only the user changing the sort, or clearing all conditions, may restore the default.

The third is filtering without showing what is filtered. With no selected-conditions bar, users forget after two pages what they ticked, and strange results just look like bugs. The selected bar is not decoration; it is the documentation of the filter feature, and it must stay visible.

The fourth is fixed price bands only. Bands like "under 50" and "50 to 100" never fit a budget of 60. A continuous condition like price needs a custom input box; bands can sit beside it as shortcuts, but they cannot replace it.

The fifth is a hidden reset, or a reset that also wipes the keyword. Reset should clear filters only; the keyword is something the user typed, and it should not be swept away as a side effect. Worse still are products with no reset at all, where users must untick everything by hand and give up at the third item.

The sixth is "apply on submit." Every tick requires a confirm click before results change, so tuning three conditions takes three confirmations. Annoying on desktop, miserable on mobile. The default should be instant application. If a scenario genuinely needs batch confirmation, such as selecting dozens of tags, the button should at least state the result count, so users know what will happen before they click.

The acceptance checklist: run through it before shipping

Do not validate search and filters by testing only that "something comes back." Run this list item by item. First, empty queries, typos, single-character queries, and very long queries: the page must never crash or go blank, and typos must get a correction prompt. Second, multi-select within a group behaves as OR, across groups as AND; the selected bar matches the actual results, and per-item removal and clear-all both work. Third, filter state lives in the URL: a copied link opened by someone else shows the same results, and returning from a detail page preserves the conditions. Fourth, custom price input works, and an invalid range such as a minimum above the maximum produces guidance rather than a silent zero. Fifth, deliberately construct a zero result and check that the page shows, in order, the current conditions, single-condition loosening suggestions, similar items, and an alert option; missing any one of them is a fail. Sixth, on mobile the drawer button carries the result count, and closing the drawer does not lose conditions. Seventh, sort order does not change on its own when filters change, and a user-chosen sort takes effect immediately. Eighth, give three people who have never seen the product three tasks with no explanation from you: find a specific edition under 60 yuan from a same-city seller, browse broadly then narrow down, and recover from a zero result to find a substitute. If all three finish without you explaining the rules, the design works.

After launch, the search log is more honest than user feedback. Once a week, look at three numbers: the share of queries returning zero results, the average number of condition changes before a user finds something, and the click rate on the loosening suggestions on empty pages. A persistently high zero rate means the data itself has gaps, or a filter's definition differs from what users understand. Many condition changes mean the combination rule is invisible. Unclicked loosening suggestions mean the suggestions are not loosening the real bottleneck. You do not need to watch these daily, but at least once a month, adjust on their basis: cut unused options, fix ambiguous definitions, and give the most commonly loosened condition a more sensible default.

The final test is simple: search and filter design is not measured by how many filter options exist, but by how many steps it takes a user to go from "I want to find something" to "I found it, or I know exactly what to change next." Fewer steps means the product behaves like someone who understands. More steps means that no matter how many filters you offer, you have simply handed the work of finding back to the user.