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).
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.
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)
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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 e-mail:
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
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).
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.
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!
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.
What about suggestions of results with images? and presenting navigation options to results main categories?
I’d be interested to know if the “product suggestions” with images route is worth taking too.
Thank you very much – this is extremely useful and well thought out.
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.
I would consider this also applicable to autocomplete “results”.
Thanks for the excellent suggestions. Pun?
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.
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),.
correct “galaxy” example in #10 makes it incorrect according to the #3
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)