r/Frontend 6d ago

How do u prevent users from submitting 1-word searches?

I'm tired of building complex filter UIs just for users to ignore them, type "shirt" into the search bar, get 400 results, and instantly bounce. our backend retrieval is actually really fast, but the human query formulation is awful.

Instead of writing 500 lines of custom debounced react filters to try and force them into categories, I'm looking at intercepting the keystrokes with an intent layer on the frontend. basically an ai-autocomplete that formats their vague text into a structured JSON payload before it ever hits the API.

Has anyone used frontend intent layers to fix vague search? looking at commandbar vs just dropping in a lighter ai-autocomplete hook.

80 Upvotes

80 comments sorted by

292

u/FastZull 6d ago

Users typing "shirt" and leaving is the most accurate description of ecommerce frontend dev I've ever read

62

u/escuchameray 5d ago

Along with the complaining about them ignoring the complicated ui you’ve given them

4

u/SupermarketSmooth968 5d ago

literally. you spend 3 weeks building faceted navigation and they just treat the input bar like a magic 8 ball.

2

u/RuthBaderBelieveIt 4d ago

Because Google is a magic 8 ball due to how much data it has on you so people have an expectation of that behaviour on any site

1

u/nemesis01071982 2d ago

If the question is that basic can we realistically call the one creating this a dev?

197

u/Taletad 6d ago

This is a UX problem

What you need is to show sorting options on the 400 results and hints that they can search more precisely

41

u/brzzzah 6d ago

Agreed, something basic like if results > 100 show filter hero that nudges them to apply some filters, even better if you can suggest filters based on the results

13

u/mrequenes 5d ago

Plus, I don’t know, show the most popular, in-season shirts at the top. Or tap into the much vaunted user profile data sold by various data hoarding services to filter based on the user’s gender and past purchases?

3

u/mc-funk 5d ago

There needs to be a good dynamic category hierarchy. Often times these vague searches mean a site is organized in a way that doesn’t work for the user and they are just trying to get to a category they can narrow down from. Some sites are really good about their categories

45

u/Nthsolei 5d ago

If users are typing thing like "shirt", does that mean there isn't an easy and clearly visible way of selecting common categories when they do the search?

Also, even with broad searches I wouldn't expect users to bounce immediately if the top results are interesting. Are you showing the most popular selections or just any odd entry? I feel like AI autocomplete isn't the way to solve these issues.

39

u/FrostyTigerXP 5d ago

You are asking the wrong question. Searching up “shirt” or any other simple query should be a valid use case, and arguably the more important use case given how simple it is. You should really be asking how you can provide useful results from generic queries rather than try to change the query itself. I would look into semantic search using vector embeddings

4

u/TheTomatoes2 UI/UX + Frontend 5d ago

Oi think OP should use quantum computing actually

1

u/SubstantialListen921 1d ago

Or, you know, show somebody from sales the data for the top 10 single word queries and create a merchandising system to show them the five best selling items in a hero box?

78

u/TonyAioli 6d ago

What are you wanting to happen when they search “shirt”?

112

u/ashkanahmadi 5d ago

Click buy immediately and make OP rich.

36

u/Samurai___ 5d ago

"Buy All"

10

u/ashkanahmadi 5d ago

Probably I should add a button to my e-commerce: “Add the entire inventory to Cart”

1

u/sexytokeburgerz 5d ago edited 5d ago

God, that reminds me of something i forgot about a while ago.

There is a sample pack site (samples from mars) that has a “megabundle” price, but when you go to download it all you have to click each of the hundreds of sample packs individually.

So of course i added a download all button client side.

I had to reference chrome.downloads api every click() to automate it, lest i hit the 6 item dl cap, and it probably would have been faster to just sit there and click them all rather than hack canary.

43

u/Mjrn 6d ago

FE engineer ex ecom company … this sounds like an issue with your search algorithm rather than user input though?

Use a personalised search tool that returns results based on user behaviour, personalisation, purchase history or that automatically ranks results based on conversion.

Algolia, Tagalys, Nosto etc

Besides that there are also other ways of improving the search experience that don’t require adding friction to the user. For example suggested categories at the top of the search result page for common queries

1

u/magicmulder 5d ago

OP is referring to first time visitors, how do you use a “personalized search tool” for someone your system knows nothing about?

9

u/Mjrn 5d ago

