Search “Autocomplete Suggestions” (also known as “predictive search”) have become increasingly popular on e-commerce sites over the past five years. Our 2019 benchmark reveals that search autocomplete is now offered at 96% of major e-commerce sites, up from 72% in 2014, where we first started benchmarking e-commerce search implementations from the 60 largest online retailers.
Despite search autocomplete suggestions being common, our UX benchmark also reveals that 27% of sites have an autocomplete implementation that has several and severe usability issues, so it overall performs poorly with end-users.
During our usability studies on e-commerce search, we observed how poorly designed autocomplete user interfaces can confuse and distract users. Luckily, testing also identified 13 design patterns for autocomplete suggestions that ensure users a great and seamless autocomplete experience.
In this article, we’ll cover our large-scale Premium UX research on how autocomplete suggestions impact the user’s e-commerce search experience and examine each of the autocomplete 13 design patterns.
When autocomplete suggestions work well, we observe that they help the user articulate better search queries. It’s not only about speeding up the search process but also about guiding the user and lending them a helping hand in constructing their search query.
In fact, during our usability testing, autocomplete suggestions were often observed to slow down users in typing and selecting their search query. However, spending a few seconds extra to construct an accurate and detailed search query — through the help of the autocomplete — saves users several wasted minutes on the otherwise often overly broad search queries they tend to submit on sites that don’t have search autocomplete.
Furthermore, during our testing, autocomplete suggestions were found to directly alter how and what users search for. Users generally perceive the autocomplete suggestions to be “recommendations” by the site, and therefore show a bias towards selecting the autocomplete suggestions over using their own query. As the autocomplete directly manipulates what users will search for and how they search, it’s one of those features that can do more harm than good if not implemented properly.
If the autocomplete widget is designed in a slightly unconventional way, it runs the risk of distracting the user in their search and in a few cases even mislead them, as observed during testing. It’s therefore critical to follow a number of underlying design and interaction patterns to ensure that your autocomplete design aligns with user expectations.
In this article, we’ll discuss 13 autocomplete design patterns that our Premium UX research have verified to be critical to achieving a high-performing autocomplete design:
Note : while our testing also led to extensive findings on the needed autocomplete logic, this article focuses exclusively on the design of the autocomplete widget, as that’s technically far easier for most sites to change. If you have Baymard Premium, see the Autocomplete research topic for all research findings).
Sweetwater displays 20 autocomplete suggestions on desktop, including some redundancies (e.g., “drumsticks” and “drum sticks”) that can make it overwhelming for users to review and select a relevant suggestion.
At Musician’s Friend, a total of 15 autocomplete suggestions display, where 4 are visible and the rest flow behind the keyboard. The lengthy list can cause users a degree of choice paralysis.
Wayfair’s desktop site limits the number of autocomplete suggestions to 9, making for a compact autocomplete list that users can view at a glance, which fosters easier decision-making.
Amazon’s mobile site presents a manageable list of 6 autocomplete suggestions that also happen to fit within the default viewport. The short list can reduce the user’s cognitive load, speeding the search interaction overall.
Because the desktop autocomplete feature should expand to fit its options (and never use a scrollbar), the number of options should be limited so they don’t overflow the user’s viewport. Furthermore, having too many options was found to cause choice paralysis in users, so the list should be kept manageable. We observed this worked best at a maximum of 10 suggestions on desktop.
During our testing, whenever the autocomplete suggestions started to exceed around 10 items, the users would either ignore the suggestions altogether (at which point the suggestions become mere noise) or spend an inordinate amount of time reading them (effectively halting their search process).
A concise autocomplete list is best for mobile, too, since users are often shown a fraction of the total suggestions in the default viewport, with the rest flowing behind the keyboard (as seen in the Musician’s Friend example, above). Most users in testing who used autocomplete selected from among the first three suggestions.
Having more autocomplete suggestions visible at once, but fewer overall choices, can help mobile users with quicker decision-making and selection of autocomplete suggestions. Given the space constraints on mobile, it makes sense to provide fewer suggestions than on desktop. A target of 4–8 suggestions on mobile will work for most sites.
While Harman does offer autocomplete category scope suggestions (e.g., “Professional Headphones in Headphones”, “Kids’ Headphones in Wireless”, etc.), the font styling has no differentiation from the other query suggestions, making it difficult for users to distinguish the unscoped from the scoped suggestions.
All of Dell’s suggestion text has an identical font style which makes it harder for users to discern the scope text from query text (see the first 2 suggestions, “inspiron 3847” and “inspiron 3847 in Desktops”).
Hayneedle’s autocomplete styling includes a distinct font color for category scopes that provides visual contrast from their respective query suggestions (e.g., “Sofa & Loveseats in Furniture”). A horizontal line also separates scoped and unscoped suggestions. The styling helps users identify the scope suggestions while giving them control over the broadness of their query (restricting search to a category vs. conducting a search sitewide).
At Home Depot, autocomplete scope suggestions (e.g., “In Top Freezer Refrigerators”) are indented beneath the suggestion and italicized to distinguish them from the sitewide suggestions.
Styling helps provide subtle cues that orient users to the different types of suggestions and data shown in autocomplete. Any alternate or auxiliary information, such as scope suggestions (i.e., “search within [XY] category”) or the number of matches, should be given a unique style so the user can easily determine what is (and isn’t) part of the actual search query suggestion.
When the tested sites styled search scopes the same as the suggested terms, for example, the users would either mistake the scope for being just another term in the query or spend an inordinate amount of time deciphering the autocomplete suggestions. It’s not that they weren’t able to work out the differences if they set their mind to it, but few actually did – and of the few that did, it added needles mental overhead to what is supposed to be a quick and seamless process.
Distinct styles make both the suggested terms and the alternate data easier to scan because the user can visually distinguish the two. This allows the user to focus in on the part they are interested in without having to read the full suggestion and deconstruct its components simply to learn, for example, which scope a given suggestion will invoke. Common alternate styles include italic, font color and text indentation.
(For research findings on the importance of suggesting search scopes in the first place, see our article E-Commerce Sites Need Multiple of These 5 ‘Search Scope’ Features)
Restoration Hardware’s desktop autocomplete bolds the characters the user has already entered, leading to numerous repetitive highlights, which makes it difficult for users to easily pick out the suggestion that best matches their desired query.
At Macy’s, styling for the suggestion text matching the user query (“clean”) and the predictive text are identical, which provides no visual delineation. Without differentiated styling, users have to work harder to read each suggestion line by line, if they’re willing to invest the time. Styling the predictive portion of the suggestion with more emphasis would help users visually scan for only the missing words that would best complete their query.
At Amazon, the autocomplete suggestion text that is an exact match for the in progress query typing (“blue sum”) uses a regular font, while the predictive portion of the suggestion uses a bold style — drawing attention to the query possibilities rather than to known text that users have typed.
Grainger’s autocomplete uses bold styling to emphasize the predictive aspect of the query suggestion, helping users focus on the most relevant terms to complete their query.
Autocomplete typically offers suggestions that are a combination of a match to the query entry and a corresponding predictive suggestion. Styling the two aspects of the query suggestion uniquely can help users understand the distinction, while reducing visual burden by helping them gloss over repeat words — in effect, giving them less to read.
So rather than repetitively highlighting the characters the user has entered in each and every autocomplete suggestion, consider a style that specifically emphasizes the predictive portion to help users “fill in the blanks”, underscoring what’s different in each suggestion. After all, the user is already well aware of the characters they have entered themselves.
This furthermore helps highlight the differences between the autocomplete suggestions, making it easier to scan the differences in the list and thus easier for the user to compare them in an instant.
In an earlier Microsoft design, autocomplete is confined to a fixed-height interface that results in a scrollbar when the number of query suggestions exceeds the height of the interface. Inline scrolling is particularly difficult for users due to unintentional clicks, scroll hijacking, and obscured content.
At REI, all query suggestions are visible without scrolling. The interaction difficulties caused by scrollbars is eliminated, and users can focus on considering query suggestions, rather than struggling with an inline scrolling interface.
Having a separate scroll area within an already interactive widget like the autocomplete is a recipe for interaction disaster. It should be avoided in favor of simply having the widget expand to its natural size. Indeed, our research studies show that inline scroll areas often cause a wide range of interaction issues and should therefore generally be avoided.
Additionally, avoid requiring that users scroll the page to view all autocomplete suggestions since it limits their ability to easily get an overview of their choices. By keeping the list manageable (suggestion 1), most sites can often avoid scrollable areas.
Urban Outfitters’s autocomplete feature includes product suggestions and trending searches that visually overpower the actual autocomplete suggestions, which can distract users from starting their search.
Birch Lane leverages a simple autocomplete design that is fully dedicated to presenting autocomplete suggestions. Limiting or removing extra content and design elements helps users maintain focus on beginning product exploration.
Clearly separating the autocomplete suggestions is key to helping users to scan the list and tell the suggestions apart from one another. While it should be easy to keep the autocomplete suggestions apart, many designs are overly complex — going overboard with padding, separators, alternating row colors, and additional content (e.g., product suggestions, articles, etc.), to the point where it distracts from the actual query suggestions. Our large-scale usability testing found that users responded negatively to these distractions.
Desktop autocomplete was observed to succumb more often to a “piling on” of added elements within the autocomplete feature due to the additional screen space available. The goal is to lower the visual noise so the user can focus on the text of the autocomplete suggestions without distraction. Of course they should be able to tell the suggestions apart, so one or two subtle visual separators should be employed — just make sure to keep it simple and subdued.
To further help the user focus on the autocomplete suggestions and lower the visual noise from other elements on the page, consider visually bringing the autocomplete widget to the foreground by adding a border or shadow to it. This creates page depth and makes it easier for the user to focus on the suggestions.
Also, if the search field is very short because it needs to fit between other page elements, the autocomplete widget overlay should expand beyond the search field width to avoid needlessly short lines that wrap after just two or three words (as is the issue in Disney’s).
An earlier version of Disney mixes broad query suggestions and specific product suggestions (which leads to a product page) within autocomplete, making it difficult for users to discern between the two types of options. Adding labels to separate query suggestions from products would help users distinguish their choices.
Grainger’s autocomplete feature offers users several paths to results and organizes suggestions and corresponding labels by type — allowing users not only access to suggestions, but also providing direct access to specific products, categories, or the option to search by brand. The benefits of offering users more choice should be weighed against the potential drawback of appearing overly complex, so the site context should be considered carefully.
Even though autocomplete suggestions have become very common and most users at this point intuitively know how to use the feature, if your audience includes less experienced web users it can be a good idea to include labels and instructions informing the user about how to interact with the autocomplete suggestions.
Add clarifying labels when displaying a mix of autocomplete suggestion types to differentiate suggested queries from category scopes and autocomplete product suggestions. For example, use headings like “Search Suggestions”, “Categories”, “Product Suggestions”, etc. Adding labels can help orient users to the different suggestion types, as opposed to mixing them all into a single unorganized list that can be difficult to decipher.
While the use of labels could also be somewhat relevant for mobile, the simplified autocomplete designs observed during mobile testing that often only show the query suggestions, makes labels unnecessary.
While HP does invoke the hand cursor on hover, the active autocomplete suggestion is otherwise unhighlighted. Using only the mouse hover point to show the active suggestion makes users connect the hand cursor to the suggestion without visual cues and puts needless burden on users (especially when the cursor and suggestion are far apart). Background shading on hover of each suggestion can help make the potential selection clear.
At Etsy, the active autocomplete suggestion uses background shading and the hand cursor is invoked, making a clear visual connection between the suggestion and the mouse hover point. The shading eliminates any doubt about where a user currently is, whether they are hovering with their mouse or using keyboard arrows to navigate the suggestions.
Clearly indicating the active suggestion is crucial — it provides the user with visual feedback and and lets them know what is active, whether they’re hovering over suggestions with a mouse or using the keyboard to navigate the list.
Incidentally, over the years operating systems and major sites such as Google have trained users that autocomplete suggestions can be navigated, modified, and submitted with keyboard inputs. It’s therefore important to support keyboard navigation — and do it in a way that aligns with user expectations.
More specifically, this means the up and down arrows should navigate the autocomplete suggestion while the return key should submit the currently focused suggestion. Ideally, the list also “loops” back to the beginning when the user reaches the end of the suggestions.
A detail that proved very important during our testing was having the suggestion copied to the search field when it received keyboard focus. This not only helped the less-experienced users more easily grasp the autocomplete concept but also allowed the users to “continue” the suggested query, adding in further details before submitting it (e.g., adding a query qualifier such as “lenses” to a suggestion for “Nikon D7100”).
Note that, if the user navigates back to the search field using the arrow keys, the search text should revert back to the original text and scope.
Also, applying background shading for emphasis on mouse hover visually clarifies the active suggestion.
Finally, consider invoking the “hand” cursor on mouse hover of the autocomplete suggestions to make it 100% obvious to the user that these are links that will perform a search if clicked.
While Banana Republic does include a border surrounding the autocomplete feature, the background is not darkened. Without background dimming, the rotating homepage carousel, neighboring ads, and other page content have equal prominence to autocomplete, which could distract users attempting to review autocomplete suggestions.
When autocomplete is active at Target’s desktop site, the page background is dimmed, making it much easier to focus on the autocomplete feature. Highlighting the autocomplete feature elevates its prominence, which helps users focus on their query and move more quickly into product exploration.
There are many components to a web page that vie for the user’s attention at all times. Darkening the page background while autocomplete is active gives it stronger emphasis, minimizing elements (e.g., ads, carousels, and other page content) that could distract users from considering autocomplete suggestions. This brings the attention and focus to the autocomplete feature.
Also, consider adding a subtle border or shadow to the autocomplete overlay to create even more depth and make it easy for the user to focus on the autocomplete suggestion options.
A user at Sephora had to contend with an ad, a sticky “Add to Basket” button, and live chat icons while autocomplete was active. All of these elements left space to display only 2 partially obscured suggestions. She continued typing her query in full, leaving autocomplete unused. When other elements crowd autocomplete, users can’t easily read suggestions, causing some to skip use of autocomplete suggestions altogether.
Amazon’s autocomplete feature doesn’t have to compete with other elements for attention. Autocomplete suggestions have also been optimized to fit within the viewport, giving users a good overview of suggestion options.
Elements adjacent to or which encroach into the autocomplete feature can compete for attention, distracting users from devising their queries.
Bear in mind that mobile autocomplete’s visible suggestions are, minimally, often sandwiched between the search field at the top and the mobile keyboard below. When other UI elements (e.g., sticky headers, main nav, buttons, ads, etc.) display in addition to the autocomplete feature, it leaves an even smaller fraction of the screen available for the display of suggestions.
Minimizing distracting elements can help users focus on autocomplete and move more smoothly into product exploration. (Also see Mobile E-Commerce UX: Deemphasize ‘Install App Ads or Avoid Them Entirely and These Three — Popular — Approaches to Implementing ‘Live Chat’ are Often Highly Disruptive for Users.)
While the same general principle applies to desktop, competition from external elements wasn’t as heavily observed in our testing, likely due to greater available space for other design elements.
“I’m not sure I know what’s going on here…” A user at Sephora attempted to find “lipstick” and was presented with autocomplete suggestions in a small font size with limited line spacing. She inadvertently selected an unintended suggestion. Presenting autocomplete suggestions with an insufficient font size causes users to have greater difficulty reading suggestions and can contribute to inadvertent selections.
At B&H Photo, the autocomplete feature uses an appropriately large font size, hit area, and spacing, as well as dividing lines to separate suggestions. Sufficient font sizes and spacing help users more easily read and select autocomplete suggestions.
If a user is unable to read the autocomplete suggestions, it becomes very difficult for them to be able to select the option that is relevant to them.
During our mobile testing, autocomplete suggestions styled in small font sizes made it difficult for users to view and select a suggestion. Further, when inadequate spacing and small font sizes were combined, it contributed to mistaps that left some users puzzled upon arrival to unexpected results pages.
To resolve readability issues within autocomplete, use legible font sizing, ensure suitable spacing between tappable elements, and provide hit areas of an appropriate size. Finally, presenting autocomplete suggestions in lower case or title case (or “headline-style”) makes for easier readability than all uppercase text.
The same principles of designing with a readable font size and sufficient spacing for autocomplete apply for desktop, but issues were less commonly observed in testing due to space availability and the ability to highlight a user’s current selection on hover.
Some of Sephora’s autocomplete suggestions are truncated with an ellipsis when the suggestion text doesn’t fit the allotted design space. The truncation issue here is primarily a result of displaying autocomplete product suggestions with long titles. Word wrapping, not to mention including broad keyword suggestions that are typically shorter in length (not just product suggestions), would make the entire suggestion visible and allow users to make informed suggestion choices.
At B&H Photo, long autocomplete suggestions are wrapped, allowing users to see the full suggestion and make an informed choice when making a selection.
When autocomplete suggestions are truncated on mobile (e.g., with an ellipsis), users have no way of viewing the entire suggestion.
Truncating suggestions diminishes the guidance that suggestions are intended to offer. Instead of text truncation, leverage text wrapping — as seen in the B&H Photo example — for lengthy autocomplete suggestions to give users the full context of potential query choices.
You can see more of our recommendations on truncation in our article 6 Guidelines for Truncation Design.
Hayneedle’s autocomplete includes 3 suggestions in the default viewport. Because the last visible suggestion (“Beds in Furniture”) is fully shown, the possibility of scrolling isn’t obvious. Users may not scroll if they perceive the last suggestion to be the end of their choices.
At Kohl’s, the last autocomplete suggestion in the list is partially visible, providing users with a subtle visual cue to indicate that scrolling is possible and that there are more autocomplete suggestions to explore below.
When scrolling to view all autocomplete suggestions on mobile is necessary, use design elements and styling to give users indications that autocomplete is scrollable.
For example, partially obscuring the last suggestion can signal that there are more suggestions that currently can’t be seen.
Additionally, while last-suggestion truncation can be difficult to consistently achieve due to the variability of mobile devices, fonts, suggestion wrapping, etc., it can be something to strive for when scrolling is necessary (with the design and testing focused on the most popular devices identified in analytics).
Note that while users in mobile testing did sometimes scroll the autocomplete suggestions, it was more common that users chose from the first several visible suggestions, as opposed to scrolling down the list. Ideally, scrolling should be minimized on mobile, but is sometimes unavoidable. Offering users subtle scroll indications can raise awareness that there’s more to see.
Autocomplete disappears when all characters are deleted from Amazon’s search field. Also, the submit button’s background color distinguishes itself from the adjacent “X” icon (which clears the query and closes autocomplete), helping users discern the two unique functions.
Some users will change their product-exploration strategy midquery, wishing to cancel out of search and get autocomplete suggestions out of their way.
When users fully delete query terms, autocomplete should disappear. Providing a sufficiently sized “clear” (“X”) icon lets users easily delete full queries and simultaneously closes autocomplete with a single tap.
However, some users will instead manually delete a query (e.g., using the delete key), so it’s important to hide autocomplete in the event users take the manual deletion route, as well.
On desktop, it’s easier for users to highlight several characters or an entire query using the mouse (drag select) or the keyboard (shift + arrow keys) in order to select and delete desired query text. So, while including an “X” icon to remove queries can be helpful for users who notice it, it wasn’t observed to be as critical for desktop.
Amazon’s desktop and mobile autocomplete features adeptly tackle the autocomplete recommendations. For example, in the desktop example, scrolling is avoided, category scope suggestions are styled differently (“in Electronics”), the active suggestion is highlighted and the hand cursor is invoked, the autocomplete feature is given prominence by dimming the page background, and suggestions are kept manageable (first image). On mobile, also notice how the number of suggestions are kept manageable and are fewer in comparison to desktop, allowing all suggestions to fit within the default viewport (second image). Further, in both the desktop and mobile example, the differences in the suggestions are highlighted.
Clearly, there’s quite a list of details to get right when it comes to designing the autocomplete feature for both desktop and mobile contexts. This is quite natural, considering autocompletes are interactive and highly transient in nature, resulting in a fairly advanced user interaction. Especially considering the autocomplete aren’t the actual focus of the page but is rather there to offer the user a little assistance in their search process.
Designers do have some leeway when it comes to the aesthetics of the autocomplete feature, but because autocomplete functionality already confronts users with what can be quite complex interactions, it’s particularly important to adhere to best practices and emerging UX patterns, as even minor deviations from these standards may throw users off course. As it happens at 27% of e-commerce sites.
To recap, in both desktop and mobile contexts, autocomplete designs should:
Tip: you can also browse 153 different autocomplete designs from major e-commerce sites in our Page Design tool.
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.
Join 25,000+ readers and get Baymard’s research articles by RSS feed or
Topics include user experience, web design, and e-commerce
Articles are always delivered ad-free and in their full length
1-click unsubscribe at any time
We first published an article on the topic of “Autocomplete Suggestions” in July 2014, this article have been rewritten entirely based on our newest usability test findings.
© 2021 Baymard Institute US: +1 (315) 216-7151 EU: +45 3696 9567 info@baymard.com
Darwin FoyeJuly 2, 2014
Great article. It’s interesting to note that the Williams-Sonoma website adheres to guideline #4 (Support Keyboard Navigation), while violating guideline #5 (Match User’s Hover Expectations).
Jamie, Baymard InstituteJuly 2, 2014
Thanks Darwin Foye, and well-spotted: Williams-Sonoma copy the hovered text into the search field when they only should be doing it during keyboard interaction. They do seem to get the rest of the hover and keyboard interactions right though.
PauloSeptember 3, 2014
If I may suggest you something, please add some zoom/lightbox feature to your article images. It’s annoying to have them open separately and then having to hit browser’s back button. Other than that, great article, as always!
Christian, Baymard InstituteSeptember 5, 2014
Hi Paulo, thanks for the suggestion. This one have been on the todo list for far too long as we had hoped to integrate it with a larger article layout re-design. Hopefully we’ll get the time to deploy a solution soon.
LRJuly 31, 2015
What about suggestions of results with images? and presenting navigation options to results main categories?
MaxAugust 24, 2015
I’d be interested to know if the “product suggestions” with images route is worth taking too.
Evan JerkunicaFebruary 29, 2016
Thank you very much – this is extremely useful and well thought out.
Fredrik CarlbomMarch 31, 2016
Hello, interesting read.
I’m trying to do highlighting of results and we do not only have a “Starts with”-matching criteria, we show search results where we allow the search term to appear anywhere. Have you done any testing with match anywhere?
In my mind “Highlight the Differences” does not apply when not only using “Starts with” matching and it is more relevant to highlight where the search term appears.
ArturoFebruary 25, 2017
I would consider this also applicable to autocomplete “results”.
guestUserOctober 28, 2017
Thanks for the excellent suggestions. Pun?
JeroenNovember 26, 2019
Great article!
Unfortunately number 12 can be very hard to achieve since browsers often give limited to no information about soft keyboards and often don’t change the viewport size to match the remaining space above the keyboard.
I also expected a mention of the little arrows that allow you to use and expand upon a suggestion, a feature I always greatly appreciate and which speeds up my searching.
Although I do wonder how many users actually understand what they are for.
Christian, Baymard InstituteNovember 28, 2019
yeah with current browser and device info the scroll bar invoking will never be perfect and 100% accurate. But you do know some things:
1. if the form field has “keyboard focus” then the touch keyboard is generally visible
2. the touch keyboard will take up at least 30% of the viewport on most normal smartphone devices. so you have that (100%-30%=70%) as your lower boundary for when you at least can safely show a scroll bar. (recommended to make a more accurate measurement based on what devices are popular on your specific site),.
Andriy KornilovNovember 26, 2019
correct “galaxy” example in #10 makes it incorrect according to the #3
Christian, Baymard InstituteNovember 28, 2019
Hi Andriy, true.. All of the positive images are only meant to illustrate a positive example of the topic/section they are directly related to. So the positive image seen for #10 may break several of the other recommendations elsewhere in this article.. All Baymard articles are like that and the reasons for this is that it’s simply impossible to find a decent amount of overall perfect examples, as only very very few sites get everything right (so those examples would have to be repeated 5-10 times in the same article if we wanted “perfect overall” examples)