What guidelines exist when working with autocomplete widgets? I'm hoping for general guidelines that apply across different application types: web, desktop, and mobile.

A response to a Search as you type thread included the following relevant items:

  • Never update the search input with one of the results unless the user requests it.
  • Provide keyboard and mouse access for selecting results.
  • Look-behind is a nice complement to look-ahead.

I've observed a few other practices:

  • Highlighting the searched-for term
  • Returning the count of matching items
  • Providing an action indicator upon selection (but not activation) of an autocomplete entry
  • Offering the originally typed text in the autocompletion list

In addition, the following questions may be asked when providing suggestions:

  • How many hints/suggestions should be provided?
  • How do you resolve those that should be displayed when many are available?
  • Should suggestions take into account likely spelling or typing errors?

Any responses discussing more complicated syntaxes like boolean expressions would also be helpful.

5 Answers 5


There are no general guidelines that work across all platforms and all applications, take for example Google web search and selecting a person from a list of coworkers - in both cases an auto-complete widget may be appropriate but every detail of the implementation will be different.

The only thing you can do is evaluate the specific needs of every application (not platform, who cares if the form you are filling is in a web browser or a dialog box) and have usability test to see what features you need (users misspell options often -> you need to take spelling error into account).

Let me quote from an old interview with Tim Lister (one of the authors of Peopleware):

Cramblitt: What do you think about the reliance on best practices?

Lister: I get chills when I hear that phrase. From my point of view there are some pretty good practices, but no best practices because that implies generic software development. All projects are related to the domain they’re in. A best practice for defibrillator software is not the best practice in another domain. I’d like people to think about patterns – abstracting their work and recognizing the patterns they’re in, good and bad, and making informed decisions to promote those patterns or replace them.

  • 2
    That's a rather semantic response. Perhaps the asker could have worded their question "Patterns for autocomplete widgets"? Would that have elicited a different response? The asker has already identified that there are patterns/practises/guidelines for this domain. He seems to simply want more.
    – cottsak
    Commented Nov 2, 2010 at 8:01
  • OP says he wants "general guidelines that apply across different application types: web, desktop, and mobile". I think that point here is that there are no such guidelines. The guidelines you use depend very heavily on the context. Commented Nov 13, 2011 at 10:01

If it's a website that has a lot of products in many categories, showing the category is a good way to help the user find what they are looking for.

Example: when a user is searching for: game of thr

Game of thrones in books

Game of thrones in DVDs

Game of thrones in eBooks

Game of thrones

Game of throubles

Game of three

and so on..

  • Not necessarily specific to websites, but still useful. Commented Apr 23, 2015 at 17:46

Google does some pretty extreme A/B testing, and auto-complete is a core product.

I think that's about as good as you will get when it comes to proven guidelines.


Implementing a some what generic autocomplete at the moment so some thinking/findings so far.

As I see it there are two types of autocomplete. On that is an actually a hidden dropdown and an other that is a text field. The dropdown autocomplete is used when you want to restrict the inputs but don't want a dropdown with hundreds of items. Used for example when selecting airports to fly from/to. The text field is used more for suggestions when searching.

In the first case I think you want to update the input. Since it has to be an valid input anyways. In this case it's important that it's clear what is your suggestion and what is the user input.

Restrict the number of shown results. The users focus is imputing text into the field. If they have to scan through a long list of options, you could as well use a dropdown. Not having to move ones eye focus and placing less burden on the users memory is probably a good thing as well.

Although I see one useful property of long lists. If I don't remember what I'm searching for. A long list will allow me to go through it and recognize(hopefully) what I'm looking for.

To choose what is shown in the list is probably on of the things that takes the most domain knowledge. Google seems to do it by search popularities, airlines by how big the airport is. T

As for look behind I'm a bit torn. It's easier to remember the first letter of a word than the third. So most of the time this probably what your users are doing. So matching anywhere in the string might give many unwanted results. Power users, who has learnt that 'ac' is faster than 'st' for 'stack' might have use for it. Matching against all words in sentences is probably also a good idea. As then you give more options for recognition.


This is a good article on patterns to use based on user research: https://baymard.com/blog/autocomplete-design

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 ...

During testing, autocomplete suggestions were found to directly alter how and what the test subjects searched for.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.