8 Design Patterns for Autocomplete Suggestions

This is the second in a series of articles on e-commerce search that draw on findings from our recent search usability report and benchmark.

Autocomplete widgets have become somewhat of a web convention for e-commerce search, with 82% of the top grossing e-commerce sites offering up autocomplete suggestions to their users as they begin typing their search query. And Google has had autocomplete suggestions on by default since 2008.

Clearly, autocomplete suggestions are common nowadays – but what should they look like and how should they work? During our recent usability study on e-commerce search we observed how poorly designed autocomplete suggestions would confuse and distract the test subjects. Luckily, testing also identified 8 design patterns for autocomplete suggestions that ensured users a great and seamless autocomplete experience.

In this article we’ll go over how autocomplete suggestions impact the user’s e-commerce search experience and examine each of the 8 design patterns.

Autocomplete Suggestions: A Helping Hand

When autocomplete suggestions work well they help the user articulate better search queries. It’s not about speeding up the search process but rather about guiding the user and lending them a helping hand in constructing their search query.

In fact, during usability testing autocomplete suggestions were often observed to slow down the search process ever so slightly (although users didn’t experience it as being slowed down). An investment that pays off if it increases the quality of the user’s search query and thus the relevance of the results.

Amazon’s autocomplete design follows nearly all of the 8 design patterns. Notice how scrollbars are avoided, suggestions are kept manageable, scope suggestions are styled differently (“.. in Clothing & Accessories”), there’s minimal visual noise, and there’s even widget labels (“Search suggestions”).

During testing, autocomplete suggestions were found to directly alter how and what the test subjects searched for. A lot of the test subjects perceived the autocomplete suggestions to be “recommendations” by the site, and therefore showed a bias towards selecting them over using their own query. Autocomplete suggestions furthermore act as reassurance as the user types and sees matches related to their query, often prompting them to add further details to the query as long as relevant autocomplete suggestions keep appearing.

However, when the autocomplete widget is designed in an 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. It’s one of the few instances where simply copying the giants may actually be a decent strategy because users largely form their autocomplete design and interaction expectations on those sites.

In this article, we’ll go over 8 such design patterns. It’s worth mentioning that these are structural design principles and interaction patterns, and therefore less about the aesthetics of the autocomplete suggestions. Indeed, our findings suggests that sites have pretty much free reign over the visual appearance of their autocomplete widget as long as it doesn’t violate these 8 design patterns:

  1. Style Auxiliary Data Differently
  2. Avoid Scrollbars & Keep the List Manageable
  3. Highlight the Differences
  4. Support Keyboard Navigation
  5. Match User’s Hover Expectations
  6. Show Search History
  7. Reduce Visual Noise
  8. Consider Including Labels & Instructions

Note: This article is about autocomplete “suggestions” – a list of different search query recommendations that take the user to the normal search results page. These should not be confused with autocomplete “results” which are specific product suggestions that lead the user directly to a product page.

1) Style Auxiliary Data Differently

Any auxiliary data in the suggestion – such as category scopes or number of matches – should be styled differently from the actual suggested search terms. Otherwise, the user won’t be able to tell at a glance what is (and isn’t) part of the suggested search terms.

When the tested sites styled e.g. search scopes the same as the suggested terms, the test subjects 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 auxiliary 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 e.g. which scope a given suggestion will invoke. Common alternate styles include italic, font color and text indentation.

2) Avoid Scrollbars & Keep the List Manageable

Having a separate scroll area within an already interactive widget is a recipe for interaction disaster, and 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.)

Furthermore, the list of autocomplete suggestions should be kept to a maximum of around 10 items to avoid inducing choice paralysis. During testing, whenever the autocomplete results exceeded 10 items, the test subjects would either ignore the results altogether (at which point the suggestions become mere noise) or spend an inordinate amount of time reading them (effectively halting their search process).

The point of autocomplete suggestions is to assist the user throughout their search process, not distract them. Therefore the autocomplete query suggestions should be kept simple (i.e. no scrollbars) and manageable (i.e. max 10 items).

3) Highlight the Differences

It’s a good idea to style the entered and suggested terms differently so the user can easily tell what’s suggested. Most sites do this, which is great. However, most of those sites highlight the terms the user has already entered themselves rather than highlighting the new suggested terms that would be added to the entered query.

Since the user is already well aware of the term(s) they have entered themselves, it makes more sense to highlight the additions in the suggested queries rather than repetitively highlighting the same term in each and every query. 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.

4) Support Keyboard Navigation

While some of the test subjects, particularly those aged 50+, would use the mouse to select autocomplete suggestions, most subjects navigated the suggestions using the keyboard arrow keys.

Northern Tool + Equipment supports keyboard navigation of their autocomplete suggestions and copies the text of the currently focused suggestion to the search field, enabling the user to easily navigate and manipulate the autocomplete suggestions.

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 testing was having the suggestion copied to the search field when it received keyboard focus. This not only helped the less experienced test subjects more easily grasp the autocomplete concept but also allowed the subjects 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.)

5) Match User’s Hover Expectations

Just like keyboard navigation should be supported, mouse interaction should be supported too. Especially the less experienced test subjects would use their mouse to select autocomplete suggestions.

It’s important that the hovered autocomplete suggestion is highlighted and invokes the “hand” cursor, to make it 100% obvious to the user that these are indeed clickable links and to underscore which suggestion is about to be submitted.

However, contrary to the keyboard navigation behavior, the “focused” item should not be copied to the search field when hovered by mouse. During our usability studies we time and again observe interaction issues related to “hover selection” and the autocomplete suggestions are no exception. Users generally don’t expect hover to manipulate data (only toggle its visibility), and indeed it would be alarming if it did, as the user would suddenly have to be very careful of how they moved their mouse around the screen. Hover should therefore be treated as a non-committing action, as opposed to mouse clicks and keyboard input where the objective is to manipulate data.