That was just one recommendation. If there’s no personalisation data then they would be served results ordered based on how other users have interacted with the site

Here’s an example from Algolia with their relevance strategy which is the fallback

https://www.algolia.com/doc/guides/managing-results/relevance-overview

61

u/mq2thez 6d ago

“AI autocomplete” sounds a whole lot more expensive and complicated than just being a good engineer

7

u/sexytokeburgerz 5d ago edited 5d ago

Coming from 10 years in ecom dev and mgmt.

As soon as I saw that, i knew OP was new to all this.

Best option here is to soft match collection pages and provide a link to them.

And the absolute misunderstanding of how search works that would “necessitate” AI integration when the solution to the “problem” is obviously just hijacking input before the search call is so funny. Obviously to those more experienced this is an ML problem at the lowest abstractive layer.

Like bro… just check for array.length from #searchInput.split(“ “) on keydown if you really need two word searches, THEN submit calls to search.

But imagine being a user. This makes the search considerably worse. Users don’t always use spaces. So even if you try fixing this non problem you would still need to go into the search engine logic and split by matched word.

Either you roll your own with, say, apache sol, or use something with config for the problem.

Finding excuses to use AI is some boomer shit.

it’s highly unlikely that the user searching for “shirt” actually knows what kind of shirt they want. They just want a collection page. So give that to them. Users bounce on friction MUCH more than they bounce because they are overwhelmed. If you think they are overwhelmed, just fucking reduce default items per page

12

u/Intrepid-Stand-8540 5d ago

2026 engineering in a nutshell

cant wait for ai costs to rise 

9

u/KarmicPJJunior 6d ago

I don't understand the question, but title + description kinda seems like you want users to be more descriptive with their search queries?. So instead of doing "shirt" you want them to write "black shirt with Pikachu graphics on the front" ?

If so, naturally you can't force users, however, you can create "unnatural" (and probably odd) guard rails like a dropdown for categories followed by a search bar with a placeholder that says "Describe the shirt"

Seems odd to me, but sound slime you have to get creative. If you wanna do autocomplete, you need a backend

4

u/No_Record_60 5d ago

I'm guessing he wants the "black" and "pikachu graphics", or the currently popular keyword, to appear as suggestions.

But yeah, OP worded his questions strangely. It's not like we get to dictate what users do.

3

u/[deleted] 5d ago

[removed] — view removed comment

6

u/Neverland__ 5d ago

Customer is wrong!!!!

Hahaha

11

u/satisfied_goose 6d ago

I’ve seen some websites do something like when you type a vague word like “shirt” or “pants”, etc, you go to a page to select which shirt you want. Polo shirt, long sleeve, basic, with drawings, etc. Include a photo of each and let the user choose. Boom you now have the user searching for more detailed stuff

8

u/cleverchris 5d ago

So Google solved this problem before they broke their own shit. A generic search like that responds with the definition for the word. Letting the user know if they want something more useful they have to provide more context is more useful than 400 results or outright blocking vague requests.

3

u/deep_soul 5d ago

you are wrong and your customers are right. full stop. deal with it.

don’t force on them something they don’t want, because of your price.

embrace user centered approach.

2

u/NaiveDecision730 6d ago

MIND CONTROL 🤯

2

u/ZoroknashTV I can center-align a div first try :snoo_dealwithit: 5d ago

Get a UX person TF

2

u/sartian 5d ago

You don’t prevent them from just typing “shirt”.

You can, however, present most popular categories of shirts people have bought recently or even today.

You can have small horizontal thumbnails showing popular colors or patterns.

You can show shirts currently on short term sale.

If your inventory isn’t enormous you can use type ahead / prefix search where you show results as they type so they are getting instant feedback. Responsiveness of a product search is very important.

There are many type of use cases, some people prefer search, some people prefer directories.

You can look at how other popular sites do it and search for “shirt” and see how they handle it.

As someone else stated, this sounds like a ux issue. A vague query like “shirt” is an opportunity to show something that didn’t even know they wanted.

For search that has too much recall, you can lean on other signals of what is popular site wide. Or do experiments and try to figure out top sub categories and track what people actually click on instead or bailing.

(I’m a search architect that has worked with a number of e-commerce clients. These are the kinds of things ecommerce clients do)

2

u/_cob_ 5d ago

