In this article, we’ll introduce 3 functional groups of user search, along with 8 types of search queries identified during our large-scale usability study of e-commerce search:
Our usability testing reveals that these 3 groups and 8 types of queries represent the main principles behind how users think of and construct their search queries when searching in an e-commerce context.
During our usability studies, beyond the common keyword search for a specific product, users were observed to rely heavily on search queries that included a product type, a theme, or a feature. Yet surprisingly, our 3 rounds of search UX benchmarking of 60 of the world’s largest sites in 2014, 2017 and late 2019, reveal a still surprisingly poor support at e-commerce sites for these query types - as is evident in the graph above (late-2019 results).
An analysis of the more than 8,400 manually set UX performance ratings from our search UX benchmark reveal a surprisingly weak support for essential e-commerce search query types, with 61% of all sites performing below an acceptable search performance that will directly misalign with user’s actual search behavior and expectations. To make matters worse, 15% of sites were found to have a downright “broken” search query type performance.
Most of the site improvements we’ve observed since we first benchmarked this in 2014 have largely been offset by users’ increasing expectations for what type of search queries they can perform online (expectations likely carried over from their general web and social media search, that generally tends to be a lot more capable).
While there has been a steady improvement in some of the search query types over the past 5 years, there are still fundamental search UX issues. For example, among 60 top grossing US and European e-commerce sites in late-2019:
In this article, we’ll go over our large-scale UX research findings for each of the 8 query types most common for e-commerce search — showing you the observed user behavior, where and how it causes UX issues for e-commerce findability, query samples, and the principled needed for how to best support each query type.
Note: Some eagle eye readers may notice that a previous version of this article covered 12 query types. While the other 4 query types that we found during our testing (Relational, Subjective, Implicit, and Natural Language query types) are still valid, they are much less frequently used by users and are often industry-specific. For this reason, we have omitted them from the article. To find out more about these query types, as well as more about the covered 8 here, you will need Baymard Premium access.
When users search in an e-commerce context, they are mostly looking for products. This prompts users to search differently than they do when performing generic web searches. In particular, users will often include one or more criteria in their search which the product must meet.
Users will commonly combine the 8 query types when devising their search queries, with certain components of the query “setting the range” of the search while other components are included to refine and delimit that range. Indeed, the 8 query types may be divided into 3 functional groups that map to those intents:
In short, the Query Spectrum is the user’s way of “setting the search range”, and they then use Query Qualifiers to “delineate the boundaries” of that range, while the Query Structure determines the syntax and context of the query.
Keep these different functional aspects of the 8 query types in mind as you read through each of them below, as it will help you better understand how users approach search on e-commerce sites. By deconstructing the functional aspect of each query type, its role in the user’s query as a whole becomes clearer, which can be immensely helpful when looking to design search logic and interfaces that align with user behavior and expectations.
Users rely on the query spectrum to indicate the range of what should be searched. Sometimes users want to see a broad collection of products, in which case they will typically set a wide Query Spectrum by, for example, submitting a generic #2 Product Type query such as “Laptops”. Other times users are looking for something very specific, and will therefore define a very narrow Query Spectrum, typically in the form of a #1 Exact Search like “Grado Prestige SR325” (a specific pair of headphones).
The query spectrum is the user’s way of “setting the search range” and includes 4 query types:
When users know the exact product they are looking for, they will typically rely on #1 Exact Search, entering the product’s title or model number, such as “Keurig 45” (a coffee maker). “Exact Searches” are typically the easiest to support technically, and most of the tested sites fared reasonably well.
While this may at first seem like an easy case of keyword matching against those two product attributes, the search engine must be a little smarter than that and there are a few conditions to take into account — refinements that will take the “Exact Search” query implementation from acceptable to great. For instance, good handling of phonetic misspellings is crucial since the user may only have heard the product title spoken and not know how to spell it, e.g. “Keurick 45”.
Furthermore, some products have alternative titles, such as Nestlé Quik vs. Nesquik or AT&T Wireless vs. Cingular Wireless vs. AT&T Mobility — all of which should invoke their respective product. This is particularly important for global e-commerce sites where product naming may be localized.
Another reason it’s important to support local and alternate product titles in addition to phonetic misspellings is that users often don’t type out the product title themselves. During testing, users were often observed to copy-paste product titles from external sites into the search field.
Any misspellings (common when copy-pasted from user-generated content, such as social media posts), or localized or alternate spellings (common when copy-pasted from industry databases, such as IMDb (movies), Goodreads (books), Projector Central (projectors), DPReview (cameras), etc.), will therefore be pasted into the search and must be handled gracefully to provide a good search experience.
Acquiring all these local and alternate spellings can prove quite the challenge and vendors may not necessarily input this data on their own. Partnering with relevant industry databases can therefore be a good way to acquire this product information — especially if they are public and users are copy-pasting from them in the first place.
Great support for #1 Exact Searches proved crucial during testing, as the users were observed to quickly conclude that a site didn’t carry the product if it didn’t show up for a request as specific as a model name or number (as opposed to more open-ended queries, such as #6 Thematic Searches).
When we look at the benchmarked top 60 grossing US and European e-commerce sites, we find that 29% of sites are incapable of producing decent results for #1 Exact Searches as of late-2019. More specifically 27% of sites are incapable of handling misspelling of just a single character in the product title, and 2% don’t allow searching on model names (as seen as Costco). (This have only improved marginally, with 34% of sites not supporting Exact Searches all the way back in 2014).
When users aren’t looking for a specific product but rather a type of product, they will rely on #2 Product Type Searches, querying for a whole category of products, such as “Sandals”.
When used on their own, product type searches are generally an attempt by the user to quickly access a category on the site — either because it’s more convenient to search for it or because they are having difficulties finding the category via the main menu. During our most recent mobile testing, 60% of mobile users turned to search as their first product-exploration strategy when landing on the homepage of a new site.
When the site can be sure of a 1:1 match with a product type search and an existing category, it’s worth autodirecting the user to the relevant matching intermediary category page, if one exists, as discussed in our article Autodirect or Guide Users to Matching Category Scopes — 46% Get It Wrong.
Still, a very important aspect of supporting #2 Product Type Searches is to return relevant results regardless of whether the searched-for product type exists as a category on the site or not. This not only requires detailed categorization and labelling of products, but also proper handling of synonyms and alternate spellings of those groupings.
A search for “t-shirt” should yield the exact same results as one for “tee shirt”, regardless of how it happens to be written in each product’s title or description. Other examples include “hair dryer” where the user might search for “blow dryer”, or users may type “multifunction printer” or even “copy machine” when looking for an “all-in-one printer”.
From a user’s point of view these everyday descriptions are just as correct as the industry jargon, and most of the users never thought of trying another synonym when they received poor search results but instead simply assumed that the poor or limited results for a search such as “copy machine” meant that was then the site’s full selection for such products.
Despite the severe impact on the user’s search experience 61% of major e-commerce sites do not return all the relevant results, if any at all, when users search by a product type or synonym, e.g., “blow dryer” instead of “hair dryer”. This is virtually no change from 2014 that found 64% and 2017 that found 61% of sites not returning all relevant results when searching by common product type synonyms.
The Product Type query is largely a missed opportunity within the industry and should always be one of the first things considered in any search UX improvement project due to the severe combination of Product Type searches being frequently used by users, the likelihood of users getting stuck and ultimately abandoning if synonyms aren’t well supported, with the fact that 61% of e-commerce sites currently don’t have proper synonym support.
A few key types of synonyms to consider when auditing or trying to improve a sites Product Type search capabilities are:
Since #2 Product Type Searches are performed by users who are looking to browse a whole category of products, it’s also crucial that such queries enable relevant filtering and sorting options so the user can easily narrow down the list and compare products. Ideally such filters and sorting options are available directly from the search results (via faceted search filters — which 51% of sites still don’t have. See guideline #376 for more on this), although an acceptable alternative is to guide users towards a relevant category scope where such options are available (as discussed in our article E-Commerce Sites Need Multiple of These 5 ‘Search Scope’ Features).
As we’ve seen thus far, when users know the specific product they are looking for, they will use Exact search, and if they don’t know the exact product or aren’t sure about which one they want, they will often rely on Product Type searches.
However, sometimes users don’t even know the type of product they are looking for — all they know is the problem which they are experiencing and that they want a solution to it. In these cases, they will rely on #3 Symptom Searches, entering the problem they are experiencing, such as “stained rug” or “dry cough”, in hopes of being presented with viable solutions and products to this problem.
Symptom search is important because it will often be the user’s last recourse. If users don’t know what solution to look for and can’t search for products by entering their problem or symptom, it’s going to be almost impossible to find the relevant products on the site. Or as one user during our testing reasoned, “You must be able to search on anything. I’m used to that from Google”. This is especially true if categories on the site aren’t problem- or symptom-based (which they often aren’t).
Furthermore Symptom Searches often also have multiple different product types as relevant solutions, making it both difficult and inconvenient for users to find the best solution for them, if the Symptom Search query type isn’t supported. For example, a symptom query for “knee pain” at a sports equipment site should provide users with an array of different product types such as knee pads, knee sleeves, supporting socks, pain-relieving products, sports tape, shock-absorbing shoe insoles, etc. If search teams need inspiration for the complete range of possible solutions to a problem relevant for your industry, consider going to physical store in your same product vertical and actually talk to the in-store experts as users in physical retail will have the same product exploration approach.
For sites where Symptom searches are particularly important, it may be a good idea to suggest its usage in the placeholder text of the search field to let users know that they can search by symptom as it isn’t all users who think of it.
The user can also be guided during search query formulation with the help of autocomplete scope suggestions (see our articles on E-Commerce Sites Need Multiple of These 5 ‘Search Scope’ Features and 13 Design Patterns for Autocomplete Suggestions — 27% Get It Wrong for more about scope and autocomplete functionality). Scope suggestions are a good complement to “Symptom” query keywords because they begin to reveal hints at possible solutions (i.e., categories) that can help guide users to a related query path.
Integrating or interlinking any help or buying guides available on the site directly on the search results page is essential, too, so that users can learn more about the differences between the different solutions available. Although Symptom searches won’t be applicable to every e-commerce industry, they are vital to some, such as drugstores, health and beauty, tools and hardware supplies, cleaning and housekeeping, specialty electronics, B2B, etc.
Our current UX benchmark shows that only 25% of sites within industries where Symptom Searches are even relevant, actually have decent support for it. On most sites, searching for a symptom like “knee pain” will return any products related to the keyword “knee”, and predominantly show irrelevant “knee” related products first, with the actual solutions to the “knee pain” symptom scattered throughout the following hundreds of partial matches – in practice rendering it impossible for users to get an overview of their relevant options.
The final type of Query Spectrum is #4 Non-Product Searches, where the user is searching for something that isn’t a product, such as the return policy or shipping information. While the primary function of search in an e-commerce context is obviously to find relevant products, the search engine shouldn’t be limited to just searching the product catalog, as we consistently observe that users expect the search field to search the entire website (not just the product catalog) - after all that is typically what a search field does on any other non-ecommerce website. Indeed, during our Accounts & Self-Service usability testing 34% of users tried to search for non-product content (e.g., “return policy”, “unsubscribe”, “cancel my order”, etc.).
During testing users would often search for this type of auxiliary content when they had difficulties finding navigational links to it. This is a logical consequence of this auxiliary content being secondary, and links to it therefore tend to be relegated to the page footer or nested deep within help sections. On mobile, finding “Non-Product” content via on-page links or navigation can be even more challenging as these options are often even harder to find compared to desktop sites.
You can read more about our findings on non-product search that we’ve covered in detail in our article E-Commerce Search Needs to Support Users’ Non-Product Search Queries - 15% Don’t.
With the Query Spectrum, the user indicates the “range” of what should be searched.
Depending on their particular needs and available information, this can go from highly specific #1 Exact Searches, to broader #2 Product Type Searches, to the inquiry-like #3 Symptom Searches. Finally, users may be looking for non-product pages, in which case they will perform a #4 Non-Product Search.
A summary of the 4 query spectrums can be found in the table below:
|1) Query Spectrum
Used to indicate the range of what should be searched
|#1. Exact Search
|Searching for specific products by title|
| #2. Product Type Search
|Searching for groups or whole categories of products|
| #3. Symptom Search
|Searching for products by querying for the problem they must solve|
| #4. Non-Product Search
|Searching for help pages, company information, and other non-product pages|
Users rely on query qualifiers to refine and delimit the boundaries of the Query Spectrum. These qualifiers are typically used when the user has a set of criteria that they want the product to meet. For example, the user may try to limit the type of TVs returned by submitting a #5 Feature query such as “OLED TV” or perform a #7 Compatibility search like “Lens for Nikon D7000” to filter out any lenses incompatible with their camera.
Query qualifiers are the user’s way of “delineating the search boundaries” and includes the 3 following query types:
Users often have a set of criteria that they want the product to meet, and very often these criteria relate to features of the product. #5 Feature Searches is when the user includes one or more features in their search query that they want the product to have. For example, a user may not want just any “jacket” but will often be looking for something slightly more specific such as a “leather jacket”.
The term “Features” should be understood in a rather broad sense referring to any type of product aspect or attribute. Features can thus be the product’s color (“red dresses”), material (“fabric sofas”), performance specs (“100000 IOPS hard drive”), or format (“Hobbit DVD”), not to mention price (“$100-$200 backpacks”), brand (“Revlon lipstick”), or size (”size 8 sneakers”). The list goes on, and all significant product attributes should be searchable, even if they don’t exist for all products sold on the site. For example, even if all products on the site don’t have a “format” attribute, movies on the site should still be searchable by it.
“Feature” searches are nearly always used as a qualifier for another search type — a way to filter the results of a certain search. For example, the user may perform a “Product Type” search and then combine it with a “Feature” search to only get a subset of those products (e.g., “volumizing paraben-free shampoo” or “blue breathable north face jacket”). During our testing, users also combined “Feature” searches with “Thematic”, “Symptom”, and “Compatibility” searches.
Users are becoming more and more accustomed to the robust features of major web and social media search engines and their almost uncanny ability to intelligently interpret and yield relevant results to complex search queries — an expectation that users increasingly carries over to e-commerce search.
In terms of implementation, the ideal solution is if to dynamically apply any features searched for as filters on the results page (if a filtering value for the feature exists), as this increases transparency and user control – with the user being able to see what is and isn’t included and being able to quickly toggle related filters on/off. For instance, in the above Wayfair example, the “red” aspect of the “red sofa” query is applied as a color filter, with the user being able to see and toggle the other available colors of sofas.
During testing, #5 Feature Searches were the by far most common Query Qualifier, making it a definite “must have” of the 12 Query Types. Among the top e-commerce sites 86% support that users search by a wide range of features (e.g. color, material, brand), which is a great improvement from the 46% seen in 2014 and 73% in 2017.
What exactly constitutes a “living room rug”, an “extreme weather sleeping bag”, or a “retro dress” ? While these are certainly concepts we can easily recognize, defining their exact boundaries can be a challenge.
#6 Thematic Searches are often a little difficult to define because they are inherently vague in nature — they often include fuzzy boundaries of usage locations (e.g., “living room furniture”), seasonal or environmental conditions (e.g., “spring jacket”, “cold weather sleeping bag”), occasions and events (e.g., “wedding gift”), or even promotional attributes (“sale lipsticks”). Nevertheless, they are very real notions to users who — in certain industries, such as apparel and furniture — include thematic qualifiers liberally in their searches.
Clearly, a great deal of interpretation is required to support “Thematic” searches, both in terms of the meaning of the actual query itself and also in the internal tagging of products, as it’s vital that a query for e.g. “spring jacket” presents all the relevant products, not just the handful of products which happen to have those keywords in their title or description. This will often require some sort of thematic tagging of the product catalog to determine, e.g. which jackets would be suitable for spring (and which wouldn’t). Similar to Feature Searcher the ideal support for most Thematic Searches is often achieved by having these themes as actual filtering values that are then pre-applied when users search by them, as this gives users direct insights into how the site have interpreted their thematic query and an easy way to narrow or broaden the thematic qualifier. (this also improves the general navigation based filtering experience greatly)
Meanwhile, a search for a “Mother’s Day bouquet” requires products to be grouped by an occasion (a social concept). Similar mappings may be necessary for abstract queries such as “macbook power” — an actual search query one of the users in our testing submitted when looking for an adapter for his MacBook Pro laptop.
Because users will sometimes think in these “Thematic” terms when typing into the search field, their product exploration is disrupted when results don’t meet their expectations — forcing users to refactor their queries in order to start a new search.
This is especially difficult on mobile devices because it sometimes requires placing the cursor in a precise position in the middle of query text and often requires backspace deleting many characters (one-by-one) to replace a word or words. During testing, this was observed to be challenging to users, some of whom simply abandoned their search or tried to find products through category navigation instead.
When “Thematic” search queries aren’t supported, users are left with absent, few, or irrelevant results, which costs users extra time to rethink (and retype) query wording, and sometimes gives the impression that the products sought simply aren’t available at the site. In fact, 46% of our benchmarked sites have problems handling “Thematic” search queries, if the thematic identifier doesn’t happen to be part of the product title. This is fairly consistent with the performances from 2014, where 54% did not handle thematic queries well, and 55% in 2017.
Users often don’t know the name of the accessory or spare part they need — instead they know the details of the product they already own. It’s therefore not uncommon to see users perform #7 Compatibility Searches where they input the name or brand of a product they own along with the type of accessory or spare part they are looking for, such as “sony cybershot camera case”.
Compatibility search requires strict compliance — it’s two or more products that must work together, with the user trying to find products that are specifically compatible with a product they already own (or are about to buy). Compatibility searches therefore tend to either
Users who know the exact model of their product will typically submit this, and #7 Compatibility Searches should therefore obviously work with product models. In fact, sometimes compatibility can only be ensured if the exact product model is provided. However, users don’t always know or recall their specific product model, and support for more generic product types and brand names are therefore important as well, so that users can enter generic queries like “13in laptop sleeve” rather than specifying the exact laptop they own.
It’s useful to note that some users deliberately exclude the accessory type in their search and only search for the product they own, as they expect accessory products will be available next to the product. Other users simply forget to include the accessory product type. In both cases, displaying an option to see accessory products for such searches will prove incredibly useful for these users, giving them a way to access compatible products from the product they already own.
Compatibility relationships can be very complex and have numerous dependencies that can be difficult to capture in a free text search. It may therefore be a good idea to integrate Compatibility searches with any product finders or wizards available on the site. For example, if a Compatibility search is detected for “Dell laptop adapter”, it could send the user to a “Laptop Adapter” wizard, ideally with “Dell laptop” preselected. Or the wizard could be displayed as an option among any autocomplete suggestions or on the search results page.
Generic compatibility queries are among the most supported query types, and we’ve seen a steady increase of the sites that sell compatibility items supporting basic compatibility queries since our 2014 benchmark at 62%, growing to 68% in 2017, and 70% in late 2019.
With Query Qualifiers, the user refines the boundaries of the Query Spectrum range by including various conditions that the products must meet.
Query Qualifiers almost never make sense as standalone queries and therefore tends to be combined with a Query Spectrum (with the possible exception being #6 Thematic searches).
Depending on the user’s approach and knowledge about the product domain, they may specify certain #5 Features that the product must have, or describe a #6 Thematic context in which it must be used. Users may similarly try to find products by defining technical #7 Compatibility requirements.
A summary of the 3 query qualifiers discussed above can be found in the table below:
|2) Query Qualifiers
Used to delimit the Query Spectrum, specifying conditions for what should and/or shouldn’t be included
|#5. Feature Search
|Searching for products with specific attributes or features|
| #6. Thematic Search
“Living room rug”
|Searching for categories or concepts that are vague in nature or have “fuzzy” boundaries|
| #7. Compatibility Search
“Lenses for Nikon D7000”
|Searching for products by their compatibility with another item|
The structure of the query determines how it should be interpreted by the search engine. It involves both the linguistic syntax of the query and the circumstances under which it was conceived.
The syntax of the user’s query can be highly important, with a symbol such as ‘-‘ taking on significantly different meanings and functions in #10 Slang, Abbreviation, and Symbol Searches like “$10-100 sleeping bags” and “-10 deg. sleeping bags”.
The query structure deals with how the query is constructed — the context in which it was written and the syntax of the query itself.
Below we discuss one of the most important query structure–type queries:
Users rely on a wide range of linguistic shortcuts when they search. This quickly became evident during our testing as several of the users frequently relied on #8 Slang, Abbreviation, and Symbol Searches, writing slang-based queries such as “RayBan shades”, or including abbreviations like “13in laptop sleeve”, or relying on symbols such as “sleeping bag -5 degrees”.
Slang and abbreviations are by far the easiest to support technically as it essentially just requires mapping between different terms, pairing slang words like “kicks” with “shoes” and “fixie” with “fixed-gear bike”; similarly abbreviations must be mapped so “ml” pairs up with “millilitre” and “HP” with “Hewlett-Packard”.
Symbols can prove a little tricker since they may act as more than mere synonyms and may change meaning depending on the word arrangement of the query. For example, the “-“ symbol could be used to denote both a minus (e.g., “sleeping bag for -10 deg.”) and a range (e.g., “sweaters $50-$100”). In these instances, not only does the meaning of the symbol change, but the symbol also acts as a filtering instruction.
Users often copy-paste search queries from various sources during activities like research and comparison shopping. Considering that many copy-pasted product titles include symbols (e.g., “Men’s Levi’s® 511™ Slim-Fit Stretch Jeans”), it’s important that search properly interpret these symbols when generating results — or risk giving users the perception that a product simply isn’t available if it doesn’t appear at or near the top of search results.
Our late 2019 search benchmark shows that 33% of sites do not support even the most basic symbol or abbreviation searches for units common to the site (e.g. “13 cubic feet fridge” vs “13 cu ft fridge”, “3 ounce” vs “3 oz”, “200 GB” vs “200 gigabyte”) – for this reason, we’ve even benchmarked slag and more complex symbols. That said the support for this support for the most basic symbol and abbreviation of units has doubled since 2017.
The Query Structure deals with how the user has put together their query, and consequently how it should be interpreted by the search engine. It’s about the syntax of the query and the context in which it was written. For instance, the user may apply various linguistic shortcuts in the form of #8 Slang, Abbreviations, and Symbols when they devise their search query.
A summary of the query structure can be found in the table below:
|3) Query Structure
How the query is constructed by the user and interpreted by the search engine
|#8. Slang, Abbreviation, and Symbol Search
“Sleeping bag -10 deg.”
|Searching for products using various linguistic shortcuts|
Ever since our first round of e-commerce search UX benchmarking back in 2014, we’ve observed surprisingly poor support at e-commerce sites for even these most common types of search queries that users are indeed observed to search by on e-commerce sites.
Let’s take another look at the graph presented earlier to see the level of support for each query type.
When e-commerce sites with millions of dollars in revenue show this low level of support for essential query types such as #2 Product Type, #6 Thematic and #8 Symbol searches, you know the current state of e-commerce search is still problematic. And since e-commerce search engines are nearly always reused across platforms (different interfaces accessing the same search engine), query support will be similarly poor on tablet and mobile sites/apps, too. What the exemplified version of this graph means for end-users is that:
The current overall lacking state of e-commerce search shouldn’t be understood as “users cannot use search at all on these sites”. However, it is a clear indication that e-commerce search isn’t nearly as easy to use as it should be and that users’ search success and search conversion rates can be improved dramatically on most sites – even when looking at these 60 major e-commerce sites.
The good news is that this also means plenty of opportunity to rise above the competition. Creating a (comparatively-speaking) superior search experience only requires proper support of 6-7 query types. In fact, supporting the right handful of the most essential query types is enough to create a decent search experience.
We recommend that you start out by making sure that your search engine supports these 4 essential query types: #1 Exact, #2 Product Type, #5 Feature, and #6 Thematic. Users can get by with basic e-commerce searches when these 4 query types are supported. Conversely, failing to support any of these core query types will result in a defective search experience.
To create a truly great search experience, all 8 of the query types must be supported. This is not done overnight and often requires more than “simply” investing in good search logic — detailed and structured product data is often just as important. The good news is that the investments can pay significant dividends as users begin finding (and thus are able to buy) the products they are looking for. Also, since the same search engine tends to be accessed by all platforms, any investments will typically pay off universally across those platforms — improving the search experience of your e-commerce desktop website and native mobile apps alike.
During our testing we observed how the users were greatly influenced by prior experience with the site. If they had previously had success searching for something on the site, they were much more likely to use search on that site, even if they generally preferred category navigation. And vice-versa: prior poor search experiences steered otherwise search-happy users towards category navigation.
Thus, not investing in good search usability can not only cost sales in the short- and mid-term, it can also set flawed user expectations for future use of your site. Expectations which can be difficult to shake off even if the search experience is eventually improved down the road.
We therefore urge e-commerce owners not to postpone investing in improvements to their e-commerce search experience, lest they be haunted by faulty user perceptions for years to come. Instead, take advantage of the dismal state of e-commerce search and turn it into a competitive advantage.
It’s time to improve the state of e-commerce search — and that starts by improving your search engine logic with support for these 8 query types.
This article presents the research findings from just 1 of the 580+ UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” on-site e-commerce search experience.
Authored by Jamie Appleseed on February 25, 2020
Join 30,000+ UX professionals and get a new UX article every second week.