6) Show Search History

Just like regular links have a “visited” state, so can autocomplete suggestions. The visited state adds an entire dimension to your site search: history. By tapping into the CSS :visited selector a site can offer its users helpful hints about pages they’ve previously visited (and by virtue therefore also hints at pages they haven’t yet tried).

Knowing which autocomplete suggestions they’ve already tried may seem like a scarce scenario unless the same users search your site on a daily basis. In other words, it may seem only relevant to the very largest of e-commerce sites and web search engines, like Amazon and Google. However, that is not the case.

During testing the subjects would frequently iterate upon the same query a number of times, trying out different variations and terms within the same general theme. It’s therefore not uncommon for users to be presented with the same autocomplete suggestions a number of times within a very short timeframe and in these scenarios it will be immensely helpful to the user to know which autocomplete suggestions they have and haven’t tried.

7) Reduce Visual Noise

Clearly separating the autocomplete suggestions is key to enabling users to scan the list and tell the suggestions apart from one another. However, the test subjects also responded negatively to the opposite: autocomplete suggestions that combined generous padding, separators, alternating row colors, etc., would distract the subjects from the suggested query itself.

Toys’R’Us adds a healthy amount of padding between the autocomplete suggestions to clearly separate them but otherwise the widget is kept clean and simple, allowing the user to focus on the actual suggested query terms. A shadow is furthermore added to the autocomplete widget to pull this element to the “foreground” of the page.

It’s therefore important not to go overboard with the visual separators. 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 results.

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). (Note: we’ll be covering search field size in an upcoming article in this series.)

8) Consider Including Labels & Instructions

While autocomplete suggestions have become very common and most users at this point intuitively know how to use them, 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.

Amazon have a “Search suggestions” label in the top right corner of the autocomplete widget to help novice users properly understand and conceptualize the widget and its options.

For example, you may consider adding instructions such as “Hit enter to search” to the field or widget, letting the user know that they can submit their query or the currently focused suggestion by simply hitting the return key (see prior Google example). Similarly, clarifying labels such as “Search suggestions” can help novice users understand what they are actually seeing – or at the very least reaffirm that their original interpretation of the suggestions was indeed correct.

Make it Seamless

Autocomplete suggestions are interactive and highly transient in nature, resulting in a fairly advanced user interaction considering that they aren’t the focus of the page but rather there to offer the user a little assistance in their search process. The autocomplete widget must therefore be kept simple and “stick to the standards” to make the user experience as self-evident and seamless as possible.

That’s exactly what these 8 autocomplete design patterns ensure – that users can interact with the autocomplete suggestions with minimal effort. While some of these design patterns may seem like minor details, they were all observed to generally improve the usability of the autocomplete widget during our e-commerce search usability study, and we therefore recommend that you adhere to at least 6 out of the 8 patterns:

  1. Style Auxiliary Data Differently
  2. Avoid Scrollbars & Keep the List Manageable
  3. Highlight the Differences
  4. Support Keyboard Navigation
  5. Match User’s Hover Expectations
  6. Show Search History
  7. Reduce Visual Noise
  8. Consider Including Labels & Instructions

Finally, notice how these patterns don’t limit the aesthetics of the autocomplete widget much. It should therefore be entirely possible to embed these “best practice” autocomplete usage patterns even in fairly unique site designs.

Tip: you can browse 41 autocomplete designs from major e-commerce sites in the Search Usability Benchmark database.

This article presents the research findings from just 1 of the 710+ UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” on-site e-commerce search experience.

Post a comment or Share:

User experience research, delivered twice a month

Join 20,000+ readers and get Baymard’s research articles by RSS feed or e-mail:

Due to spam, you need JavaScript to do that.

(1-click unsubscribe at any time)

Article series

  1. Deconstructing E-Commerce Search: The 12 Query Types
  2. 8 Design Patterns for Autocomplete Suggestions
  3. E-Commerce Sites Should Include Contextual Search Snippets (96% Get it Wrong)
  4. E-Commerce Search Field Design and Its Implications
  5. E-Commerce Sites Need Multiple of These 5 ‘Search Scope’ Features
  6. Faceted Sorting - A New Way of Sorting Search Results

Related Articles

See all 11 ‘On-Site Search’ articles

More E-Commerce Research

Free Research Content:

Products & Services:

Comments (10 so far)

Darwin Foye July 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).

Due to spam, you need JavaScript to do that.

Jamie, Baymard Institute July 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.

Due to spam, you need JavaScript to do that.

Paulo September 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!

Due to spam, you need JavaScript to do that.

Christian, Baymard Institute September 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.

Due to spam, you need JavaScript to do that.

LR July 31, 2015

What about suggestions of results with images? and presenting navigation options to results main categories?

Due to spam, you need JavaScript to do that.

Max August 24, 2015

I’d be interested to know if the “product suggestions” with images route is worth taking too.

Due to spam, you need JavaScript to do that.

Evan Jerkunica February 29, 2016

Thank you very much – this is extremely useful and well thought out.

Due to spam, you need JavaScript to do that.

Fredrik Carlbom March 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.

Due to spam, you need JavaScript to do that.

Arturo February 25, 2017

I would consider this also applicable to autocomplete “results”.

Due to spam, you need JavaScript to do that.

guestUser October 28, 2017

Thanks for the excellent suggestions. Pun?

Due to spam, you need JavaScript to do that.

Post a comment!

Due to spam, you need JavaScript to do that.