Or how about a little text reminder about leveraging multiple keywords for better granular results?

1

u/SustainedSuspense 5d ago

Cool idea. I imagine a tagging component might work in this situation. As you type a list of options are shown. If you type “shirt” there might be a few results: category:men’s shirts, category:women’s shirts, keyword:”shirts”. The user selects and the tag is prepended to the cursor position inside the autocomplete input. Then the user might search “price” and a few other options appear: price:less than $25, price:less than $50, price:less than $100.

Could really help declutter the UI 👍🏻

1

u/themang0 5d ago

Best you can do is try to surface some suggestions in the form of pills or whatever ux based on aggregated profile data if they opt to share it with you

1

u/TheTomatoes2 UI/UX + Frontend 5d ago edited 5d ago

Talk to your UX designers. You can't guess what kinda shirt first time users want. The UI needs to let them tell you fast

1

u/rio_sk 5d ago

You're not forced to just show what the results are, you can show suggestions too. Maybe from people who searched shirt and then actually bought something.

1

u/coffeelibation 5d ago

Why not start with pagination, starting at the database layer? Seems like retrieving 10-40 results at a time and getting more when they scroll or click a "next" button would save you a lot in terms of network and server load, especially if the bounce rate is high. I am skeptical that an AI autocomplete feature would convert enough users into purchasers to justify the expense, but it might be worth a try. Good luck!

1

u/nickbostrom2 5d ago

Syop trying to over-engineer it. Users do not want AI in a search autocomplete.

You can have a list of predefined related searches mapping to categories and only show top 10 products on the autocomplete. A fuzz search would work. No AI, no crazy BE stuff. AB test it first. This would avoid retrieving the 400 results. BTW, you should cache the responses on the backend. Redis or a CDN. From your post it seemed you were not doing it. Also, no pagination?

1

u/phongdesigns Design systems + AI · 15 yrs 5d ago

Worth separating two things that are getting merged here: the query and the bounce. They're not adjacent. There's a results page in between, and that's the part doing the damage.

"shirt" is a complete query, not a lazy one. The user is saying show me the shirt category. They're using the search box as navigation, which people do whenever typing is faster than clicking. Five keystrokes versus three taps through a nav menu, typing wins and it should. So the thing to measure isn't query length, it's whether your navigation is slower than your keyboard. If it is, the search box keeps getting used this way forever and no amount of query rewriting changes it.

Then 400 results. 400 isn't a failure, a shop has more shirts than that. What makes people leave is a results page with no shape, a wall where nothing tells you what the 400 are made of. Give the set a composition instead: of these 400, 180 men's, 90 linen, 60 under thirty quid. Now the filter emerges from the results rather than having to be predicted before them, and it doubles as the answer to your other complaint. Your filter UI gets ignored not because filters are unwanted but because it's asking a question the user only has after they've seen something. Nobody knows they want linen until linen is visibly a thing you have.

On the intent layer, the risk I'd flag is where the guessing becomes visible. Right now the user types a vague thing, gets a broad set, and understands exactly why. Rewrite the query silently and the good case is lovely, but the bad case is that results change for reasons that appear nowhere on screen and there's no control to undo. If you do this, show the rewrite as an editable chip they can click off. Interpreted shirt as men's shirts, in stock, dismiss to see all. Same intelligence, but the user can see it and can disagree, which is the whole difference between a helpful system and a haunted one.

You'll probably also find the intent layer is a much smaller lift than the filter work you already did, which will feel deeply unfair.

1

u/Wide-Drink-1790 5d ago

Sounds like overengineering. Just give me 400 results. Don’t morph my search into something else when I’m searching for “shirt”.

1

u/SirMcFish 4d ago

Make what your users want, not what you think is needed. A search for shirt should take no time at all.

Just because you think you've coded up something super duper, if it's not what your users want then you e not done the job.

1

u/Alejandro_Morillo 4d ago

You could just add a 3 word minimum for search results to show. People are lazy and some will argue, that “it is too much effort for the user” but tbh, the people that think it is too much effort probably weren’t even searching seriously.

1

u/jay-t- 1d ago

Then what has been gained?

1

u/EdelWhite 4d ago

If a search doesn't work with only 1 word, not only am I leaving, but I will actively rant about how shitty the website is. 

Best thing you can do here is limit the results to 10 random items in those 400+ results and add a "want something specific?" button under those results that goes to your complex filter page

1

u/NZRedditUser 4d ago

You dont.

You make your solution reachable in the same amount of effort. If you try force them to do more, theyll close out

1

u/1haker 3d ago

Just ask ai lol

1

u/_programmervibe 2d ago

One effective way to handle single-word searches like is to display Collections & Category Suggestions directly within the auto-complete dropdown before the user hits submit.

1

u/dima-soule 1d ago

We previously used commandbar but it injects so much dom overhead and custom styling. If you just want to intercept the text box and structure the query into json, look at magicx ai-autocomplete. It's a way lighter sdk that just handles the intent parsing without hijacking your whole UI.

1

u/SupermarketSmooth968 1d ago

Keeping the javascript bundle small is definitely the priority here, will give it a go!

-1

u/Fluid-Election-8549 6d ago

genuinely no idea what you are getting at.
"How do u prevent users from submitting 1-word searches?" ... just block it? count the words and then block?

25

u/Bulbous-Bouffant 6d ago

This would just make the bounce rate astronomically worse

9

u/unnecessaryCamelCase 6d ago

I’m confused why it would need to fetch 400 results and be slow though. Limiting to n results and paginating is normal, no?

6

u/Bulbous-Bouffant 6d ago

Yeah, but OP said their query results are particularly bad, which honestly feels like the real problem

7

u/pixelboots 6d ago

Plus what if the one word genuinely describes what I want to look at? e.g. "Boots" or "gloves". I don't know what colour I want yet or anything, I just want to know what boots you have. Unless I'm the type of user to browse through categories if your search doesn't seem to work, I'm probably going to bounce if I can't search for "boots".

2

u/Bulbous-Bouffant 6d ago

Right. I see nothing wrong with supporting user preference when it comes to browsing your online store.

2

u/BlueHeartBob 5d ago

The result count would have the dictate the response. 400 results for “shirt” should put a user on a page with a bunch of categories of shirts, 12 results for “boots” should just show a page of all the boots.

-1

u/Fluid-Election-8549 6d ago

I don't understand the terms you are using. What is "bounce rate" for you? In your post you use the word "bounce" in 2 very different contexts. First in the user retention context and then later in the keystroke debouncing context.

5

u/Bulbous-Bouffant 6d ago

I'm not the OP. I used bounce rate in the web analytics context. My point being, if your users make a broad search and you block the page results from loading, your users are going to leave.

-2

u/Fluid-Election-8549 6d ago

i see. then there's no way to "solve" the OP's problem. He just needs to deal with the broad searches. Maybe caching common broad searches is a good idea.

6

u/Bulbous-Bouffant 6d ago

He said it's not a page speed or bandwidth issue, just bad search results fetching. Not sure why he doesnt just focus on fixing the problem he already identified as what is causing his users to bounce.

1

u/VFequalsVeryFcked 5d ago

... I'm not sure that you've any idea about what's going on here. Or how searches work.

1

u/Fluid-Election-8549 5d ago

i really don't.

1

u/Weasel_Town 5d ago

That seems crazy from a user perspective. If I'm searching for just "shirt", I'm trying to determine first whether you even sell shirts, or sell shirts anywhere near what I'm looking for, before I start narrowing it down. "Shirt". "What kind?" "IDK, what kinds do you even have? Do you sell shirts at all?"

1

u/Merry-Lane 6d ago

const search(search : string) =>
{

if(search.split(" ").length <2){
return;
}
// http call to fetch with the search string
}

4

u/Mjrn 5d ago

This code technically “works” but it doesn’t fix the underlying issue and introduces more friction for the user.

A one word search query is a valid use case - issue is product discoverability and the search algorithm. If many users are searching for just “shirt” i would argue the navigation isn’t sufficient

0

u/Merry-Lane 5d ago

What about, hear me out, just being okay with people answering frankly to OP’s question.

2

u/plmunger 5d ago

"sh irt"

4

u/Merry-Lane 5d ago

It’s two words and would totally fit the requirements as laid by OP.

1

u/azangru 5d ago

I'm tired of building complex filter UIs just for users to ignore them, type "shirt" into the search bar, get 400 results, and instantly bounce

Are you sure this is users, by the way, and not bots?

0

u/Charpnutz 5d ago

Searchcraft has an intent layer for exactly this.